微服务篇：什么是同步式微服务

微服务可以通过事件（本书所建议的方法）实现成异步的形式，或者实现成同步的形式（同步服务通常出现在面向服务的架构中）。同步的微服务通常采用“请求–响应”的方法来实现，服务间通信直接通过 API 来满足业务需求。

同步式微服务的缺点

同步式微服务有很多问题，这使得它们难以大规模地使用。这并不是说一个公司不能用同步式微服务来获得成功，Netflix、Lyft、Uber 和 Facebook等公司的成功就证明了这一点。但是也有许多公司使用过时的、混乱的意大利面式代码和单体应用发了大财，所以不要把公司的最终成功与底层架构的质量混为一谈。市面上有许多介绍如何实现同步式微服务的图书，可以读读它们以更好地理解同步方法。

例如由 Sam Newman 所著的《微服务设计》以及由 Kasun Indrasiri 和 Prabath Siriwardena合著的 Microservices for the Enterprise。

此外，请注意，无论是点到点的“请求–响应”型微服务还是异步的事件驱动型微服务，严格来说都没有绝对的优劣之分。在一个组织里它们都有自己的一席之地，因为有些任务更适合采用其中的一种模式。然而，我以及我的许多同行和同事的经验表明，事件驱动型微服务架构提供了无与伦比的灵活性，这是同步的“请求–响应”型微服务所不具备的。当你继续阅读本书时可能会同意我的观点，至少你会了解它们的优缺点。

以下是同步的“请求–响应”型微服务的几大缺点。

点到点的耦合

同步的微服务依赖其他服务来帮助它们执行业务任务。那些服务同样有自己的依赖服务，而这些依赖服务又有自己的依赖服务，以此类推。这会导致过度的扇出，且难以跟踪哪些服务要为实现业务逻辑的特定部分负责。服务之间的连接数量多得惊人，这会进一步增强现有的沟通结构并使得未来的变更更加困难。

有依赖的可伸缩性

你自身服务的扩容能力依赖于所有依赖服务的扩容能力，并且直接与通信的扇出程度有关。实现技术可能是可伸缩性的瓶颈。高度变化的负载和激增的请求模式会使情况更加复杂，所有这些都需要在整个体系架构内同步处理。

服务故障的处理

如果一个依赖服务关闭，则必须做出如何处理这个异常的决策。生态系统中的微服务越多，决定如何处理停机、何时重试、何时失败以及何时恢复以确保数据一致性就越困难。

API 版本和依赖管理

多个 API 定义和服务版本通常需要同时存在。强制让客户端升级到最新的API 并不总是可行或可取的。这会增加跨多个服务协调 API 更改请求的复杂性，特别是当它们伴随着对底层数据结构的更改时。

数据访问耦合于实现

同步的微服务在访问外部数据时会遇到所有跟传统的服务相同的问题。虽然有减少访问外部数据需求的服务设计策略，但微服务通常还是需要访问来自其他服务的通用数据。这就把数据访问和可伸缩性的责任重新放在了实现沟通结构上。

分布式的单体应用

服务可以被组合成一个分布式的单体应用，在它们之间进行许多相互交织的调用。这种情况通常出现在团队分解一个单体应用，并决定使用同步的点到点调用来模拟这个单体应用内部的边界时。点对点的服务可以很容易地模糊界限上下文的边界，因为对远程系统的函数调用可以一行一行地插入现有单体式代码。

测试

集成测试可能很困难，因为每个服务都需要完全可操作的依赖项，而这些依赖项又需要自己的依赖项。在单元测试中将它们截取出来可能是可行的，但并不足以满足更广泛的测试需求。

同步式微服务的优点

同步式微服务有许多不可否认的优点。一些数据访问模式很适合直接的“请求–响应”耦合，比如验证用户身份和 AB 测试中的上报。与外部第三方解决方案的集成大多数时候使用同步机制，并且通常使用 HTTP 以提供一种灵活的、与语言无关的通信机制。

跟踪跨多个系统的操作在同步环境下会比异步环境下更简单。详细的日志可以显示在哪些系统上调用了哪些函数，从而实现业务操作的高度可调试性和可见性。

承载 Web 和移动体验的服务通常由“请求–响应”设计提供支持，无论它们是同步还是异步性质。客户会收到完全满足了其需求的及时响应。经验因素也是非常重要的，尤其是当今市场上的许多开发者往往对同步、单体类型的编码更有经验。总的来说，这使得获取熟悉同步系统的人才比获取熟悉异步事件驱动开发的人才更容易。

　一个公司的架构很少完全基于事件驱动型微服务。混合式架构肯定会成为常态，同步和异步的解决方案会根据问题空间的需要进行并行部署。

小结

沟通结构指导着在组织的整个生命周期中如何创建和管理软件。数据沟通结构通常是开发不完全且临时的，但是，如事件驱动系统所体现的那样，引入一组持久的、易于访问的领域事件可以使得更小的、专门构建的实现得以应用