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

微服務是什麼

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

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

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

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

現在，如果業務呈指數級增長，需要處理數十萬或數百萬使用者，會發生什麼？最初，短期解決方案是確保執行應用程式的伺服器具有強大的硬體規格以承受更高的負載，如果沒有，則向伺服器新增更多記憶體、儲存和處理能力。這稱為垂直縮放，是增加硬體功能的行為（如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中用。

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

容器

軟體容器技術是下一個需要討論以解釋雲原生應用程式的關鍵技術。容器只是將一些軟體封裝在隔離的使用者空間或“容器”中的想法。

例如，MySQL資料庫可以在容器內部隔離，其中存在環境變數和它所需的配置。容器外部的軟體預設情況下不會看到容器內包含的環境變數或配置。多個容器可以存在於同一本地虛擬機器、雲虛擬機器或硬體伺服器上。

容器提供了在同一臺機器上執行眾多隔離了的軟體服務的能力，包括所有配置、軟體依賴關係、執行時、工具和附帶檔案。在雲環境中，這種能力轉化為節省的成本和工作量，因為為每個微服務配置和購買伺服器節點的需求將減少，不同的微服務可以部署在同一主機上而不會相互干擾。容器與微服務架構相結合，是構建現代、便攜、可擴充套件且經濟高效的軟體的強大工具。在生產環境中，需要多個伺服器節點與眾多容器相結合才能實現可擴充套件性和冗餘。

除了微服務隔離之外，容器還為雲原生應用程式增加了更多好處。使用容器，你可以將具有所需的所有配置、依賴關係和環境變數的微服務移動到新的伺服器節點，而無需重新配置環境，實現強大的可移植性。

由於軟體容器技術的強大和普及，一些新的作業系統，如CoreOS或Photon OS，是為用作容器的主機而從頭開始構建的。

軟體行業最受歡迎的軟體容器專案之一是Docker。思科、谷歌和IBM等大公司在其基礎設施及產品中使用Docker容器。

軟體容器世界中另一個值得注意的專案是Kubernetes。Kubernetes是一個允許自動化容器部署、管理和擴充套件的工具。它是由谷歌建立的，以便管理容器（每週數十億個）。Kubernetes提供了一些強大的功能，例如容器之間的負載均衡、故障容器的重新啟動以及容器使用的儲存編排。該專案和Prometheus都是雲原生基礎的一部分。

容器的複雜性

在容器的情況下，有時管理它們的任務可能變得相當複雜，原因與管理不斷增加的微服務數量相同。隨著容器或微服務的規模不斷擴大，需要有一種機制來識別每個容器或微服務的部署位置、目的是什麼以及它們需要什麼資源保持執行。

無伺服器應用程式

無伺服器架構是一種新的軟體架構正規化，它因為AWS Lambda服務而推廣。為了完全理解無伺服器應用程式，有助於瞭解一個稱為功能即服務或簡稱FaaS的重要概念。

FaaS的理念是，諸如亞馬遜之類的雲提供商甚至是諸如Fission.io或funktion之類的本地軟體都可以提供服務，其中使用者可以請求遠端執行的功能以執行非常特定的任務。功能結束後，這些結果將返回給使用者。不維護任何服務或有狀態資料，並且使用者將功能程式碼提供給執行該功能的服務。

使用恰當無伺服器架構設計的雲原生生產應用程式背後的想法是，不構建預期持續執行的多個微服務以執行單個任務，而是構建一個與FaaS結合的微服務較少的應用程式，其中FaaS涵蓋不需要持續執行服務的任務。

FaaS是一種比微服務更小的結構。例如，在我們之前介紹的活動預訂應用程式的情況下，有多個微服務涵蓋不同的任務。如果我們使用無伺服器應用程式模型，一些微服務會被替換為用於相同目的的許多功能。

這是一個使用無伺服器架構展示應用程式的圖：

在此圖中，事件處理程式微服務以及預訂處理程式微服務被許多產生相同功能的功能所取代。這消除了執行和維護兩個現有微服務的需要。

無伺服器架構的優勢在於，不需要配置虛擬機器和/或容器來構建利用FaaS的應用程式部分。一旦它們的功能結束，執行這些功能的計算例項從使用者的角度來看就不再存在。此外，需要由使用者監控和維護的微服務和/或容器的數量減少，節省了成本、時間和精力。

無伺服器架構為軟體工程師和架構師提供了另一種功能強大的軟體構建工具，可用於設計靈活且可擴充套件的軟體。已知的FaaS有Amazon的AWS Lambda、Microsoft的Azure Functions、Google的Cloud Functions等。

無伺服器應用程式的另一個定義是使用BaaS或後端作為服務正規化的應用程式。 BaaS的想法是，開發人員只編寫其應用程式的客戶端程式碼，然後依賴於託管在雲中的多個軟體預構建服務（可通過API訪問）。BaaS在移動應用程式程式設計中很受歡迎，開發人員可以依賴大量的後端服務來驅動應用程式的大部分功能。 BaaS服務的例子有：Firebase和Parse。

無伺服器應用程式的缺點

與微服務和雲原生應用程式類似，無伺服器架構並不適用於所有場景。

FaaS提供的功能本身並不保持狀態，這意味著在編寫功能程式碼時需要特別注意。這與全微服務不同——開發人員可以完全控制狀態。儘管有這種限制，但在FaaS的情況下保持狀態的一種方法是將狀態傳播到資料庫或像Redis這樣的記憶體快取。

這些功能的啟動時間並不總是很快，因為要有時間分配給FaaS服務提供商傳送請求，然後在某些情況下啟動執行該功能的計算例項也需要時間。在設計無伺服器應用程式時必須考慮這些延遲。

FaaS不像微服務那樣持續執行，這使得它們不適合任何需要持續執行軟體的任務。

無伺服器應用程式具有與其他雲原生應用程式相同的限制，其中應用程式從一個雲提供商到另一個雲提供商，或從雲到本地環境的可移植性因供應商鎖定而變得具有挑戰性。

結論

雲端計算架構為開發高效、可擴充套件且可靠的軟體開闢了道路。本文介紹了雲端計算領域的一些重要概念，如微服務、雲原生應用程式、容器和無伺服器應用程式。

微服務是大多數可擴充套件的雲原生應用程式的構建塊，它們將應用程式任務分解為各種有效的服務。容器是如何將微服務隔離並安全地部署到生產環境而不汙染它們的方式。無伺服器應用程式將應用程式任務分離為更小的構造，這些構造通常稱為可通過API使用的功能。雲原生應用程式利用所有這些架構模式來構建可擴充套件、可靠且始終可用的軟體。

原文連結：

1. http://superuser.openstack.org/articles/modern-cloud-native-architecture-what-you-need-to-know-about-micro-services-containers-and-serverless/

2. http://superuser.openstack.org/articles/modern-cloud-native-architectures-microservices-containers-and-serverless-part-2/

   
   

溫馨提示：

請識別二維碼關注公眾號，點選原文連結獲取更多技術資料和文章。