前言

之前看過一篇文章是 一登微服務(wù)架構(gòu)配置文件存放，找了好久 連接沒有找到。
大體意思是， 微服務(wù)由于服務(wù)眾多，節(jié)點眾多，就有個問題，是如何管理如此眾多的服務(wù)配置。作者的是通過redis來實現(xiàn)集中管理，有一個中心redis節(jié)點，存放著所有redis服務(wù)之間的配置，達(dá)到節(jié)點配置管理集中化，易于操作。

思考

如此情況下，只是達(dá)到了，部署服務(wù)的簡單化。本文討論的是 微服務(wù)之間的通信。
微服務(wù)，以在將服務(wù) 簡單化，將服務(wù)細(xì)分，這樣單服務(wù)處理的事情簡單化。這樣無論是對于開發(fā)還是維護(hù)都是十分實用。但是服務(wù)細(xì)分，就難免遇到一個問題，服務(wù)間如何通信呢？

解決方案

我之前用HTTP API的方式來達(dá)到服務(wù)間通信，但是經(jīng)?；谕皇录?，會不斷的加新需求，乃至隨著新需求要加新服務(wù)，那么基于一個服務(wù)A的一個A1事件，可能需要很多服務(wù)去處理，而如果使用傳統(tǒng)HTTP方式，則每添加一個新的服務(wù)就要在A的A1事件上加一個HTTP請求，這樣也就是每次都要改老代碼， 需要改其他服務(wù)的代碼。 所以，在這里我們引入消息隊列的發(fā)布訂閱模型，每個事件 訂閱一個channel，其他服務(wù)如需處理，只需訂閱此channel即可，這樣原先代碼不需修改，新代碼，可以在毫無影響老代碼的基礎(chǔ)上開發(fā)，省時省力。

PS

本文 還未實踐，并且 本文只適用于 不需返回處理結(jié)果的 通信需求，如需其他服務(wù)返回處理結(jié)果，發(fā)布訂閱模型并不適用。