这个Awesome Software Architecture存储库来分享一组有价值和鼓舞人心的架构文章链接,点击标题。
- 软件架构
- Actor 模型架构
- 算法
- 人工智能
- 清洁架构
- 洋葱架构
- 六边形架构
- 垂直切片架构
- 事件驱动架构
- 面向服务架构
- 领域驱动设计
- 数据驱动设计
- 控制查询规则
- 微服务
- 模块化整体
- 建筑设计原则
- 设计模式
- 云设计模式
- 云最佳实践
- 云原生
- 平台即服务
- 基础设施即服务
- DevOps
- 反向代理 - 负载平衡
- 服务发现与注册
- 服务网格
- 面向对象设计
- 系统设计
- 扩展
- 背压
- 清洁代码
- 抽象
- 设计最佳实践
- 反模式
- 最终一致性
- 消息传递
- 分布式事务
- 分布式锁定
- 最终一致性
- RESTful API 设计
- rpc
- 缓存
- 函数式编程
- 并发
- 分片
- 重构
- 数据库
- 关系数据库
- 微软 Azure 云
- 造型
- 开源
- 代码审查
- 面试
- 架构决策记录 (ADR)
- 微前端
软件架构
- 软件架构:软件架构是指软件系统的基本结构以及创建此类结构和系统的学科。
- Actor 模型是一种编程范式,其中的基本执行单元是 Actor。在 Actor 模型中,Actor 通过使用消息来表达对系统或给定系统内其他 Actor 的操作。
清洁架构
- 清洁架构:清洁架构 (Clean Architecture) 是 Robert C. Martin(鲍勃大叔)提出的系统架构指南,源自六边形架构、洋葱架构等许多架构指南...
洋葱架构
- 洋葱架构:洋葱架构由 Jeffrey Palermo 提出,它是一种分层架构,我们可以将这些层视为同心圆。
- 六边形架构:六边形架构或端口和适配器架构由 Alistair Cockburn 提出,它是一种架构模式,允许用户或外部系统的输入通过适配器从端口到达应用程序,并允许输出从应用程序通过端口发送到适配器。
- 垂直切片架构:垂直切片架构是一种通过围绕功能或分离应用程序来帮助我们构建可维护的应用程序的技术vertical slices。
- 事件驱动架构:事件驱动架构是一种软件设计模式,其中解耦的应用程序可以通过事件代理异步发布和订阅事件。
- 面向服务架构:面向服务架构 (SOA) 是一种软件架构设计模式,其中应用程序组件使用网络通信协议向其他组件提供服务。SOA 旨在实现软件组件之间的松散耦合,允许轻松替换或更新它们,而不会影响系统的其余部分。
- 领域驱动设计:领域驱动设计的关键概念和原则,强调围绕对业务领域的共享理解和使用通用语言构建软件系统的重要性。
- 值对象:领域驱动设计中的值对象的概念,它们是表示概念或测量的不可变对象,并且以其值而不是其身份为特征。
- 聚合:领域驱动设计中的聚合概念,它是一种将对象分组在一起以形成可作为单个实体处理逻辑单元的方式。
- 贫血领域模型:领域驱动设计中的贫血领域模型反模式,指的是领域对象包含很少或不包含行为,业务逻辑在单独的服务中实现的模型。
- 富领域模型:领域驱动设计中的富领域模型模式,主张将行为和业务逻辑放置在领域对象本身中,而不是单独的服务中。
- 领域模型:领域驱动设计中的领域模型概念,它是构成业务领域的核心概念、实体和关系的表示。
- 领域服务:领域驱动设计中的领域服务概念,它是一个无状态的、执行业务任务的事务操作,不与任何特定实体关联。
- 应用服务:领域驱动设计中的应用服务概念,负责协调多个领域服务的执行,以实现更高层次的业务目标。
- 领域事件:领域驱动设计中的领域事件概念,它们是表示业务领域内重要事件的消息,可用于触发下游流程或其他系统的更新。
- 整合活动:领域驱动设计中的集成事件概念,它是表示外部系统上下文中重要事件的消息,可用于触发下游流程或本地系统的更新。
- 有界上下文:领域驱动设计中的有界上下文概念,是一种将大型复杂的业务领域划分为由通用语言、上下文和边界集定义的更小、更易于管理的部分的方法。
- 基础设施:领域驱动设计中的基础设施概念,包括支持应用程序运行的所有组件和系统,例如数据库、消息代理和第三方服务。
- 战术设计模式:领域驱动设计中的战术设计模式,是构建领域模型、服务和存储库时出现的常见问题的反复解决方案。
- 战略设计模式:领域驱动设计中的战略设计模式,是指导大型复杂软件系统整体架构和组织的高级原则和模式。
- 映射:领域驱动设计中的映射概念,即用于在领域模型和系统其他部分(例如数据库或用户界面)之间转换数据的机制。
- 领域原语:领域驱动设计中的领域原语概念,它们是表示领域中的基本概念(例如日期、时间和数量)的简单、不可变的值类型。
- 枚举:领域驱动设计中的枚举概念,它是一种特殊类型的领域原语,代表一组离散的值。
- 异常和验证:领域驱动设计中的异常处理和验证的概念,这是确保应用程序的正确性和健壮性的重要机制。
- 数据驱动设计:数据驱动设计是一种软件开发方法,强调使用数据和分析来指导设计决策。它涉及收集、分析和使用数据来创建和改进软件产品、服务和体验。这种方法依靠经验证据来指导设计选择,并且需要强大的数据基础架构和分析能力。数据驱动设计可以帮助组织根据实际数据做出明智的决策,从而创建更有效、更高效、更用户友好的产品和服务。它还可以提高客户参与度、增加收入和提高用户满意度。
- 控制查询规则:CQRS(命令查询职责分离)是一种设计模式,它将系统中的命令执行和数据查询问题分开。CQRS 背后的基本思想是将应用程序模型拆分为两个独立的模型:一个用于读取数据,另一个用于写入数据。这样可以针对特定目的对这两个模型进行优化,并提供更好的可扩展性、性能和可维护性等优势。CQRS 模式通常与事件源结合使用,事件源是一种将应用程序状态的所有更改捕获为事件序列的技术。CQRS 和事件源相结合可以提供一种构建高度可扩展和容错系统的强大方法。
微服务简单介绍微服务的概念,包括其优点和缺点,以及微服务架构的常见特征。
- 通信:概述微服务架构中可以使用的不同通信模式和协议,例如同步与异步通信、REST 与基于消息的通信以及服务总线的使用。
- 复合用户界面:讨论复合 UI 模式,该模式涉及将多个微服务组合成一个用户界面,以及实现它的不同方法,例如服务器端组合与客户端组合。
- 服务边界:探索如何在微服务架构中定义和强制执行服务边界,包括识别服务边界的策略和实现它们的技术,例如领域驱动设计和有界上下文。
- 测试:微服务测试指南,包括测试单个服务和测试服务间交互的策略,以及测试微服务的工具和框架。
- API 网关:介绍 API 网关的概念,它作为客户端访问多个微服务的单一入口点,以及使用 API 网关的优点和缺点。
- API 网关-Ambassador:使用 Ambassador 开源项目实现 API 网关的具体实现,包括其功能概述以及如何配置和部署它。
- API 网关-Kong:使用 Kong 开源项目实现 API 网关的具体实现,包括其功能概述以及如何配置和部署它。
- API 网关-Ocelot:使用Ocelot开源项目实现API网关的具体实现,包括功能概述以及如何配置和部署它。
- 可观察性:探索微服务架构中的可观察性概念,涉及监控和调试分布式系统的能力,以及实现可观察性的不同技术和工具,例如日志记录、跟踪、健康检查和监控。
- 可观察性 - 分布式跟踪:深入研究如何使用分布式跟踪作为实现微服务架构可观察性的工具,包括分布式跟踪的工作原理概述、常见的跟踪框架以及如何对微服务进行跟踪。
- 可观察性 - 监控:概述微服务架构中可以使用的不同类型的监控,例如系统监控、应用程序监控和业务监控,以及用于监控微服务的不同工具和方法。
- 可观察性 - 诊断:概述用于诊断和调试微服务架构中问题的不同技术和工具,包括日志分析。
- 可观察性 - 日志记录:日志记录是微服务架构中可观察性的一个重要方面。本主题介绍用于监控和故障排除分布式系统的不同日志记录框架和策略。
- 可观察性-CorrelationId:关联 ID 是一种用于跟踪跨多个微服务的请求的技术。本主题介绍什么是关联 ID 以及如何在分布式系统中实现它。
- 可观察性 - 工具 - EFK:EFK 堆栈(Elasticsearch、Fluentd 和 Kibana)是一种流行的日志记录和可观察性解决方案。本主题介绍 EFK 的基础知识、其工作原理以及如何在微服务架构中设置它。
- 可观察性 - 工具 - ELK:ELK 堆栈(Elasticsearch、Logstash 和 Kibana)是另一种流行的日志记录和可观察性解决方案。本主题介绍 ELK 的基础知识、其工作原理以及如何在微服务架构中设置它。
- 可观察性 - 工具 - Fluent Bit:Fluent Bit 是一款轻量级且高效的日志处理器和转发器。本主题介绍 Fluent Bit 的基础知识、其工作原理以及如何在微服务架构中设置它。
- 可观察性 - 工具 - FluentD:Fluentd 是一个开源日志收集器和聚合器。本主题介绍 Fluentd 的基础知识、其工作原理以及如何在微服务架构中设置它。
- 可观察性 - 工具 - Loki:Loki 是一个可水平扩展、高可用性的日志聚合系统。本主题介绍 Loki 的基础知识、其工作原理以及如何在微服务架构中设置它。
- 弹性:弹性是指系统从故障中恢复并继续运行的能力。本主题介绍了用于构建容错微服务的不同弹性模式和策略。
- 弹性 - 幂等性:幂等性是一种用于确保操作可以安全重试而不会导致意外影响的技术。本主题介绍什么是幂等性以及如何在微服务架构中实现它。
- 弹性 - 高可用性:高可用性是系统的一种属性,可确保系统在出现硬件或软件故障时仍能正常运行。本主题介绍了用于构建容错微服务的不同高可用性模式和策略。
- 安全:安全性是任何分布式系统的关键方面。本主题介绍了用于保护微服务的不同安全挑战和策略。
- 安全 - Key Vault:密钥保管库是用于存储微服务架构使用的加密密钥、证书和机密的安全存储位置。本主题介绍密钥保管库是什么以及如何使用它来安全地管理微服务中的敏感数据
- 工具——CAP:CAP(“CAPability”的缩写)是一种基于最终一致性理念的微服务分布式事务解决方案。它提供了具有 Outbox 模式的事件总线,允许您以可靠且事务性的方式将消息/事件发布到多个微服务。CAP 是用 .NET Core 编写的
- 工具-Dapr:Dapr(分布式应用程序运行时)是一个用于构建基于微服务的应用程序的开源框架。它提供了一组构建块,例如状态管理、发布/订阅消息和服务到服务调用,可帮助开发人员专注于编写业务逻辑而不是基础架构代码。Dapr 的设计与语言无关,可与任何编程语言和任何云或边缘环境一起使用。本主题介绍 Dapr 的主要功能以及如何使用它来构建分布式应用程序。
- 工具 - 流量:Mass Transit 是 .NET 的一个开源分布式应用程序框架。它提供了一组抽象和构建块,用于构建可扩展且具有容错能力的基于微服务的应用程序。Mass Transit 支持各种消息传递技术,例如 RabbitMQ、ActiveMQ 和 Azure 服务总线,并提供请求-响应、发布/订阅消息传递和消息路由等功能。本主题介绍 Mass Transit 的主要功能以及如何使用它来构建分布式应用程序。
- 工具-NService Bus:NService Bus 是 .NET 的商业分布式应用程序框架。它提供了一组抽象和构建块,用于构建可扩展且可靠的基于微服务的应用程序。NService Bus 支持各种消息传递技术,例如 RabbitMQ、Azure Service Bus 和 Amazon SQS,并提供请求-响应、发布/订阅消息传递和消息路由等功能。本主题介绍 NService Bus 的主要功能以及如何使用它来构建分布式应用程序。
- 工具 - SteelToe:Steeltoe 是一个开源框架,用于构建在 Cloud Foundry 和 Kubernetes 上运行的基于 .NET 微服务的应用程序。Steeltoe 提供了一组库和构建块,例如服务发现、断路器和安全性,可帮助开发人员构建和操作云原生应用程序。Steeltoe 被设计为模块化的,可与任何 .NET 框架一起使用,例如 ASP.NET、.NET Core 和 .NET Framework。本主题介绍 Steeltoe 的主要功能以及如何使用它来构建云原生应用程序。
- 工具 - Tye:Tye 是一款开源开发工具,用于构建、测试和部署基于微服务的应用程序。Tye 提供了一种简单快捷的方法,可以使用容器在本地开发和运行应用程序,而无需管理基础架构。Tye 支持各种编程语言,例如 .NET、Java 和 Node.js,并与 Docker、Kubernetes 和 Helm 等流行工具集成。本主题介绍 Tye 的主要功能以及如何使用它在本地开发和部署基于微服务的应用程序。
- 工具 - 金刚狼 :Wolverine 是一个开源项目,为 .NET 提供下一代命令和消息总线。它允许开发人员通过基于消息的架构实现应用程序不同部分之间的通信,从而构建可扩展的分布式应用程序。Wolverine 建立在 Jasper 框架之上,提供分布式命令路由、消息序列化和版本控制等功能。它支持同步和异步消息处理,并且可以与各种传输协议(如 HTTP、RabbitMQ 和 Azure 服务总线)一起使用。
模块化整体
- 模块化整体模块化单体是一种架构方法,它结合了单体架构和微服务架构的优点。它旨在构建具有模块化设计的单体应用程序,从而可以将其划分为更小、更易于管理的部分,每个部分都有自己明确的职责和接口。这种方法允许团队独立开发和部署功能,同时仍保持单个代码库和数据库。模块化设计还有助于应用程序的测试和维护,以及各个模块的扩展。
架构设计原则
架构设计原则全面概述设计软件架构时应考虑的最重要的原则。
- CAP:CAP 定理,描述了分布式系统中一致性、可用性和分区容忍度之间必须做出的权衡。
- 凝聚:内聚力的概念,指模块或组件内各元素之间的相关程度以及为实现单一目的而共同努力的程度。
- 耦合:耦合的概念,指一个模块或组件对另一个模块或组件的依赖程度。
- 命令查询分离:命令查询分离 (CQS) 原则,建议方法要么改变对象的状态(命令),要么返回一个值(查询),但不能同时改变两者。
- 横切关注点:横切关注点是跨系统中的多个组件或模块的功能或要求,例如安全性、日志记录或事务管理。
- 依赖反转:依赖倒置原则,规定高级模块不应该依赖于低级模块,但两者都应该依赖于抽象。
- DRY:不要重复自己 (DRY) 原则,该原则指出代码不应在系统内重复,而应抽象为可重用的函数或模块。
- 封装:封装是向用户隐藏对象或模块的实现细节并提供与其交互的明确定义的接口的原则。
- 快速失败设计原则:快速失败设计原则旨在通过尽早检测错误和故障并在错误进一步传播之前停止系统执行来减少系统中错误和故障的影响。
- 组合优于继承:组合优于继承原则,建议在设计面向对象软件时优先考虑组合(通过组合简单的对象来构建复杂的对象)而不是继承(通过扩展现有类来创建新的类)。
- GRASP:通用职责分配软件模式 (GRASP) 是一组用于为软件系统中的对象和模块分配职责的指南。
- 接口隔离:接口隔离原则,该原则规定客户端不应被迫依赖于他们不使用的接口,并且接口应设计为具有凝聚力并专注于单一目的。
- 反转控制控:制反转 (IoC) 模式是一种通过反转依赖关系的方向来解耦系统中模块或组件之间的依赖关系的技术。
- KISS:保持简单,愚蠢(KISS)是一种设计原则,鼓励保持系统和解决方案尽可能简单,以避免不必要的复杂性并提高可维护性。
- 开放封闭原则:开放封闭原则 (OCP) 是一种设计原则,它提倡编写对扩展开放但对修改封闭的代码的理念,这意味着应该在不改变现有代码库的情况下将新功能添加到系统中。
- 持久性无知:持久性无知 (PI) 是一种设计原则,它鼓励将业务逻辑与持久性逻辑分离,以提高灵活性、可维护性和可测试性。
- 单一职责:单一职责原则 (SRP) 是一种设计原则,它主张一个类或模块只有一个改变的原因,这意味着它应该只有一个职责或工作。
- 绞杀无花果模式:Strangler Fig 模式是一种软件现代化方法,它涉及逐步用新系统逐个模块地替换现有系统,而不是试图一次性迁移所有系统。
- SOLID:SOLID 是五个面向对象设计原则(单一职责原则、开放封闭原则、里氏替换原则、接口隔离原则和依赖倒置原则)的首字母缩写,旨在使软件系统更易于维护、可扩展和可测试。
- YAGNI:你不需要它(YAGNI)是一项原则,建议不要为尚不需要的功能编写代码,以避免给代码库添加不必要的复杂性,并专注于仅提供所需的功能。
以上内容在Jdon.com都有涉及跟踪:https://www.jdon.com/tag/