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

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

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

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

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

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

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

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

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

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

可見(jiàn)，各個(gè)組件都能夠獲取更高的正常運(yùn)行時(shí)間。

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

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

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

這是否意味著微服務(wù)架構(gòu)并不好呢?不一定。這只是意味著除了受益于微服務(wù)所帶來(lái)的各項(xiàng)好處之外，開(kāi)發(fā)人員需要采取其他的措施，來(lái)保護(hù)自己的應(yīng)用程序，并減少潛在的停機(jī)時(shí)間。頗為有趣的是，我們?cè)诖丝梢砸肓硪豁?xiàng)微服務(wù)--阿里云的消息服務(wù)(Alibaba Cloud's Message Service，請(qǐng)參見(jiàn)https://www.alibabacloud.com/product/message-service)。

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

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

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

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

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

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

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

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

讓我們?cè)僦匦禄仡櫼幌律鲜鰧?duì)于請(qǐng)求檢查的業(yè)務(wù)邏輯。其實(shí)，對(duì)于發(fā)布消息的用戶(hù)來(lái)說(shuō)，他既不會(huì)關(guān)心后臺(tái)所執(zhí)行的身份驗(yàn)證，又不太會(huì)注意消息的合規(guī)性，更不必知道消息是如何存儲(chǔ)的，以及后臺(tái)是如何保證每個(gè)組成員都能夠收到新的消息。他只需關(guān)心自己的消息最終能否發(fā)布到目標(biāo)組中。

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

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

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

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

原文標(biāo)題：Improving the Reliability of Microservices，作者：Don Omondi

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