該小節介紹了各種技術和它們的優缺點，並提供了網上的更多資源（如果你想獲得這些技術的實踐經驗，你可以看看Adrian Mouat的書Using Docker）。

ZooKeeper

Apache ZooKeeper是ASF的頂級專案，基於JVM的集中式配置管理工具，提供了與Google的Chubby相相容的功能。ZooKeeper(ZK)將資料載荷組織成檔案系統，成為znodes的層級結構。在叢集中，選舉出一個leader節點，客戶端能夠連線到伺服器中的任意一個來獲取資料。一個ZK叢集中需要2n+1個節點。最常見的配置是3、5、7個節點。

ZooKeeper是經戰場證明的、成熟的、可擴充套件的解決方案，但是也有一下缺點。有些人認為ZK叢集的安裝和管理不是一個令人愉快的體驗。我碰到的大多數ZK問題都是因為某個服務（我想到了Apache Storm）錯誤地使用了它。它們可能在znodes裡放入了太多資料，更糟糕的是，他們的讀寫率很不健康（unhealthy read-write ratio），特別是寫得太快。如果你打算使用ZK的話，至少考慮使用高層介面。例如，Apache Curator封裝了ZK，提供了大量的方法；Netflix的Exhibitor可以管理和監控一個ZK叢集。

從圖4-1可以看出，你可以看到兩個元件：R/W

(作為註冊監控器（registration watcher），你需要自己提供)和NGINX（被R/W控制）。當一個容器被排程到一個節點上時，它會在ZK中註冊，使用一個路徑為/$nodeID/$containerID的znode，IP地址作為資料載荷。R/W監控znodes節點的變化，然後相應地配置NGINX。這種方法對於HAProxy和其他負載均衡器也同樣有效。

圖 4-1

etcd

etcd是由CoreOS團隊使用Go語言編寫的。它是一個輕量級的、分散式鍵值對資料庫，使用Raft演算法實現一致性（帶有leader選舉的leader-follower模型），在叢集中使用複製日誌（replicated log）向followers分發lead收到的寫請求。從某種意義上說，在概念上，etcd和ZK是相當類似的。雖然負載資料是任意的，但是etcd的HTTP API是基於JSON的。就像ZK一樣，你可以觀察到etcd儲存的值的變化。etcd的一個非常有用的特性是鍵的TTL，是服務發現的重要的一個結構單元。和ZK一樣，一個etcd叢集至少需要2n+1個節點。

etcd的安全模型支援基於TLS/SSL和客戶端證書加密的線上加密（on-the-wire encryption），加密可以發生在客戶端和叢集之間，也可以在etcd節點之間。

在圖4-2中，你可以看到etcd服務發現的搭建和ZK是相當類似的。主要區別在於etcd使用confd來配置NGINX，而不是使用自己編寫的指令碼。和ZK一樣，這種搭建方法也適用於HAProxy或者其他負載均衡器。

圖 4-2

Consul

Consul是HashiCorp的產品，也是用Go語言寫的，功能有服務註冊、服務發現和健康檢查，可以使用HTTP API或者DNS來查詢服務。Consul支援多資料中心的部署。

Consul的其中一個特性是一個分散式鍵值對資料庫，與etcd相似。它也是用Raft一致性演算法（同樣需要2n+1個節點），但是部署方式是不同的。Consul有agent的概念，有兩種執行方式：伺服器模式（提供鍵值對資料庫和DNS）和客戶端模式（註冊服務和健康檢查），使用serf實現了成員和節點發現。

使用Consul，你有四種方式來實現服務發現（從最可取到最不可取）：

• 使用服務定義配置檔案（service definition config file），由Consul agent解釋。
• 使用traefik等工具，其中有Consul後端（backend）。
• 編寫你自己的程序通過HTTP API註冊服務。
• 讓服務自己使用HTTP API來註冊服務。

想要學**Consul來做服務發現嗎？請閱讀這兩篇文章：Consul Service Discovery with Docker和Docker DNS & Service Discovery with Consul and Registrator。 

純基於DNS的解決方案在網際網路中，DNS經受了數十年的戰場驗證，是很健壯的。DNS系統的最終一致性、特定的客戶端強制性地（aggressively）快取DNS查詢結果、對於SRV記錄的依賴這些因素使你明白這是正確的選擇。

本小節之所以叫做“純基於DNS的解決方案”的原因是，技術上講Consul也是用了DNS伺服器，但這只是Consul做服務發現的其中一個選項。以下是著名的、常用的、純粹的基於DNS的服務發現解決方案：

Mesos-DNS該解決方案是專門用於Apache Mesos的服務發現的。使用Go編寫，Mesos-DNS下拉任意任務的有效的Mesos Master程序，並通過DNS或HTTP API暴露IP:PORT資訊。對於其他主機名或服務的DNS請求，Mesos-DNS可以使用一個外部的域名伺服器或者你的現有DNS伺服器來轉發Mesos任務的請求到Mesos-DNS。

SkyDNS使用etcd，你可以將你的服務通告給SkyDNS，SkyDNS在etcd中儲存了服務定義，並更新DNS記錄。你的客戶端應用傳送DNS請求來發現服務。因此，在功能層面，SkyDNS與Consul是相當類似的，只是沒有健康檢查。

WeaveDNSWeaveDNS由Weave 0.9引入，作為Weave網路的服務發現解決方案，允許容器按照主機名找到其他容器的IP地址。在Weave 1.1中，引入了所謂的Gossip DNS，通過快取和超時功能使得查詢更加快速。在最新的實現中，註冊是廣播到所有參與的例項上，在記憶體中儲存所有條目，並在本地處理查詢。

Airbnb的SmartStack和Netflix的Eureka在本小節中，我們將會看一下兩個定做的系統，它們是用來解決特定的需求。這並不意味著你不能或者不應該使用它們，你只是需要意識到它們。

Airbnb的SmartStack是一個自動的服務發現和註冊框架，透明地處理建立、刪除、故障和維護工作。在容器執行的同一個宿主機上，SmartStack使用了兩個分離的服務：Nerve（寫到ZK）用於服務註冊，Synapse（動態配置HAProxy）用於查詢。這是一個針對非容器環境的完善的解決方案，隨著實踐推移，你會看到對於Docker，SmartStack也是有用的。

Netflix的Eureka則不同，它執行在AWS環境中（Netflix全部執行在AWS上）。Eureka是一個基於REST的服務，用於定位服務以便負載均衡和中介軟體層伺服器的故障遷移；Eureka還有一個基於Java的客戶端元件，可以直接與服務互動。這個客戶端有一個內建的負載均衡器，可以做基本的round-robin的負載均衡。在Netflix，Eureka用於做red/black部署、Cassandra和memcached部署、承載應用中關於服務的元資料。

Eureka叢集在參與的節點之間非同步地複製服務註冊資訊；與ZK、etcd、Consul不同，Eureka相對於強一致性更傾向於服務可用性，讓客戶端自行處理過時的讀請求，優點是在網路分割槽上更有彈性。你也知道的：網路是不可靠的。

負載均衡服務發現的一個方面是負載均衡，有的時候負載均衡被認為是正交的，有的時候負載均衡被認為是服務發現的一部分。它可以在很多容器之間分散負載（入站服務請求）。在容器和微服務的語境下，負載均衡同時具有以下功能：
最大化吞吐量，最小化響應時間防止熱點（hotspotting），例如單一容器過載可以處理過度激進的DNS快取（overly aggressive DNS caching）
以下列舉了一些有名的Docker中的負載均衡解決方案：
* NGINX
* HAProxy
* Bamboo
* Kube-Proxy
* vulcand
* Magnetic.io的vamp-router
* moxy
* HAProxy-SRV
* Marathon的servicerouter.py
* traefik

如果你想了解更多關於負載均衡的資訊，請檢視Mesos meetup視訊和nginx.conf 2014上關於NGINX和Consul的負載均衡的演講。

更多話題在本章的最後，我列舉了服務發現解決方案的一覽表。我並不想評出一個優勝者，因為我相信這取決於你的用例和需求。因此，把下表當做一個快速定位和小結：


最後請注意：服務發現領域在不斷變化中，每週都會出現新工具。例如，Uber最近開源了它的內部解決方案Hyperbahn，一個路由器的overlay網路，用來支援TChannel RPC協議。因為容器服務發現在不斷髮展，因此你可能要重新評估最初的選擇，直到穩定下來為止。

容器和編排就像上一章中介紹的那樣，使用cattle方法來管理基礎架構，你不必手動為特定應用分配特定機器。相反，你應該使用排程器來管理容器的生命週期。儘管排程是一個重要的活動，但是它其實只是另一個更廣闊的概念——編排的一部分。

從圖5-1，可以看到編排包括健康檢查（health checks）、組織原語（organizational primitives，如Kubernetes中的labels、Marathon中的groups）、自動擴充套件（autoscaling）、升級/回滾策略、服務發現。有時候base provisioning也被認為是編排的一部分，但是這已經超出了本書的討論範圍，例如安裝Mesos Agent或Kubernetes Kubelet。

服務發現和排程是同一枚硬幣的兩面。決定一個特定的容器執行在叢集的哪個節點的實體，稱之為排程器。它向其他系統提供了containers->locations的對映關係，可以以各種方式暴露這些資訊，例如像etcd那樣的分散式鍵值對資料庫、像Mesos-DNS那樣的DNS。

圖 5-1
本章將從容器編排解決方案的角度討論服務發現和網路。背後的動機很簡單：假設你使用了某個平臺，如Kubernetes；然後，你主要的關注點是平臺如何處理服務發現和網路。

 注意：
接下來，我會討論滿足以下兩個條件的容器編排系統：開源的和相當大的社群。
你可以看一下以下幾個不同的解決方案：Fackebook的Bistro或者託管的解決方案，如Amazon EC2的容器服務ECS。
另外，你如果想多瞭解一下分散式系統排程這個主題，我推薦閱讀Google關於Borg和Omega的研究論文。在我們深入探討容器編排系統之前，讓我們先看一下編排的核心元件——排程器到底是做什麼的。
排程器到底是做什麼的？分散式系統排程器根據使用者請求將應用分發到一個或多個可用的機器上。例如，使用者可能請求執行應用的100個例項（或者Kubernetes中的replica）。

在Docker中，這意味著：（a）相應的Docker映象存在宿主機上；（b）排程器告訴本地的Docker Daemon基於該映象開啟一個容器。

在圖5-2中，你可以看到，對於叢集中執行的應用，使用者請求了三個例項。排程器根據它對於叢集狀態的瞭解，決定將應用部署在哪裡。比如，機器的使用情況、成功啟動應用所必須的資源、約束條件（該應用只能執行在使用SSD的機器）等。進一步地，服務質量也是考量因素之一。

圖 5-2
通過John Wilkes的Cluster Management at Google瞭解更多內容。

 警告：
對於排程容器的限制條件的語義，你要有概念。例如，有一次我做了一個Marathon的demo，沒有按照預期工作，原因是我沒有考慮佈局的限制條件：我使用了唯一的主機名和一個特定的角色這一對組合。它不能擴充套件，原因是叢集中只有一個節點符合條件。同樣的問題也可能發生在Kubernetes的label上。
Vanilla Docker and Docker Swarm創造性地，Docker提供了一種基本的服務發現機制：Docker連線（links）。預設情況下，所有容器都可以相互通訊，如果它們知道對方的IP地址。連線允許使用者任何容器發現彼此的IP地址，並暴露埠給同一宿主機上的其他容器。Docker提供了一個方便的命令列選項--link，可以自動實現這一點。

但是，容器之間的硬連線（hard-wiring of links）並不有趣，也不具擴充套件性。事實上，這種方法並不算好。長久來說，這個特性會被棄用。

讓我們看一下更好的解決方案（如果你仍然想要或者必須使用連線的話）：ambassador模式。

Ambassadors如圖5-3所示，這個模式背後的想法是使用一個代理容器來代替真正的容器，並轉發流量。它帶來的好處是：ambassador模式允許你在開發階段和生產階段使用不同的網路架構。網路運維人員可以在執行時重寫應用，而不需要更改應用程式碼。

簡單來說，ambassador模式的缺點是它不能有效地擴充套件。ambassador模式可以用在小規模的、手動的部署中，但是當你使用真正的容器編排工具（如Kubernetes或Apache Mesos）時，應該避免使用ambassador模式。

圖 5-3
 注意：
如果你想要了解如何在Docker中部署ambassador模式，我再次建議你參考Adrian Mouat的書Using Docker。事實上，在圖5-3中，我使用的就是他的amouat/ambassador映象。
Docker Swarm除了容器的靜態連結（static linking），Docker有一個原生的叢集工具Docker Swarm。Docker Swarm基於Docker API構建，並通過以下方式工作：有一個Swarm manager負載排程，在每一個宿主機上運行了一個agent，負責本地資源管理（如圖5-4所示）。

Swarm中有趣的地方在於，排程器是外掛式的（plug-able）,所以你可以使用除了內建以外的其他排程器，如Apache Mesos。在寫本書的過程中，Swarm釋出了1.0版本，並完成了GA（General Availability）；新的特性（如高可用性）正在進行開發中。

圖 5-4

 網路在本書的第2章和第3章中，我們介紹了Docker中的單宿主機和多宿主機中的網路。

 服務發現Docker Swarm支援不同的後端：etcd、Consul和Zookeeper。你也可以使用靜態檔案來捕捉叢集狀態。最近，一個基於DNS的服務發現工具wagl被引入到了Swarm中。

如果你想更多瞭解Docker Swarm，可以讀一下Rajdeep Dua的幻燈片。

KubernetesKubernetes（請看圖5-5）是一個opinionated的開源框架，彈性地管理容器化的應用。簡單來說，它吸取了Google超過十年的執行容器負載的經驗，我們會簡要地介紹一下。進一步地，你總是可以選擇其他開源或閉源的方法來替換Kubernetes的預設實現，比如DNS或監控。

圖 5-5
以下討論假設你已經熟悉Kubernetes和它的技術。如果你還不熟悉Kubernetes的話，我建議看一下Kelsey HighTower的Kubernetes Up and Running。

Kubernetes中，排程單元是一個pod，這是a tightly coupled set of containers that is always collocated。pod執行例項的數目是由Replication Controller定義和指定的。pods和services的邏輯組織是由labels定義的。

在每個Kubernetes節點上，執行著一個稱為Kubelet的agent，負責控制Docker daemon，向Master彙報節點狀態，設定節點資源。Master節點提供API（例如，圖5-6中的web UI），收集叢集現在的狀態，並存儲在etcd中，將pods排程到節點上。

圖 5-6

 網路在Kubernetes中，每個pod都有一個可路由的IP，不需要NAT，叢集節點上的pods之間也可以相互通訊。pod中的所有容器共享一個埠名稱空間（port namespace）和同一個notion localhost，因此沒有必要做埠代理（port brokering）。這是Kubernetes的基本要求，可以通過network overlay來實現。

在pod中，存在一個所謂的infrastructure容器，kubelet例項化的第一個容器，它會獲得pod的IP，並設定網路名稱空間。pod中的所有其他容器會加入到infra容器的網路和IPC名稱空間。infra容器的網路啟用了bridge模式（請參考第九頁的bridge模式網路），pod中的所有其他容器使用container模式（請參考第11頁的container模式網路）來共享它的名稱空間。infra容器中的初始程序實際上什麼也沒做，因為它的目的只是提供名稱空間的載體。關於埠轉發的最近的work around可能在infra容器中啟動額外的程序。如果infra容器死亡的話，那麼Kubelet會殺死pod中所有的程序，然後重新啟動程序。

進一步地，Kubernetes的名稱空間會啟動所有control points。其中一個網路名稱空間的例子是，Calico專案使用名稱空間來強化coarse-grained網路策略（policy）。

 服務發現在Kubernetes的世界裡，有一個服務發現的canonical抽象，這是service primitive。儘管pods隨時可能啟動和銷燬因為他們可能失敗（或者pods執行的宿主機失敗），服務是長時間執行的：它們提供叢集層面的服務發現和某種級別的負載均衡。它們提供了一個穩定的IP地址和持久化名字，compensating for the shortlivedness of all equally labelled pods。Kubernetes提供了兩種發現機制：通過環境變數（限制於一個特定節點上）和DNS（叢集層面上的）。