在初始约束固定的情况下，工作流管理在这种方法中更加灵活。工作流更改对编排器来说仍然是本地化的，并保有一定的灵活性，由于通信是同步的，所以同步消费者可以在没有中介组件的情况下进行通信。但是，编排器需要持续保持所有活动请求，这使得编排器比其他服务承担更重的责任，也容易导致单点故障。这种风格的架构仍然适合读取繁重的系统。
编排，同步和并行
在之前的方法基础上的一个小改进是使独立请求可以并发，这可以获得更高的效率和性能。由于这个责任属于编排器，所以很容易做到。工作流管理已经集中，需要做的只是更改声明以区分并行和顺序调用。这可以提高流程执行速度，通过缩短响应时间，协调器可以获得更高的吞吐量。
工作流管理比以前的方法更复杂，但它仍然可能是一个合理的折衷方案，因为它可以提高吞吐量和性能并同时保持消费者的通信同步。由于其同步特性，该系统对于读取型架构来说仍然更好。
尽管同步调用更易于掌控，调试和实现，但在分布式环境中实施则需要一些权衡。
平衡能力
它要求有意平衡所有服务的能力。一个组件上的流量激增可能淹没其他服务请求。在异步通信中，队列可以缓解流量激增。同步通信缺少这种中介，需要服务容量在流量激增期间进行匹配。如果做不到这一点，可能会出现级联故障。另外，像断路器这样的弹性范例可以帮助缓解同步系统中的流量激增。
级联故障的风险
同步通信使上游服务在微服务架构中容易出现级联故障。如果下游服务出现故障或最坏情况，则需要很长时间才能回应，资源会很快耗尽。这可能会导致系统产生多米诺骨牌效应。可能的缓解策略可能涉及一致的错误处理，合理的超时时间以及执行服务质量保障协议。在同步环境中，一个服务会立即影响到其他服务。如前所述，通过实施舱壁架构或断路器可防止级联错误。
增加负载平衡和服务发现开销
通过将参与服务放置在负载均衡器后面可以解决其冗余和可用性需求。这增加了每个服务的隔离级别。此外，每项服务都需要加入中央服务发现设置，这允许它推送它自己的地址并解析下游服务的地址。
耦合
同步系统会在一段时间内表现出更紧密的耦合。服务之间没有抽象，服务直接和其他服务的合同绑定。这在一段时间内产生了强烈的关联。对于合同中的简单更改，拥有的服务不得不在早期采用版本控制。它增加了系统的复杂性，或者会导致与合同相关的所有消费者服务的变化。
随着服务网格等新兴架构范例的出现，有可能解决一些陈述的问题。Istio，Linkerd，特使等工具，允许服务网格创建。这个社区正在成熟并且充满希望，它可以帮助构建同步的，解耦的和容错的系统。
异步异步通信非常适合分布式体系结构。它不需要等待响应，从而将两个或多个服务的执行分开。异步通信的实现有几种方式，通过RPC（例如，grpc）或通过中介消息总线直接调用远程服务就是一些例子。编排消息传递和事件编排都使用消息总线通道。
中央消息总线的一个优点是一致的通信和消息传递语义。这给服务间的直接异步通信带来了巨大的便利。我们通常使用像消息总线这样的媒介来保证跨服务通信的一致性。下面将基于使用中央消息管道的假设来讨论的异步通信的种类。
变体异步通信可以更好地处理流量激增。体系结构中的每个服务都会生成消息，消费消息或执行两者。我们来看看这种范式的不同变体。
异步事件协同
在这种方法中，每个组件监听中央消息总线并等待事件，事件的到来是执行的信号，执行所需的任何上下文都是事件有效负载的一部分，触发下游事件是每个服务所拥有的责任。基于事件的体系结构的目标之一是将组件分离，不幸的是，需要在设计层面满足这种需求。
通知组件接受到事件时可能电子邮件或SMS发送。由于所有其他服务需要做的事情是生产事件，因此它看起来可能是彼此分离的。但是，确实需要有组件承担决定通知类型和内容的责任，通知可以根据传入的事件信息做出该决定，如果发生这种情况，我们就已经建立了通知和上游服务之间的耦合。如果上游服务将此作为有效负载的一部分，则他们仍然感觉到下游的流量。
即便如此，事件协同也非常适合需要发生的隐式操作。比如错误处理，通知，搜索索引等。
这种体系结构遵循分散的工作流程管理。该体系结构适合写入繁重的系统。缺点是同步读取需要协调，并且工作流会在系统进行广播。
编排、异步和顺序
我们可以从我们的协调同步通信方法中借鉴一些。我们可以通过中央编排器建立异步通信。