微服务架构的流行设计模式
在这篇文章中，了解对构建和开发微服务应用至关重要的最重要的设计模式。
几十年来，应用程序一直采用单体架构构建；然而，现在许多应用程序正在向微服务架构转变。微服务架构为我们提供了更快的开发速度、可扩展性、可靠性、用适合的最佳技术栈开发每个组件的灵活性，以及更多。微服务架构依赖于可独立部署的微服务。每个微服务都有自己的业务逻辑和数据库，由特定的领域背景组成。每个服务的测试、增强和扩展都独立于其他微服务。
然而，微服务架构也容易出现自身的挑战和复杂性。为了解决最常见的挑战和问题，一些设计模式已经发展起来。在这篇文章中，我们将看一下其中的几个。
必要的设计模式
在一个典型的微服务架构中，有超过8种必须的设计模式可以使开发顺利进行。在本节中，我们将更详细地了解这些模式。我们根据正在创建的应用程序的类型将其分为两部分--绿地或棕地。
绿地应用程序的设计模式
当我们从头开始构建一个应用程序时，我们可以自由地应用微服务架构所需的所有最新和现代设计模式。让我们深入了解一下其中的几个模式。
API网关模式
将整个业务逻辑分解成多个微服务带来了各种问题，导致了一些问题，例如：
- 你如何处理交叉问题，如授权、速率限制、负载平衡、重试策略、服务发现等？
- 你如何避免过多的往返和由于客户端到微服务的直接通信而产生的紧耦合？
- 在客户需要一个数据子集的情况下，谁来做数据过滤和映射？
- 如果客户需要调用多个微服务来获取数据，谁来做数据聚合？
为了解决这些问题，API网关位于客户端应用程序和微服务之间。它带来的功能包括反向代理、请求聚合、网关卸载、服务发现等。它可以为每个客户端暴露不同的API。
客户端UI组成模式
在这种模式中，微服务是由面向业务能力的团队开发的。一些UI屏幕可能需要来自多个微服务的数据。例如，一个购物网站将包括诸如目录、购物车、购买选项、客户评论等功能。每个数据项都属于一个特定的微服务。现在，每个要显示的数据项都是由不同的团队负责的。我们怎样才能解决这个问题呢？
一个UI团队应该创建一个页面骨架，通过合成多个UI组件来构建屏幕。每个团队开发一个客户端的UI组件，该组件是针对服务的。这个骨架也被称为单页应用程序（SPA）。像AngularJS指令和ReactJS组件这样的框架支持这一点。这也允许用户在任何数据变化时刷新屏幕的特定区域，提供更好的用户体验。
每个服务的数据库模式
微服务需要独立和松散的耦合。那么，微服务应用的数据库架构应该是怎样的呢？
- 一个典型的业务交易可能涉及来自不同团队拥有的多个服务的查询、连接或数据持久化操作。
- 在多角化的微服务架构中，每个微服务可能有不同的数据存储需求，可以考虑非结构化数据（NoSQL数据库）、结构化数据（关系型数据库）和/或图数据（Neo4j）。
- 数据库需要复制和分片以达到扩展的目的。
一个微服务交易必须限制在它自己的数据库中。任何需要该数据的其他服务必须使用服务API。如果你使用的是关系型数据库，那么每个服务的模式是最好的选择，可以使数据对微服务私有。为了创建一个屏障，为每个服务分配一个不同的数据库用户ID。这可以确保开发人员不会被诱惑绕过微服务的API而直接访问数据库。
这使得每个微服务可以使用最适合其要求的数据库类型。例如，使用Neo4j处理社交图数据，使用Elasticsearch处理文本搜索。
Saga模式
当我们为每个服务使用一个数据库时，就会在实现跨越多个微服务的交易时产生问题。在这种情况下，我们如何带来数据的一致性？本地ACID事务在这里没有帮助。解决方案是saga模式。传奇是一个本地事务链，每个事务都会更新数据库并发布一个事件来触发下一个本地事务。传奇模式要求在任何本地事务失败的情况下都要有补偿事务。
有两种方法来实现saga：
- 协调- 一个协调器（对象）与所有的服务协调，进行本地交易，获得更新，并执行下一个事件。在失败的情况下，它承担着触发补偿事件的责任。
- 编排--每个微服务负责监听和发布事件，它在失败的情况下启用补偿事件。
协调比编排的实现要简单得多。在协调中，只有一个组件需要协调所有的事件，而在编排中，每个微服务必须监听并对事件做出反应。
断路器模式
在微服务架构中，一个事务涉及调用多个服务。如果一个下游的微服务发生故障，它将不断调用该服务并耗尽所有其他服务的网络资源。这也会影响用户体验。我们如何处理级联故障？
断路器功能激发了断路器模式--这个问题的解决方案。一个代理位于客户端和微服务之间，它跟踪连续失败的数量。如果它超过一个阈值，它就会跳过连接并立即失败。在一个超时期之后，断路器再次允许有限数量的测试请求，以检查电路是否可以恢复。否则，超时期重新开始。
按业务能力或子域模式分解
在微服务架构中，一个大型复杂的应用必须被分解、凝聚以及松散耦合。它还应该是自主的，小到可以由一个 "比萨饼大小 "的团队（6到8名成员）开发。我们如何分解它？
有两种方法可以分解一个绿地应用程序--按业务能力或子域来分解。
- 业务能力是能够产生价值的东西。例如，在一家航空公司，业务能力可以是预订、销售、支付、座位分配等等。
- 子域的概念来自于领域驱动设计（DDD）。一个领域由多个子域组成，如产品目录、订单管理、交付管理等等。
棕地应用程序的设计模式
因为我们已经建立了几十年的应用程序，大约80%的公司运行在现有的应用程序上，这些应用程序被称为棕地应用程序。将棕地应用迁移到微服务是最具挑战性的任务。让我们来看看某些设计模式，它们可以帮助使迁移变得更容易。
绞肉机模式
我们如何将一个单体应用迁移到微服务架构中？绞杀者模式是基于一个藤蔓的比喻，它可以绞杀它所缠绕的树。在这种模式中，单体应用的一小部分被转换为微服务，对于客户来说，没有什么变化，因为外部API保持不变。慢慢地，所有的部分都被重构为微服务，而新的架构 "扼杀 "或取代了原来的单体架构。
反贪污层模式
当一个现代的应用程序需要与一个遗留的应用程序集成时，与过时的基础设施协议、API和数据模型进行互操作是具有挑战性的。遵循旧的模式和语义可能会破坏新的系统。我们怎样才能避免这种情况呢？
这需要一个翻译两个系统之间通信的层。一个反腐层符合旧系统或现代系统的数据模型，这取决于它与哪个系统进行通信以获得数据。它确保旧系统不需要改变，而现代系统也不会在其设计和技术上妥协。
结论
微服务架构为开发者提供了很大的灵活性，但随着需要管理的组件数量的增加，也带来了很多挑战。在这篇文章中，我们谈到了最重要的设计模式，这些设计模式对于构建和开发微服务应用程序至关重要。
