微服務反模式與陷阱翻譯終結篇

都在說微服務，那麼微服務的反模式和陷阱是什麼（一）
http://www.jianshu.com/p/3986239138fe

都在說微服務，那麼微服務的反模式和陷阱是什麼（二）
http://www.jianshu.com/p/c76f7f234a31

九、通訊協議使用的陷阱

在微服務架構體系中要求每個服務都是獨立佈署，這就意味著服務之間會有通訊，也就是說會有很多的遠端訪問。

當你不知道這些遠端訪問需要多長時間的時候，就會掉入到這個陷阱，當然我們可以假定遠端訪問一次50毫秒，但我們是否真正的進行過測試呢？那麼服務的平均響應時間是多少呢？即使有看上去很好的平均響應時間，那麼糟糕的“長尾延遲”也會將整體系統摧毀。

9.1 延遲測量

在生產環境中進行壓力測試，是檢測我們系統效能的重要手段之一，舉個例子：我們有一個特定業務需要四個服務來協調處理，假如遠端訪問一次的時間是100毫秒，那麼這個特定業務就需要消耗500毫秒（初始請求+四個服務的呼叫時間），這個只是遠端訪問的時間，還不算實際業務程式碼的執行時間，這是大多數應用系統都不能接受的時間。

9.2 通訊協議比較

不同協議的延遲響應時間其實在不同的環境中表現的差異很大，因此我們也需要在不同的業務請求下建立一些測試基準。

從圖9-1中可以看出AMQP的效能要比REST的快近一倍，可以我們就可以做出一些選擇了，在什麼場景下應該用什麼協議，另外在選擇協議時效能並不是唯一的考慮因素，在第十章將會為大家介紹除了效能還需要考慮的點是什麼。

十、REST陷阱

目前使用REST協議已然成了微服務協議的最佳選擇了，現在最流行的DropWizard和Spring boot就是基於REST進行通訊的，那問題來了，如果REST是一個最佳選擇，那為什麼又說它是一個陷阱呢？如果把REST作為唯一的通訊方式，就有可能掉入這個陷阱，比如如何處理非同步通訊(http 1.1是blocking的)、如何在一個事務中管理多次服務呼叫？如何支援廣播？

你應該考慮兩種型別的訊息標準作為微服務架構中的訊息傳遞：特定平臺的標準和平臺無關的標準。特定平臺的標準比如 JMS for java、MSMQ for .net。平臺無關的比如 AMQP。

使用訊息系統的好處可以非同步請求，還可以實現廣播的方式，還可以實現事務請求。

10.1 非同步請求

使用微服務架構首先要考慮的是非同步通訊方式，因為非同步通訊的呼叫者不需要考慮等待服務的響應時間，如圖10-1所示。

使用非同步方式的好處不僅提升了整體效能，還增加了一些可靠性的因素，另外也不需要擔心超時問題和在程式中設定斷路器模式。

10.2 廣播能力

這個最典型的就是訊息的“釋出-訂閱”，如圖10-2所示。

10.3 事務請求

訊息系統需要支援事務訊息的概念，這意味著如果訊息被髮送到多個佇列或Topic中，在傳送方對該事務進行提交之前， 這些訊息實際上不會被接收方所接收。服務消費者傳送一個訊息到第一個服務，然後傳送另一個訊息的第二個服務，如圖10-3所示。在服務使用者執行提交之前，這些訊息都儲存在佇列中。一旦服務使用者執行提交，兩個訊息就會被釋放。

在圖10-3中，服務消費者將訊息傳送到第一個佇列中，然後服務消費者業務報錯， 這時可以在訊息事務中進行回滾，從訊息系統的佇列中刪除掉剛才發的訊息。

使用REST實現這種事務能力就非常困難，其實就是要求服務使用者使用TCC、或者補償方式來達到最終一致性。

結束語

關於微服務的反模式和陷阱三部曲，到現在為止已經全部翻譯完成，英文文件一共60多頁，這裡面有不少內容大家都是耳熟能詳的，關於原版的英文文件我也提供給大家做一個參考，最後感謝大家的支援和幫助。

原版文件連結如下：http://pan.baidu.com/s/1qY3Etoo 密碼:l26d