【译】Consul负载均衡策略

Consul是一个免费的开源工具, 它提供服务发现、健康检查、负载均衡和全局分布的键值存储。此外, 它还提供了一组用于构建业务流程工作流和 工具 的基础元素。在微服务体系结构中, 应用程序通常跨越多个IP地址运行, 并绑定到各种端口。服务发现有助于查找这些不同的服务, 而不管它们位于何处。

由于同一个服务的多个实例通常同时运行在微服务体系结构中, 因此在实例健康变化时，实例数量变化时，以及集群状态变化时，我们需要一种策略去平等地均衡所有到健康实例的流量。这就是负载均衡层的工作。本文讨论了在微服务体系结构中与Consul进行负载均衡的几种常用策略。

直接使用Consul

对Consul进行负载均衡的一种方法是使用Consul的内置负载均衡功能。Consul将健康检查与服务发现结合在一起。这意味着不健康的主机永远不会通过查询返回到服务发现层。在这种模式下, 每次应用程序和服务希望在数据中心查找其他服务时，他们直接与Consul进行对话。

请考虑以下配置文件, 其中包括某个后端服务的IP地址:

services: 
  backend: 10.2.5.391
复制代码

通常情况下，对于IP地址进行硬编码(尤其是在微服务体系结构中)，被认为是一种不好的做法。随着应用程序在整个系统中运行, 将此配置文件保持为最新, 尤其是在计算机集群上，变得非常困难。相反, 更好的方法是利用Consul的DNS发现层。

services: 
  backend: backend.service.consul
复制代码

就像"www.hashicorp.com"是一个web地址, "backend.service.consul"也是。这里，TLD 或域后缀（domain suffix）是可配置的, 但默认值为 .Consul 。任何以该TLD结尾的请求都将被解析到Consul。这里 .service 命名空间告诉Consul查找服务 (而不是机器的节点)， . backend 是要查找的服务的名称。对 "backend.service.consul"的请求被解析到一组IP地址, 就像"www.hashicorp.com"被解析为一组IP地址一样。然而, 对于Consul, 该解析发生在服务发现层，并集成了健康检查机制。

每次应用程序或内核解析该DNS条目时, 它都会收到一个与集群中的健康服务对应的 IP 地址列表的随机循环（round-robin）响应。DNS接口基本上提供了零配置（zero-touch）服务发现，并能集成到任何应用程序中。

优点：

• 不依赖外部工具或流程
• 没有其他服务用于监视或维护
• 默认情况下高度可用
• 尽可能接近实时
• DNS易于使用, 工作量极小
• 健康检查是分布式的, 集群负载极小

缺点：

• 单点故障-即使Consul在默认情况下是高度可用的, 但如果Consul不可用或无法访问, 此模式不提供故障转移
• 要求在应用程序中直接使用HTTP API, 或进行 DNS 查询, 假定端口或进行两个 DNS 查询以查找地址和端口
• 应用与Consul强耦合

Fabio

Fabio 是一个开源工具, 它为Consul管理的服务提供快速、现代、零配置的负载均衡HTTP(s)和TCP路由器。用户在Consul注册服务，并提供健康检查，Fabio将自动把流量路由到他们。不需要额外配置。

用户注册一项服务, 采用以 urlprefix- 开头的tag, 如:

urlprefix-/my-service
复制代码

在本示例中, 当在/my-service上，对Fabio发出请求时, Fabio将自动将流量路由到集群中的健康服务上。Fabio还支持更高级的 路由配置 。

优点：

• 与Consul丰富集成
• 比DNS方法更多控制负载均衡
• 强大的社区支持和超过4000的GitHub star
• 支持TCP代理
• 访问日志记录和一系列其他令人称赞的 功能
• 集成HashiCorp Vault
• 用于路由可视化的可选Web UI
• 非常详细的开源文档

缺点：

• 需要额外的服务才能运行和监视
• 与Consul和Consul tag紧密耦合

Nginx/HAProxy with Consul Template

对Consul进行负载均衡的另一种方法是使用第三方工具 （如Nginx 或HAProxy） 来平衡流量，并使用开源工具 （如 Consul Template ） 来管理配置。在这种模式下, Consul Template动态管理 nginx.conf 或 haproxy.conf配置文件, 它定义负载均衡器和服务列表。此列表是模板化的, Consul Template作为服务运行以保持模板为最新。 Consul Template与Consul群集有持续的连接, 当服务池发生更改时, Consul Template会写入一个新的配置文件, 并发出信号让Nginx或HAProxy进程重新加载其配置。这里是一个示例的Nginx的Consul Template模板:

upstream myapp {
{{ range service "myapp" }}
  server {{ .Address }}:{{ .Port }}
{{ end }}
}
复制代码

在此示例中, Consul Template将监视所有名为 "myapp" 的服务。如果它们的任何状态发生更改, Consul Template将产生一个新的配置文件, 并指示 Nginx 进程重新加载。上面的模板在nginx.conf中呈现为这样:

upstream myapp {
  server 10.2.5.60:13845
  server 10.6.96.234:45033
  server 10.10.20.123:18677
}
复制代码

必须指出, 在这种模式下, Nginx 和 HAProxy 都不知道Consul的存在;它们只是读取它们的配置, 就好像这些值是由操作员或配置管理工具硬编码的一样。

优点：

• 处理在非默认端口上运行的应用程序, 而无需额外的API 请求
• Nginx 和 HAProxy 都是经过线上考验的工具
• 团队可能已经拥有这些工具的专业知识或现有的基础设施
• 如果Consul离线, 仍然有最后已知良好的服务状态的一个记录
• Consul template也可与Vault集成, 如果配置文件具有像TLS 私钥或共享密码等机密数据时，这使得它一个理想的解决方案,。

缺点：

• 需要两个额外的服务来管理和监视-Nginx/HAProxy 和Consul Template
• 由于阻塞查询, 低效模板可能给Consul群集造成巨大压力
• 对实践 "一个容器一个服务" 范式的挑战
• 一个 "飞行猪" 群集 （服务在健康和不健康之间翻转的群集或具有大量连续快速流失的群集） 可能导致 Nginx/HAproxy 配置不稳定

Nginx with Custom Module

最近, 我开始尝试移除Consul Template, 但保持经过时间考验的灵活性和熟悉度的Nginx。社会上有一些非常有趣和创新的做法, 即:

• Dynamic Nginx Upstreams for Consul via lua-nginx-module by Zachary Schneider
• Nginx upsync module
• Nginx Pro DNS resolution
• ngx_http_set_backend which inspired binding Nginx modules in C to Consul in Golang

最终, 这些方法要么涉及太多的移动部件, 要么包括Consul的基本服务发现之外的扩展功能。因此, 我写的 ngx_http_consul_backend_module , 对于每个导向nginx的请求，动态选择upstream。

它看起来这样:

http {
  server {
    listen       80;
    server_name  example.com;

    location /my-service {
      consul $backend service-name;
      proxy_pass http://$backend;
    }
  }
}
复制代码

对于每个请求, consul关键字告诉 Nginx 委托给自定义模块并选择一个随机的健康后端服务, 然后将请求代理到该后端服务。肯定有改进的地方, 但是这个概念验证表明, 没有中介工具，也 可能直接连接 Nginx 和Consul。

优点：

• 处理非默认端口上运行的应用程序, 而无需额外的 API 请求
• 没有外部工具-只是运行 Nginx 并直接指向Consul
• 使用正式Consul SDK客户端库提供的HTTP/2、stale queries等等

缺点：

• 需要从源代码编译 Nginx 以安装自定义模块
• 每个到后端的请求，调用Consul（每个请求需要消耗请求的RTT和Consul解析的RTT）
• 需要 Nginx 定制模块的知识来完成任务
• 对于TLS私钥或共享密码，不能与Vault集成
• 模块经过线上严苛测试 （尚未）

HAProxy 1.8

HAProxy 1.8 （当前在撰写本篇文章时发布的候选版本） 在不使用第三方工具或模块的情况下, 通过 DNS 添加了服务发现的内置功能。HAProxy 已经内置 DNS 解决方案有一段时间了, 但 HAProxy 1.8 通过 SRV 记录和支持 EDNS 为端口带来了解决方案 , 使其与Consul完美配对。

优点：

• 没有外部工具-只是运行HAProxy，并直接指向Consul
• 优雅的处理重新加载, TTLs 等。
• 也支持 Kubernetes 和Docker Swarm服务发现

缺点：

• 需要 HAProxy
• 相较于Consul Template，对于失败场景，更少的灵活性

结论

对于采用Consul的应用，有许多负载均衡的策略和技术。这篇文章详细介绍了一些最常见的技术, 并希望激发灵感, 以新的，振奋人心的方式集成行业标准的负载均衡工具和Consul。无论您是直接使用Consul, 弥合与Consul模板的差距, 编译自己的Nginx定制版本, 或尝试HAProxy 1.8候选发布版本, 我们期待听到您如何负载均衡您的微服务应用。

原文链接： www.hashicorp.com/blog/load-b…