最佳实践系列丨Docker EE 服务发现参考架构（二）
出品丨Docker公司（ID：docker-cn）
編譯丨小東
每周一、三、五晚6點10分 與您不見不散
服務發現對服務進行注冊并發布其連接信息，以使其他服務了解如何連接到服務。隨著應用向微服務和面向服務的架構轉變，服務發現已經成為所有分布式系統的必要組成部分，增加了這些環境的運維復雜性。點擊以下標題，回顧第一部分內容：
- 最佳實踐系列丨Docker EE 服務發現參考架構（一）
HTTP 網格路由
swarm mode 網格路由非常適合傳輸層路由。它使用服務的已發布端口路由到服務。但是，如果希望基于主機名將流量路由到服務應該怎么辦？HTTP 網格路由 (HRM) 是一項新功能，它可以在應用層 (L7)上啟用服務發現。HRM 通過添加 HTTP 標頭檢查等應用層功能對 swarm mode 網格路由進行了擴展。HRM 和 swarm mode 網格路由兩者結合使用可實現靈活且穩健的服務交付。結合 HRM 可通過傳遞給服務的 DNS 標記使每個服務都可以被訪問。隨著服務的橫向擴展以及更多從節點的添加，服務也將使用輪詢負載均衡。
HRM 通過使用 HTTP/1.1 標頭字段定義工作。每個 HTTP/1.1 TCP 請求都包含 Host: 標頭。可以使用 curl查看 HTTP 請求標頭：
$ curl -v docker.com* Rebuilt URL to: docker.com/* Trying 52.20.149.52...* Connected to docker.com (52.20.149.52) port 80 (#0)> GET / HTTP/1.1> Host: docker.com> User-Agent: curl/7.49.1> Accept:*/*將 HRM 與 HTTP 請求搭配使用時，需要串聯使用 swarm mode 網格路由和 HRM。當使用 com.docker.ucp.mesh.http 標記創建服務時，HRM 配置將會更新，以將所有包含 Host: 標頭（在 com.docker.ucp.mesh.http 標記中指定）的 HTTP 請求路由到新建服務的 VIP。由于 HRM 是服務，可使用配置的已發布端口在集群中的任何節點上訪問 HRM。
以下圖表顯示了 swarm mode 網格路由和 HRM 共同使用時的工作原理的高級視圖。
- 流量從外部負載均衡器流入 swarm mode 網格路由；
- HRM 服務配置為偵聽端口 80 和 8443，因此任何對 UCP 集群的端口 80 或 8443 的請求都會流向 HRM 服務；
- 所有連接到經啟用可實現“基于主機名的路由”的網絡的服務都可使用 HRM 來基于 HTTP Host: 標頭路由流量；
仔細看，您就會了解 HRM 的工作過程。下圖對上一圖表中表示的工作原理進行了更詳細的說明。
- 流量經由入口網絡上的 swarm mode 網格路由流向 HRM 服務的已發布端口。
- 創建服務時，會在 swarm mode 網格路由 (L4) 上向它們分配 VIP。
- HRM 接收 TCP 數據包并檢查 HTTP 標頭。
- 將檢查包含 com.docker.ucp.mesh.http 標記的服務來查看它們是否與 HTTP Host: 標頭匹配。如果 Host: 標頭和服務標記匹配，就會使用 swarm mode 網格路由 (L4) 將流量路由到服務的 VIP。
- 如果服務包含多個從節點，那么將使用內部 L4 網格路由通過輪詢對每個從節點容器進行負載均衡。
RM 和 Swarm Mode 網格路由的差異
HRM 和 swarm mode 網格路由的主要差異在于 HRM 僅能夠在應用層上供 HTTP 流量使用，而 swarm mode 網格路由在較靠下的傳輸層上工作。
根據應用來決定使用哪種網格路由。如果應用需要被公開訪問且為 HTTP 服務，那么 HRM 就非常適合。如果需要進行雙向 TLS 認證才可訪問后端應用，那么使用傳輸層可能會更加適合。
使用 HRM 的另一項優勢在于僅需較少的配置就可將流量路由到服務。通常，在服務上設置標記時僅需一條 DNS 記錄。如果使用了通配符 DNS 記錄，那么除設置服務標記之外，就無需進行其他配置。在很多組織中，通常會限制對負載均衡器和 DNS 進行訪問。如果僅通過服務標記就可控制對應用的請求，開發人員就能夠快速循環訪問更改。對于 swarm mode 網格路由，可以配置任意前端負載均衡器來將流量發送到服務的已發布端口。
下面的圖表顯示了使用通配符 DNS 的示例：
啟用 HRM
可從 UCP Web 控制臺啟用 HTTP 網格路由。要啟用它：
啟用后，UCP 會在 swarm 集群上創建服務來基于 HTTP Host: 標頭將流量路由到指定的容器。由于 HRM 服務是 swarm mode 服務，UCP 集群中的每個節點都可通過接收來自端口 80 和 8443 的流量來將流量路由到 HRM。HRM 服務在集群范圍內公開端口 80 和 8443，任何通過端口 80 和 8443 發送的對集群的請求都會發送到 HRM。網絡和訪問控制 HTTP 網格路由使用一個或多個 overlay 網絡來與后端服務進行通信。默認情況下會創建名為 ucp-hrm 的單個網絡，訪問控制標記為 ucp-hrm。要向該網絡添加服務，需要具備管理員級別的訪問權限，或用戶必須屬于具有 ucp-hrm 訪問權限的組。
網絡和訪問控制
HTTP 網格路由使用一個或多個 overlay 網絡來與后端服務進行通信。默認情況下會創建名為 ucp-hrm 的單個網絡，訪問控制標記為 ucp-hrm。要向該網絡添加服務，需要具備管理員級別的訪問權限，或用戶必須屬于具有 ucp-hrm 訪問權限的組。
該默認配置無法對使用 HTTP 網格路由的各個服務進行隔離，因為各個服務共享 ucp-hrm 網絡。
要對服務實施隔離，必須在啟用 HTTP 網格路由前使用 com.docker.ucp.mesh.http 標記創建一個或多個 overlay 網絡。HRM 啟用后，它可以路由到連接到這些網絡的所有服務，但是不同網絡上的服務不能直接通信。要使 HRM 在新的網絡上可用，唯一方法是禁用并重新啟用 HRM。
以下為創建包含 com.docker.mesh.http 標記的 overlay 網絡的示例。對管理員用戶或具有管理員權限的用戶使用 UCP 客戶端證書包時，請運行以下命令：
docker network create -d overlay --label com.docker.ucp.mesh.http=true new-hrm-network也可使用 UCP UI 達到相同的目的，方法是在創建網絡時選擇啟用基于主機名的路由。
HRM 要求
要使用 HRM，服務需要滿足三個要求。
針對 HRM 配置DNS
該部分介紹如何為使用 HRM 的服務配置 DNS。要使用 HRM，服務的 DNS 記錄需要指向 UCP 集群。由于 swarm mode 網格路由提供了靈活性，可通過多種不同的方式配置服務的 DNS 記錄。
如果服務需要可以被公開訪問才可將請求發送到 foo.example.com，那么可以通過以下任何一種方式配置服務的 DNS 記錄：
最佳解決方案（為實現高可用性）是在 UCP 集群的前端配置外部 HA 負載均衡器。使用外部 HA 負載均衡器時需要牢記以下注意事項：
- 將 foo.example.com 的 DNS 記錄設置為指向外部負載均衡器。
- 外部負載均衡器應指向駐留在不同的可用性區域中的多個 UCP 節點，以增強可恢復性。
- 配置外部負載均衡器來對 HRM 服務的已配置的已發布端口執行 TCP 運行狀況檢查，以便通過運行狀況良好的 UCP 節點路由流量。
應該使用哪些節點來路由流量？管理節點還是工作節點？針對此問題的回答有好幾種。
1.對于規模較小的部署，可通過管理節點來路由流量，因為管理節點通常為靜態性質。
- 優勢：它們通常不會（在新主機、新 IP 等之間）經常變動，所以易于使負載均衡器指向相同的節點。
- 缺點：它們負責路由控制平面流量。如果應用流量較多，采用這種方法可能會使這些節點上的流量飽和，從而給集群帶來不利影響。
2.通過工作節點路由流量
- 優勢：它們不管理整個集群，因此額外網絡開銷較少。
- 缺點：它們屬于“cattle”節點。如果負載均衡器指向工作節點，圍繞銷毀和構建節點構建自動化時需要考慮這一點。
無論前端負載均衡器將流量指向哪種類型的實例，都需要確保實例具有足夠的網絡連接。
總結
以上是生活随笔為你收集整理的最佳实践系列丨Docker EE 服务发现参考架构（二）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 正则表达式 - 元字符
- 下一篇： 4-玩转数据结构-链表