发布订阅模型在微服务架构下的服务间通信中的思考

前言

之前看过一篇文章是 一登微服务架构配置文件存放，找了好久 连接没有找到。
大体意思是， 微服务由于服务众多，节点众多，就有个问题，是如何管理如此众多的服务配置。作者的是通过redis来实现集中管理，有一个中心redis节点，存放着所有redis服务之间的配置，达到节点配置管理集中化，易于操作。

思考

如此情况下，只是达到了，部署服务的简单化。本文讨论的是 微服务之间的通信。
微服务，以在将服务 简单化，将服务细分，这样单服务处理的事情简单化。这样无论是对于开发还是维护都是十分实用。但是服务细分，就难免遇到一个问题，服务间如何通信呢？

解决方案

我之前用HTTP API的方式来达到服务间通信，但是经常基于同一事件，会不断的加新需求，乃至随着新需求要加新服务，那么基于一个服务A的一个A1事件，可能需要很多服务去处理，而如果使用传统HTTP方式，则每添加一个新的服务就要在A的A1事件上加一个HTTP请求，这样也就是每次都要改老代码， 需要改其他服务的代码。 所以，在这里我们引入消息队列的发布订阅模型，每个事件 订阅一个channel，其他服务如需处理，只需订阅此channel即可，这样原先代码不需修改，新代码，可以在毫无影响老代码的基础上开发，省时省力。

PS

本文 还未实践，并且 本文只适用于 不需返回处理结果的 通信需求，如需其他服务返回处理结果，发布订阅模型并不适用。