關於雲原生，這是最詳細的技術知識

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

微服務是什麼

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

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

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

這種單體應用程序適用於中小負載。它在單個伺服器上運行，連接到單個資料庫，並且可能使用相同的編程語言編寫。

現在，如果業務呈指數級增長，需要處理數十萬或數百萬用戶，會發生什麼？最初，短期解決方案是確保運行應用程序的伺服器具有強大的硬體規格以承受更高的負載，如果沒有，則向伺服器添加更多內存、存儲和處理能力。這稱為垂直縮放，是增加硬體功能的行為（如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使用的功能。雲原生應用程序利用所有這些架構模式來構建可擴展、可靠且始終可用的軟體。

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

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

溫馨提示：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！