CloudFoundry架构优化：NATS集群化方案

编者按：NATS是由Cloud Foundry开发的一个基于事件驱动的、轻量级的消息系统。它基于EventMachine实现，第一版本CloudFoundry被人诟病的一个问题就是NATS服务器是单节点的，让人不大放心。集群版本则被反映不够稳定，都没有在生产环境使用。本文作者为京东云擎（JAE）的架构师强娃，从事云平台特别是PaaS平台的架构、开发多年。作者对开源PaaS框架CloudFoundry进行了优化，解决了NATS单节点问题，大大减小了NATS单节点的风险问题。目前京东云擎就是基于这种方案来实现的，避免了单个NATS节点挂掉导致整个云擎无法运行的情况。以下为原文：

概述

是基于CloudFoundry（后文统一使用CF作为简称）开源系统进行二次开发的，我们利用CF开源系统的基本框架，然后整合了京东自己的各个云服务产品，并且根据需求开发了智能路由、弹性伸缩、智能启动和资源隔离等扩展功能。

CF开源系统作为一个通用的PaaS平台解决方案，很好的满足了大部分基本需求，但是要打造一个高可靠的PaaS平台，还需要做很多架构容错和改进。

CF由很多组件构成，有一些核心组件是必不可少的，还有很多可选组件可以根据需求选择性使用。其中NATS、Router和Cloudontroller三个组件更是整个CF的最关键的组件，其中任何一个组件不可用都会导致整个PaaS平台不可用，所以这三个组件的容错显得更加重要。 Router的容错可以VIP实现，Cloudontroller本身通过Router的软域名映射进行容错。NATS作为整个CF各个组件的连接枢纽，一旦不可用所有CF组件都出问题，所以NATS的重要性不言而喻，但是目前业界普遍使用单实例。虽然NATS的稳定性不容置疑，但是不能解决由于网络、服务器硬件故障和操作系统故障导致的不可用，特别是由于服务器不可用导致的故障，恢复成本很高，时间也是很长的。开源的NATS组件也有集群版本，但是普遍反映不够稳定，都没有在生产环境使用。本人表达一下对NATS升级改造的一点看法。

NATS集群化方案设计

为了提高京东云擎的可靠性，京东云擎团队基于GO语言版本的NATS设计并实现了NATS的集群化方案，这个方案在预发布环境运行了一个月，现在也正式上线，表现都非常稳定。下面就对我们的NATS集群化方案和实现进行阐述。

首先看看NATS集群化方案的架构图，如下：

通过上面的架构图可以知道，NATS服务器各个节点采用了zookeeper进行心跳存活的管理，这样可以保证所有NATS客户端获取到的NATS服务器节点都是存活的；NATS服务器各个节点直接也会相互通信，主要是保证订阅信息的同步。

这个NATS集群化方案有如下优点：

1. 方便的横向扩展，随时上线下线NATS服务器节点；
2. 通过zookeeper管理NATS服务器节点的存活，保证了客户端得到的NATS服务器实例都是可用的；
3. 通过最多两次的消息转发，极大的提高了消息转发的性能。

NATS集群化方案实现

NATS集群化实现的难点主要在于怎样保证消息的订阅与发布能够在各个NATS节点之间进行同步。下面分别从NATS服务器节点启动、订阅消息、发布消息和NATS客户端改进等方面说明NATS集群化方案的实现。

1. NATS服务器节点启动

为了保证各个NATS服务器节点订阅信息的同步，启动一个NATS服务器节点的时候需要判断是否已存在其他NATS服务器节点，如果存在那么需要连接其他NATS服务器节点进行订阅消息的同步。NATS服务器节点的各个功能或者服务初始化完毕以后将自己的地址以临时节点的方式注册到zookeeper集群中，这样就可以开始对外提供服务了。

2. 消息订阅

集群化版本的NATS对于NATS客户端发布订阅消息是透明的，即不管NATS客户端选择的哪一个NATS服务器节点都只需要向这一台进行消息订阅与发布。

NATS服务器节点收到订阅消息以后，首先加入自己的消息订阅队列，然后广播到其他NATS服务器节点，在广播的时候做了一点点优化，就是看这个主题的消息订阅是否已经被广播过了，那么就不需要重复广播，防止订阅信息过多，并且这些都是不需要的垃圾订阅消息。

最后如果某一个客户端取消订阅消息，同样需要广播取消订阅消息。

3. 消息发布

NATS服务器节点接收到NATS客户端发布的消息以后，还是首先根据消息订阅列表进行转发，和单机NATS不同的是，这次转发可能会转发到其他NATS服务器节点，只要其他NATS服务器节点也有同样的消息主题订阅，那么这种情况就存在一次中间转发的过程，但是也最多只存在一次中间转发过程，所以性能基本上不受什么影响。

4. NATS客户端改进

NATS客户端的改进主要是支持从zookeeper集群上获取NATS服务器的节点地址，并且能够兼容以前老的直接配置某一个NATS服务器节点地址。当客户端第一次连接NATS服务器节点时，需要从zookeeper集群获取所有可用的NATS服务器节点地址并且缓存到本地，然后随机选择一个NATS服务器节点建立连接并且进行消息订阅与发布。缓存所有NATS服务器节点地址主要是防止zookeeper不可用的时候并且NATS服务器节点有挂掉的情况不影响客户端切换NATS服务器节点，在切换的时候需要把NATS客户端以前订阅的消息全部重新订阅一次。

其他改进

本次针对NATS单点问题进行整个京东云擎的架构升级，完成升级以后整体运行很稳定。不过除了NATS集群化，本次架构升级还做了其他很多改进，本次架构升级主要目的是让京东云擎具有高可靠。下面在简单介绍本次架构升级其他方面的改进：

1. 使用分布式文件系统替换原来的单磁盘存放droplet，解决了由于用户猛增导致droplet存储空间受限的问题；
2. 用户控制台界面dashboard的改变；
3. Router对后端多实例包括CloudController的容错；
4. 独立域名绑定支持；
5. 应用打包部署流程优化；
6. 同组件的不同实例分别部署到不同物理机的云主机上；
7. 其他组件功能优化。

总结

云擎是京东给个人开发者、微小中型企业提供的一站式应用免费托管平台，所以保证云擎高可靠性就是保证所有个人开发者和微小中型的应用的可靠性。

通过对核心CF的组件进行多实例或者集群化容错处理来保证和提供云擎的可靠性，尤其在对消息中间件这个核心组件，云擎团队设计和实现了自己的集群化方案，保证了消息通信的可靠性，并且通过GO语言进行开发扩展了单机NATS的消息通信的性能。我们设计的NATS集群化方案具有方便横向扩展的能力，由此京东云擎团队解决了消息中间通信的瓶颈。

云擎团队后面考虑对NATS集群化方案进行服务提供给京东云擎的用户使用，让用户也能够通过消息中间件开发分布式的应用。