如何實現微服務的自動擴展
前面講了一些關於自動擴展的理論知識，但如何實現自動擴展，並不是三言兩語就能夠說得清楚的。特別是為了實現前面提到的那些自動擴展的模式及策略，在作業系統級別方面會需要大量的執行腳本。在自動擴展方面，SpringCloud框架也並沒有給出確切的答案。
隨著微服務架構的流行，以Docker等為首的容器技術開始火熱發展。Docker 是實現自動擴展非常好的基礎，因為它提供了一個統一-的容 器處理方式，而不管微服務所使用的技術如何。它還幫助用戶隔離微服務，以避免相鄰的服務之間產生資源的競爭。
但是，Docker 和腳本只能部分解決問題。在大規模Docker部署的情況下，仍然需要回答如下問題。
●如何管理數千個容器?
●如何監控他們?
●在部署工件時，如何應用規則和約束?
●如何確保能夠正確地利用容器來獲得資源效率?
●如何確保至少有一定數量的最小實例正在運行?
如何確保依賴服務正常運行?
●如何進行滾動升級和優雅的遷移?
●如何回滾錯誤的部署?
所有這些問題都指出需要有一個解決方案來解決以下兩個關鍵功能。
●一個容器抽象層，在許多物理或虛擬機上提供統一的抽象 。
●容器編排和初始化系統在集群抽象之上智能管理部署。
本節將會重點討論這兩點。
容器編排
容器編排工具為開發人員和基礎架構團隊提供了一個抽象層來處理大規模的貨櫃部署。容器編排工具提供的功能因供應商而異。然而，他們都提供了共同的功能，其中包括發現、資源管理、監控和部署。
1.容器編排的重要性
編排很重要，是因為在微服務的架構裡面，應用程式被拆分成不同的微服務應用，因此需要更多的伺服器節點進行部署。為了正確管理微服務，開發人員傾向於為每個虛擬機部署一個微服務 ，這在一定程度上:降低了資源利用率。在很多情況下，這會導致CPU和內存的過度分配。
在大型系統的部署中，微服務的高可用性要求迫使運維人員會添加越來越多的服務實例以實現冗餘。實際上，雖然它提供了所需的高可用性，但這會導致未充分利用的伺服器實例。一般來說，與單一應用程式部署相比，微服務部署需要更多的基礎設施。由於基礎設施成本的增加，反而令許多組織看不到微服務的價值。如圖14-9 所示，為了實現系統的高可用性，每個微服務都會部署多個實例。
為了解決圖14-9 中所述的問題，首先需要一個能夠執行以 下操作的工具。
●自動執行一些活動。例如，高效地將容器分配給基礎設施，這對開發人員和管理員來說是透明的。
●為開發人員提供一個抽象層，以便他們可以將其應用程式部署到數據中心，而無須關心到底應用是要使用哪臺機器。
可以是最少的人為交互。
●通過最大限度地利用可用資源來高效構建、部署和管理應用程式。
容器正是能夠勝任上述工作的有力工具。使用容器，就可以以統一的方式來處理應用程式， 而無須關心微服務具體是使用了哪種技術。
2.容器編排的工作職責
典型的容器編排工具有助於虛擬化- -組計算機並將其作為- -個集群進行管理。容器協調工具還有助於將工作負載或容器移動到對用戶透明的機器上。
對於容器編排，業界並沒有統-的術語，常見的稱呼有容器編排、集群管理、數據中心虛擬化、容器調度、容器生命周期管理、數據中心作業系統等。
容器編排工具是為了幫助自助服務和配置基礎設施，而不是要求基礎設施團隊按照預定義的規格分配所需的機器。在這種自動化的容器編排方法中，機器不再是預配置並預先分配給應用程式。
一些容器編排工具還可以幫助跨多個異構機器，甚至可以跨多個虛擬化數據中心，並創建-一個彈性的私有雲式基礎架構。
容器編排工具目前沒有標準的參考模型。因此，不同的供應商可能實現的功能各不相同。
容器編排軟體一般都會具備以下關鍵功能。
●集群管理:將一個虛擬機和物理機集群作為- -臺大型機器進行管理。這些機器在資源能力方面可能是異構的，但基本上還是以Linux 為主要作業系統的機器。這些虛擬集群可以在雲端，也可以是在本地，或者是兩者的組合。
●自動部署:它支持應用程式容器的多個版本，並支持在大量集群機器上進行滾動升級。這些工具也能夠處理錯誤，並且可以回滾到可用的版本。
●可伸縮性:這樣可以根據需要處理應用程式實例的自動和手動可伸縮性，並將其作為主要目標進行優化利用。
● 運行狀況監控:適用於管理集群、節點和應用程式的運行狀況。它可以從集群中刪除有故障的機器和應用程式實例。
●基礎架構抽象:開發者不用擔心關於機器、容量等。這完全是容器編排軟體來決定如何計劃和運行應用。這些工具還從開發者中抽象出機器的細節，如容量、利用率和位置等。對於應用程式所有者來說，這相當於- - 臺幾乎可以無限容量的大型機器。
● 資源優化:這些工具的固有行為是以高效的方式在一組可用機器上分配容器工作負載，從而降低成本，並提高機器的利用率。
●資源分配:根據應用程式開發人員設置的資源可用性和約束來分配伺服器。資源分配將基於這些約束(如關聯性規則、埠要求、應用程式依賴性、運行狀況等)。
●服務可用性:確保服務在集群中的某處運行。在發生機器故障的情況下，容器編排通過在集群中的某個其他機器上重新啟動這些服務來自動處理故障。
●敏捷性:敏捷性工具能夠快速將工作負載分配給可用資源，或者在資源需求發生變化時將工作負載移至機器上。此外，還可以根據業務關鍵性、業務優先級等設置約束來重新調整資源。
●隔離:這些工具中有一些提供了開箱即用的資源隔離功能。因此，即使應用程式沒有進行容器化，也可以實現資源的隔離。
3.資源分配的常用算法
從簡單算法到具有機器學習和人工智慧的複雜算法，在容器編排中，資源分配會使用各種算法。
比較常用的算法有傳播( Spread)、裝箱( Bin Packing )和隨機( Random)。針對應用程式設置的約束，來設置基於資源可用性的默認算法。
圖14-10~圖14-12 顯示了這些算法是如何用部署填充到可用的機器上的。在這種情況下，這裡用兩臺機器進行演示。
資源分配的3種常用策略解釋如下。
●傳播:這將工作負載平均分配到可用的機器上，如圖14-10所示。
●裝箱: 這將試圖通過機器填充機器，並確保機器的最大利用率。在按需付費的雲服務中，裝箱算法是特別好的。
隨機:隨機選擇機器並在隨機選擇的機器上部署容器，如圖14-12所示。
隨著科技的發展，機器學習和協作過濾等手段可以更好地提高效率。例如，可以將未分配的資源分配給高優先級的任務( 這些任務意味著有更高的收益)，以便充分利用現有資源，提高創收。
4.與微服務的關係
微服務的基礎設施(如果配置不當)很容易導致基礎設施過大，本質上導致成本的增加。正如前面部分所討論的那樣，在處理大規模微服務架構系統時，具有容器編排工具的類似雲的環境對於實現成本效益至關重要。
在Spring Cloud 項目中利用Spring Boot來構建微服務，是利用容器編排技術的理想工具。由於基於Spring Cloud的微服務並不關心具體的位置，因此可以將這些服務部署到集群中的任何位置。
每當出現服務時，它都會自動註冊到服務註冊中心並通告其可用性。另外，消費者總是尋找服務註冊表來發現可用的服務實例。這樣，應用程式就可以支持完整的流體結構，而無須預先部署拓撲結構。使用Docker能夠在抽象運行時，以便服務可以在任何基於Linux的環境中運行。
5.與虛擬化技術的關係
容器編排解決方案在許多方面與傳統的伺服器虛擬化解決方案有著比較大的差異。容器編排解決方案作為應用程式組件，運行在虛擬機或物理機器之上。
常用的容器編排技術
1. Docker Swarm
Docker Swarm是Docker的本地容器編排解決方案。Swarm 提供與Docker的本地和更深層次的集成，並有著與Docker的遠程API兼容的API。它在邏輯上將- -組 Docker主機分組，並將它們作為一個大型的Docker虛擬主機進行管理。應用程式管理員和開發人員無須決定容器是在哪個主機上部署，這個決策將被委託給Docker Swarm。它將根據分組打包和擴展算法決定使用哪個主機。
由於Docker Swarm基於Docker的遠程API,現有Docker用戶的學習曲線與其他任何容器業務流程工具相比要少得多。然而，Docker Swarm是市場上較新的產品，僅支持Docker容器。
Docker Swarm使用管理器( manager)和節點( node)的概念。管理員通過管理器來與Docker容器進行交互和調度。節點則是Docker容器部署和運行的地方。
2. Kubernetes
Kubermetes ( k8s )來自Google 的工程設計，使用Go語言編寫，並正在Google進行大規模部署的測試。與Swarm類似，Kubernetes幫助管理跨集群節點的容器化應用程式。它有助於自動化容器部署和容器的調度與可伸縮性。它支持許多有用的開箱即用功能，如自動逐步展開、版本化部署和容器彈性管理等。
Kubermetes 體系結構具有主節點( master)、節點(node)和pod等概念。主節點和節點一起被稱為Kubernetes集群。主節點負責跨多個節點分配和管理工作負載，節點就是虛擬機或物理機器。
節點既可以被進一-步分割成pod,也可以託管多個pod。一個或多個容器在一個pod內分組並執行。
pod還有助於管理和部署共存服務以提高效率。Kubernetes 也支持標籤的概念作為鍵值對，以便查詢和查找容器。標籤是用戶定義的參數，用於標記執行常見類型工作負載的某些類型的節點，如前端Web伺服器等。
部署在集群上的服務將獲得- - 個IP/DNS用來訪問該服務。Kubernetes 對Docker有開箱即用的支持。然而，Kubernetes 的學習曲線會比Docker Swarm更多。作為OpenShift 平臺的一部分， RedHat為Kubernetes提供商業支持。
3. Apache Mesos
有關ApacheMesos的介紹，最早可追溯到BenjaminHindman等所寫的技術白皮書Mesos:APlatform for Fine-Grained Resource Sharing in the Data Center (可以在線查看該文章htp://mesos.berkeley.edu/mesos_ tech_ reportpdf )。後來Benjamin Hindman加入了Twitter, 負責開發和部署Mesos。再後來Benjamin Hindman離開Twitter而去了Mesosphere, 著手建設並商業化以Mesos為核心的DC/OS (數據中心作業系統)。
Mesos是Apache下的開源分布式資源管理框架，它被稱為是分布式系統的內核，使用內置Linux內核相同的原理，只是在不同的抽象層次。該Mesos內核運行在每個機器上，在整個數據中心和雲環境內向應用程式(如Hadoop、Spark、 Kafka、 Elasticsearch 等)提供資源管理和資源負載的API接口。
Apache Mesos具備以下特性。
● 線性可擴展性:業界認可的可擴展到10000個節點。
●高可用性:使用ZooKeeper實現master和agent的容錯，且實現了無中斷的升級。
支持容器:原生支持Docker容器和AppC鏡像。
●可拔插的隔離:對CPU、內存、磁碟、埠、GPU和模塊實現自定義資源的一-等( first class )隔離支持。
●二級調度:支持使用可插拔調度策略來在相同集群中運行雲原生和遺留的應用程式。
API: 提供HTTP API在操作集群、監控等方面開發新的分布式應用程式。
Web界面:內置Web界面查看集群的狀態，並可以導航containersandbox(容器沙箱)
跨平臺:可以在Linux、OSX和Windows 上運行，並且與雲服務提供商無關。
Mesos與以往的解決方案稍有不同。它更多的是依靠其他框架來管理工作負載執行的資源管理器。它位於作業系統和應用程式之間，提供了- -個邏輯的機器集群。
Mesos是一個分布式系統內核，將多臺計算機邏輯分組並將其虛擬化為一臺 大型機器。它能夠將許多異構資源分組到一個統一資源集群 上，在這個集群上可以部署應用程式。基於這些原因，Mesos也被稱為在數據中心建立私有雲的工具。
Mesos具有主節點和從節點的概念。與早期的解決方案類似，主節點負責管理集群，而從節點負責運行工作負載。它在內部使用ZooKeeper進行集群協調和存儲，也支持框架的概念。這些框架負責調度和運行非貨櫃應用程式和容器。Marathon、 Chronos 和Aurora是應用程式調度和執行的流行框架。Netflix 的Fenzo是另一個開源的Mesos框架。有趣的是，Kubernetes 也可以用作Mesos框架。
Marathon支持Docker容器，以及非容器化的應用程式。Spring Boot可以直接配置在Marathon中。Marathon提供了許多開箱即用的功能，如支持應用程式依賴項用於擴展和升級服務的應用程式分組、實例的啟動和關閉、滾動升級、回滾失敗升級等。
Mesosphere作為DC/OS平臺的一部分， 為Mesos和Marathon提供商業支持。
總結
Spring Cloud並沒有提供現成的處理自動擴展的方案，但結合目前市面上常用的容器編排技術(如上文提到的Docker Swarm、Kubermetes、Apache Mesos等),能夠方便地實現服務的自動擴展。
自動擴展在微服務架構中是一個相對複雜的問題，學習成本相對也比較高。由於自動擴展並非是Spring Cloud的核心話題，因此本文也只是給出了一些基本的概念和思路，不做深入的探討。如果讀者對這方面感興趣，也可以自行查閱相關資料。以下是一些常用的學習連結地址。
Docker Swarm: htps://cs.docker.com/swarm
● Kubernetes : htps://kubermetes.io/docs/home/.
●Apache Mesos: htp:/m/esos.apache .org/documentation/latest。
本篇文章內容給大家講解的是如何實現微服務的自動擴展
下篇文章給大家講解的是微服務的高級主題一 熔斷機制；
覺得文章不錯的朋友可以轉發此文關注小編；
感謝大家的支持！