前言
之前看过一篇文章是 一登微服务架构配置文件存放,找了好久 连接没有找到。
大体意思是, 微服务由于服务众多,节点众多,就有个问题,是如何管理如此众多的服务配置。作者的是通过redis来实现集中管理,有一个中心redis节点,存放着所有redis服务之间的配置,达到节点配置管理集中化,易于操作。
思考
如此情况下,只是达到了,部署服务的简单化。本文讨论的是 微服务之间的通信。
微服务,以在将服务 简单化,将服务细分,这样单服务处理的事情简单化。这样无论是对于开发还是维护都是十分实用。但是服务细分,就难免遇到一个问题,服务间如何通信呢?
解决方案
我之前用HTTP API的方式来达到服务间通信,但是经常基于同一事件,会不断的加新需求,乃至随着新需求要加新服务,那么基于一个服务A的一个A1事件,可能需要很多服务去处理,而如果使用传统HTTP方式,则每添加一个新的服务就要在A的A1事件上加一个HTTP请求,这样也就是每次都要改老代码, 需要改其他服务的代码。 所以,在这里我们引入消息队列的发布订阅模型,每个事件 订阅一个channel,其他服务如需处理,只需订阅此channel即可,这样原先代码不需修改,新代码,可以在毫无影响老代码的基础上开发,省时省力。
PS
本文 还未实践,并且 本文只适用于 不需返回处理结果的 通信需求,如需其他服务返回处理结果,发布订阅模型并不适用。
网友评论