服务的协作：服务间的消息传递——《微服务设计》读书笔记

     在微服务集成——《微服务设计》读书笔记文章中，我们说过服务间的消息传递有几种方式，一种是请求/响应技术，另一种是基于事件的机制。

RPC（远程过程调用）

      RPC是Remote Procedure Call的简称。

      这是请求/响应技术的一种，它使用本地调用的方式和远程进行交互，如SOAP、Thrift等，比如我们常使用的WebService和Java RMI，就是这种类型。它先在本地生成桩代码，然后通过桩代码进行远程调用。

      RPC会带来一些问题，如Java RMI，其耦合性较紧，同时RPC会对调用进行大量的封装和解封装，同时修改接口时会造成服务的提供方和调用方都要修改。

 

REST

      REST是受Web启发而产生的一种架构风格，REST风格包含的内容很多，Richardson的成熟度模型（http://martinfowler.com/articles/richardsonMaturityModel.html），其中有对REST不同风格的比较。

      REST本身并没有提到底层应该使用什么协议，最常用的是HTTP，HTTP本身提供了很多功能，这些功能对于实现REST风格非常有用，比如HTTP的动词（GET、POST、PUT等）就能很好地和资源一起使用。

      在使用REST时，传输的数据格式是XML还是JSON，这个没有一个定论。

      基于HTTP的REST也有缺点：1.它无法帮你生成桩代码，2.在要求低延迟的场景下，每个HTTP请求的封装开销可能是个问题，使用TCP、UDP可能更合适。

 

基于事件的异步协作

       这种方式主要有两个部分需要考虑：微服务发布事件消费者接收事件机制。

      消息队列（如RabbitMQ）可以同进处理上述两方法的问题。生产者使用API向代理发布事件，代理可以向消费者提供订阅服务，并且在事件发生时通知消费者。这种代理甚至可以跟踪消费者的状态，如标记哪些消息是该消费者已经消费过的。这种系统通常具有较好的可伸缩性和弹性，但这么做会增加开发流程的复杂度，因为你需要一个额外的系统（即消息代理）才能开发及测试服务。

      另一种方式是使用HTTP来传播事件，ATOM是一个符合REST规范的协议，可以通过它提供资源聚合的发布服务，当服务提供方发生改变时，只需要简单地向该聚合发布一个事件即可，消费者会轮询该聚合以查看变化。它的缺点是：HTTP不擅长处理低延迟的场景，而且使用ATOM的话，用户还需要自己追踪消息是否送达及管理轮询等工作。

      异步架构有其复杂性，比如，消息丢失了怎么办？消息重试失败了怎么办？消息重发了怎么办？消息请求崩溃了怎么办？我们可以通过设置最大重试、黑名单、白名单等措施来解决这些问题。但这也意味着复杂性的增加。

 

参考

      《微服务设计》（Sam Newman 著 / 崔力强 张骏 译）