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

自从软件开发的早期(1960年代)以来，解决大型软件系统中的复杂性一直是一项艰巨的任务。多年来，软件工程师和架构师为解决软件系统的复杂性进行了许多尝试：David Parnas的模块化和信息隐藏(1972)，Edsger W. Dijkstra的关注分离(1974)，面向服务的体系结构(1998)。

他们所有人都使用了久经考验的成熟技术来解决大型系统的复杂性：分而治之。自2010年代以来，这些技术不足以解决Web规模应用程序或现代大型企业应用程序的复杂性。结果，架构师和工程师开发了一种新方法来解决现代软件系统的复杂性：微服务架构。它也使用了相同的旧"分而治之"技术，尽管采用了新颖的方式。

软件设计模式是解决软件设计中常见问题的通用，可重用的解决方案。设计模式可帮助我们共享通用词汇，并使用经过实战检验的解决方案，而不是重新发明轮子。今天描述的是一组设计模式，以帮助您实现这些最佳实践。

本文主要内容：

· 微服务架构

· 微服务架构的优势

· 微服务架构的缺点

· 何时使用微服务架构

· 微服务架构设计模式

请注意，此清单的大多数设计模式都有几种上下文，可以在非微服务体系结构中使用。但是我将在微服务架构的背景下对其进行描述。

微服务架构

微服务体系结构：简要概述以及为什么要在下一个项目中使用它以及模块化单片软件体系结构真的死了吗?

我的微服务架构定义是：

微服务架构旨在将大型，复杂的系统垂直(按功能或业务要求)划分为较小的子系统，这些子系统属于流程(因此可独立部署)，并且这些子系统之间通过与语言无关的轻量级网络通信相互通信(例如REST，gRPC)或异步(通过消息传递)方式。

这是具有微服务架构的业务Web应用程序的组件视图：

> Microservice Architecture by Md Kamaruzzaman

微服务架构的重要特征：

· 整个应用程序分为多个单独的进程，每个进程可以包含多个内部模块。

· 与模块化Monoliths或SOA相反，微服务应用程序是垂直拆分的(根据业务能力或领域)微服务边界是外部的。结果，微服务通过网络调用(RPC或消息)相互通信。

· 由于微服务是独立的流程，因此它们可以独立部署。他们以轻巧的方式交流，不需要任何智能交流渠道。

微服务架构的优势：

· 更好的开发规模。

· 更高的发展速度。

· 支持迭代或增量现代化。

· 充分利用现代软件开发生态系统(云，容器，DevOps，无服务器)的优势。

· 支持水平缩放和粒度缩放。

· 由于尺寸较小，它降低了开发人员的认知复杂度。

微服务架构的缺点：

· 大量的活动部件(服务，数据库，流程，容器，框架)。

· 复杂性从代码转移到基础架构。

· RPC调用和网络流量的激增。

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

· 设计整个系统比较困难。

· 介绍分布式系统的复杂性。

何时使用微服务架构：

· Web规模应用程序开发。

· 当多个团队处理应用程序时，进行企业应用程序开发。

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

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

微服务架构的设计模式

每个微服务独占数据库

一旦公司用许多较小的微服务替换了大型的单片系统，它面临的最重要的决定就是关于数据库。在整体架构中，使用大型中央数据库。许多架构师都喜欢保留数据库原样，即使他们转向微服务架构也是如此。尽管它提供了一些短期好处，但它是一种反模式，尤其是在大规模系统中，因为微服务将紧密耦合在数据库层中。转向微服务的整个目标将失败(例如，团队授权，独立开发)。

更好的方法是为每个微服务都提供自己的数据存储，以使数据库层中的服务之间不存在强耦合。在这里，我使用数据库一词来表示数据的逻辑分离，即微服务可以共享同一物理数据库，但是它们应该使用单独的架构/集合/表。它还将确保根据域驱动设计正确隔离微服务。

> Database per Microservice by Md Kamaruzzaman

优点：

· 数据对服务的完全所有权。

· 开发服务的团队之间的松耦合。

缺点：

· 在服务之间共享数据变得充满挑战。

· 提供应用程序范围的ACID事务保证变得更加困难。

· 将Monolith数据库分解为较小的零件需要仔细设计，这是一项艰巨的任务。

每个微服务何时使用数据库：

· 在大型企业中的应用。

· 当团队需要其微服务的完全所有权以进行开发扩展和提高开发速度时。

什么时候不使用每个微服务的数据库：

·