1. 程式人生 > >雲原生架構系列之微服務

雲原生架構系列之微服務

本系列旨在揭示現代軟體行業的關鍵主題——雲原生應用程式。這篇文章涉及微服務、容器和無伺服器應用程式。在這裡,我們將討論這些技術的實際優點和缺點。

微服務

微服務架構作為構建現代軟體應用程式的強大方法而享有盛譽。那麼什麼是微服務?微服務可以簡單地描述為,將軟體應用程式所需的功能分離為多個獨立的小型軟體服務或“微服務”。每個微服務負責自己專注的任務。為了使微服務協同工作以形成大型可伸縮應用程式,它們之間進行通訊和交換資料。

微服務的誕生是因為需要克服單體應用程式的複雜性和不靈活性。單體應用程式是一種應用程式,其中所有必需的功能一起編碼到同一服務中。例如,這是一個表示單體活動(如音樂會、演出等)預訂應用程式的圖表,負責預訂支付處理和活動預訂:

 

 

 

使用者可以使用該應用程式預訂音樂會或演出。需要一個使用者介面。此外,我們還需要一個搜尋功能來查詢活動、一個預訂處理程式來處理使用者預訂然後儲存該預訂、一個活動處理程式來幫助查詢活動(確保有可用的座位,然後將其連結到預訂)。在生產級應用程式中,需要更多的任務,例如支付處理,但是現在我們主要關注上圖中概述的四個任務。

這種單體應用程式適用於中小負載。它在單個伺服器上執行,連線到單個數據庫,並且可能使用相同的程式語言編寫。

現在,如果業務呈指數級增長,需要處理數十萬或數百萬使用者,會發生什麼?最初,短期解決方案是確保執行應用程式的伺服器具有強大的硬體規格以承受更高的負載,如果沒有,則向伺服器新增更多記憶體、儲存和處理能力。這稱為垂直縮放,是增加硬體功能的行為(如RAM和硬碟驅動器容量),以執行繁重的應用程式。但是,從長遠來看,這通常是不可持續的,因為應用程式上的負載持續增加。

單體應用程式的另一個挑戰是僅限於一種或兩種程式語言所導致的不靈活性。這種不靈活性會影響整體質量和應用效率。例如,node.js是用於構建Web應用程式的流行JavaScript框架,而R在資料科學應用程式中很流行。單體應用程式很難同時使用這兩種技術,而在微服務應用程式中,我們可以簡單地構建用R編寫的資料科學服務和用Node.js編寫的Web服務。

活動應用程式的微服務版本將採用以下形式:

 

 

此應用程式將能夠在多個伺服器之間進行擴充套件,這種做法稱為水平擴充套件。每個服務都可以使用專用資源部署在不同的伺服器上,也可以部署在不同的容器中(稍後會詳細介紹)。不同的服務可以用不同的程式語言編寫,從而實現更大的靈活性,不同的專業團隊可以專注於不同的服務,從而實現應用程式的更高整體質量。

使用微服務的另一個顯著優勢是易於持續交付,這是經常、在任何時間部署軟體的能力。微服務使持續交付更容易的原因是,與單體應用程式相比,部署到一個微服務的新功能不太可能影響其他微服務。

微服務的問題

嚴重依賴微服務的一個顯著缺點是,隨著數量和範圍的擴大,它們可能變得太複雜而無法長期管理。有一些方法可以通過利用Prometheus等監控工具來檢測問題,像Docker這樣的容器技術來避免汙染主機環境並避免過度設計服務。但是,這些方法需要付出努力和時間。

雲原生應用程式

微服務架構非常適合雲原生應用程式。雲原生應用程式簡單地定義為從頭開始為雲端計算架構而構建應用程式。這意味著,如果我們將應用程式設計為預期將部署在分散式、可擴充套件的基礎架構上,我們的應用程式就是雲原生的。

例如,構建具有冗餘微服務架構的應用程式使得應用程式雲原生化,因為這種架構允許我們的應用程式以分散式方式部署,從而使其可擴充套件且幾乎總是可用。雲原生應用程式不需要始終部署到AWS等公有云,我們可以將其部署到自己的分散式雲基礎設施中(如果有的話)。

實際上,使應用程式完全雲原生的原因不僅僅是使用微服務。你的應用程式應採用持續交付,這樣你能夠不間斷地為生產應用程式提供更新。你的應用程式還應該使用訊息佇列和容器、無伺服器等技術(容器和無伺服器是現代軟體架構的重要主題)。

雲原生應用程式假定可以訪問眾多伺服器節點,可以訪問預先部署的軟體服務(如訊息佇列或負載均衡器),易於與持續交付服務整合等。

如果將雲原生應用程式部署到AWS或Azure等商業雲,則應用程式可以選擇使用只能在雲上用的軟體服務。例如,DynamoDB是一個功能強大的資料庫引擎,只能在AWS上用於生產應用程式。另一個例子是Azure中的DocumentDB資料庫。還有僅雲的訊息佇列,例如Amazon Simple Queue Service(SQS),可用於允許AWS雲中的微服務之間的通訊。

如前所述,雲原生微服務應設計為允許服務之間的冗餘。如果我們以活動預訂應用程式為例,應用程式將如下所示:

 

每個微服務將分配多個伺服器節點,允許部署冗餘微服務架構。如果主節點或服務因任何原因而失敗,則輔助節點可以接管以確保雲原生應用程式的持久可靠性和可用性。這種可用性對於電子商務平臺等不容錯的應用程式至關重要,因為停機時間會導致大量的收入損失。

雲原生應用程式為開發人員、企業和初創公司提供了巨大價值。

Prometheus是一個值得一提的微服務和雲端計算領域的工具。Prometheus是一個開源系統監控和警報工具,可用於監控複雜的微服務架構,並在需要採取措施時發出警報。Prometheus最初是由SoundCloud建立的,用於監控他們的系統,後來逐漸發展成為一個獨立的專案。該專案現在是雲原生計算基礎的一部分,該基礎是為雲原生應用程式構建可持續生態系統的基礎。

雲原生的限制

對於雲原生應用程式,如果需要遷移部分或全部應用程式,你將面臨一些挑戰。這是由多種原因造成的,具體取決於部署應用程式的位置。

例如,如果你的雲原生應用程式部署在AWS等公有云上,則雲原生API不是跨雲平臺的。因此,應用程式中使用的DynamoDB資料庫API僅適用於AWS,但不適用於Azure,因為DynamoDB僅屬於AWS。API也永遠不會在本地環境中工作,因為DynamoDB在生產中只能在AWS中用。

另一個原因是因為在構建一些雲原生應用程式時會做出一些假設,例如在需要時可以使用幾乎無限數量的伺服器節點,並且可以非常快速地使用新的伺服器節點。在需要購買真正的伺服器、網路硬體和佈線的本地資料中心環境中,有時難以保證這些假設。