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

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
EMR Serverless StarRocks,5000CU*H 48000GB*H
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 服务发现对服务进行注册并发布其连接信息,以使其他服务了解如何连接到服务。随着应用向微服务和面向服务的架构转变,服务发现已经成为所有分布式系统的必要组成部分,增加了这些环境的运维复杂性。

screenshot

本文首发自“Docker公司”公众号(ID:docker-cn)
编译丨小东
每周一、三、五 与您不见不散!


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

Docker 企业版 (Docker EE) 包含服务发现和负载均衡功能,可为整个组织的开发运维计划提供助力。服务发现和负载均衡可以方便开发人员创建可动态互相发现的应用。另外,这些功能还简化了运维工程师扩展应用的过程。

Docker 使用称作服务的概念来部署应用。服务由基于相同的镜像创建的容器组成。每个服务都由在工作节点上执行并且会定义应用的状态的任务组成。部署服务时,服务定义在创建服务时完成。服务定义包含很多信息,其中包括,服务包含的容器、发布的端口、连接的网络和从节点的数量。所有这些任务共同组成服务的理想状态。如果某个节点未通过运行状况检查或服务定义中某个特定的服务任务未通过运行状况检查,那么集群将调整服务状态,使其与另一个运行状况良好的节点的服务状态一致。Docker EE 包含服务发现、负载均衡、扩展和调整事件,以使该编排可以无缝工作。


学习内容

此参考架构涵盖 Docker EE 提供的服务发现和负载均衡领域的解决方案。创建服务时,Docker 使用 DNS 实现服务发现,而且 Docker 内置了不同的网格路由,可确保应用高度可用。UCP 2.0 发行版引入了新的应用层网格路由,称为 HTTP 网格路由 (HRM),它基于 DNS 主机名路由 HTTP 流量。阅读完本文档之后,您将充分了解 HRM 的工作原理以及它如何与其他 Docker 服务发现和负载均衡功能集成。


使用 DNS 的服务发现

Docker 使用嵌入的 DNS 来为在单个 Docker 引擎上运行的容器和在 Docker Swarm 中运行的任务提供服务发现功能。Docker 引擎具备内部 DNS 服务器,可为用户定义的 bridge、overlay 和 MACVLAN 网络中的主机上的所有容器提供名称解析。每个 Docker 容器(或任务(swarm mode 中))都具备一个可将 DNS 查询转发到 Docker 引擎的 DNS 解析器,它充当 DNS 服务器。然后,Docker 引擎将在发送请求的容器所属的每个网络上检查 DNS 查询是否属于容器或服务。如果属于,Docker 引擎将在其键值存储中查找与容器、任务、或服务的名称匹配的 IP 地址,并将 IP 或服务虚拟 IP (VIP) 返回给请求方。

服务发现将网络作为范围,这意味着只有在相同网络上的容器或任务才可使用嵌入的 DNS 功能。不在相同网络上的容器无法解析彼此的地址。而且,只有在特定网络上具备容器或任务的节点才会存储该网络的 DNS 条目。这有助于提高安全性和性能。

如果目标容器或服务和源容器位于不同的网络上,Docker 引擎会将 DNS 查询转发到默认 DNS 服务器。

screenshot

本示例中,有一个具有两个容器的服务,称为 myservice。在相同的网络上还存在第二个服务 (client)。client 运行两个 curl 操作(为 docker.com 和 myservice)。以下为因此发生的操作:

  • client 为 docker.com 和 myservice发起 DNS 查询;
  • 容器的内置解析器在 127.0.0.11:53 上拦截 DNS 查询,并将其发送到 Docker 引擎的 DNS 服务器;
  • myservice 解析到服务的虚拟 IP (VIP),并在内部均衡分配到各个任务 IP 地址。容器名也将被解析,只不过是直接解析到其 IP 地址;
  • docker.com 没有作为服务名称存在于 mynet 网络中,所以请求被转发给已配置的默认 DNS 服务器;

内部负载均衡

当在 Docker Swarm 集群中创建服务时,将自动向其分配虚拟 IP (VIP),它是服务的网络的一部分。解析服务的名称时将返回 VIP。流向 VIP 的流量将被自动发送到整个 overlay 网络上该服务的所有运行状况良好的任务。此方法可避免由于在客户端进行任何负载均衡,因为仅有一个 IP 返回到客户端。Docker 会处理所有路由并将流量平均分发给运行状况良好的服务任务。

screenshot

要获取服务的 VIP,请按以下方式运行 docker service inspect myservice 命令:

# Create an overlay network called mynet

$ docker network create -d overlay mynet

a59umzkdj2r0ua7x8jxd84dhr

# Create myservice with 2 replicas as part of that network

$ docker service create --network mynet --name myservice --replicas 2 busybox ping localhost

8t5r8cr0f0h6k2c3k7ih4l6f5

# Get the VIP that was created for that service

$ docker service inspect myservice

...

“VirtualIPs":[
               {
                   "NetworkID":"a59umzkdj2r0ua7x8jxd84dhr",

                   "Addr":“10.0.0.3/24"
               },
]

DNS 轮询 (DNS RR) 负载均衡是适用于服务(使用 --endpoint-mode配置)的另外一个负载均衡选项。在 DNS RR 模式下,不为每个服务单独创建 VIP。Docker DNS 服务器通过轮询方式将服务名称解析到各个容器 IP。


外部负载均衡(Swarm Mode 网格路由)

创建或更新服务时,您可以使用 --publish 标志在外部公开服务。在 Docker swarm mode 下公开端口意味着集群中的每个节点都将侦听端口。但是,如果服务的任务不在侦听该端口的节点上应该怎么办呢?

在这种情况下需要使用网格路由。网格路由是 Docker 引擎 1.12 中的一项新功能,它将 ipvs 和 iptables 相结合以创建功能强大的全集群传输层 (L4) 负载均衡器。它允许所有 swarm 节点接受服务发布的端口上的连接。任何 swarm 节点收到发往运行中服务的已发布 TCP/UDP 端口的流量时,它会使用称为入口的预定义 overlay 网络将流量转发到服务的 VIP。入口网络的行为方式与其他 overlay 网络相似,但是其唯一的目标是将网格路由流量从外部客户端传输给集群服务。它使用与前一部分中所述相同的基于 VIP 的内部负载均衡功能。

启动服务后,您就可以为应用创建外部 DNS 记录,并将其映射到任何或所有 Docker swarm 节点。您无需担心容器在哪里运行,因为有了网格路由路由功能,集群中的所有节点就像一个整体。

#Create a service with two replicas and export port 8000 on the cluster

$ docker service create --name app --replicas 2 --network appnet --publish 8000:80 nginx

screenshot

该图表对网格路由的工作原理进行了说明。

  • 创建带有两个从节点的服务,并将其端口映射到外部端口 8000;
  • 网格路由在集群中的每个主机上公开端口 8000;
  • 发往应用的流量可从任何主机进入。在这种情况下,外部 LB 无需通过服务从节点就可将流量发送到主机;
  • 内核的 IPVS 负载均衡器将入口 overlay 网络上的流量重定向到运行状况良好的服务从节点;
相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
8天前
|
Kubernetes 监控 开发者
掌握容器化:Docker与Kubernetes的最佳实践
【10月更文挑战第26天】本文深入探讨了Docker和Kubernetes的最佳实践,涵盖Dockerfile优化、数据卷管理、网络配置、Pod设计、服务发现与负载均衡、声明式更新等内容。同时介绍了容器化现有应用、自动化部署、监控与日志等开发技巧,以及Docker Compose和Helm等实用工具。旨在帮助开发者提高开发效率和系统稳定性,构建现代、高效、可扩展的应用。
|
6天前
|
JavaScript 持续交付 Docker
解锁新技能:Docker容器化部署在微服务架构中的应用
【10月更文挑战第29天】在数字化转型中,微服务架构因灵活性和可扩展性成为企业首选。Docker容器化技术为微服务的部署和管理带来革命性变化。本文探讨Docker在微服务架构中的应用,包括隔离性、可移植性、扩展性、版本控制等方面,并提供代码示例。
33 1
|
13天前
|
Kubernetes 负载均衡 Docker
构建高效微服务架构:Docker与Kubernetes的完美搭档
【10月更文挑战第22天】随着云计算和容器技术的快速发展,微服务架构逐渐成为现代企业级应用的首选架构。微服务架构将一个大型应用程序拆分为多个小型、独立的服务,每个服务负责完成一个特定的功能。这种架构具有灵活性、可扩展性和易于维护的特点。在构建微服务架构时,Docker和Kubernetes是两个不可或缺的工具,它们可以完美搭档,为微服务架构提供高效的支持。本文将从三个方面探讨Docker和Kubernetes在构建高效微服务架构中的应用:一是Docker和Kubernetes的基本概念;二是它们在微服务架构中的作用;三是通过实例讲解如何使用Docker和Kubernetes构建微服务架构。
51 6
|
12天前
|
负载均衡 应用服务中间件 nginx
基于Nginx和Consul构建自动发现的Docker服务架构——非常之详细
通过使用Nginx和Consul构建自动发现的Docker服务架构,可以显著提高服务的可用性、扩展性和管理效率。Consul实现了服务的自动注册与发现,而Nginx则通过动态配置实现了高效的反向代理与负载均衡。这种架构非常适合需要高可用性和弹性扩展的分布式系统。
19 4
|
14天前
|
监控 Cloud Native 持续交付
云原生架构下微服务的最佳实践与挑战####
【10月更文挑战第20天】 本文深入探讨了云原生架构在现代软件开发中的应用,特别是针对微服务设计模式的最优实践与面临的主要挑战。通过分析容器化、持续集成/持续部署(CI/CD)、服务网格等关键技术,阐述了如何高效构建、部署及运维微服务系统。同时,文章也指出了在云原生转型过程中常见的难题,如服务间的复杂通信、安全性问题以及监控与可观测性的实现,为开发者和企业提供了宝贵的策略指导和解决方案建议。 ####
41 5
|
11天前
|
存储 监控 Linux
Docker技术架构概述
【10月更文挑战第22天】Docker采用CS架构,Client与Daemon交互,Compose管理多容器应用。
|
13天前
|
Kubernetes Cloud Native 持续交付
云原生架构下的微服务设计原则与最佳实践##
在数字化转型的浪潮中,云原生技术以其高效、灵活和可扩展的特性成为企业IT架构转型的首选。本文深入探讨了云原生架构的核心理念,聚焦于微服务设计的关键原则与实施策略,旨在为开发者提供一套系统性的方法论,以应对复杂多变的业务需求和技术挑战。通过分析真实案例,揭示了如何有效利用容器化、持续集成/持续部署(CI/CD)、服务网格等关键技术,构建高性能、易维护的云原生应用。文章还强调了文化与组织变革在云原生转型过程中的重要性,为企业顺利过渡到云原生时代提供了宝贵的见解。 ##
|
13天前
|
负载均衡 应用服务中间件 nginx
基于Nginx和Consul构建自动发现的Docker服务架构——非常之详细
通过使用Nginx和Consul构建自动发现的Docker服务架构,可以显著提高服务的可用性、扩展性和管理效率。Consul实现了服务的自动注册与发现,而Nginx则通过动态配置实现了高效的反向代理与负载均衡。这种架构非常适合需要高可用性和弹性扩展的分布式系统。
29 3
|
12天前
|
监控 安全 Serverless
"揭秘D2终端大会热点技术:Serverless架构最佳实践全解析,让你的开发效率翻倍,迈向技术新高峰!"
【10月更文挑战第23天】D2终端大会汇聚了众多前沿技术,其中Serverless架构备受瞩目。它让开发者无需关注服务器管理,专注于业务逻辑,提高开发效率。本文介绍了选择合适平台、设计合理函数架构、优化性能及安全监控的最佳实践,助力开发者充分挖掘Serverless潜力,推动技术发展。
29 1
|
4天前
|
关系型数据库 MySQL API