架构设计学习资料（持续更新）

小鱼儿 2022-09-09 10:54 237阅读 0赞

### 文章目录 ###

*  架构设计学习资料（持续更新）
 *   *  图书
     *  Video
     *  架构模式
     *   *  Layered Architecture 分层架构模式
         *  Multi-Tier 多层模式
         *  Pipe and Filter 管道与过滤器模式
         *  Client Server 客户端/服务器架构模式
         *  MVC模式
         *  MVC, MVP and MVVM
         *  Event Driven Architecture 事件驱动架构模式
         *  Microservices Architecture 微服务架构模式
     *  数据一致性设计
     *  应用弹性设计
     *  云架构设计模式目录
     *  软件设计通用原则
     *  微服务架构设计模式
     *  工具
     *  绘图标准
     *   *  拓扑图
         *  框图
         *  E-R图
         *  UML图
         *  BPMN图
     *  参考文档

# 架构设计学习资料（持续更新） #

## 图书 ##

*  《Software Architecture Patterns》Mark Richards
 *  《Fundamentals of Software Architecture》Mark Richards, Neal Ford

## Video ##

*  [Getting the Basics - Software Architecture Introduction - part 1][]
 *  [Scaling Distributed Systems - Software Architecture Introduction - part 2][]
 *  [Distributed Cache explained - Software Architecture Introduction - part 3][]

## 架构模式 ##

*  Layered Architecture 分层架构模式
 *  Multi-Tier 多层模式
 *  Pipe and Filter 管道与过滤器模式
 *  Client Server 客户端/服务器架构模式
 *  Model View Controller MVC模式
 *  Event Driven Architecture 事件驱动架构模式
 *  Microservices Architecture 微服务架构模式

### Layered Architecture 分层架构模式 ###

模式：

*  Presentation Layer
 *  Business Layer
 *  Persistence Layer
 *  Database Layer

在DDD分层架构中，将Business Layer再分为：

*  Application Service Layer 业务服务层
 *  Domain Service Layer 领域服务层

优点：

*  容易理解，被广泛使用
 *  层与层之间相互解耦，可以独立演进

缺点：

*  分层导致性能损失

适用场景：

*  小型、简单的应用程序或网站
 *  快速开发

### Multi-Tier 多层模式 ###

模式：

*  和分层架构模式类似

优点：

*  和分层架构一致

缺点：

*  前期成本较大
 *  复杂

适用场景：

*  分布式系统

### Pipe and Filter 管道与过滤器模式 ###

模式：

*  Input：输入
 *  Process：处理过程
 *  Output：输入

处理过程的过滤器包括：

*  Producer (source): 流程的起点
 *  Transformer (map)：数据转换
 *  Tester (reduce)：测试
 *  Consumer (sink)：终点

优点：

*  处理过程的环节可重用，松耦合

缺点：

*  处理过程环节过多时，会增加复杂性，并降低性能

适用场景：

*  简单单向处理的任务 （比如CI/CD流水线、函数计算、网关Filter，数据预处理等）

### Client Server 客户端/服务器架构模式 ###

模式：

*  客户端向服务器发送请求，然后等待回复。
 *  服务器接收客户端的请求并向其发送回复。

优点：

*  简单，广泛使用
 *  “拉”式架构

缺点：

*  服务器可能是性能瓶颈和单点故障 （可通过负载均衡和集群解决）
 *  不适合“推”式架构

适用场景：

*  Web应用

### MVC模式 ###

模式：

*  Model: 模型，包含应用的数据
 *  View：视图，展示数据，并与用户交互
 *  Controller：控制器，协调模型和视图。

优点：

*  简单，广泛使用
 *  现代的MVC模式已经和前后端分离模式结合使用

缺点：

*  依赖于特定MVC开发框架

适用场景：

*  Web应用

### MVC, MVP and MVVM ###

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>MVC</th> 
   <th>MVP</th> 
   <th>MVVM</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>组件</td> 
   <td>Model, View and Controller</td> 
   <td>Model, View and Presenter</td> 
   <td>Model, View and View Model</td> 
  </tr> 
  <tr> 
   <td>特点</td> 
   <td>MVC 设计模式将应用程序分为三个主要方面：模型、视图和控制器。</td> 
   <td>MVP 模式类似于 MVC 模式。它源自 MVC 模式，其中控制器被演示者取代。这种模式将应用程序分为三个主要方面：模型、视图和演示者。</td> 
   <td>MVVM 模式支持 View 和 View-Model 之间的双向数据绑定。这允许将视图模型状态内的更改自动传播到视图。通常，View-Model 使用观察者模式将 View-Model 中的更改通知给模型。j</td> 
  </tr> 
  <tr> 
   <td>入口</td> 
   <td>Controller</td> 
   <td>View</td> 
   <td>View</td> 
  </tr> 
  <tr> 
   <td>Model</td> 
   <td>模型是指需要在视图中显示的数据。模型表示描述业务逻辑（业务模型和数据模型）的类的集合。它还定义了数据方式的业务规则，即如何更改和操作数据。</td> 
   <td>模型表示一组描述业务逻辑和数据的类。它还定义了数据的业务规则，意味着如何更改和操作数据。</td> 
   <td>MVVM 中使用的模型类似于 MVC 中使用的模型，由运行软件所需的基本数据组成。</td> 
  </tr> 
  <tr> 
   <td>View</td> 
   <td>视图代表 UI 组件，如 XML、HTML 等。视图显示从控制器接收到的数据作为结果。在 MVC 模式中，View 监视模型的任何状态变化并显示更新的模型。模型和视图使用观察者模式相互交互。</td> 
   <td>View 是一个直接与用户交互的组件，如 XML、Activity、Fragment。它不包含任何实现的逻辑。</td> 
   <td>View 是用户和设计模式之间的图形界面，类似于 MVC 中的界面。 它显示处理数据的输出。</td> 
  </tr> 
  <tr> 
   <td>X</td> 
   <td>控制器负责处理传入的请求。它通过 Model 处理用户的数据，并将结果传回给 View。它通常充当视图和模型之间的中介。</td> 
   <td>Presenter 通过 View 接收用户的输入，然后在 Model 的帮助下处理用户的数据，并将结果传回给 View。 Presenter 通过接口与视图通信。接口在presenter 类中定义，它将所需的数据传递给它。活动/片段或任何其他视图组件实现此接口并以他们想要的方式呈现数据。</td> 
   <td>视图模型负责公开方法、命令和其他有助于维护视图状态、操作模型作为视图操作的结果以及在视图本身中触发事件的属性。 View 有对 View-Model 的引用，但 View-Model 没有关于 View 的信息。 View 和 View-Model 之间是多对一的关系，意味着多个 View 可以映射到一个 View-Model。它完全独立于视图。<br>视图与视图模型之间的双向数据绑定或双向数据绑定可确保视图模型中的模型和属性与视图同步。</td> 
  </tr> 
 </tbody> 
</table>

References:

*  [MVC, MVP and MVVM Design Pattern][MVC_ MVP and MVVM Design Pattern]
 *  [MVC vs MVP vs MVVM][]

### Event Driven Architecture 事件驱动架构模式 ###

模式：

*  发布者：发布事件
 *  订阅者：读取事件，并进行处理

优点：

*  解耦发布者与订阅者

缺点：

*  需要额外作异常处理
 *  实时性比客户端/服务器模式差一些

适用场景：

*  大型分布式系统

### Microservices Architecture 微服务架构模式 ###

模式：

*  将单体应用程序分成多个微服务

优点：

*  高内聚、低耦合

缺点：

*  需要有相应的微服务开发框架、微服务治理组件、容器平台、ServicMesh等支持

适用场景：

*  复杂业务系统

## 数据一致性设计 ##

*  [https://docs.microsoft.com/zh-cn/previous-versions/msp-n-p/dn589800(v=pandp.10)][https_docs.microsoft.com_zh-cn_previous-versions_msp-n-p_dn589800_v_pandp.10]

复杂系统的数据一致性设计考虑：

*  消息队列
 *  补偿机制：[补偿事务 (Compensating Transaction)][_Compensating Transaction]
 *  对账机制

## 应用弹性设计 ##

复杂系统的应用的弹性设计：

*  防止单点故障：负载均衡，集群
 *  避免雪崩效应（级联故障）：[断路器 (Circuit Breaker)][_Circuit Breaker]
 *  故障隔离：[隔舱或舱壁 (Bulkhead)][_Bulkhead]
 *  重试
 *  超时

## 云架构设计模式目录 ##

<table> 
 <thead> 
  <tr> 
   <th>模式</th> 
   <th>描述</th> 
   <th>适用场景</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/ambassador" rel="nofollow">代表 (ambassador)</a></td> 
   <td>创建代表客户服务或应用程序发送网络请求的帮助程序服务。</td> 
   <td>Proxy （代理）模式的一种。Sidecar（边车）模式可认为是代表模式的一种实现。比喻：谈判全权代表。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/anti-corruption-layer" rel="nofollow">防损层 (Anti-Corruption Layer)</a></td> 
   <td>在现代应用程序与旧系统之间实施外观或适配器层。</td> 
   <td>隔离层模式或适配模式的一种。隔离新旧，解耦新旧，用于遗留系统的逐步迁移。DDD的上下文映射关系的一种。比喻：保护垫。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/async-request-reply" rel="nofollow">异步请求-答复 (Asynchronous Request-Reply)</a></td> 
   <td>在后端处理需要是异步处理但前端仍需要明确响应的情况下，将后端处理与前端主机分离。</td> 
   <td>消息处理模式的一种。非阻塞，异步调用。除了用消息队列实现外，还可用HTTP轮询或回调方式实现。比喻：快递柜。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/backends-for-frontends" rel="nofollow">用于前端的后端 (Backends for Frontends, BFF)</a></td> 
   <td>创建单独的后端服务，供特定的前端应用程序或接口使用。</td> 
   <td>适配模式的一种。在一个接口无法满足不同前端的数据需求时，不试图提供一个通用的接口来满足不同前端的数据需求，而是在为每个前端适配一个BFF层，由该BFF层汇聚一个或多个后端服务的数据，经过过滤、转换后再返回给前端。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/bulkhead" rel="nofollow">隔舱或舱壁 (Bulkhead)</a></td> 
   <td>将应用程序的元素隔离到池中，这样，如果一个元素发生故障，其他元素可继续工作。</td> 
   <td>隔离故障模式或容错模式的一种。避免雪崩效应或级联故障，避免进程被挂死，资源被耗尽，资源死锁。比喻：轮船的水密舱。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/cache-aside" rel="nofollow">缓存端 (Cache-Aside)</a></td> 
   <td>将数据按需从数据存储加载到缓存中。</td> 
   <td>缓存模式的一种。越靠近计算的地方，缓存的数据读取速度越快。比喻：CPU的L1缓存，L2缓存，内存，硬盘，离CPU越近，数据读取速度越快。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/choreography" rel="nofollow">编排 (Choreography)</a></td> 
   <td>让每项服务都参与决定业务运营的处理时间和处理方式，而不是依赖于一个中心型业务流程协调程序。</td> 
   <td>去中心化模式的一种。不由一个中心化的大脑来指挥、控制和协调各个服务，而是让各个服务自己去处理。但是并不是绝对地去中心化，比如仍然需要消息队列来实现编排。比喻：奥运会决赛中国队德比时，双方教练都不再在场指导，让双方运动员各自处理。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/circuit-breaker" rel="nofollow">断路器 (Circuit Breaker)</a></td> 
   <td>连接到远程服务或资源时处理故障，此类故障所需修复时间不定。</td> 
   <td>快速失败模式或容错模式的一种。在系统发生异常时，为保护整个系统，在达到阈值时，暂时停止服务，待系统恢复后，继续提供服务。断路器的状态包括：关闭，打开，半开。比喻：保险丝熔断。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/claim-check" rel="nofollow">声明检查 (Claim Check)</a></td> 
   <td>将大型消息拆分成声明检查和有效负载，以免消息总线过载。</td> 
   <td>引用模式或分离引用和负载模式的一种。消息队列中只发送引用（比如ID，link），负载不通过消息发送，而是外部化存储在数据库或服务器中。因为消息队列通常限制消息的大小，消息队列擅长于处理大量的小消息，而不适合于处理小量的大消息。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/compensating-transaction" rel="nofollow">补偿事务 (Compensating Transaction)</a></td> 
   <td>撤销一系列会共同定义最终一致操作的工作。</td> 
   <td>数据最终一致性模式的一种。在处理失败时，需要撤销先前已完成的工作。应将补偿事务中的步骤定义为幂等命令。 这样，补偿事务自身失败时可重复步骤。类似Sagas策略。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/competing-consumers" rel="nofollow">竞争性消费者 (Competing Consumers)</a></td> 
   <td>使多个并发消费者能够处理同一消息队列上收到的消息。</td> 
   <td>消息处理模式的一种。为了提高消息处理的吞吐量和性能，一个应用会有多个消费者同时处理消息，但是要保证一个消息只能被该应用的一个消费者处理。比喻：Kafka的consumer group。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/compute-resource-consolidation" rel="nofollow">计算资源合并 (Compute Resource Consolidation)</a></td> 
   <td>将多个任务或操作合并到单个计算单元。</td> 
   <td>提高资源利用率模式或共享资源池模式的一种。一类相关的工作负载，或不互相抢占资源的工作负载，可合并为一组来部署和共享资源。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/cqrs" rel="nofollow">CQRS</a></td> 
   <td>使用独立接口将读取数据的操作与更新数据的操作分离。</td> 
   <td>读写分离模式的一种。适用于读多写少，业务复杂的场景。如果只有一个数据库，写入表，从物化视图中查询数据。如果有多个数据库，写入写数据库，从读数据库中查询，为了提高性能，会有多个读数据库。另外会被频繁读取的数据从缓存中查询，树形结构的数据从文档型NoSQL（比如MongoDB）中查询，搜索的数据从搜索引擎（比如Elasticsearch或Solr）中查询。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/deployment-stamp" rel="nofollow">部署戳 (Deployment Stamps)</a></td> 
   <td>部署应用程序组件的多个独立副本，包括数据存储。</td> 
   <td>副本模式或缩放模式的一种。适用于横向扩展。比如：Kubernetes的Replica。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/event-sourcing" rel="nofollow">事件溯源 (Event Sourcing)</a></td> 
   <td>使用只追加存储来记录描述域中数据采取的操作的完整系列事件。</td> 
   <td>只追加（append only)模式的一种。不仅存储数据的当前状态，还使用只追加存储来记录数据的全部操作。可用于快照，重放，恢复，审计。比喻：Git版本控制系统。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/external-configuration-store" rel="nofollow">外部配置存储 (External Configuration Store)</a></td> 
   <td>将配置信息从应用程序部署包移出，移到一个集中的位置。</td> 
   <td>外部化模式或注入模式的一种。适用于一个应用需要在不同环境中部署，或需要集中化管理多个应用的配置。比喻：Spring Boot应用的application.yaml，或Spring Cloud Config Server。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/federated-identity" rel="nofollow">联合标识 (Federated Indentiy)</a></td> 
   <td>将身份验证委托给外部标识提供者。</td> 
   <td>联合（或联邦）模式的一种。将身份认证委托给外部可信任的Identity Provider，将用户身份认证与应用程序分离。比如，SSO或Social Login。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/gatekeeper" rel="nofollow">守护程序 (Gatekeeper)</a></td> 
   <td>通过使用专用的主机实例保护应用程序和服务，该实例用于充当客户端和应用程序或服务之间的中转站、验证和整理请求，并在它们之间传递请求和数据。</td> 
   <td>看门人模式或中转模式的一种。设立一个中转人（看门人）来保护后端的资源。比喻，防火墙，WAF，DMZ区。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/gateway-aggregation" rel="nofollow">网关聚合 (Gateway Aggregation)</a></td> 
   <td>使用网关可将多个单独请求聚合成一个请求。</td> 
   <td>聚合模式或网关模式的一种。使用网关减少客户端与服务之间的通信频率。网关接收客户端请求，将请求分派到不同的后端系统，然后聚合结果并将其返回给请求客户端。不要在网关中内置聚合，而应考虑将聚合服务放在网关后面。比喻，客户在餐厅向一个服务员点餐，服务员再通知厨房做菜，各个岗位厨师做好菜后，再由服务员上菜给客户。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/gateway-offloading" rel="nofollow">网关卸载 (Gateway Offloading)</a></td> 
   <td>将共享或专用服务功能卸载到网关代理。</td> 
   <td>职责分离模式的一种。让专业团队处理专业的事情，比如将某些功能（比如SSL）卸载到网关，对外HTTPS，对内HTTP。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/gateway-routing" rel="nofollow">网关路由 (Gateway Routing)</a></td> 
   <td>使用单个终结点将请求路由到多个服务。</td> 
   <td>网关模式的一种。使用网关作路由分发。使用此模式，客户端应用程序只需了解单个终结点并与之通信。 如果服务进行合并或分解，客户端不一定需要更新。 它可以继续向网关发出请求，只有路由会更改。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/geodes" rel="nofollow">多地部署 (Geodes)</a></td> 
   <td>将后端服务部署到一组地理节点，其中的每个节点可为任何区域中的任何客户端请求提供服务。</td> 
   <td>靠近客户部署模式。为保证用户体验，多地靠近客户部署，降低网络延迟，降低某个地域的负载。现代云基础结构已发展为支持前端服务的地理负载均衡（比如域名、全局负载均衡、地域负载均衡、CDN加速），同时允许对后端服务进行地理复制（比如数据异地复制服务）。比如，国外用国外公有云，国内用国内公有云，按照客户分布多地部署。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/health-endpoint-monitoring" rel="nofollow">运行状况节点监视 (Health Endpoint Monitoring)</a></td> 
   <td>在应用程序中实施可让外部工具通过公开节点定期访问的功能检查。</td> 
   <td>健康检查模式的一种。通过将请求发送到应用程序上的节点来实施运行状况监视。 应用程序应执行必要的检查，并返回其状态指示。比如，Spring Boot Actuator，Kuberentes健康检查探针。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/index-table" rel="nofollow">索引表 (Index Table)</a></td> 
   <td>基于数据存储中经常由查询引用的字段创建索引。</td> 
   <td>索引模式。比如数据库表索引，搜索引擎索引，文件系统索引。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/leader-election" rel="nofollow">领导选择 (Leader Election)</a></td> 
   <td>通过选拔一个实例作为领导来负责管理其他实例，协调分布式应用程序中协作性任务实例集合所执行的操作。</td> 
   <td>领导模式或竞争模式的一种。为了协调和避免冲突，需要选出一个领导。可通过指定，竞选，算法来选出领导。原领导不可用时，需要有可靠的机制来选出新领导。比如，Zookeeper中的leader。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/materialized-view" rel="nofollow">物化视图 (Materialized View)</a></td> 
   <td>当未针对所需的查询操作完美设置数据的格式时，在一个或多个数据存储中基于数据生成预填充的视图。</td> 
   <td>视图模式。数据库物化视图。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/pipes-and-filters" rel="nofollow">管道和筛选器 (Pipes and Filters)</a></td> 
   <td>将一个执行复杂处理的任务分解为一系列可重复使用的单个元素。</td> 
   <td>流水线模式。将每个流所需的处理分解为一组单独的组件（或筛选器），每个组件执行一项任务。 通过标准化每个组件接收和发送的数据的格式，这些筛选器可以一起组合到管道中。 这有助于避免代码重复，并在处理要求发生更改的情况下，还可以让删除、替换或集成其他组件的任务变得轻松。流水线可串行，也可并行。比如，CI/CD pipeline，函数计算，请求拦截与过滤。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/priority-queue" rel="nofollow">优先级队列 (Priority Queue)</a></td> 
   <td>为发送到服务的请求确定优先级，以便高优先级请求能够得到比低优先级请求更快速地接收和处理。</td> 
   <td>优先级模式或插队模式。队列通常是先入先出 (FIFO) 结构，使用者通常是按将消息发布到队列的相同顺序接收的。 但是，某些消息队列支持优先级消息传送。 发布消息的应用程序可以分配优先级，并且队列中的消息自动重新排序，以便优先级高的消息先于优先级较低的消息收到。比喻，VIP客户可以插队。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/publisher-subscriber" rel="nofollow">发布方/订阅方 (Publisher/Subscriber)</a></td> 
   <td>使应用程序能够以异步方式向多个感兴趣的使用者公布事件，而无需将发送方与接收方耦合。</td> 
   <td>消息处理模式。解耦发布方与订阅方。强烈建议使用支持发布-订阅模型的可用消息传送产品和服务，而不要自行构建。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/queue-based-load-leveling" rel="nofollow">基于队列的负载调控 (Queue-Based Load Leveling)</a></td> 
   <td>使用队列在任务与所调用的服务之间充当缓冲，从而缓解间歇性负载过大现象。</td> 
   <td>缓冲模式。缓冲输入与输出之间的不同速率。在任务和服务之间引入队列。 任务和服务异步运行。 任务将包含服务所需数据的消息发布到队列。 队列充当缓冲区来存储消息，直至消息被服务检索出去。 服务从队列检索消息并对其进行处理。 多个任务提交的请求（其生成速度可能差异很大）可以通过同一消息队列传递给服务。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/retry" rel="nofollow">重试 (Retry)</a></td> 
   <td>当应用程序尝试连接到服务或网络资源时，使应用程序能够通过以透明方式重试先前失败的操作来处理预期的临时故障。</td> 
   <td>重试模式。在遇到暂时性错误时，重新尝试，降低错误，并对客户端透明。有限重试次数，可配重试间隔。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/scheduler-agent-supervisor" rel="nofollow">计划程序代理监督程序 (Scheduler Agent Supervisor)</a></td> 
   <td>跨一组分布式服务和其他远程资源协调一组操作。</td> 
   <td>容错设计模式的一种。比如，Linux上的supervisor。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/sequential-convoy" rel="nofollow">顺序保护 (Sequential Convoy)</a></td> 
   <td>按定义的顺序处理一组相关的消息，不需阻止对其他消息组的处理。</td> 
   <td>顺序处理模式的一种。将相关消息推送到队列系统内的类别，让队列侦听器锁定并仅从一个类别（一次一条消息）拉取。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/sharding" rel="nofollow">分片 (Sharding)</a></td> 
   <td>将数据存储划分为一组水平分区或分片。</td> 
   <td>分而治之模式的一种。将数据存储划分为水平分区或分片。 每个分片具有相同的架构，但保存其自己数据的不同子集。 分片是自己权限内的数据存储（可以包含不同类型的许多实体的数据），在服务器上作为存储节点运行。分片策略包括：查找策略，范围策略，哈希策略。比如，数据库分区，分表，分库。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/sidecar" rel="nofollow">Sidecar</a></td> 
   <td>将应用程序的组件部署到单独的进程或容器中，以提供隔离和封装。</td> 
   <td>代理模式的一种。将一组内聚性的任务与主应用程序放在一起，不过，要将它们放在其自身的进程或容器内，以便为跨语言的平台服务提供同构接口。比喻，将Envovy proxy容器和主容器放在同一个Pod中，由Envovy proxy代理主容器的所有流量。和“代表”模式类似。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/static-content-hosting" rel="nofollow">静态内容托管 (Static Content Hosting)</a></td> 
   <td>将静态内容部署到基于云的存储服务，再由后者将它们直接传送给客户端。</td> 
   <td>动静分离模式。将静态内容（CSS，JavaScript，图片）放到CDN上。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/strangler-fig" rel="nofollow">绞杀者（Strangler Fig）</a></td> 
   <td>通过将特定的功能片断逐渐取代为新的应用程序和服务，逐步迁移旧系统。</td> 
   <td>新旧替换模式或门面模式的一种。用新的应用程序和服务逐步替换特定的功能。 创建一个外层来拦截请求前往后端旧版系统。 外层可将这些请求路由到旧版应用程序或新服务。 现有功能可逐步迁移到新系统，使用者可继续使用相同的接口，他们并不知道迁移已发生。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/throttling" rel="nofollow">限制 (Throttling)</a></td> 
   <td>控制应用程序实例、单个租户或整个服务对资源的消耗。</td> 
   <td>资源消耗模式的一种。控制应用程序实例、单个租户或整个服务对资源的消耗。比喻，Kuberentes的资源requests和limits。</td> 
  </tr> 
  <tr> 
   <td><a href="https://docs.microsoft.com/zh-cn/azure/architecture/patterns/valet-key" rel="nofollow">密钥 (Valet Key)</a></td> 
   <td>使用令牌或密钥，向客户端授予对特定资源或服务的受限直接访问权限。</td> 
   <td>访问控制模式的一种。为客户端提供数据存储可以验证的密钥或令牌。令牌有有效期。可设置访问级别。比喻，OAuth2的Access Token。</td> 
  </tr> 
 </tbody> 
</table>

## 软件设计通用原则 ##

*  KISS - Keep it simple, stupid. 保持简单，连傻瓜都不会做错。（反模式：故弄玄虚）
 *  DRY - Don’t repeat yourself. 不要重复造轮子。（反模式：粗制滥造地封装开源库）
 *  YAGNI - You aren’t gonna need it. 不要做一些以后用不到的事 （反模式：预留的扩展字段）
 *  SoC - Separation of concern 每个人做好自己的事 （反模式：自己的事情还没做好，又去操别人的心）
 *  SOLID (Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion)

## 微服务架构设计模式 ##

*  同步（基于API）
    
     *  直接调用
     *  聚合
        
         *  Service Registry
         *  API Gateway
         *  BFF
     *  扁平
        
         *  Service Mesh
 *  异步（基于事件/消息）
    
     *  发布/订阅 （Message Broker）
     *  Event Driven Architecture (Event Hub)
 *  数据
    
     *  CQRS （Read database / Write database)
     *  Event Sourcing (Event Store)

微服务架构设计原则

*  从简单的架构开始
 *  架构是手段，不是目的
 *  采用适合的架构，逐步演进
 *  可混合使用

## 工具 ##

*  [架构师的效率工具][Link 1]

## 绘图标准 ##

### 拓扑图 ###

按某种顺序画应用架构的拓扑图，比如请求（流量）进入的顺序、业务流程的顺序。

### 框图 ###

用框框表示不同的概念，概念分组，概念分层的逻辑关系。

### E-R图 ###

数据库表设计用的E-R图。

### UML图 ###

用UML类图（Class Diagram) 作类的设计，比如DDD中的领域模型。

用UML序列图（Sequence Diagram）作交互流程说明，比如OAuth2的Authorization Flow。

参见：

*  [UML Class Diagram Tutorial][]
 *  [UML Sequence Diagram][]

### BPMN图 ###

用BPMN图作业务流程建模，比如使用工作流平台定义流程。

参见：

*  [BPMN Diagram][]

## 参考文档 ##

*  [Software Architecture: The Most Important Architectural Patterns You Need to Know][Software Architecture_ The Most Important Architectural Patterns You Need to Know]
 *  [Microsoft | Cloud Design Patterns][Microsoft _ Cloud Design Patterns]
 *  [Software Architecture Cheat Sheet for Daily Usage][]
 *  [Monolithic to Microservices Architecture with Patterns & Best Practices][Monolithic to Microservices Architecture with Patterns _ Best Practices]
 *  [Microservice Architecture and Design Patterns for Microservices][]
 *  [Camel | ENTERPRISE INTEGRATION PATTERNS][Camel _ ENTERPRISE INTEGRATION PATTERNS]
 *  [软件架构图的艺术][Link 2]

[Getting the Basics - Software Architecture Introduction - part 1]: https://www.youtube.com/watch?v=8UlLgOf20Ho
[Scaling Distributed Systems - Software Architecture Introduction - part 2]: https://www.youtube.com/watch?v=gxfERVP18-g
[Distributed Cache explained - Software Architecture Introduction - part 3]: https://www.youtube.com/watch?v=QBMTGngjWdU
[MVC_ MVP and MVVM Design Pattern]: https://medium.com/@ankit.sinhal/mvc-mvp-and-mvvm-design-pattern-6e169567bbad
[MVC vs MVP vs MVVM]: https://levelup.gitconnected.com/mvc-vs-mvp-vs-mvvm-35e0d4b933b4
[https_docs.microsoft.com_zh-cn_previous-versions_msp-n-p_dn589800_v_pandp.10]: https://docs.microsoft.com/zh-cn/previous-versions/msp-n-p/dn589800%28v=pandp.10%29
[_Compensating Transaction]: https://docs.microsoft.com/zh-cn/azure/architecture/patterns/compensating-transaction
[_Circuit Breaker]: https://docs.microsoft.com/zh-cn/azure/architecture/patterns/circuit-breaker
[_Bulkhead]: https://docs.microsoft.com/zh-cn/azure/architecture/patterns/bulkhead
[Link 1]: https://blog.csdn.net/nklinsirui/article/details/104847742
[UML Class Diagram Tutorial]: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
[UML Sequence Diagram]: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-sequence-diagram/
[BPMN Diagram]: https://www.visual-paradigm.com/guide/bpmn/what-is-bpmn/
[Software Architecture_ The Most Important Architectural Patterns You Need to Know]: https://levelup.gitconnected.com/software-architecture-the-important-architectural-patterns-you-need-to-know-a1f5ea7e4e3d
[Microsoft _ Cloud Design Patterns]: https://docs.microsoft.com/en-us/azure/architecture/patterns/
[Software Architecture Cheat Sheet for Daily Usage]: https://azeynalli1990.medium.com/software-architecture-cheat-sheet-for-daily-usage-9923922ea75b
[Monolithic to Microservices Architecture with Patterns _ Best Practices]: https://medium.com/design-microservices-architecture-with-patterns/monolithic-to-microservices-architecture-with-patterns-best-practices-a768272797b2
[Microservice Architecture and Design Patterns for Microservices]: https://medium.com/@madhukaudantha/microservice-architecture-and-design-patterns-for-microservices-e0e5013fd58a
[Camel _ ENTERPRISE INTEGRATION PATTERNS]: https://camel.apache.org/components/latest/eips/enterprise-integration-patterns.html
[Link 2]: https://www.infoq.cn/article/crafting-architectural-diagrams/