系统设计基础7：发布订阅和请求响应

我们在微服务的基础上，继续介绍微服务之间通信的两种方式：请求响应和发布订阅，以及它们各自的一些实现细节和优缺点比较。

请求响应(Request/Response)

架构图

下图是采用请求响应方式设计的架构图。客户端的请求先发送到S0，S0继续将请求同时发送给S1和S2，这里并不关心发送的先后顺序。S2在接收到请求后，再将请求发送给S3和S4。当S3和S4完成对请求的处理后，将响应发送给S2。S0在接收到S1和S2的响应后，在处理后将最终的响应返回给客户端。

请求-响应

优缺点分析

• 优点：
  • 其实也没什么优点，这是大部分设计比较能直接想到的通信方式。
• 缺点：
  • 失败的请求耗时较长：如果S4出现故障，S2等待S4的响应直到超时，相应的，S0和客户端也会等待到超时。
  • 数据一致性问题：如果S4出现故障，因为请求已经经过了S0，S0的数据库数据已经修改，但S2的数据未修改。当请求再次发送时，会再次修改S0的数据，同时修改S2的数据，导致S0和S2的数据不一致。

发布订阅(Publisher/Subscriber)

架构图

发布订阅的架构图和请求响应的区别在于，微服务之间的通信是通过消息队列完成的，某服务需要请求其他服务时，将请求的相关信息封装成消息，发送到消息队列中，其他服务订阅该消息队列，获取信息并处理请求。

发布-订阅

优缺点分析

• 优点：
  • 解耦：每个服务互相之间无依赖，都统一和消息队列进行交互。服务的调用方将消息发送到消息队列后，当前请求的处理就完成了。
  • 提升可靠性：当订阅者的服务中断时，消息会持久化在消息队列中，当服务恢复时继续处理，不需要发布者重新发送消息。
  • 部分事务性：由于每条在消息队列中的消息，即使当时服务中断无法处理，未来也一定会被处理，因此提供了一定的事务性保证。
  • 简化交互：消息的发布者可以发送更加通用的消息到消息队列中，而不关心订阅者如何使用的，不存在请求响应中需要讨论接口定义的问题。
  • 提升可扩展性：如果需要开发一个新的服务S6，经过S0的请求都要调用S6，那么只需要让S6订阅S0发布的消息队列即可，而不需要对S0进行改动。
• 缺点：
  • 数据一致性问题：假如S1和S2同时处理一条消息，S1处理完成，但S2服务中断未完成，此时S1处理完成的状态无法恢复，导致后续的数据状态出现错误。该问题的处理方法会在以后的文章中介绍。
  • 幂等性问题：如果S2在将消息发送到消息队列时出现失败，可能导致S2中的处理逻辑重复执行，如果这部分逻辑需要修改服务的内部状态或者数据库，重复执行将导致同一变化被执行多次。一种解决方法是将每次修改和Request ID绑定，如果已经处理过的Request ID就会忽略，避免重复执行。但这些必须由用户的代码保证，架构本身没有幂等性保证。

小结

这两种架构设计方式是各有优缺点的，比如对于事务性要求较高的财务系统，使用发布订阅的方式需要做很多事务性的保证；如果是像Twitter这样的系统，就很适合使用发布订阅的方式设计了，具体还是要按需考虑。

欢迎大家订阅专题，其中包含了系统设计基础系列的全部文章：System Design