最佳实践系列丨Docker EE 服务发现参考架构(二)-阿里云开发者社区

开发者社区> docker公司> 正文

最佳实践系列丨Docker EE 服务发现参考架构(二)

简介: swarm mode 网格路由非常适合传输层路由。它使用服务的已发布端口路由到服务。但是,如果希望基于主机名将流量路由到服务应该怎么办?
+关注继续查看

screenshot

出品丨Docker公司(ID:docker-cn)
编译丨小东
每周一、三、五晚6点10分 与您不见不散


服务发现对服务进行注册并发布其连接信息,以使其他服务了解如何连接到服务。随着应用向微服务和面向服务的架构转变,服务发现已经成为所有分布式系统的必要组成部分,增加了这些环境的运维复杂性。点击以下标题,回顾第一部分内容:


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 共同使用时的工作原理的高级视图。

screenshot

  • 流量从外部负载均衡器流入 swarm mode 网格路由;
  • HRM 服务配置为侦听端口 80 和 8443,因此任何对 UCP 集群的端口 80 或 8443 的请求都会流向 HRM 服务;
  • 所有连接到经启用可实现“基于主机名的路由”的网络的服务都可使用 HRM 来基于 HTTP Host: 标头路由流量;

仔细看,您就会了解 HRM 的工作过程。下图对上一图表中表示的工作原理进行了更详细的说明。

screenshot

  • 流量经由入口网络上的 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 的示例:

screenshot


启用 HRM

可从 UCP Web 控制台启用 HTTP 网格路由。要启用它:

  1. 登录 UCP Web 控制台。
  2. 浏览至管理员设置 > 网格路由。
  3. 选中启用 HTTP 网格路由。
  4. 配置 HRM 要侦听的端口,默认值为 80 和 8443。HTTPS 端口默认为 8443,这样它就不会和默认 UCP 管理端口 (443) 互相干扰。

screenshot

启用后,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 达到相同的目的,方法是在创建网络时选择启用基于主机名的路由。

screenshot


HRM 要求

要使用 HRM,服务需要满足三个要求。

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

针对 HRM 配置DNS

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

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

  1. 将 DNS 配置为指向 UCP 集群上的任何一个节点。对于 foo.example.com 的所有请求都将通过该节点路由到 HRM。
  2. 配置轮询 DNS 来指向 UCP 集群上的多个节点。任何收到对于 foo.example.com 的请求的节点都将通过 HRM 被路由。
  3. 最佳解决方案(为实现高可用性)是在 UCP 集群的前端配置外部 HA 负载均衡器。使用外部 HA 负载均衡器时需要牢记以下注意事项:

    • 将 foo.example.com 的 DNS 记录设置为指向外部负载均衡器。
    • 外部负载均衡器应指向驻留在不同的可用性区域中的多个 UCP 节点,以增强可恢复性。
    • 配置外部负载均衡器来对 HRM 服务的已配置的已发布端口执行 TCP 运行状况检查,以便通过运行状况良好的 UCP 节点路由流量。

screenshot

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

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

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

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

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

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Cassandra最佳实践(3)配置篇
cassandra最佳实践之cassandra的配置
2032 0
使用Docker构建服务
使用Docker构建服务
1196 0
Cassandra 最佳实践系列(1) - CQL QuickStart
Cassandra最佳实践之简单搭建以及使用cql
1554 0
【微服务从入门到精通】:(二)构建微服务到Docker镜像
如果单纯得做微服务开发,虽然也可以通过传统得脚本,或者Jinkens工具以脚本的方式进行CI/CD发布,但是相对于Docker镜像来讲,还不是最方便的,所以如果要做CI/CD,最好还是使用Docker镜像来发布。
1257 0
docker服务发现——最终测试
最终测试 首先启动confd,按照前面的命令,去掉onetime参数,放到后台最为守护进程长期运行,确保etcd注册目录修改之后,能准实时生成haproxy的配置文件。 然后在两台slave,一台启动两个nginx容器,一台启动一台,模拟上面的a.abc.com和b.abc.com两个域名。
1723 0
《Greenplum5.0 最佳实践》 系统参数 (二)
主要目的是帮助开发者更好的去理解系统参数配置信息,以及配置信息起到的具体作用
2822 0
docker服务发现——confd
confd confd通过读取配置(支持etcd,consul,环境变量),通过go的模板,生成最终的配置文件。 安装 安装和etcd一样,非常方便,已经提供了64位的可执行程序,下载下来之后直接放到PATH中(/usr/local/bin)即可(别忘了+x)。 haproxy配置生成 c
8239 0
Flink 与 TiDB 联合发布实时数仓最佳实践白皮书
点击链接,动动手指获取白皮书~另外,实时数仓 Meetup 议题征集中!
1133 0
Cassandra 最佳实践系列(2) - 选型篇
Cassandra最佳实践之选型,选择什么样子的机器
1352 0
Cassandra 最佳实践系列(4) - 管理篇之一
Cassandra之系统管理命令介绍之第一部分
1619 0
+关注
130
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载