分佈式的本質就是多進程協作，共同完成任務，彼此之間肯定需要通信
1 遠程調用
不同機器中運行的進程之間的相互通信，常用的是RPC，這個大家應該都懂，不說了~
大家可以看看dubbo，內部就是RPC+註冊中心實現的
2 發佈訂閱
RPC進程之間是直接交互的，當進程比較多時，會導致進程維護通信的複雜度非常高，且一個進程通信接口改變，與其通信的進程都會受到影響；
隨着業務和分佈式計算規模的逐漸增大和複雜化，出現了專門的異步通信模式，也就是消息發佈訂閱模式和消息隊列模式，首先講解發布訂閱
原理：生產者消費者
看圖就很清晰了，發佈和訂閱可以是一對一、一對多，核心就在於消息中心
場景：kafka，需要消費者提前向消息中心訂閱消息，比較適合消費者爲長駐進程或服務的場景。
發佈訂閱模式很類似觀察者模式，其區別在於：
觀察者模式採用直接通信，觀察者和被觀察者通信時延會低一些，但它們的依賴關係比較強，不管是被觀察者還是觀察者邏輯或接口有更改，另外一個均會受影響；
發佈者和訂閱者模式採用間接通信，引入了消息中心，相對比較厚重，且通信時延相對會高一點，但實現了訂閱者與發佈者的解耦
3 消息隊列
發佈訂閱模式是發佈者產生數據到消息中心，訂閱者訂閱自己感興趣的消息，消息中心根據訂閱者的訂閱情況，
將相關消息或數據發送給對應的訂閱者，可以理解爲“推”
也可以用“拉”，將消息或數據放到一個隊列裏，誰需要誰就去隊列裏面取，這種模式就是消息隊列模式
場景：RocketMQ，這種模式對消費者沒有特別需求，因此比較適合消費者爲臨時用戶的場景，比較靈活
消息中心對比：消息隊列模式中採用了具有先進先出特徵的隊列結構進行存儲，而訂閱發佈採用了 map 或數組等方式存儲