微服务是一种架构范例。在这种架构中，多个小型独立组件协同工作，从而构成一个系统。尽管它的操作复杂性较高，但这种范式已经被迅速采用。这是因为它有助于将复杂的系统分解为可管理的服务。这些服务更关注微观层面的问题，包括单一责任，关注点分离，模块化等。
微服务模式是一个系列博客。每篇博文都将聚焦一种微服务的架构模式，分析其可行性并概述它们适用的场景。所有这一切都要遵守各系统间相互制约的设计约束。
服务间通信和执行流程是分布式系统的基础，它可以是同步的也可以是异步的。这两种方法都有其利弊，本博客试图详细剖析各种选择并分析其影响。
维度每种实现方式都可以从多种维度进行权衡。从这些维度对权衡点和系统约束进行评估，有助于我们分析其可行性和适用性。每种实现方式都有折衷。与此同时，考虑中的系统可能有各种各样的维度。根据这些限制评估取舍可以帮助我们推断方法和适用性。系统的各个维度都会影响系统的执行流程和通信方式，下面我们来看看其中的一些维度。
消费者系统的消费者可以是外部程序，网页/手机接口，物联网设备等。消费者应用程序通常会同步处理服务器，并期望接口支持。用消费者的统一接口掩盖分布式系统的复杂性也是可取的，必要条件是，我们的通信方式选择能带来便利。
工作流管理业务工作流贯穿多个服务，因此，业务工作流的管理至关重要。它可以是隐含的，并且可以发生在每个服务上，因此仍然分布在各个服务中。换言之，它可以是明确的。协调器服务可以承担协调业务流程的责任。编排是两者的结合。工作流规范规定了执行顺序和对服务的实际调用。协调器与参与服务遵循的通信范式紧密相关。通信风格和执行流程推动了协调器的实现。
第三个选项是基于事件编排的设计，通过一个将所有服务绑定的事件总线来代替编排器。
所有这些都是系统中的工作流管理机制，我们将在本系列的后续篇章详细介绍工作流程管理。在我们评估和选择通信方式时，我们会考虑当前上下文中与其相关的约束条件。
读/写频率偏差系统的读/写频率可能是其体系结构中的关键因素。一个读取繁重的系统需要大部分操作同步完成。一个很好的例子就是大规模运营的天气预报服务的公共API。或者，写入繁重的系统可从异步执行中受益。一个例子就是一个平台，无数物联网设备都在不断报告数据。当然，它们之间也有系统。由于读写偏斜，有时候倾向于一种风格是有用的。在其他时候，将读取和写入拆分为单独的组件可能是有意义的。
在我们审视各种方法时，我们需要保持这些约束。这些维度将帮助我们提取每种实现方式的适用性。
同步同步通信是调用方等待响应可用的通信方式，是一个突出并得到广泛使用的方法。简单且直观的概念使其适用于大多数情况。
同步通信与HTTP协议密切相关。但是，其他协议仍然是实现同步通信的合理方式。另一个很好的例子是RPC调用，每个组件都公开一个其他服务所调用的同步接口。
入口点附近的拦截器拦截业务流程请求，然后将请求推送到下游服务，所有的后续调用本质上都是同步的。这些调用可以是并行或顺序的，直到处理完成。系统内的调用处理可能会有不同的方式。一个编排者可以显式调度所有的调用，或者调用可以跨组件有机地渗透。下面我们看看几个可能的机制。
变化在同步系统中，架构可以采用几种方法，以下简要说明各种方法的可行性。
去中心化和同步
去中心化的同步通信方式在入口点拦截流量，拦截器将请求转发到下一步并等待响应，该循环一直下行，直到所有服务都已完成执行，每个服务可以顺序或并行执行一个或多个下游服务。
虽然实现很简单，但流程细节分布在整个系统中，从而导致组件之间的耦合。
这些调用在整个系统中保持同步。因此，这种通信方式可以满足同步消费者的期望。由于分布式工作流的性质，该方式缺少灵活性，并不适用于经常更改的复杂工作流。由于对系统的每个请求都可能阻塞服务，因此对于读/写频率高的系统来说，这并不理想。
编排、同步和顺序
同步通信的一种变体带有中央编排器，编排器仍然是拦截服务。它处理传入的工作流定义请求并将其转发到下游服务，并接受响应（如下图所示）。在处理请求过程中，编排器一直在对服务进行调用。