《用消息服務來提升微服務的可靠性》

前言：

過去，咱們很容易經過：取出裸機服務器、安裝全部必需的軟件、添加全部應用代碼、將數據加載上去的一系列流程，來部署單體應用程序(monolithic application)。因爲一切組件都集中在一臺服務器上，所以這種應用不但可以處理較大的流量，而且很是容易管理與部署。

然而，此類應用存在的大問題即是效率低下。例如，您必須事先估算峯值時的負載，才能配上足夠性能的服務器。可是具備此類配置服務器的資源又會在正常負載下處於閒置狀態，甚至在小負載時形成大量的浪費。

此外，咱們可能須要痛苦地經過手動操做，來對該服務器進行資源上的擴展。而若是某個組件須要比服務器自己更多的資源時，整臺機器必須被迫停機升級，這勢必會影響到全部其餘的組件。所以，誠然裸機服務器仍有它獨有的適用場景，可是它們已逐漸被新的微服務架構所取代。

什麼是微服務架構?

微服務架構是一種軟件開發技術，它將應用程序構建成鬆耦合的服務集合。這些具備輕量級協議特徵的細化服務，不但提升了應用程序的模塊化特性，並且便於被理解、開發和測試。小型自治化的團隊經過使用它們可以獨立地進行並行開發、部署、以及擴展各自的服務。另外，基於微服務的架構還可以支持持續交付與部署(來源：維基百科， https://en.wikipedia.org/wiki... )。

所以，咱們再也不被限制在一臺服務器上部署全部的代碼、數據庫和數據資產，而是將每套代碼分紅不一樣的組，並彼此獨立地運行。所以，咱們既可以經過設置特定的存儲區域，來讓部分代碼只負責上傳、操做、保存圖像;也能夠經過建立特定的數據庫，來讓部分代碼只負責檢查和建立會話。另外，您既能夠用某個特定的代碼塊，去處理新用戶的帖子，又能夠用另外一個代碼塊(或服務)，去檢查是否出現了不當言論。一個數據庫能夠被用於存儲各類評論，而另外一個庫則能夠被用於按關鍵字進行搜索。

那麼，微服務有哪些實際好處呢?

· 首先，每一個微服務均可以根據使用狀況，來按比例伸縮調整容量，以節省寶貴的服務資源。

· 其次，咱們能夠更好地將開發人員與負責數據庫的人員、編寫後端代碼的人員、以及UI/UX人員等分離開來。

· 並且，因爲每一項服務都是彼此可以獨立工做的，那麼某個組件的負載大小不會影響到另外一個組件。一樣，某個組件的升級也不須要牽扯到對於另外一個組件的拆分。

可見，各個組件都可以獲取更高的正常運行時間。

微服務架構的侷限性

凡事都有利有弊，微服務架構的主要缺點之一即是：應用程序總體正常運行時間的保障問題。因爲咱們將整個應用程序分散到了各個微服務中，雖然單個組件的可靠性提升了，可是其代價是給應用程序的總體可靠性帶來了不肯定因素。

在單體裸機應用中，不管是網絡、硬盤、內存、仍是其餘方面出現問題，該應用總體就會中斷服務。所以，若是供應商向您承諾99.5%的正常運行時間，那麼您就只須要操心如何在99.5%的基礎上進行改進即可。可是，若是您使用的是微服務架構，那麼每一個組件都會有各自的正常運行時間基線。例如，您的應用程序用到了10個服務，而每一個服務正常運行時間的整體佔比爲99.5%，則總體的正常運行佔比是99.5%的10次方 = 95.0%。

這是否意味着微服務架構並很差呢?不必定。這只是意味着除了受益於微服務所帶來的各項好處以外，開發人員須要採起其餘的措施，來保護本身的應用程序，並減小潛在的停機時間。頗爲有趣的是，咱們在此能夠引入另外一項微服務--阿里雲的消息服務(Alibaba Cloud's Message Service，請參見 https://www.alibabacloud.com/... )。

什麼是阿里雲的消息服務?

阿里雲的消息服務是一種分佈式的消息排隊和通知服務。它支持併發式操做，有助於在應用程序和解耦的系統之間的傳輸消息。阿里雲的消息服務使得用戶可以在分佈式應用程序之間經過傳輸數據，來實現各類複雜的任務，進而構建出具備解耦且容錯特性的應用程序。

消息服務如何提升正常運行時間?

爲了更好地理解消息服務是如何提升可靠性的，讓咱們來討論一個典型的羣聊應用。假設您已經構建了一個球迷類的羣聊應用—Sports App，其中包含各類聊天組，例如：切爾西、巴塞羅那、皇家馬德里、拜仁慕尼黑、以及曼聯等熱門足球俱樂部。

任何人均可以向任何羣裏發佈消息，並能夠經過訂閱他們喜歡的俱樂部小組，以獲悉其餘粉絲所發佈的消息通知。顯然，您在開發此類應用時應充分考慮其可擴展性。經過持續監控其增加，您還能過濾掉各類不當的消息言論與圖像，並提供消息搜索功能。所以，爲了知足這些需求，您爲每一項功能都提供了一系列的雲服務。其最終的系統架構以下圖所示：

在上述案例設置中，當用戶要向某個組發佈新的消息時，該Sports App的後端會接收該請求，而後將其傳遞給各項微服務，並最終通知該用戶傳遞成功與否的回執。具體流程爲：

首先，後端檢查該用戶是否有權將消息發佈到特定組中，同時過濾掉不規範的HTML標記、或是帶有其餘危險參數的輸入。
而後，應用經過一些人工智能的相關服務，來檢查消息的合規性，若是經過了檢查，則繼續將該消息保存到某個雲端數據庫中。
接着，程序將該消息傳遞給Elasticsearch之類的搜索優化類數據存儲服務。Sports App能夠決定爲數據分析添加單獨的服務，以分析哪些說起次數多的俱樂部名稱等特徵。
另外，開發人員還能夠經過添加對於應用的監控，以瞭解該請求的執行方式。
最後，Sports App會提醒全部成員，這條新消息已發佈到了該目標組中。
正如咱們所看到的，整個過程可能有點冗長，就算它們是在幾毫秒內完成的，整個消息傳輸鏈條上仍包含有許多潛在的失敗點。並且，一旦鏈條上的某一個服務失敗了，那麼整個請求的傳遞過程就會出錯。

讓咱們再從新回顧一下上述對於請求檢查的業務邏輯。其實，對於發佈消息的用戶來講，他既不會關心後臺所執行的身份驗證，又不太會注意消息的合規性，更沒必要知道消息是如何存儲的，以及後臺是如何保證每一個組成員都可以收到新的消息。他只需關心本身的消息最終可否發佈到目標組中。

所以，讓咱們來經過使用消息服務(Message Service)，來調整技術棧，以知足此類需求。新的技術棧所對應的系統架構以下圖所示：

在上述架構中，當用戶發佈新的消息時，咱們須要作的只是將其傳遞給消息服務。若是順利完成，該消息會返回給用戶成功的回執。全程只需幾毫秒，這對應用方和用戶端來講都是很是好的使用體驗。

而在單獨的請求中，應用服務會代替用戶將對應的信任憑據和參數回傳到Sports的後端服務器上。在此過程當中，若是發生任何錯誤的話，咱們只需事先設置好標準的錯誤響應代碼，如「503：服務不可用」即可。同時，消息服務還會反覆地重試該請求，直至它被成功傳遞、或7天后默認超時。

固然，您徹底沒必要止步於此。經過使用消息服務，您能夠更進一步地解決諸如：受權檢查、或消息合規性檢查等方面的問題。籍此，您能夠逐步提升本身的應用所使用到的各項微服務的可靠性。