前面所說的隔離設計通常都需要對系統做解耦設計，而把一個單體系統解耦，不單單是把業務功能拆分出來，正如上面所說，拆分完後還會面對很多的問題。其中一個重要的問題就是這些系統間的通訊。
通訊一般來說分同步和異步兩種。同步通訊就像打電話，需要實時響應，而異步通訊就像發郵件，不需要馬上回複。各有千秋，我們很難說誰比誰好。但是在面對超高吐吞量的場景下，異步處理就比同步處理有比較大的優勢了，這就好像一個人不可能同時接打很多電話，但是他可以同時接收很多的電子郵件一樣。
同步調用雖然讓系統間隻耦合于接口，而且實時性也會比異步調用要高，但是我們也需要知道同步調用所帶來如下的問題。
- 同步調用需要被調用方的吞吐不低于調用方的吞吐。否則會導緻被調用方因為性能不足而拖死調用方。換句話說，整個同步調用鍊的性能會由最慢的那個服務所決定。
- 同步調用會導緻調用方一直在等待被調用方完成，如果一層接一層地同步調用下去，所有的參與方會有相同的等待時間。這會非常消耗調用方的資源（因為調用方需要儲存現場（Context）等待遠端傳回，是以對于并發比較高的場景來說，這樣的等待可能會極度消耗資源）。
- 同步調用隻能是一對一的，很難做到一對多的通訊方式。
- 同步調用最不好的是，如果被調用方有問題，那麼其調用方就會跟着出問題，于是會出現多米諾骨牌效應，故障一下就蔓延開來。
是以，異步通訊相對于同步通訊來說，除了可以增加系統的吞吐量之外，最大的一個好處是其可以讓服務間的解耦更為徹底，系統的調用方和被調用方可以按照自己的速率而不是步調一緻，進而可以更好地保護系統，讓系統更有彈力。
異步通訊的倆種方式
請求響應式
在這種情況下，發送方（sender）會直接請求接收方（receiver），被請求方接收到請求後，直接傳回——收到請求，正在處理。
對于傳回結果，有兩種方法，一種是發送方時不時地去輪詢一下，問一下幹沒幹完。另一種方式是發送方注冊一個回調方法，也就是接收方處理完後回調請求方。這種架構模型在以前的網上支付中比較常見，頁面先從商家跳轉到支付寶或銀行，商家會把回調的 URL 傳給支付頁面，支付完後，再跳轉回商家的 URL。
很明顯，這種情況下還是有一定耦合的。是發送方依賴于接收方，并且要把自己的回調發送給接收方，處理完後回調。
通過 Broker 的方式
所謂 Broker，就是一個中間人,我了解就是MQ，發送方（sender）和接收方（receiver）都互相看不到對方，它們看得到的是一個 Broker，發送方向 Broker 發送消息，接收方向 Broker 訂閱消息。如下圖所示。
這是完全的解耦。所有的服務都不需要互相依賴，而是依賴于一個中間件 Broker。這個 Broker 是一個像資料總線一樣的東西，所有的服務要接收資料和發送資料都發到這個總線上，這個總線就像協定一樣，讓服務間的通訊變得标準和可控。
在 Broker 這種模式下，發送方的服務和接收方的服務最大程度地解耦。但是所有人都依賴于一個總線，是以這個總線就需要有如下的特性：
- 必需是高可用的，因為它成了整個系統的關鍵；
- 必需是高性能而且是可以水準擴充的；
- 必需是可以持久化不丢資料的。
事件驅動設計
上述的第二種就是比較著名的事件驅動架構（EDA – Event Driven Architecture）。正如前面所說，事件驅動最好是使用 Broker 方式，服務間通過交換消息來完成交流和整個流程的驅動。
如下圖所示，這是一個訂單處理流程。下單服務通知訂單服務有訂單要處理，而訂單服務生成訂單後發出通知，庫存服務和支付服務得到通知後，一邊是占住庫存，另一邊是讓使用者支付，等待使用者支付完成後通知配送服務進行商品配送。
每個服務都是“自包含”的。所謂“自包含”也就是沒有和别人産生依賴。而要把整個流程給串聯起來，我們需要一系列的“消息通道（Channel）”。各個服務做完自己的事後，發出相應的事件，而又有一些服務在訂閱着某些事件來關聯。
事件驅動方式的好處至少有五個。
- 服務間的依賴沒有了，服務間是平等的，每個服務都是高度可重用并可被替換的。
- 服務的開發、測試、運維，以及故障處理都是高度隔離的。
- 業務流程不再那麼明顯和好管理。整個架構變得比較複雜。解決這個問題需要有一些可視化的工具來呈現整體業務流程。
- 事件可能會亂序。這會帶來非常 Bug 的事。解決這個問題需要很好地管理一個狀态機的控制。
- 事務處理變得複雜。需要使用兩階段送出來做強一緻性，或是退縮到最終一緻性
思考：異步通訊可以提升系統的吞吐量，以及業務解耦。但什麼事情都有兩面性，帶來好處的同時，也引入了新的問題，比如排查問題困難，以及資料順序問題，資料一緻性問題。是以我們要适度的使用異步通信。美酒雖好，切莫貪杯。