前言：

過去，我們很容易通過：取出裸機伺服器、安裝所有必需的軟體、新增所有應用程式碼、將資料載入上去的一系列流程，來部署單體應用程式(monolithic application)。由於一切元件都集中在一臺伺服器上，因此這種應用不但能夠處理較大的流量，並且非常容易管理與部署。

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

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

什麼是微服務架構?

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

因此，我們不再被限制在一臺伺服器上部署所有的程式碼、資料庫和資料資產，而是將每套程式碼分成不同的組，並彼此獨立地執行。因此，我們既能夠通過設定特定的儲存區域，來讓部分程式碼只負責上傳、操作、儲存影象;也可以通過建立特定的資料庫，來讓部分程式碼只負責檢查和建立會話。另外，您既可以用某個特定的程式碼塊，去處理新使用者的帖子，又可以用另一個程式碼塊(或服務)，去檢查是否出現了不當言論。一個數據庫可以被用於儲存各種評論，而另一個庫則可以被用於按關鍵字進行搜尋。

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

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

· 其次，我們可以更好地將開發人員與負責資料庫的人員、編寫後端程式碼的人員、以及UI/UX人員等分離開來。

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

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

微服務架構的侷限性

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

在單體裸機應用中，無論是網路、硬碟、記憶體、還是其他方面出現問題，該應用整體就會中斷服務。因此，如果供應商向您承諾99.5%的正常執行時間，那麼您就只需要操心如何在99.5%的基礎上進行改進便可。但是，如果您使用的是微服務架構，那麼每個元件都會有各自的正常執行時間基線。例如，您的應用程式用到了10個服務，而每個服務正常執行時間的總體佔比為99.5%，則整體的正常執行佔比是99.5%的10次方 = 95.0%。

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

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

阿里雲的訊息服務是一種分散式的訊息排隊和通知服務。它支援併發式操作，有助於在應用程式和解耦的系統之間的傳輸訊息。阿里雲的訊息服務使得使用者能夠在分散式應用程式之間通過傳輸資料，來實現各種複雜的任務，進而構建出具有解耦且容錯特性的應用程式。

訊息服務如何提高正常執行時間?

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

任何人都可以向任何群裡釋出訊息，並可以通過訂閱他們喜歡的俱樂部小組，以獲悉其他粉絲所釋出的訊息通知。顯然，您在開發此類應用時應充分考慮其可擴充套件性。通過持續監控其增長，您還能過濾掉各種不當的訊息言論與影象，並提供訊息搜尋功能。因此，為了滿足這些需求，您為每一項功能都提供了一系列的雲服務。其最終的系統架構如下圖所示：

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

• 首先，後端檢查該使用者是否有權將訊息釋出到特定組中，同時過濾掉不規範的HTML標記、或是帶有其他危險引數的輸入。
• 然後，應用通過一些人工智慧的相關服務，來檢查訊息的合規性，如果通過了檢查，則繼續將該訊息儲存到某個雲端資料庫中。
• 接著，程式將該訊息傳遞給Elasticsearch之類的搜尋優化類資料儲存服務。Sports App可以決定為資料分析新增單獨的服務，以分析哪些提及次數多的俱樂部名稱等特徵。
• 另外，開發人員還可以通過新增對於應用的監控，以瞭解該請求的執行方式。
• 最後，Sports App會提醒所有成員，這條新訊息已釋出到了該目標組中。

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

讓我們再重新回顧一下上述對於請求檢查的業務邏輯。其實，對於釋出訊息的使用者來說，他既不會關心後臺所執行的身份驗證，又不太會注意訊息的合規性，更不必知道訊息是如何儲存的，以及後臺是如何保證每個組成員都能夠收到新的訊息。他只需關心自己的訊息最終能否釋出到目標組中。

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

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

而在單獨的請求中，應用服務會代替使用者將對應的信任憑據和引數回傳到Sports的後端伺服器上。在此過程中，如果發生任何錯誤的話，我們只需事先設定好標準的錯誤響應程式碼，如“503：服務不可用”便可。同時，訊息服務還會反覆地重試該請求，直至它被成功傳遞、或7天后預設超時。

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

獲取資料：

本次給大家分享一些學習資料，裡面包括：（高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty，Redis，Kafka，Mysql，Zookeeper，Tomcat，Docker，Dubbo，Nginx等多個知識點的架構資料）以及Java進階學習路線圖。

領取方式，加微訊號  weixing99ting  驗證訊息備註：資料 ，即可獲取。
最後，祝大家