微服务架构指的是将大型复杂系统按功能或者业务需求垂直切分成更小的子系统，这些子系统以独立部署的子进程存在，它们之间通过轻量级的、跨语言的同步（比如REST，gRPC）或者异步（消息）网络调用进行通信。下图是基于微服务架构的商业 Web 应用的组件视图。

微服务架构的重要特征：
①整个应用程序被拆分成相互独立但包含多个内部模块的子进程。
②与模块化的单体应用（Modular Monoliths）或 SOA 相反，微服务应用程序根据业务范围或领域垂直拆分。
③微服务边界是外部的，微服务之间通过网络调用（RPC 或消息）相互通信。
④微服务是独立的进程，它们可以独立部署。
⑤它们以轻量级的方式进行通信，不需要任何智能通信通道。
微服务架构的优点：
①更好的开发规模。
②更快的开发速度。
③支持迭代开发或现代化增量开发。
④充分利用现代软件开发生态系统的优势（云、容器、 DevOps、Serverless）。
⑤支持水平缩放和细粒度缩放。
⑥小体量，较低了开发人员的认知复杂性。
微服务架构的缺点：
①更高数量级的活动组件（服务、数据库、进程、容器、框架）。
②复杂性从代码转移到基础设施。
③RPC 调用和网络通信的大量增加。
④整个系统的安全性管理更具有挑战性。
⑤整个系统的设计变得更加困难。
⑥引入了分布式系统的复杂性。
何时使用微服务架构：
①大规模 Web 应用开发。
②跨团队企业级应用协作开发。
③长期收益优先于短期收益。
④团队拥有能够设计微服务架构的软件架构师或高级工程师。

微服务架构的设计模式：独享数据库（Database per Microservice）
当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。
更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。

优点：数据由服务完全所有；服务的开发团队之间耦合度降低。
缺点：服务间的数据共享变得更有挑战性；在应用范围的保证 ACID 事务变得困难许多；细心设计如何拆分单体数据库是一项极具挑战的任务。
何时使用独享数据库：在大型企业应用程序中；当团队需要完全把控微服务以实现开发规模扩展和速度提升。
何时不宜使用独享数据库：在小规模应用中；如果是单个团队开发所有微服务。
可用技术示例：所有 SQL、 NoSQL 数据库都提供数据的逻辑分离（例如，单独的表、集合、结构、数据库）。

事件源（Event Sourcing）
在微服务架构中，特别使用独享数据库时，微服务之间需要进行数据交换。对于弹性高可伸缩的和可容错的系统，它们应该通过交换事件进行异步通信。在这种情况，您可能希望进行类似更新数据库并发送消息这样的原子操作，如果在大数据量的分布式场景使用关系数据库，您将无法使用两阶段锁协议（2PL），因为它无法伸缩。而 NoSQL 数据库因为大多不支持两阶段锁协议甚至无法实现分布式事务。

在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务实体的当前“状态”，而在事件源中任何“状态”更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。这意味着业务实体的所有更改将被保存为一系列不可变的事件。因为数据是作为一系列事件存储的，而非直接更新存储，所以各项服务可以通过重放事件存储中的事件来计算出所需的数据状态。

优点：为高可伸缩系统提供原子性操作；自动记录实体变更历史，包括时序回溯功能；松耦合和事件驱动的微服务。
缺点：从事件存储中读取实体成为新的挑战，通常需要额外的数据存储（CQRS 模式）；系统整体复杂性增加了，通常需要领域驱动设计；系统需要处理事件重复（幂等）或丢失；变更事件结构成为新的挑战。
何时使用事件源：使用关系数据库的、高可伸缩的事务型系统；使用 NoSQL 数据库的事务型系统；弹性高可伸缩微服务架构；典型的消息驱动或事件驱动系统（电子商务、预订和预约系统）。
何时不宜使用事件源：使用 SQL 数据库的低可伸缩性事务型系统；在服务可以同步交换数据（例如，通过 API）的简单微服务架构中。

命令和查询职责分离（CQRS）
如果我们使用事件源，那么从事件存储中读取数据就变得困难了。要从数据存储中获取实体，我们需要处理所有的实体事件。有时我们对读写操作还会有不同的一致性和吞吐量要求。
这种情况，我们可以使用 CQRS 模式。在该模式中，系统的数据修改部分（命令）与数据读取部分（查询）是分离的。而 CQRS 模式有两种容易令人混淆的模式，分别是简单的和高级的。
在其简单形式中，不同实体或 ORM 模型被用于读写操作，如下所示：

Saga
如果微服务使用独享数据库，那么通过分布式事务管理一致性是一个巨大的挑战。你无法使用传统的两阶段提交协议，因为它要么不可伸缩（关系数据库），要么不被支持（多数非关系数据库）。
但您还是可以在微服务架构中使用 Saga 模式实现分布式事务。Saga 是 1987 年开发的一种古老模式，是关系数据库中关于大事务的一个替代概念。但这种模式的一种现代变种对分布式事务也非常有效。Saga 模式是一个本地事务序列，其每个事务在一个单独的微服务内更新数据存储并发布一个事件或消息。Saga 中的首个事务是由外部请求（事件或动作）初始化的，一旦本地事务完成（数据已保存在数据存储且消息或事件已发布），那么发布的消息或事件则会触发 Saga 中的下一个本地事务。

面向前端的后端 （BFF）
在现代商业应用开发，特别是微服务架构中，前后端应用是分离和独立的服务，它们通过 API 或 GraphQL 连接。如果应用程序还有移动 App 客户端，那么 Web 端和移动客户端使用相同的后端微服务就会出现问题。因为移动客户端和 Web 客户端有不同的屏幕尺寸、显示屏、性能、能耗和网络带宽，它们的 API 需求不同。
面向前端的后端模式适用于需要为特殊 UI 定制单独后端的场景。它还提供了其他优势，比如作为下游微服务的封装，从而减少 UI 和下游微服务之间的频繁通信。此外，在高安全要求的场景中，BFF 为部署在 DMZ 网络中的下游微服务提供了更高的安全性。

API 网关
在微服务架构中，UI 通常连接多个微服务。如果微服务是细粒度的（FaaS） ，那么客户端可能需要连接非常多的微服务，这将变得繁杂和具有挑战性。此外，这些服务包括它们的 API 还将不断进化。大型企业还希望能有其他横切关注点（SSL 终止、身份验证、授权、节流、日志记录等）。
一个解决这些问题的可行方法是使用 API 网关。API 网关位于客户端 APP 和后端微服务之间充当 facade，它可以是反向代理，将客户端请求路由到适当的后端微服务。它还支持将客户端请求扇出到多个微服务，然后将响应聚合后返回给客户端。它还支持必要的横切关注点。