大部分時候，微服務都是建立在一種基於請求和響應的協議之上。比如， REST 等。這種方式是自然的。我們只需要呼叫另外一個模組就是了，然後等待響應返回，然後繼續。這樣的方式確實也滿足了我們的很多的場景：使用者通過點選頁面的一個按鈕然後希望發生一些事情。
但是，當我們開始接觸許多獨立的 service 的時候，事情就發生改變了。隨著 service 數量急速的增長，同步互動比例也隨著 service 在急速增長。這時候，我們的 service 就會遇到很多的瓶頸。 l。
於是，不幸的ops工程師們就被我們坑了，他們疲憊的奔波於一個又一個的service，拼湊在一起的二手資訊片段，誰說了什麼，去往哪裏，什麼時候發生？等等。。。
這是一個非常典型的問題。市面上也有一些解決方案。一種方案就是確保您的個人服務具有比您的系統更高的SLA。 Google提供了這樣做的協議。另一種方法是簡單地分解將服務繫結在一起的同步關係 。
上面的做法都沒有從模式上根本解決問題。我們可以使用非同步機制來解決這個問題。比如，電商網站中你會發現這樣的同步介面，比如 getImage() 或者 processOrder() ，也許你感覺蠻正常。呼叫瞭然後希望馬上有一個響應。但當用戶點選了“購買”後，觸發了一個複雜且非同步的處理過程。這個過程涉及到購買、送貨上門給使用者，這一切都是發生在當初的那一次的按鈕點選。所以把一個程式處理邏輯切分成多個非同步的處理，是我們需要解決的問題。這也正符合我們的真實的世界，真實世界本來就是非同步的，擁抱非同步吧 。
在實際情況下，我們其實已經自動擁抱了非同步了。我們發現自己會定時輪詢資料庫表來更改又或者通過 cron 定時 job 來實現一些更新。這些方法都是一些打破同步的方式，但是這種做法總讓人感覺有種黑客範兒，感覺像是黑客行為，怪怪的。
