CloudFoundry架構(gòu)優(yōu)化：NATS集群化方案

編者按：NATS是由Cloud Foundry開發(fā)的一個基于事件驅(qū)動的、輕量級的消息系統(tǒng)。它基于EventMachine實現(xiàn)，第一版本CloudFoundry被人詬病的一個問題就是NATS服務(wù)器是單節(jié)點的，讓人不大放心。集群版本則被反映不夠穩(wěn)定，都沒有在生產(chǎn)環(huán)境使用。本文作者為京東云擎（JAE）的架構(gòu)師強娃，從事云平臺特別是PaaS平臺的架構(gòu)、開發(fā)多年。作者對開源PaaS框架CloudFoundry進行了優(yōu)化，解決了NATS單節(jié)點問題，大大減小了NATS單節(jié)點的風險問題。目前京東云擎就是基于這種方案來實現(xiàn)的，避免了單個NATS節(jié)點掛掉導(dǎo)致整個云擎無法運行的情況。以下為原文：

概述

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

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

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

NATS集群化方案設(shè)計

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

首先看看NATS集群化方案的架構(gòu)圖，如下：

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

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

1. 方便的橫向擴展，隨時上線下線NATS服務(wù)器節(jié)點；
2. 通過zookeeper管理NATS服務(wù)器節(jié)點的存活，保證了客戶端得到的NATS服務(wù)器實例都是可用的；
3. 通過最多兩次的消息轉(zhuǎn)發(fā)，極大的提高了消息轉(zhuǎn)發(fā)的性能。

NATS集群化方案實現(xiàn)

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

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

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

2. 消息訂閱

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

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

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

3. 消息發(fā)布

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

4. NATS客戶端改進

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

其他改進

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

1. 使用分布式文件系統(tǒng)替換原來的單磁盤存放droplet，解決了由于用戶猛增導(dǎo)致droplet存儲空間受限的問題；
2. 用戶控制臺界面dashboard的改變；
3. Router對后端多實例包括CloudController的容錯；
4. 獨立域名綁定支持；
5. 應(yīng)用打包部署流程優(yōu)化；
6. 同組件的不同實例分別部署到不同物理機的云主機上；
7. 其他組件功能優(yōu)化。

總結(jié)

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

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

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

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學習有所幫助,可以手機掃描二維碼進行捐贈