本人作為京東云擎(JAE)的架構師，在從事云平臺特別是PASS平臺的架構、開發多年，有一些體會以及一些解決方案。下面，我想對開源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集群化方案進行服務提供給京東云擎的用戶使用，讓用戶也能夠通過消息中間件開發分布式的應用。

最后，自己也不忘給京東云擎打個小廣告：免費得應用托管平臺，穩定、可靠，服務態度好，歡迎訪問云擎官網：http://jae.jd.com。