新瓶裝舊酒？從微服務同步REST的自然缺陷提及

今天小數給你們帶來的乾貨來自國外一個小組會議上的分享。目前，大部分微服務架構都會使用REST協議以實現不一樣服務之間的通訊，可是它卻有自然的缺陷——怎樣的缺陷？如何解決？請看下文。

最近，Lightbend技術負責人James Roper在紐約Java特別興趣小組會議上分享了一個觀點：

如今許多人正着手將傳統的總體式應用拆分紅微服務集合，但若是這些微服務組件都經過REST（即表述性狀態轉移）實現彼此通訊，那麼它依然只是一款總體式的應用程序。

Roper表示本身是異步通訊的鐵桿支持者——Lightbend（前身爲Typesafe）推出的一套名爲Lagom的Scala微服務平臺正好是基於異步通訊所打造。

何謂異步通訊

這裏提到的「異步通訊」與咱們常說的「異步I/O」並非一回事。異步I/O的實質在於避免因等待進程線程完成而致使的操做中止。而做爲微服務中的重要組成部分，異步通訊則旨在設計出一套系統，其中某項服務的執行無需等待另外一項任務的完成。

「使用異步通訊，若是用戶向某項服務提出一條請求，而該服務又須要向另外一服務發出請求，那麼前一服務的通訊無需受阻便可向用戶直接返回響應，」Roper解釋稱。

REST的固有缺陷

目前，大部分微服務架構都會使用REST協議以實現不一樣服務之間的通訊（取代對象調用）。儘管REST較其它常規方式（例如基於XML的SOAP）更爲簡單，但其同步特性仍然成爲固有缺陷——換言之，它自然擁有同步屬性，而非異步。

「當客戶端發出一條請求，服務器則發出一條響應，」Roper這樣形容REST的工做原理。

一項服務發生故障，即會致使操做總體癱瘓。

面向用戶的服務一般包含大量以同步方式通訊的微服務，這意味着各微服務彼此依賴。這種處理方式在各服務皆能正常運轉時並不會帶來什麼麻煩，然而一旦某項服務發生故障，即會引起不可阻擋的故障鏈並致使最終用戶面臨拒絕服務情況。

一樣的，若是某項微服務速度緩慢，則響應時間也會被同時拖累。

使用REST等同步通訊機制，Roper指出，「從技術角度講，咱們仍然至關於構建了一款總體式方案。不管各組件是否被拆分爲獨立服務，系統自己仍是會像總體應用那樣高度關聯。」

異步通訊來填坑

而在異步通訊中，各服務間仍然彼此依賴，但再也不因相互等待結果而致使響應速度緩慢。所以，若是一項服務發生故障，其不會影響到其它服務，瓶頸與單點故障問題也將不復存在。

利用基於Java的一套類Twitter服務演示，Roper解釋瞭如何經過多種方式實現代碼中的異步調用。方法之一在於確保每項微服務都在信息更新時對其進行發佈，而非等待其它微服務針對該信息提出請求。經過這種辦法，假設通信服務須要一份用戶的「好友」列表，則可以使用由「好友」相關微服務提供的最新信息，而非直接指向該服務發出請求。

來自異步通訊的挑戰

Roper坦言，異步通訊帶來的最大挑戰在於如何確保最終用戶始終可以得到最新信息。不少社交網絡都會使用最終一致性機制，並不保證每位用戶都可以得到最新版本信息。

另外，REST調用因爲極易實現而使用戶產生了穩定的使用習慣。一位與會者提到，須要通過大量編碼工做才能實現異步通訊。

實時REST調用應該被取代嗎？

Roper指出，像Apache Kafka這樣的軟件可以自動處理異步服務中的低級細節，「若是使用簡單的REST調用，你們的服務有可能癱瘓。而經過這種方式，狀況就不會那麼糟糕。」