DockerCon 2016 深度解读: Citrix 服务发现解决方案 —— Nitrox

说起Citrix公司的NetScaler这款硬件负载均衡器大家可能不熟悉，它的竞争对手F5，在运维界可能比较多人了解。硬件负载均衡器通常作为网络入口流量分流的设备，例如像淘宝网的流量特别大，可能只有几个入口IP，在淘宝网的流量的最前端就会部署像F5或者NetScaler这样的硬件负载均衡器作为分流。

随着云计算越来越深入人心，像Citrix这种硬件设备商越来越卖不动了，因为绝大部分中小企业都直接跟云计算公司采购所需的虚拟设备，这样的设备可定制，可按需动态分配。Citrix也是积极跟云计算公司，例如AWS合作，推广自己的虚拟版本的NetScaler。

容器化大潮和微服务概念的推广下，系统被拆分成了一个个只有单一职责的微服务，服务的扩容通过增加容器的数量来解决，服务之间的调用关系越来越复杂，像一张密密麻麻的网。当一个服务启动，扩容或者缩容之后，需要迅速被依赖它的服务感知到，即发现，所以发现的过程必须是自动的，且现有大部分的C/S模式的代码都没有提供client服务发现的能力，因此服务发现最好是对client来说是透明的。通过负载均衡器配合server端实现服务发现管理的功能正是基于容器的微服务架构特别需要的方案。由上述可见，通过负载均衡器的方式来解决服务发现的问题是微服务架构中一个特别重要的问题，而且该问题目前没有特别好的解决方案。Citrix推出的Nitrox正是试图解决这个问题。总结下Citrix推出Nitrox的原因：

• 通过提供NetScaler CPX负载均衡软件进军容器市场
• 解决容器架构中容器与容器之间服务发现的问题
• Nitrox中使用的NetScaler CPX与硬件负载均衡设备的API接口保持一致，方便其现有用户从其他架构迁移到容器架构

我们先来看看Nitrox的重要部分，即NetScaler CPX负载均衡软件，该软件是一款收费的软件。
NetScaler的部署模式如下图所示：

1. 通过硬件设备NetScaler MPX来解决网络进入容器集群的入口流量的负载均衡，就是图中所说的南北的流量（N-S traffic）。
2. 通过软件设备NetScaler CPX来解决容器集群内，不通服务之间通信负载均衡的问题，就是图中所说的东西的流量（W-E traffic）。
3. 通过与编排系统配合（Mesos/Kubernetes/Swarm）来解决自动化服务发现，动态变更负载均衡配置的问题，图右侧底层的支持平台。
4. Citrix的软负载设备和硬负载设备是统一的api接口Nitro，保证了迁移的平滑和接口的一致性，对于Citrix已有的硬件负载设备用户来说，架构的迁移很简单。

接下来看看Citrix推出的整体的容器集群的服务发现解决方案Nitrox。Citrix开源了该解决方案，地址是Nitrox，该方案同时支持基于Mesos/Kubernetes/Swarm等多个编排系统的服务发现。其基本原理，如下图所示：

Nitrox作为一个容器，跑在容器集群内，同时有侦听编排系统(Mesos/Kubernetes/Swarm)事件，以及读取编排系统信息的能力，当各主机上的容器状态发生变化时，变化上报到编排系统(Mesos/Kubernetes/Swarm)，编排系统再把事件通知到各个侦听的客户端。Nitrox作为客户端接收到事件后，重新获取当前容器集群中各个容器的状态。根据最新的集群状态来更新各个容器的路由。除了初始化基本的配置，上面说的负载均衡动态配置，都是通过脚本自动完成的，最终做到了服务的自动发现。

现在我们来总结下Docker容器架构通过动态负载均衡来实现服务发现的方法

• 在容器里面实现负载均衡通常采用以下思路

  • 负载均衡设备

    • 4层包括IPVS，各大云计算厂商的负载均衡设备，例如aliyun的SLB， AWS的ELB等，以及本文中提到的F5，NetScaler
    • 既包含4层又包含7层的负载均衡软件，目前最流行的包括Haproxy，Nginx（以及衍生出来的国内的Tengine)
    • 通过DNS来做负载均衡，问题比较多，例如DNS有本地缓存，容易导致数据不一致，且对某些client端有要求，某些client端不会每次请求都去DNS拿最新的路由信息，因此一般很少将DNS作为负载均衡的方案。
• 获取负载均衡信息的API（从swarm，kubernetes，mesos获取）或者注册中心获取，即registry，包括 Zookeeper，etcd，Consul等
• 通过脚本监听registry或者编排系统的事件，某些事件如果导致负载均衡发生变化，便将最新的负载均衡信息更新到负载均衡设备中

最后，从几个角度来对比类似负载均衡实现的差异。

预测最终Docker官方会逐步推出自己的服务发现完整方案，我们在Docker 1.12中应该能看到该方面的迹象，其他公司在解决服务发现方面的提供的产品会是一个很重要的补充。