基于Zookeeper的配置管理中心設計與實現

苗 凡，閻志遠，戴琳琳

(中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 100081)

客票系統核心交易中間件線上包括CTMS、INETIS、CTMSX等，主要為鐵路12306網站、12306 APP提供接口服務。線下包括CTMS、AFCIS、TVMIS等，主要為窗口、代售點、自動售票機、閘機等提供接口服務。其中，CTMSX、INETIS與CTMS部署在鐵路總公司的兩個數據中心，共同承擔各渠道的交易請求。客票系統日均售票800萬張，節假日高峰期超過1 200萬張[1]，中間件服務作為交易系統中的重要一環，在保證系統的穩定性中起著重要的作用。

交易中間件的應用均含有多個配置文件，根據業務場景的不同，替換的配置文件也不同。當前中間件服務更換配置文件后，需要重啟服務才能生效，若服務與其它應用保持長連接，還需要通知其它應用進行重連，整個升級可能需要10 min才能恢復，極大地影響了生產環境的可用性[2]。為解決上述問題，本文提出了一種基于Zookeeper進行配置管理的方案，Zookeeper是一個高可用的分布式數據管理與系統協調框架，能夠保證分布式環境中數據的一致性。

1 Zookeeper的數據結構

Zookeeper 采用了類似文件系統目錄樹型結構的數據模型，結構中的每一個節點稱為znode。與文件系統不同的是，每個節點具有與之對應的數據內容，可以擴展任意的節點和葉子節點，每個節點都可以存儲KB級別的數據[3]。節點維護一個stat數據結構（包括數據變化的版本號、ACL變化、時間戳），以允許緩存驗證與協調更新。以INETIS下的test節點為例，通過get命令獲取節點內容，如圖1所示。

每當節點數據內容改變，版本號dataVersion均會增長，客戶端獲取數據的同時也會獲取數據版本號。節點的數據內容以原子方式讀寫，讀操作讀取全部內容，寫操作替換全部內容，節點還具有一個訪問控制列表來約束某些操作。

圖1 znode節點信息

Zookeeper有兩種類型的節點：（1）臨時節點，在創建該節點會話的存活期間存在，會話結束，臨時節點自動刪除；（2）持久節點，節點創建后一直存在，直到有刪除操作來主動清除這個節點[4]。

2 實現方案

2.1 配置管理中心

配置管理中心以B/S方式提供給維護人員使用，可以進行增加、更改、刪除、查看等操作。每一個配置文件均對應一個Zookeeper中的節點，節點變更會通知到注冊過該節點的各應用。同時可以查看配置文件的歷史版本，便于對比，配置管理中心與各應用的調用關系如圖2所示。

圖2 配置管理中心與各應用的調用關系

配置管理中心以Web頁面的方式供維護人員使用，并與客票系統交易中間件保持連接，配置管理中心保存著INETIS、ATCTMS和CTMSX3個應用服務的配置文件。配置中心的主要功能如下：

（1）基于Web頁面的配置文件管理。通過頁面可以查看各個服務當前的配置文件，并檢查當前運行的配置文件是否與Zookeeper中的配置文件一致。同時Web界面可以連到各個集群中的服務，通過后臺服務提供的接口，查看各配置項在內存中的值與配置文件中是否一致。

（2）同一個APP下的多個配置文件。同一個應用下存在多個配置文件，對配置進行分類，對于經常更改的，加入到Zookeeper節點中。并在客戶端中對該節點注冊watcher事件。

（3）配置文件的版本管理。生產中每次更改的配置文件需要進行備份，如果升級不成功可以回退。選取Git進行配置文件的版本管理，Web頁面查看歷史版本配置文件。

（4）數據持久化保存。當交易中間件從統一配置管理中心得到數據更新后，將數據保存在配置文件中。以防Zookeeper異常時，無法得到配置文件，應用無法啟動。

（5）實時更新。對于新獲取的配置文件，在持久化保存后，需要將更改的值重新加載入內存替換舊的值，達到無需重啟應用即完成配置生效的功能。

2.2 配置文件節點設計

客票系統交易中間件的配置文件以節點的方式存于Zookeeper中，配置文件在Zookeeper server中節點的設計如圖3所示，＜＞表示目錄。從圖中可以看到，最上一級目錄名為middle_ware，表示客票交易中間件的目錄，它的子目錄為app_name，即CTMS、INETIS、CTMSX等。每個中間件應用服務下有兩個子目錄，分別為conf與version，conf節點下的子節點為最終的配置文件節點，節點里面的內容即為配置文件里的值。以中間件應用服務INETIS為例，INETIS中的配置文件gemfire.cfg在Zookeeper Server里的節點路徑即為/middle_ware/INETIS/CONF/gemfire，配置文件eid.cfg對應的節點為/middle_ware/INETIS/CONF/eid。

2.3 配置文件的獲取與更新

客票交易中間件如CMTS、INETIS等在運行之前，必須先加載本地配置文件，再進行一系列參數的校驗與初始化后才能正常啟動。更新配置文件時，需要同步兩個中心的所有服務器，確保各服務器的配置無誤后才能重啟服務。為了改進這種更新方式，提高應用程序維護的效率，需要解決兩個問題。

圖3 配置文件節點設計

2.3.1 自動獲取

配置文件的自動獲取即應用程序從Zookeeper中獲取配置文件，Zookeeper所有讀操作getdata、getchildren和exists均具有設置watch的選項，Zookeeper 的watch事件是一次性觸發器，當watch監視的數據發生變化時，通知設置了該watch的client，即 watcher[5]。

為了完成應用程序從Zookeeper中自動獲取配置文件的內容，需要改造應用程序，使應用程序啟動前讀取znode節點里的內容，并且將watch事件一直注冊在該節點上，只要節點內容有變化，作為Zookeeper客戶端的應用將獲取數據變化事件。

2.3.2 重新加載

當Zookeeper節點內容發生變化時，watch該節點的回調函數便會執行。函數里實現了重新解析配置文件的內容，刷新各個配置項在內存中的值，便可實現配置文件的實時更新。同時為了防止Zookeeper服務器出現異常，需要將最新的配置文件持久化寫入本地文件，以防程序重啟時因無法獲取配置文件而導致服務不可用，還可以進行版本管理。

2.3.3 更新

配置文件節點的創建與更新需要開發一個單獨的發布程序，發布程序的接口與配置文件獲取類似，區別主要在發布用的是setdata，獲取用的是getdata[6]。由于每個應用均包括多個配置文件，在發布程序里肯定會包括全部的配置文件的加載，但有時生產只需要更新一個配置文件，因此在setdata之前是需要對比新的配置文件里的內容與Zookeeper里對應節點的內容，如果兩者內容一致，則不需要設置這個節點，反之如果不一樣，則對這個節點進行setdata。

涉及到節點改變的不同方式，Zookeeper可能維護兩個watch列表：節點的數據watch和子節點git的watch。getData和exists設置了內容watch，getChildren設置了子節點watch，操作返回的數據類型不同，前者是節點的內容，后者是節點的子節點列表[7]。

2.4 配置文件版本管理

版本管理的功能在于跟蹤記錄整個配置文件的變更過程，在時間上全程跟蹤記錄工具將會自動記錄開發過程中的每個更改細節和不同版本，以便對不同階段的配置文件進行差別分析，輔助協調管理維護開發團隊。

Git是當前流行的版本管理工具，Git的每次提交都會根據SHA1算法生成唯一的commitid，而不是像SVN那樣對單個文件分別進行版本更改，所以跟蹤以前某次提交的代碼時，不用考慮到底提交了哪些文件，所有變動的配置文件都會一次性的取出來。常用的 git命令有 git add，git commit，git checkout等。

對于統一配置管理中心的維護人員來說，顯然不希望了解版本庫里的所有信息，因此，本系統的目標是對git版本庫中的配置文件信息進行針對性的展示。在版本控制系統中，分支的個數，提交的次數，提交者以及提交的時間都是十分重要的信息，在配置文件首頁看到的是配置文件節點的最新提交信息。

2.5 REST Web Service接口設計

REST包含3個主要內容：資源，表示和狀態。資源指網絡上一種體現為比特流的實物或抽象概念，可通過統一資源定位符URI定位；表示指資源呈現的方式，為構建可擴展，松耦合的Web提供準則；狀態是服務器端資源狀態或終端狀態，資源的狀態保存在服務端，應用的狀態由應用自身維護，由于REST所有交互都是無狀態的，因此終端的每次請求需要攜帶交互所需要的全部信息[8]。

REST將整個服務端抽象成資源的集合，資源由URI標識，終端調用HTTP的主要方法包括POST、DELETE、PUT及GET，可以分別對資源進行增加、刪除，更改和查詢等操作。基于REST實施的上述架構約束，可輕松解決系統開發中接口可擴展性和終端異構性等問題。

統一配置管理中心給維護人員使用，根據統一配置中心的需求分析，其提供的主要功能有：

（1）集群中各服務的運行狀態，包括服務連接池使用大小，錯誤日志的監控。（2）集群中各主機的狀態，包括CPU，內存，磁盤，網絡的利用率。（3）對各服務進行操作，包括對服務的啟動與停止。（4）更新或更改配置文件等功能，根據需求，通過表單提交配置項的值，并將新的配置信息返回給開發人員。（5）權限管理，包括用戶角色分配、用戶登錄、注冊、添加及修改用戶基本信息等。

結合上述需求分析，遵循REST規范，設計出符合REST風格的統一配置管理中心接口設計，如表1所示。

表1 配置文件管理REST接口設計

3 測試數據分析

為了獲得更好的可靠性服務和更快的同步速度，測試環境采用集群的方式部署Zookeeper服務，通過客票交易中間件建立到ZooKeeper實例的連接，然后在服務集群中創建節點，并將節點設置為監聽狀態，該節點的內容為交易中間件INETIS配置文件的內容。當維護人員需要修改INETIS配置文件內容時，只需要通過Web頁面選擇對應的配置文件，并對文件內容進行修改，可以看到Zookeeper中的節點內容已經修改，而此時監聽了這個節點INETIS配置文件的最新修改時間已經更新為當前時間，內容與修改后的一致。新的同步方式幾乎在秒級完成，而采用傳統的文件傳輸方式完成一次同步需要近10 min。

4 結束語

服務器增長的速度已遠遠高于開發人員的增長速度，通過傳統人工手段登錄服務器實現配置文件的更新不僅效率低而且容易出錯，本文提出了一種基于Zookeeper的配置文件管理方案，將客票交易中間件應用服務器眾多的配置文件集中式地存放在Zookeper節點上，在Zookeeper的客戶端，通過與服務端連接，可以方便快捷地獲取應用服務器最新的配置文件，并在此基礎上增加了過期配置文件的備份功能。目前，該方案已經應用在客票系統雙中心，應用結果表明，此方案不僅能保證各配置文件的一致性而且無需重啟服務，整個更新在秒級完成，極大地提高了升級與維護的效率，保證了服務的不間斷運行。Zookeeper除了這個功能外，還能管理集群中的節點，下一步我們將繼續深入研究，持續提高系統的可靠性。