微服务最重要的10个设计模式

从软件开发早期（1960 年代）开始，应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性，软件工程师和架构师们做了许多尝试：David Parnas 的模块化和封装 （1972）， Edsger W. Dijkstra （1974）的关注点分离以及 SOA（1988）

他们都是使用分而治之这项成熟的传统技术来应对大型系统的复杂性。自 2010 年开始，这些技术被证实无法继续应对 Web 级应用或者现代大型企业级应用的复杂性。因此架构师和工程师们发展出了一种全新的现代方式来解决这个问题，就是微服务架构。它虽然延续了分而治之的思想，但却是以全新的方式来实现的。

软件设计模式是解决软件设计中常见问题的通用、可复用的解决方案。设计模式让我们可以分享通用词汇并使用经实战检验的方案，以免重复造轮子。

通过阅读这篇文章，你会学到：

• 微服务架构。

• 微服务架构的优势。

• 微服务架构的劣势。

• 何时使用微服务架构。

• 最重要的微服务架构设计模式，包括其优缺点、用例、上下文、技术栈示例及可用资源。

请注意，本清单中的大部分设计模式常出现在多种语境中，并且可以在非微服务架构中使用。而我将在微服务这个特定语境中介绍它们。

微服务架构

那到底什么是微服务架构？有很多种定义方法。我的定义是这这样的：

微服务架构指的是将大型复杂系统按功能或者业务需求垂直切分成更小的子系统，这些子系统以独立部署的子进程存在，它们之间通过轻量级的、跨语言的同步（比如 REST，gRPC）或者异步（消息）网络调用进行通信。关注公号：码猿技术专栏，回复关键：1111 获取阿里内部Java性能调优手册

下面是基于微服务架构的商业 Web 应用的组件视图：

 

微服务架构的重要特征：

• 整个应用程序被拆分成相互独立但包含多个内部模块的子进程。

• 与模块化的单体应用（Modular Monoliths）或 SOA 相反，微服务应用程序根据业务范围或领域垂直拆分。

• 微服务边界是外部的，微服务之间通过网络调用（RPC 或消息）相互通信。

• 微服务是独立的进程，它们可以独立部署。

• 它们以轻量级的方式进行通信，不需要任何智能通信通道。

微服务架构的优点：

• 更好的开发规模。

• 更快的开发速度。

• 支持迭代开发或现代化增量开发。

• 充分利用现代软件开发生态系统的优势（云、容器、 DevOps、Serverless）。

• 支持水平缩放和细粒度缩放。

• 小体量，较低了开发人员的认知复杂性。

微服务架构的缺点：

• 更高数量级的活动组件（服务、数据库、进程、容器、框架）。

• 复杂性从代码转移到基础设施。

• RPC 调用和网络通信的大量增加。

• 整个系统的安全性管理更具有挑战性。

• 整个系统的设计变得更加困难。

• 引入了分布式系统的复杂性。

何时使用微服务架构：

• 大规模 Web 应用开发。

• 跨团队企业级应用协作开发。

• 长期收益优先于短期收益。

• 团队拥有能够设计微服务架构的软件架构师或高级工程师。

微服务架构的设计模式

1. 独享数据库（Database per Microservice）

当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。关注公号：码猿技术专栏，回复关键：1111 获取阿里内部Java性能调优手册

更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。

 

优点

• 数据由服务完全所有。

• 服务的开发团队之间耦合度降低。

缺点

• 服务间的数据共享变得更有挑战性。

• 在应用范围的保证 ACID 事务变得困难许多。

• 细心设计如何拆分单体数据库是一项极具挑战的任务。

何时使用独享数据库