【51CTO.com快譯】過去，我們很容易通過：取出裸機服務器、安裝所有必需的軟件、添加所有應用代碼、將數(shù)據(jù)加載上去的一系列流程，來部署單體應用程序(monolithic application)。由于一切組件都集中在一臺服務器上，因此這種應用不但能夠處理較大的流量，并且非常容易管理與部署。

然而，此類應用存在的大問題便是效率低下。例如，您必須事先估算峰值時的負載，才能配上足夠性能的服務器。但是具有此類配置服務器的資源又會在正常負載下處于閑置狀態(tài)，甚至在小負載時造成大量的浪費。

此外，我們可能需要痛苦地通過手動操作，來對該服務器進行資源上的擴展。而如果某個組件需要比服務器本身更多的資源時，整臺機器必須被迫停機升級，這勢必會影響到所有其他的組件。因此，誠然裸機服務器仍有它獨有的適用場景，但是它們已逐漸被新的微服務架構所取代。

什么是微服務架構?

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

因此，我們不再被限制在一臺服務器上部署所有的代碼、數(shù)據(jù)庫和數(shù)據(jù)資產(chǎn)，而是將每套代碼分成不同的組，并彼此獨立地運行。因此，我們既能夠通過設置特定的存儲區(qū)域，來讓部分代碼只負責上傳、操作、保存圖像;也可以通過創(chuàng)建特定的數(shù)據(jù)庫，來讓部分代碼只負責檢查和創(chuàng)建會話。另外，您既可以用某個特定的代碼塊，去處理新用戶的帖子，又可以用另一個代碼塊(或服務)，去檢查是否出現(xiàn)了不當言論。一個數(shù)據(jù)庫可以被用于存儲各種評論，而另一個庫則可以被用于按關鍵字進行搜索。

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

· 首先，每個微服務都可以根據(jù)使用情況，來按比例伸縮調整容量，以節(jié)省寶貴的服務資源。

· 其次，我們可以更好地將開發(fā)人員與負責數(shù)據(jù)庫的人員、編寫后端代碼的人員、以及UI/UX人員等分離開來。

· 而且，由于每一項服務都是彼此能夠獨立工作的，那么某個組件的負載大小不會影響到另一個組件。同樣，某個組件的升級也不需要牽扯到對于另一個組件的拆分。

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

微服務架構的局限性

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

在單體裸機應用中，無論是網(wǎng)絡、硬盤、內存、還是其他方面出現(xiàn)問題，該應用整體就會中斷服務。因此，如果供應商向您承諾99.5%的正常運行時間，那么您就只需要操心如何在99.5%的基礎上進行改進便可。但是，如果您使用的是微服務架構，那么每個組件都會有各自的正常運行時間基線。例如，您的應用程序用到了10個服務，而每個服務正常運行時間的總體占比為99.5%，則整體的正常運行占比是99.5%的10次方 = 95.0%。

這是否意味著微服務架構并不好呢?不一定。這只是意味著除了受益于微服務所帶來的各項好處之外，開發(fā)人員需要采取其他的措施，來保護自己的應用程序，并減少潛在的停機時間。頗為有趣的是，我們在此可以引入另一項微服務--阿里云的消息服務(Alibaba Cloud's Message Service，請參見https://www.alibabacloud.com/product/message-service)。

什么是阿里云的消息服務?

阿里云的消息服務是一種分布式的消息排隊和通知服務。它支持并發(fā)式操作，有助于在應用程序和解耦的系統(tǒng)之間的傳輸消息。阿里云的消息服務使得用戶能夠在分布式應用程序之間通過傳輸數(shù)據(jù)，來實現(xiàn)各種復雜的任務，進而構建出具有解耦且容錯特性的應用程序。

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

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

任何人都可以向任何群里發(fā)布消息，并可以通過訂閱他們喜歡的俱樂部小組，以獲悉其他粉絲所發(fā)布的消息通知。顯然，您在開發(fā)此類應用時應充分考慮其可擴展性。通過持續(xù)監(jiān)控其增長，您還能過濾掉各種不當?shù)南⒀哉撆c圖像，并提供消息搜索功能。因此，為了滿足這些需求，您為每一項功能都提供了一系列的云服務。其最終的系統(tǒng)架構如下圖所示：

在上述案例設置中，當用戶要向某個組發(fā)布新的消息時，該Sports App的后端會接收該請求，然后將其傳遞給各項微服務，并最終通知該用戶傳遞成功與否的回執(zhí)。具體流程為：

• 首先，后端檢查該用戶是否有權將消息發(fā)布到特定組中，同時過濾掉不規(guī)范的HTML標記、或是帶有其他危險參數(shù)的輸入。
• 然后，應用通過一些人工智能的相關服務，來檢查消息的合規(guī)性，如果通過了檢查，則繼續(xù)將該消息保存到某個云端數(shù)據(jù)庫中。
• 接著，程序將該消息傳遞給Elasticsearch之類的搜索優(yōu)化類數(shù)據(jù)存儲服務。Sports App可以決定為數(shù)據(jù)分析添加單獨的服務，以分析哪些提及次數(shù)多的俱樂部名稱等特征。
• 另外，開發(fā)人員還可以通過添加對于應用的監(jiān)控，以了解該請求的執(zhí)行方式。
• 最后，Sports App會提醒所有成員，這條新消息已發(fā)布到了該目標組中。

正如我們所看到的，整個過程可能有點冗長，就算它們是在幾毫秒內完成的，整個消息傳輸鏈條上仍包含有許多潛在的失敗點。而且，一旦鏈條上的某一個服務失敗了，那么整個請求的傳遞過程就會出錯。

讓我們再重新回顧一下上述對于請求檢查的業(yè)務邏輯。其實，對于發(fā)布消息的用戶來說，他既不會關心后臺所執(zhí)行的身份驗證，又不太會注意消息的合規(guī)性，更不必知道消息是如何存儲的，以及后臺是如何保證每個組成員都能夠收到新的消息。他只需關心自己的消息最終能否發(fā)布到目標組中。

因此，讓我們來通過使用消息服務(Message Service)，來調整技術棧，以滿足此類需求。新的技術棧所對應的系統(tǒng)架構如下圖所示：

在上述架構中，當用戶發(fā)布新的消息時，我們需要做的只是將其傳遞給消息服務。如果順利完成，該消息會返回給用戶成功的回執(zhí)。全程只需幾毫秒，這對應用方和用戶端來說都是非常好的使用體驗。

而在單獨的請求中，應用服務會代替用戶將對應的信任憑據(jù)和參數(shù)回傳到Sports的后端服務器上。在此過程中，如果發(fā)生任何錯誤的話，我們只需事先設置好標準的錯誤響應代碼，如“503：服務不可用”便可。同時，消息服務還會反復地重試該請求，直至它被成功傳遞、或7天后默認超時。

當然，您完全不必止步于此。通過使用消息服務，您可以更進一步地解決諸如：授權檢查、或消息合規(guī)性檢查等方面的問題。籍此，您可以逐步提高自己的應用所使用到的各項微服務的可靠性。

原文標題：Improving the Reliability of Microservices，作者：Don Omondi

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】