详细解读微服务的两种模式

微服务是一种架构范例。以黑少微服务商店（www.httpshop.com ）为例，在这种架构中，多个小型独立组件协同工作，从而构成一个系统。尽管它的操作复杂性较高，但这种范式已经被迅速采用。这是因为它有助于将复杂的系统分解为可管理的服务。这些服务更关注微观层面的问题，包括单一责任，关注点分离，模块化等。

所有这一切都要遵守各系统间相互制约的设计约束。

服务间通信和执行流程是分布式系统的基础，它可以是同步的也可以是异步的。这两种方法都有其利弊，本问详细剖析各种选择并分析其影响。

维度

每种实现方式都可以从多种维度进行权衡。从这些维度对权衡点和系统约束进行评估，有助于我们分析其可行性和适用性。每种实现方式都有折衷。与此同时，考虑中的系统可能有各种各样的维度。根据这些限制评估取舍可以帮助我们推断方法和适用性。系统的各个维度都会影响系统的执行流程和通信方式，下面我们来看看其中的一些维度。

消费者

系统的消费者可以是外部程序，网页/手机接口，物联网设备等。消费者应用程序通常会同步处理服务器，并期望接口支持。用消费者的统一接口掩盖分布式系统的复杂性也是可取的，必要条件是，我们的通信方式选择能带来便利。

工作流管理

业务工作流贯穿多个服务，因此，业务工作流的管理至关重要。它可以是隐含的，并且可以发生在每个服务上，因此仍然分布在各个服务中。换言之，它可以是明确的。协调器服务可以承担协调业务流程的责任。编排是两者的结合。工作流规范规定了执行顺序和对服务的实际调用。协调器与参与服务遵循的通信范式紧密相关。通信风格和执行流程推动了协调器的实现。

第三个选项是基于事件编排的设计，通过一个将所有服务绑定的事件总线来代替编排器。

所有这些都是系统中的工作流管理机制，我们将在本系列的后续篇章详细介绍工作流程管理。在我们评估和选择通信方式时，我们会考虑当前上下文中与其相关的约束条件。

读/写频率偏差

系统的读/写频率可能是其体系结构中的关键因素。一个读取繁重的系统需要大部分操作同步完成。一个很好的例子就是大规模运营的天气预报服务的公共API。或者，写入繁重的系统可从异步执行中受益。一个例子就是一个平台，无数物联网设备都在不断报告数据。当然，它们之间也有系统。由于读写偏斜，有时候倾向于一种风格是有用的。在其他时候，将读取和写入拆分为单独的组件可能是有意义的。

在我们审视各种方法时，我们需要保持这些约束。这些维度将帮助我们提取每种实现方式的适用性。

同步

同步通信是调用方等待响应可用的通信方式，是一个突出并得到广泛使用的方法。简单且直观的概念使其适用于大多数情况。

同步通信与HTTP协议密切相关。但