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

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

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

什么是微服務(wù)架構(gòu)?

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

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

那么，微服務(wù)有哪些實際好處呢?

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

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

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

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

微服務(wù)架構(gòu)的局限性

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

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

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

什么是阿里云的消息服務(wù)?

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

消息服務(wù)如何提高正常運行時間?

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

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

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

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

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

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

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

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

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

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

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

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