常見MQ技術
MQ （MessageQueue），中文是消息隊列，字面來看就是存放消息的隊列。也就是事件驅動架構中的Broker。
支援的協定越多，以後能幹的事情就越多
RabbitMQ、RocketMQ、Kafka都是能夠支援分布式叢集
兩種通信方式比較
大多數情況下會使用同步，對并發沒有很高的要求，但是對時效性有很高的要求，因為我希望我查詢到的資訊立馬就在下面的業務中用到，那必須得用同步調用。
而如果說不需要對方的結果，隻是希望對方能幹一件事情，對吞吐量的要求、并發的要求較高，還希望解除服務間的耦合關系，那此時應該使用異步通信。
1、同步通信
微服務間基于Feign的調用就屬于同步方式。以下圖為列
其優點：時效性較強，可以立即得到結果。
缺點：
- 耦合度高：每次加入新的需求，都要修改原來的代碼
- 性能下降：調用者需要等待服務提供者響應，如果調用鍊過長則相應時間等于每次調用的時間之和。
- 資源浪費：調用鍊中的每個服務在等待響應過程中，不能釋放請求占用的資源，高并發場景下會極度浪費系統資源
- 級聯失敗:如果服務提供者出現問題，所有調用方都會跟着出問題，迅速導緻整個微服務叢集故障
2、異步通信
異步調用常見實作就是事件驅動模式
- 服務解耦合
- 性能提升，吞吐量提高
因為之前我們支付服務要調取訂單服務、倉儲服務、短信服務等，每個服務都有一定的耗時，總耗時就是四個服務的耗時之和；
而現在支付服務向broker釋出事件，這個時候支付服務就可以立即結束告訴使用者支付成功了（後續的訂飯服務、倉儲服務、短信服務和支付服務是沒有關系的），後續的服務由Broker去通知他們完成，而他們什麼時候完成，耗時多久和支付服務并沒有任何的關系，隻能能做完就行。
是以業務的總耗時變成了支付時間耗時+釋出支付成功事件耗時
此時我們支付服務的總耗時是60ms
- 服務沒有強依賴，不擔心級聯失敗問題
比如倉儲服務挂掉了，但是和支付服務沒關系了。支付服務釋出完就結束了，是以後面的所有的服務挂掉了都和支付服務沒有關系。
- 流量削峰
Broker就像一個大壩，壓力都由Broker扛着
- 依賴于Broker的可靠性、安全性、吞吐能力
假如Broker崩掉之後也會對後續的服務造成很大的影響
- 架構複雜了，業務沒有明顯的流程線，不好追蹤管理
将來出了問題不好排查