本人作為京東云擎(JAE)的架構師，在從事云平臺特別是PASS平臺的架構、開發(fā)多年，有一些體會以及一些解決方案。下面，我想對開源PaaS框架CloudFoundry的一個NATS單節(jié)點的問題發(fā)表一下個人看法。目前京東云擎也是基于這種方案來實現，大大減小了NATS 單節(jié)點的風險問題，避免了單個NATS節(jié)點掛掉而導致整個云擎無法運行的情況發(fā)生，從而提高云擎的高可靠性。

為了避免有宣傳個人之嫌疑，希望小編屏蔽自己的名字，改用本人之“藝名”--- 強娃。

一、概述

云擎是基于CloudFoundry(后文統(tǒng)一使用CF作為簡稱)開源系統(tǒng)進行二次開發(fā)的，我們利用CF開源系統(tǒng)的基本框架，然后整合了京東自己的各個云服務產品，并且根據需求開發(fā)了智能路由、彈性伸縮、智能啟動和資源隔離等擴展功能。

CF開源系統(tǒng)作為一個通用的PaaS平臺解決方案，很好的滿足了大部分基本需求，但是要打造一個高可靠的PaaS平臺，還需要做很多架構容錯和改進。

CF由很多組件構成，有一些核心組件是必不可少的，還有很多可選組件可以根據需求選擇性使用。其中NATS、Router和Cloudontroller三個組件更是整個CF的最關鍵的組件，其中任何一個組件不可用都會導致整個PaaS平臺不可用，所以這三個組件的容錯顯得更加重要。 Router的容錯可以VIP實現，Cloudontroller本身通過Router的軟域名映射進行容錯。NATS作為整個CF各個組件的連接樞紐，一旦不可用所有CF組件都出問題，所以NATS的重要性不言而喻，但是目前業(yè)界普遍使用單實例。雖然NATS的穩(wěn)定性不容置疑，但是不能解決由于網絡、服務器硬件故障和操作系統(tǒng)故障導致的不可用，特別是由于服務器不可用導致的故障，恢復成本很高，時間也是很長的。開源的NATS組件也有集群版本，但是普遍反映不夠穩(wěn)定，都沒有在生產環(huán)境使用。本人表達一下對NATS升級改造的一點看法。

二、NATS集群化方案設計

為了提高京東云擎的可靠性，京東云擎團隊基于GO語言版本的NATS設計并實現了NATS的集群化方案，這個方案在預發(fā)布環(huán)境運行了一個月，現在也正式上線，表現都非常穩(wěn)定。下面就對我們的NATS集群化方案和實現進行闡述。

首先看看NATS集群化方案的架構圖，如下：

通過上面的架構圖可以知道，NATS服務器各個節(jié)點采用了zookeeper進行心跳存活的管理，這樣可以保證所有NATS客戶端獲取到的NATS服務器節(jié)點都是存活的;NATS服務器各個節(jié)點直接也會相互通信，主要是保證訂閱信息的同步。

這個NATS集群化方案有如下優(yōu)點：

(1)方便的橫向擴展，隨時上線下線NATS服務器節(jié)點;

(2)通過zookeeper管理NATS服務器節(jié)點的存活，保證了客戶端得到的NATS服務器實例都是可用的;

(3)通過最多兩次的消息轉發(fā)，極大的提高了消息轉發(fā)的性能。

三、NATS集群化方案實現

NATS集群化實現的難點主要在于怎樣保證消息的訂閱與發(fā)布能夠在各個NATS節(jié)點之間進行同步。下面分別從NATS服務器節(jié)點啟動、訂閱消息、發(fā)布消息和NATS客戶端改進等方面說明NATS集群化方案的實現。

1. NATS服務器節(jié)點啟動

為了保證各個NATS服務器節(jié)點訂閱信息的同步，啟動一個NATS服務器節(jié)點的時候需要判斷是否已存在其他NATS服務器節(jié)點，如果存在那么需要連接其他NATS服務器節(jié)點進行訂閱消息的同步。NATS服務器節(jié)點的各個功能或者服務初始化完畢以后將自己的地址以臨時節(jié)點的方式注冊到zookeeper集群中，這樣就可以開始對外提供服務了。

2. 消息訂閱

集群化版本的NATS對于NATS客戶端發(fā)布訂閱消息是透明的，即不管NATS客戶端選擇的哪一個NATS服務器節(jié)點都只需要向這一臺進行消息訂閱與發(fā)布。

NATS服務器節(jié)點收到訂閱消息以后，首先加入自己的消息訂閱隊列，然后廣播到其他NATS服務器節(jié)點，在廣播的時候做了一點點優(yōu)化，就是看這個主題的消息訂閱是否已經被廣播過了，那么就不需要重復廣播，防止訂閱信息過多，并且這些都是不需要的垃圾訂閱消息。

最后如果某一個客戶端取消訂閱消息，同樣需要廣播取消訂閱消息。

3. 消息發(fā)布

NATS服務器節(jié)點接收到NATS客戶端發(fā)布的消息以后，還是首先根據消息訂閱列表進行轉發(fā)，和單機NATS不同的是，這次轉發(fā)可能會轉發(fā)到其他NATS服務器節(jié)點，只要其他NATS服務器節(jié)點也有同樣的消息主題訂閱，那么這種情況就存在一次中間轉發(fā)的過程，但是也最多只存在一次中間轉發(fā)過程，所以性能基本上不受什么影響。

4. NATS客戶端改進

NATS客戶端的改進主要是支持從zookeeper集群上獲取NATS服務器的節(jié)點地址，并且能夠兼容以前老的直接配置某一個NATS服務器節(jié)點地址。當客戶端第一次連接NATS服務器節(jié)點時，需要從zookeeper集群獲取所有可用的NATS服務器節(jié)點地址并且緩存到本地，然后隨機選擇一個NATS服務器節(jié)點建立連接并且進行消息訂閱與發(fā)布。緩存所有NATS服務器節(jié)點地址主要是防止zookeeper不可用的時候并且NATS服務器節(jié)點有掛掉的情況不影響客戶端切換NATS服務器節(jié)點，在切換的時候需要把NATS客戶端以前訂閱的消息全部重新訂閱一次。

四、其他改進

本次針對NATS單點問題進行整個京東云擎的架構升級，完成升級以后整體運行很穩(wěn)定。不過除了NATS集群化，本次架構升級還做了其他很多改進，本次架構升級主要目的是讓京東云擎具有高可靠。下面在簡單介紹本次架構升級其他方面的改進：

(1)使用分布式文件系統(tǒng)替換原來的單磁盤存放droplet，解決了由于用戶猛增導致droplet存儲空間受限的問題;

(2)用戶控制臺界面dashboard的改變;

(3)Router對后端多實例包括CloudController的容錯;

(4)獨立域名綁定支持;

(5)應用打包部署流程優(yōu)化;

(6)同組件的不同實例分別部署到不同物理機的云主機上;

(7)其他組件功能優(yōu)化。

五、總結

云擎是京東給個人開發(fā)者、微小中型企業(yè)提供的一站式應用免費托管平臺，所以保證云擎高可靠性就是保證所有個人開發(fā)者和微小中型的應用的可靠性。

通過對核心CF的組件進行多實例或者集群化容錯處理來保證和提供云擎的可靠性，尤其在對消息中間件這個核心組件，云擎團隊設計和實現了自己的集群化方案，保證了消息通信的可靠性，并且通過GO語言進行開發(fā)擴展了單機NATS的消息通信的性能。我們設計的NATS集群化方案具有方便橫向擴展的能力，由此京東云擎團隊解決了消息中間通信的瓶頸。

云擎團隊后面考慮對NATS集群化方案進行服務提供給京東云擎的用戶使用，讓用戶也能夠通過消息中間件開發(fā)分布式的應用。

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