微服务通信策略

在 GeeCON 2018 大会上， Michael Plöd 在一场介绍微服务之间不同的通信策略的演讲中解释说，在从单体架构迁移到微服务架构时，暗含在单体架构中的复杂性会明确显露出来，通信挑战将呈指数级增长。

Plöd 是 InnoQ 首席顾问。他首先指出，根据他的经验，团队经常把微服务视为默认架构。他强调，分布式系统是高难度的系统；如果你不需要一个分布式系统，你就不必为了微服务而力争实现那样的架构。在这种情况下，构建良好的单体通常是更好的选择。

当单体不满足需求而使用微服务时，必须把它们集成，Plöd 指出，这不只是技术问题，还有其他方面的影响：

• 团队之间需要通过沟通来解决集成问题，这可能会导致政治和治理问题。
• 耦合：实现服务之间的松耦合非常重要，否则，你很容易最终得到一个分布式单体。
• 质量标准：在一致性、性能、可扩展性、健壮性方面，找出真正需要的是什么，你应该尽早评估你的应用程序。
• 技术：虽然 REST 很常用，但那不是唯一的通信选项。

为了帮助团队通信及管理耦合，Plöd 指出，领域驱动设计（DDD）对在业务层面找出边界非常有帮助——有界上下文。这些上下文彼此之间通常以不同的方式进行交互，为了描述它们之间的关系，可以使用上下文映射。这些交互模式包括：

• 打开主机服务：指定一个可供服务使用的协议，如 REST；
• 共享内核：两个服务可以共享部分代码或定义交互的库；
• 消费者 / 供应商：一个服务是另一个服务的消费者，因此，可能会影响它的实现；
• 防腐层：消费者服务创建一个适配器，最小化它与之交互的另一个服务所带来的影响。

看下通信的技术方面，Plöd 首先介绍了通信的一般分类——Orchestration_ 和 _Choreography。使用 Orchestration，微服务知道过程，会主动调用其他服务来完成任务。使用 _Choreography_，微服务会发布一个事件，其他服务会响应事件，完成相应的动作。在 Plöd 看来，这是一个重要的区别，他认为，我们应该就系统首选的工作方式做架构决策。他还建议考虑宏架构和微架构，并指出，微服务并不是说团队可以随意选择他们喜欢的东西，因为那样做的话，你最终会陷入完全的混乱。相反，他建议采用一种有规则的宏架构，所有团队都必须遵守这些规则。在微架构中，团队有更大的自由，可以选择他们自己的实现风格。

让我们看下通信的技术选项，Plöd 指出了四种类型：

• RESTful 资源
• 消息传递
• 领域事件
• 订阅

虽然 REST 如今已经广为人知，但根据 Plöd 的经验，只有很少团队很好地实现了，尤其是在超媒体和多表示形式方面。他指出，实现一个 RESTful 资源调用非常简单，但是，实现一个可以在微服务环境中正常运行的健壮调用要困难许多。以下是需要知道的一些陷阱和挑战：

• 服务发现：一种服务用来发现它与之通信的服务的 URL 的方式。
• 弹性：包括如何处理错误和宕机。服务的优雅退化非常重要，可以避免异常服务使整个应用程序性能下降。
• 负载均衡：可以处理不断增长的负载。有许多不同的实现方法，使用哪种方法取决于应用程序的运行环境。

下一个选项是消息传递，微服务发送和消费消息，通常是通过一个消息代理。下面描述的这些有关 REST 的挑战不是很切题：

• 服务发现已经没意义，因为服务仅知道消息系统。
• 弹性主要由消息系统处理。主要的风险是延迟因为错误或宕机增加。
• 负载均衡是通过向上扩展消息系统或增加消息消费者数量来实现的。

Plöd 的第三个选项是领域事件。它们表示过去在业务层面上已经发生的事实。使用它们进行通信会得到事件驱动的微服务，现如今，这是一种非常流行的架构风格。当使用事件通信时，对于事件中的有效载荷，他介绍了几个可选方案：

• 满负载模式：事件中包含处理事件所需的所有数据，例如关于客户的所有数据。这可以简化消费者的工作，但也意味着更紧密的耦合。
• REST URL：只有一个指向代表事件的资源的 URL。
• 空模式：仅包含关于事件本身的数据。消费者必须通过其他方式找到它需要的数据。
• 混合模式：比如，有少量的数据和一个用于找到其他数据的 URL。在大多数情况下，这都是 Plöd 首选的方式。

Plöd 最后的选项是使用 Atom Feeds 组合 REST 和事件。现在，服务会利用事件发布推送信息，消费者订阅并异步读取。在大多数环境中，使用 HTTP 都非常容易通信，而且可以利用像 ETags 、最后修改时间、分页和链接这样的特性。另外一个好处是，服务发布推送信息，可以从消费者完全解耦。推送消息的读取完全是由消费者按照它们认为恰当的方式进行的，而且，已消费事件的跟踪也是由消费者完成的。

为了提供推送消息，事件必须持久化，这就轮到事件源登场了。我们可以使用这些事件作为我们主要的持久化模型，这还使得我们可以使用 CQRS 来获得视图，这些视图是经过优化的事件读取模型。Plöd 特别指出，CQRS 和事件源只是系统特定部分的解决方案，而不代表系统中随处都在使用的架构。

要了解更多有关集成的信息，Plöd 强烈推荐由 Gregor Hophe 和 Bobby Wolf 所著的 _ Enterprise Integration Patterns _ 一书。

查看英文原文： Strategies for Microservices Communication