分佈式體系結構之集中式結構

前言

對於雲計算通俗的理解是把多個服務器管理起來，作爲一個統一的資源提供服務。而如何組織，就是分佈式體系結構的範疇了。在很多場景下請求都會彙總到一臺服務器上，由這臺服務器統一協調我們的請求和其他服務器之間的關係。這種由一臺服務器統一管理其他服務器的方式，就是分佈式體系結構中的集中式結構（也稱爲 Master/Slave 架構），其中統一管理其他服務器的服務器是主，其他服務器是從。下文主要介紹分佈式體系結構中的集中式結構。

1. 分佈式集中式結構概述

集中式結構就是，由一臺或多臺服務器組成中央服務器，系統內的所有數據都存儲在中央服務器中，系統內所有的業務也均先由中央服務器處理。多個節點服務器與中央服務器連接，並將自己的信息彙報給中央服務器，由中央服務器統一進行資源和任務調度：中央服務器根據這些信息，將任務下達給節點服務器；節點服務器執行任務，並將結果反饋給中央服務器。
集中式結構最大的特點，就是部署結構簡單。這是因爲，集中式系統的中央服務器往往是多個具有較強計算能力和存儲能力的計算機，爲此中央服務器進行統一管理和調度任務時，無需考慮對任務的多節點部署，而節點服務器之間無需通信和協作，只要與中央服務器通信協作即可，具體示意圖如下所示：

2. 典型的集中式結構介紹

接下來以 Google Borg、Kubernetes 和 Apache Mesos 三個典型的集羣管理系統爲例，來更加深入學習集中式結構的原理。

2.1 Google Borg

Borg 是 Google 內部使用的集羣管理系統，採用了典型的集中式結構，負責提交、調度、開始、重啓和管理 Google 運行在其上的所有應用。
在 Borg 中，一個集羣稱爲一個 Cell，每個 Cell 裏面有一個 Leader，稱爲 BorgMaster，即爲中央服務器；其他服務器爲節點服務器或從服務器，被稱爲 Borglet。
其中中央服務器 BorgMaster 由兩個進程組成，一個是 Borgmaster 主進程，一個是獨立的 scheduler 進程：

• 主進程處理客戶端的 RPC 請求，比如任務的執行狀態更新或者查詢等；同時，管理系統中所有實體的狀態（比如，服務器、任務等），並負責和Borglet 通信。
• scheduler 進程負責任務調度，通過任務對資源的需求以及當前 Borglet所在服務器的資源情況進行匹配，爲任務尋找一個合適的節點服務器執行。
  而其他節點服務器的Borglet：是運行在每個節點機器的一個 agent，負責任務的拉起、停止、重啓等，並管理和蒐集本服務器資源，將任務的狀態、服務器狀態等信息上報給 BorgMaster。而 BorgMaster 會週期性地輪詢每個 Borglet，以獲取節點服務器的狀態和資源信息等。
  Borg 的整體架構示意圖如下所示：
  
  Borg 的主要用戶是 Google 的開發者以及運行 Google 應用和服務的系統管理員（網站可靠性工程師，簡稱 SRE）。用戶以 Job 的形式向 Borg 提交工作，每個 Job 由運行一個或多個運行相同程序的 Task 組成。每個 Job 運行在一個 Borg Cell 中，並將一組機器當做一個單元進行管理。
  Borg 可以運行各種各樣的任務，這些任務主要分爲兩類：
• 第一類是長服務，即長時間運行不停止的服務，並且要求能夠處理短暫的、延遲敏感的請求（延遲要求在幾微秒到幾百毫秒之間）。這些服務主要用於面向終端用戶的服務（比如 Gmail、Google Docs、Web 搜索），以及內部的一些基礎設施服務（比如 BigTable）。
• 第二類是批處理任務。通常需要幾秒到幾天的時間來完成的批處理 Job，這些 Job 對短時間的性能波動並不是非常敏感。
  這些負載通常在 Cell 之間混合分佈，每個 Cell 隨着主要租戶以及時間的不同會運行各種不同的應用。

Borg的主要優勢

• 開發者只需關注應用，不需要關注底層資源管理。它隱藏了資源管理以及錯誤處理，因此用戶能集中精力開發應用。
• 高可靠性和可用性，支持多種應用。
• 支持上千級服務器的管理和運行。

2.2 Kubernetes

Kubernetes 是 Google 開源的容器集羣管理系統，是 Borg 的一個開源版本。Kubernetes 是用於自動部署、擴展和管理容器化應用程序的開源系統。其核心是，在集羣的節點上運行容器化應用，可以進行自動化容器操作，包括部署、調度和在節點間彈性伸縮等。Kubernetes 也是典型的集中式結構，一個 Kubernetes 集羣，主要由 Master 節點和 Worker 節點組成，以及客戶端命令行工具 kubectl 和其他附加項。
Master 節點的組件構成及功能：
它運行在中心服務器上，Master 節點由 API Server、Scheduler、Cluster State Store 和 Control Manger Server 組成，負責對集羣進行調度管理。

• API Server：是所有 REST 命令的入口，負責處理 REST的操作，確保它們生效，並執行相關業務邏輯。
• Scheduler：根據容器需要的資源以及當前 Worker節點所在節點服務器的資源信息，自動爲容器選擇合適的節點服務器。
• Cluster State Store：集羣狀態存儲，默認採用etcd，etcd 是一個分佈式 key-value 存儲，主要用來做共享配置和服務發現。
• Control Manager：用於執行大部分的集羣層次的功能，比如執行生命週期功能（命名空間創建和生命週期、事件垃圾收集、已終止垃圾收集、級聯刪除垃圾收集等）和API 業務邏輯。
  Worker 節點組件構成及功能：
  Worker是真正的工作節點，運行在從節點服務器，包括 kubelet 和 kube-proxy核心組件，負責運行業務應用的容器。其中 ：
• kubelet：用於通過命令行與 API Server 進行交互，根據接收到的請求對 Worker節點進行操作。也就是說，通過與 API Server 進行通信，接收 Master 節點根據調度策略發出的請求或命令，在 Worker節點上管控容器（Pod），並管控容器的運行狀態（比如，重新啓動出現故障的 Pod）等。Pod 是 Kubernetes的最小工作單元，每個 Pod 包含一個或多個容器。
• kube-proxy：負責爲容器（Pod）創建網絡代理 / 負載平衡服務，從 APIServer 獲取所有 Server 信息，並根據 Server 信息創建代理服務，這種代理服務稱之爲Service。Kube-proxy 主要負責管理 Service 的訪問入口，即實現集羣內的 Pod 客戶端訪問Service，或者是集羣外訪問 Service，具有相同服務的一組 Pod 可抽象爲一個 Service。每個 Service都有一個虛擬 IP 地址（VIP）和端口號供客戶端訪問。
  Kubernetes 架構示意圖如下所示：
  
  如上圖所示：
• Kube DNS ：負責爲整個集羣提供 DNS 服務；
• CNI 是 Container Network Interface 的一個標準的通用接口，用於連接容器管理系統和網絡插件。

Kubernetes 的主要優勢

是一個容器編排引擎，不僅支持 Docker，還支持 Rocket(另一種容器技術)。Kubernetes 也已經被很多公司採用，比如網易雲、華爲在需要使用容器進行資源隔離以運行相關業務的場景下，採用了大規模 Kubernetes 集羣。在容器管理方面，Kubernetes 有很多優勢。

• 自動化容器的部署和複製。Kubernetes 執行容器編排，因此不必人工編寫這些任務的腳本。
• 將容器組織爲組，彈性伸縮。Kubernetes引入 Pod 機制，Pod 代表着能夠作爲單一應用程序加以控制的一組容器集合。通過 Pod 機制，Kubernetes實現了多個容器的協作，能夠有效避免將太多功能集中到單一容器鏡像這樣的錯誤實踐中。此外，軟件可以向外擴展跨越多個 Pods實現初步部署，且相關部署可隨時進行規模伸縮。
• 容器間負載均衡。Services 用於將具備類似功能的多個 Pod整合爲一組，可輕鬆進行配置以實現其可發現性、可觀察性、橫向擴展以及負載均衡。
• 易於版本控制與滾動更新。Kubernetes採取“滾動方式”實現編排，且可跨越部署範圍內的全部 Pod。這些滾動更新可進行編排，並以預定義方式配合當前可能尚不可用的 Pods數量，以及暫時存在的閒置 Pods 數量。Kubernetes 利用新的應用程序鏡像版本對已部署 Pods進行更新，並在發現當前版本存在不穩定問題時回滾至早期部署版本。

2.3 Mesos

Mesos是Apache 旗下的開源分佈式資源管理框架，被稱爲是分佈式系統的內核，最初由加州大學伯克利分校的 AMPLab 開發，後在 Twitter 得到廣泛使用。
Mesos 的開發受到了 Borg 系統的啓發，也是採用的典型的集中式架構。
Mesos 與 Borg 不同之處在於：

• Borg 的 Master 直接對接用戶應用，也就是說用戶可以向 Borg 的 Master 直接請求任務。但Mesos 只負責底層資源的管理和分配，並不涉及存儲、 任務調度等功能；
• Mesos Master 對接的是 Spark、Hadoop、Marathon 等框架，用戶的任務需要提交到這些框架上。
• Mesos 的任務調度框架是雙層結構。

在 Mesos 中，一個集羣包括：

• Mesos Master：運行在中央服務器上，負責收集和管理所有 Agent 所在服務器的資源和狀態，並且對接 Spark、Hadoop 等框架，將集羣中服務器的資源信息告知給這些框架，以便這些框架進行任務資源匹配和調度。
• Mesos Agent：運行在節點服務器上，負責任務的拉起、停止、重啓等，並負責收集所在服務器的資源 (比如 CPU、內存等) 信息和狀態，上報給 Mesos Master。

Mesos Master 通常採用一主兩備的方式，以方便故障處理和恢復。而 Mesos Master 的選主策略，採用的就是 ZAB 算法。
Mesos 架構示意圖如下所示：

Mesos支持容器部署

Mesos 本身只負責資源管理，不負責任務調度。但 Mesos 可以對接不同的框架，Mesos+Marathon 可以支持容器調度和部署。Marathon 支持容器的調度，將容器部署請求發給 Mesos Master，Mesos Master 再將請求轉發給 Mesos Agent，Mesos Agent 的執行器會將容器拉起。目前，Mesos+Marathon 支持的容器，主要包括 Docker 和 cgroups。

Mesos 的主要優勢

Mesos 對接的是框架，並且可以同時對接多個框架，目前已經被很多公司使用。比如，國外的 Twitter、Apple、Airbnb、Uber 等，國內的愛奇藝、去哪兒、攜程、噹噹等。
這些公司選擇 Mesos，主要是因爲它具有如下優勢：

• 效率：Mesos對物理資源進行了邏輯抽象，在應用層而不是物理層分配資源，通過容器而不是虛擬機（VM）分配任務。因爲應用程序的調度器知道如何最有效地利用資源，所以在應用層分配資源能夠爲每個應用程序的特殊需求做考量 ; 而通過容器分配任務則能更好地進行“裝箱”。
• 可擴展性：Mesos 可擴展設計的關鍵是兩級調度架構，其中 Framework進行任務調度，Mesos Master 進行資源分配。由於 Master不必知道每種類型的應用程序背後複雜的調度邏輯，不必爲每個任務做調度，因此可以用非常輕量級的代碼實現，更易於擴展集羣規模。
• 模塊化：每接入一種新的框架，Master無需增加新的代碼，並且 Agent 模塊可以複用，爲此開發者可以專注於應用和框架的選擇。就使得 Mesos可以支持多種框架，適應不同的應用場景。隨着分佈式應用程序和微服務的流行，越來越多的用戶正在尋找一種技術，來幫助他們管理這些複雜的應用程序。而Mesos 爲數據中心帶來的這些好處，就使得越來越多的人關注 Mesos 及其相關項目。

總結