通信是微服务应用的一个基本要素。微服务相互通信才能完成有用的工作。微服务会向其他微服务发送命令通知和请求操作，开发者选择的通信方式也决定着所开发的应用的结构。
何时使用同步消息
同步消息通常是首先会想到的设计方案。它们非常适合于那些在执行新的操作前需要获取前一个操作的数据结果或者确认前一个操作成功还是失败的场景。
左边的服务构造要发给接收方的消息，然后采用一种传输机制（如HTTP）来将消息发送出去。目标服务会收到这条消息并相应地进行处理。
1．选择传输方式
无论是选择RESTful HTTP、RPC库还是选择其他传输方式，都会影响服务的设计方案。每种传输方式都具有不同的特性，这些特性包括时延、语言支持情况和规范性。比如gRPC支持生成使用Protobuf的客户端/服务器端的API契约，而HTTP与消息的上下文无关。在应用中，只使用一种同步传输方式能产生规模效益，这样也更易于通过一些监控和工具来排查问题。
微服务的关注点分离也同样重要。应该将传输方案的选择与服务的业务逻辑拆分开，服务不需要了解HTTP状态码或者gRPC的响应流。这么做有助于在未来应用演进时替换为另一种不同的机制。
同步消息的缺点如下：
1）服务之间耦合更紧，因为服务必须知道协作者的存在。
2）不能很好地支持广播模型以及发布-订阅模型。这限制了执行并行工作的能力。
3）在等待响应的时候，代码执行是被阻塞的。在基于线程或者进程的服务模型中，这可能会耗尽资源并触发连锁故障。
（4）过度使用同步消息会导致出现很深的依赖链，而这又会增加调用路径整体的脆弱性。
何时使用异步消息
异步消息更加灵活。开发者可以通过事件通知的方式来扩展系统处理新的需求。因为服务不再需要了解下游的消费者。新服务可以直接消费已有的事件，而不需要对已有的服务进行修改。
事件（event）表示了事后（post-hoc）的状态变化。
这种方式下，应用演化更加平滑，服务间的耦合更低。但是付出的代价是：异步交互更加难以理解，因为整个系统行为不再是那种显式的线性顺序。系统行为变得更加危险——服务间的交互变得不可预测——需要在监控上增加投入来充分地跟踪所发生的情况。
异步消息通常需要一个通信代理（communication broker），这是一个独立的系统组件，负责接收事件并把它们分发给对应的消费者。有时候也叫作事件中枢（event backbone），这也表明了这个组件对整个应用是多么重要。常用作代理的工具包括Kafka、RabbitMQ和Redis。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论