你好,我是胡忠想。今天我继续来给同学们做答疑,第二期答疑主要涉及微服务架构、注册中心和负载均衡算法,需要一定的基础,如果对这些内容不了解,可以先返回专栏第 14 期、第 17 期和第 18 期复习一下。 专栏里我主要讲的是基于 RPC 通信的微服务架构,除此之外还有一种微服务架构是基于 MQ 消息队列通信的,下面我就从这两种架构不同的适用场景来给你讲讲它们的区别。
基于 RPC 通信的微服务架构,其特点是一个服务依赖于其他服务返回的结果,只有依赖服务执行成功并返回后,这个服务才算调用成功。这种架构适用于用户请求是读请求的情况,就像下图所描述的那样,比如微博用户的一次 Feed API 请求,会调用 Feed RPC 获取关注人微博,调用 Card RPC 获取微博中的视频、文章等多媒体卡片信息,还会调用 User RPC 获取关注人的昵称和粉丝数等个人详细信息,只有在这些信息都获取成功后,这次用户的 Feed API 请求才算调用成功。
而基于 MQ 消息队列通信的架构,其特点是服务之间的交互是通过消息发布与订阅的方式来完成的,一个服务往 MQ 消息队列发布消息,其他服务从 MQ 消息队列订阅消息并处理,发布消息的服务并不等待订阅消息服务处理的结果,而是直接返回调用成功。这种架构适用于用户请求是写请求的情况,就像下图所描述的那样,比如用户的写请求,无论是发博、评论还是赞都会首先调用 Feed API,然后 Feed API 将用户的写请求消息发布到 MQ 中,然后就返回给用户请求成功。如果是发博请求,发博服务就会从 MQ 中订阅到这条消息,然后更新用户发博列表的缓存和数据库;如果是评论请求,评论服务就会从 MQ 中订阅到这条消息,然后更新用户发出评论的缓存和数据库,以及评论对象收到评论的缓存和数据库;如果是赞请求,赞服务就会从 MQ 中订阅到这条消息,然后更新用户发出赞的缓存和数据库,以及赞对象收到的赞的缓存和数据库。这样设计的话,就把写请求的返回与具体执行请求的服务进行解耦,给用户的体验是写请求已经执行成功,不需要等待具体业务逻辑执行完成。