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

微服务架构设计模式

基于微服务的应用程序的主要特征在微服务，Monoliths和NoOps中定义。 它们是功能分解或领域驱动的设计，定义明确的接口，显式发布的接口，单一职责原则以及潜在的多语言。 每个服务都是完全自治的和全堆栈的。 因此，更改服务实现对其他服务使用定义良好的接口进行通信不会产生任何影响。 这样的应用程序有几个优点，但是它不是免费的午餐，并且在NoOps中需要付出很大的努力。

但是可以说，您了解构建这样的应用程序并愿意跳出伞所需的努力，或者至少是其中的一些工作。 你是做什么？ 您设计此类应用程序的方法是什么？ 这些微服务如何相互配合，是否有任何设计模式？

应用程序和团队的功能分解是构建成功的微服务架构的关键。 这使您可以实现松散耦合（REST接口）和高内聚性（多个服务可以相互组合以定义更高级别的服务或应用程序）。

应用程序的动词（例如Checkout）或名词（乘积）是实现现有应用程序分解的有效方法之一。 例如，产品，目录和结帐可以是三个单独的微服务，然后相互配合以提供完整的购物车体验。

功能分解可提供敏捷性，灵活性，可伸缩性和其他功能，但业务目标仍然是创建应用程序。 因此，一旦确定了不同的微服务，您如何组合它们以提供应用程序的功能？

该博客将讨论有关如何将微服务组合在一起的一些推荐模式。

聚合器微服务设计模式

第一个，也许是最常见的，是聚合器微服务设计模式。

以最简单的形式，Aggregator将是一个简单的网页，可以调用多个服务来实现应用程序所需的功能。 由于每个服务（服务A，服务B和服务C）都是使用轻量级的REST机制公开的，因此网页可以检索数据并相应地处理/显示数据。 如果需要某种处理，例如将业务逻辑应用于从各个服务接收的数据，那么您可能会拥有一个CDI bean，该数据将转换数据以便可以在网页上显示。

Aggregator的另一个选择是不需要显示，而只是一个更高级别的复合微服务，可以被其他服务使用。 在这种情况下，聚合器将只从每个单独的微服务收集数据，对其应用业务逻辑，然后将其作为REST端点发布。 然后，其他需要它的服务可以使用它。

此设计模式遵循DRY原理。 如果有多个服务需要访问服务A，B和C，则建议将该逻辑抽象为一个复合微服务并将该逻辑聚合为一个服务。 在此级别进行抽象的一个优点是，各个服务（即服务A，B和C）可以独立发展，并且复合微服务仍然可以满足业务需求。

请注意，每个单独的微服务都有自己的（可选）缓存和数据库。 如果Aggregator是复合微服务，则它可能也具有自己的缓存和数据库层。

聚合器也可以在X轴和Z轴上独立缩放。 因此，如果是网页，则可以启动其他Web服务器，或者如果其使用Java EE的复合微服务，则可以启动其他WildFly实例以满足不断增长的需求。

代理微服务设计模式

代理微服务设计模式是Aggregator的一种变体。 在这种情况下，不需要在客户端上进行任何聚合，但是可以根据业务需要调用不同的微服务。

就像聚合器一样，代理服务器也可以在X轴和Z轴上独立缩放。 您可能希望在不需要将每个单独的服务都暴露给使用者的情况下执行此操作，而应该通过一个界面进行。

该代理可以是哑代理，在这种情况下，它只是将请求委托给服务之一。 替代地，它可以是智能代理 ，其中在将响应提供给客户端之前应用一些数据转换。 一个很好的例子就是可以将不同设备的表示层封装在智能代理中。

链接微服务设计模式

链接的微服务设计模式产生对请求的单个合并响应。 在这种情况下，来自客户端的请求由服务A接收，然后与服务B通信，而服务B又可以与服务C通信。所有服务都可能使用同步HTTP请求/响应消息传递。

要记住的关键部分是客户端被阻塞，直到完成完整的请求/响应链，即服务<->服务B和服务B <->服务C。 从服务B到服务C的请求可能看起来与从服务A到服务B的请求完全不同。类似地，从服务B到服务A的响应可能看起来从服务C到服务B完全不同。这就是所有不同之处服务正在增加其商业价值。

这里要理解的另一个重要方面是不要使链条太长。 这一点很重要，因为链的同步特性在客户端看起来就像是漫长的等待，尤其是当其网页正在等待显示响应时。 此阻止请求/响应有一些解决方法，将在后续的设计模式中进行讨论。

具有单个微服务的链称为单例链 。 这可以允许链在以后扩展。

分支微服务设计模式

分支微服务设计模式扩展了聚合器设计模式，并允许同时从两个可能互斥的微服务链进行响应处理。 根据业务需求，该模式还可用于调用不同的链或单个链。

网页或复合微服务的服务A可以同时调用两个不同的链，在这种情况下，这类似于Aggregator设计模式。 或者，服务A只能基于从客户端收到的请求来调用一个链。

这可以使用JAX-RS或Camel端点的路由进行配置，并且需要动态配置。

共享数据微服务设计模式

自治是微服务的设计原则之一。 这意味着该服务是全栈式的，并且可以控制所有组件– UI，中间件，持久性，事务。 这样可以使服务成为多语言，并为正确的工作使用正确的工具。 例如，如果可以使用NoSQL数据存储，而不是将数据阻塞在SQL数据库中，则更合适。

但是，一个典型的问题（尤其是从现有的单片应用程序重构时）是数据库规范化，以使每个微服务都拥有正确数量的数据-一无是处。 即使在整体应用程序中仅使用SQL数据库，对数据库进行非规范化也会导致数据重复，并可能导致不一致。 在过渡阶段，某些应用程序可能会受益于共享数据微服务设计模式。

在这种设计模式中，某些微服务（可能在链中）可能共享缓存和数据库存储。 仅当两个服务之间存在牢固的耦合时，这才有意义。 有些人可能认为这是一种反模式，但在某些情况下可能需要业务需求来遵循此模式。 对于基于微服务设计的未开发应用程序，这无疑是一种反模式。

这也可以看作是过渡阶段，直到微服务过渡到完全自治为止。

异步消息微服务设计模式

尽管REST设计模式非常普遍，并且广为人知，但是它具有同步性和阻塞性的局限性。 可以实现异步，但是可以通过特定于应用程序的方式来实现。 因此，某些微服务架构可能会选择使用消息队列而不是REST请求/响应。

在这种设计模式中，服务A可以同步调用服务C，然后使用共享消息队列与服务B和D异步通信。 服务A->服务C的通信可能是异步的，可能使用WebSockets，以实现所需的可伸缩性。

REST请求/响应与发布/订阅消息传递的组合可用于满足业务需求。

微服务中的耦合与自主性是有关为微服务选择哪种消息传递模式的很好的阅读。

希望您发现这些设计模式有用。

您正在使用哪种微服务设计模式？

翻译自: https://www.javacodegeeks.com/2015/04/microservice-design-patterns.html

微服务架构设计模式