最佳实践系列丨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 Web 控制台。
浏览至管理员设置 > 网格路由。
选中启用 HTTP 网格路由。
配置 HRM 要侦听的端口，默认值为 80 和 8443。HTTPS 端口默认为 8443，这样它就不会和默认 UCP 管理端口 (443) 互相干扰。

启用后，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，服务需要满足三个要求。

服务必须连接到具有 com.docker.ucp.mesh.http 标记的网络
服务必须发布一个或多个端口
服务必须包含一个或多个带有前缀 com.docker.ucp.mesh.http 的标记，以指定要路由的端口
针对 HRM 配置 DNS

针对 HRM 配置DNS

该部分介绍如何为使用 HRM 的服务配置 DNS。要使用 HRM，服务的 DNS 记录需要指向 UCP 集群。由于 swarm mode 网格路由提供了灵活性，可通过多种不同的方式配置服务的 DNS 记录。

如果服务需要可以被公开访问才可将请求发送到 foo.example.com，那么可以通过以下任何一种方式配置服务的 DNS 记录：

将 DNS 配置为指向 UCP 集群上的任何一个节点。对于 foo.example.com 的所有请求都将通过该节点路由到 HRM。
配置轮询 DNS 来指向 UCP 集群上的多个节点。任何收到对于 foo.example.com 的请求的节点都将通过 HRM 被路由。
最佳解决方案（为实现高可用性）是在 UCP 集群的前端配置外部 HA 负载均衡器。使用外部 HA 负载均衡器时需要牢记以下注意事项：
- 将 foo.example.com 的 DNS 记录设置为指向外部负载均衡器。
- 外部负载均衡器应指向驻留在不同的可用性区域中的多个 UCP 节点，以增强可恢复性。
- 配置外部负载均衡器来对 HRM 服务的已配置的已发布端口执行 TCP 运行状况检查，以便通过运行状况良好的 UCP 节点路由流量。

应该使用哪些节点来路由流量？管理节点还是工作节点？针对此问题的回答有好几种。

1.对于规模较小的部署，可通过管理节点来路由流量，因为管理节点通常为静态性质。

优势：它们通常不会（在新主机、新 IP 等之间）经常变动，所以易于使负载均衡器指向相同的节点。
缺点：它们负责路由控制平面流量。如果应用流量较多，采用这种方法可能会使这些节点上的流量饱和，从而给集群带来不利影响。

2.通过工作节点路由流量

优势：它们不管理整个集群，因此额外网络开销较少。
缺点：它们属于“cattle”节点。如果负载均衡器指向工作节点，围绕销毁和构建节点构建自动化时需要考虑这一点。

无论前端负载均衡器将流量指向哪种类型的实例，都需要确保实例具有足够的网络连接。