基于REST風格的輕量級注冊中心設計

胡喜明，胡 淼，夏夢瑩，周慧敏

(杭州電子科技大學 通信工程學院，浙江 杭州 310018)

0 引 言

RPC是當前分布式架構中重要的組成部分[1,2]。多個服務通過RPC框架以XML、JSON等形式進行數據交互，降低整體系統的耦合性，而注冊中心是保證RPC服務間可靠通信不可或缺的組件[3]。WebService是實現注冊中心的一種方式，其內部采用SOAP協議實現服務間通信。SOAP底層應用XML格式進行數據傳輸，在傳輸的過程中需要額外標簽的支持，而隨著SOAP協議的完善，傳輸中所需要的標簽數量也在持續增加，使得WebService傳輸帶寬增加并且降低了系統的傳輸效率[4,5]。

當前主流系統中多采用Zookeeper作為注冊中心，內部以字節數組的形式對注冊信息進行存儲，解決了SOAP中帶寬需求增加的問題。但是Zookeeper存在以下問題：首先，在集群部署的情況下，Master節點宕機時的選舉機制一般需要耗時30 s-120 s，在此期間所有服務均不可用。其次，Zookeeper缺少可視化界面管理，無法對服務進行細粒度治理。最后，Zookeeper運行時受到系統內存的限制，運行中不斷產生的數據會使可用內存不斷減少，進而導致整體系統性能降低[6]。

本文提出了一種基于REST風格的注冊中心系統(mRegistry)。項目中采用REST替代SOAP作為對外接口風格，REST傳輸內容以及操作方式更為簡潔，其內部實現了跨語言訪問功能，有效解決SOAP傳輸冗余的問題[7]。系統采用FreeMaker、Springboot和Mybatis框架[8]，搭建了可視化后端管理頁面，實現服務細粒度控制。內置數據持久化方案保證服務系統的穩定高效。通過與SOAP注冊中心對比，該系統具有更好的并發處理能力。

1 mRegistry系統概述

注冊中心是RPC系統的核心組件，其承載著連接服務提供者與服務消費者的任務[9]。一個完整的注冊中心應具備功能如下：

(1)服務注冊表功能：服務注冊表是記錄當前各個服務的信息，例如服務的名稱、ip、地址等。服務注冊表需要提供服務增加、查詢、修改、移除的功能；

(2)服務發現與注冊：第三方應用在接入注冊中心項目后，對注冊的應用進行保存，并開放查詢的API功能；

(3)服務監控：注冊中心需要對服務進行定時檢測，若發現服務長時間無法訪問，應該自動對服務進行清除；

如圖1所示為mRegistry注冊中心體系結構圖。mRe-gistry 服務注冊中心主要包括客戶端遠程API接口以及后臺管理中心。Java項目可通過引入對應maven依賴并配置相關參數實現自動化服務管理功能，非java語言或者未接入該系統的java程序可通過自定義REST風格API接口實現服務的注冊、發現、監控功能。注冊中心在接收到服務的注冊信息后通過內部線程化機制將信息寫入到Mysql數據庫中，隨后會定時輪循保存到本地磁盤。

圖1 mRegistry體系結構

mRegistry注冊中心為管理員提供了完備的后臺管理頁面，通過調用內部接口可查看當前提供的服務數以及注冊信息，并實現對當前服務的添加、修改、查看等功能。接下來針對mRegistry注冊中心中服務接口以及架構設計進行詳細分析。

2 mRegistry系統架構設計

2.1 數據庫設計

mRegistry系統在收到注冊/更新請求后需要對當前服務進行數據庫更新以及本地磁盤存儲。項目中采用3個實體類分別對應數據庫中3張表結構，見表1～表3，m_re-gister 表主要搭載在管理頁面，可通過管理員后臺對其進行編輯修改。m_register_data表主要記錄當前運行中的注冊信息，在服務停止后通過異步處理的方式清除無效的服務，同時更新m_register表中的地址信息。m_register_message表主要作為變更操作記錄表，系統將服務變更信息存入表中作為當前操作記錄，內部通過線程化機制定時檢測當前表中是否存在數據，在檢測到記錄表中的數據后，會按順序將變更信息更新到本地磁盤，保證本地數據與數據庫一致。

表1 m_register歷史注冊信息

表2 m_register_data當前服務注冊信息

表3 m_register_message信息更改記錄

2.2 mRegistry對外接口設計

mRegistry對外提供了基于REST風格的API調用接口，REST采用面向資源協議實現資源抽象化，并通過統一資源標志符(uniform resource locator，URI)以及 HTTP 規范所定義的GET、POST、PUT、DELETE實現資源的訪問。其操作方式更為簡潔，充分發揮了HTTP訪問的特性。由于REST內置了跨語言訪問功能，非JAVA項目以及未接入該系統的JAVA項目也可以實現接口的訪問。為保證開放性接口的安全性，接口調用中需要設置相應的令牌進行權限校驗，防止外部非法訪問。如圖2所示，注冊中心對外提供服務注冊與續約、服務發現、服務下線、服務監控的功能。

圖2 外部API功能結構

(1)服務注冊與續約

系統啟動后，服務提供者會向注冊中心發送注冊請求，請求的內容包括校驗令牌、服務訪問地址以及業務名稱。注冊中心收到JSON格式數據后，通過Jackson序列化工具將數據反序列化為輸出對象。系統調用內部驗證方法對數據進行格式以及令牌權限的校驗，校驗不通過返回權限不足的提示信息。對于通過校驗的數據，為保證在高并發模式下的接口安全性，服務內部采用Volatile關鍵字聲明的阻塞隊列registryQueue進行數據保存，該隊列底層采用JAVA多線程的ReetrantLock鎖機制，保證數據在高并發下的線程安全。為保證服務響應性能，數據存儲到registryQueue隊列后并非直接進行持久化存儲，而是等待內部線程進行處理。系統可通過異步回調數據向客戶端返回注冊成功信息，不需要等待內部完成注冊。

(2)服務的發現

服務消費者向mRegistry發送服務發現請求，通過傳入服務注冊的KEY、業務標識、環境標識來唯一的確定所需要的服務。同服務注冊相同，需要先對數據進行反序列化以及格式校驗。由于數據最終將持久化同步到本地磁盤，因此系統會采用服務注冊的KEY、業務標識、環境標識生成文件存儲路徑，通過JAVA文件流將文件信息從本地磁盤加載到內存中，最終將數據以KEY-VALUE形式返回，其中KEY為服務參數名，VALUE對應服務提供者所提供的接口信息列表。該接口主要針對非JAVA項目以及未接入該項目的程序進行臨時調用。為提高響應速度，采用 redis 對查詢數據進行緩存，并設置相應的過期時間。當下一次查詢相同服務時可直接從redis中獲取，減少磁盤訪問次數。

(3)服務下線

服務下線功能是服務提供者主動向注冊中心提交的下線請求。通過傳入的業務標識，業務地址以及服務名稱唯一的確定所要下線的服務。在接口通過校驗后，系統內部采用Volatile關鍵字聲明的removeQueue隊列，將通過校驗后的信息加入到隊列中，后續交給內部線程去執行下線操作。

(4)服務監控

該接口主要用在調用注冊請求時監控當前服務是否更新地址信息。服務調用者傳入業務標識、地址以及服務名稱進行接口調用。該接口會應用Spring框架中的DeferredResult類作為返回值，該類主要為了處理耗時操作，在沒有超過所設置的時間范圍或者未調用setResult方法時，接口不返回。系統通過異步請求的形式設置相應的心跳時間對監聽的接口進行檢測，同時將信息存儲在key-value所表示的Map中。系統每次調用心跳接口時調用方都會主動阻塞10 s，直至阻塞超時或服務注冊信息變動時響應。該接口為自動化管理提供心跳服務。

2.3 mRegistry對外接口處理模塊設計

對外接口處理模塊主要針對REST接口所注冊的服務進行存儲、更新以及實時監控操作。為了提高系統的整體性能，該模塊采用并發編程思想中的線程池技術，在不影響主線程運行的情況下實現內部操作線程化，提高系統響應速度。其中主要分為服務注冊處理、服務下線處理、檢測服務更新以及心跳檢測。

(1)服務注冊處理

在2.2節的服務注冊API中可以看到，當調用對外開放接口后數據將存儲在registryQueue隊列中，為了保證數據庫中數據的一致性，采用線程池技術開啟多個線程對隊列中的數據進行處理。服務注冊處理流程如下，系統通過registryQueue隊列獲取當前隊列存儲數據，若隊列為空則進行下一個循環繼續監聽隊列，否則將隊列中的數據存儲到數據庫中。添加完成后將該服務狀態從本地磁盤中讀取出來，對服務的注冊信息進行封裝并與Mysql數據庫中數據作對比，將產生變化的信息存入m_registry_message中等待后續本地磁盤數據同步。

(2)服務下線處理

為降低服務響應的延時，服務下線階段同樣采用線程池技術，開啟多個線程進行輪循處理。需要做下線操作的服務信息均存儲在2.2節所提到的removeQueue隊列中，系統會輪循檢測隊列是否存在信息，將檢測到的信息與數據庫進行對比并移除對應服務。服務移除后需要對在m_registry_message表中記錄當前操作信息，等等后續線程處理。

(3)檢測服務更新處理

服務更新檢測是為了將服務注冊以及服務下線的數據進行本地磁盤同步。當前服務中更新的數據都存儲在 m_registry_message 表中，系統首先會對數據庫表中數據進行獲取，將獲取到的數據進行狀態監測，對于鎖定的服務將地址置空。系統將監測后的數據按順序進行本地磁盤同步。該功能中為保證客戶端服務查詢的可靠性，采用廣播的形式對客戶進行通知服務，線程的輪詢操作為用戶提供了秒級通知的效果。在變更信息的同時會對數據庫中過期信息進行清理，使得外部監控接口在監測到數據更改時可以得到正確的返回結果。

(4)心跳檢測處理

服務注冊處理線程中應用registryQueue與線程池技術進行服務的注冊，在檢測到當前服務信息存在時，將會對注冊時間進行更新，保證當前注冊信息的有效性。注冊中心內部設置心跳檢測時間，若數據庫中時間與心跳時間的總和小于當前時間即可認為當前服務已經失效，此時需要清除 m_registry_data表中的信息。為了保證在調用服務發現API時，本地數據查詢到最新的數據，在清除表中信息后需要對當前操作進行本地磁盤同步處理。

2.4 mRegistry后臺管理中心設計

如圖3所示，后臺管理中心主要分為服務展示、服務管理以及使用說明3部分。管理員通過輸入賬號密碼實現后臺的登錄，為保證服務的安全性系統，系統采用MD5加密模式對輸入賬號進行校驗。登陸成功后系統生成對應Token令牌存儲在Redis中并返回前端，每次在操作管理界面功能時都需要進行令牌校驗。該存儲模式主要為了實現單點登錄功能以及解決集群環境下的Session不一致現象。圖4為登錄成功后顯示的后臺管理頁面，在運行報表標簽中可以查看當前系統中正在運行的注冊服務數量以及當前系統注冊的人員數量，方便管理人員進行數據統計。服務注冊標簽為該后臺管理的核心功能，其中主要包括對服務的增加、修改、刪除以及禁用功能，管理員還可以通過輸入業務標識、環境標識以及注冊的key進行服務的精確查找。在使用教程界面中主要對該系統的功能點進行了描述，同時還提供了完整的使用說明，方便管理人員使用。

圖3 后臺管理功能結構

圖4 系統管理員界面

目前傳統Web頁面設計主要采用HTML+CSS+JSP框架。JSP功能比較強大，可以在頁面上編寫處理邏輯代碼，但隨著頁面功能的擴展，邏輯代碼的復雜度提高，且在第一次執行的時候還需要進行編譯轉換操作，增加了系統的維護難度。項目中采用FreeMaker模板引擎技術，該技術主要用在MVC模型中，遵循模板+數據=頁面的形式，模板只負責數據在頁面中的表現，不涉及任何的邏輯代碼，而所有的邏輯都是由數據模型來處理。用戶最終看到的輸出是模板和數據模型合并后的結果，真正實現了前后端分離開發。應用模板引擎技術開發提高了代碼復用率以及頁面的加載速度[10,11]。

2.5 客戶端服務優化

對于接入mRegistry的RPC框架，直接調用對外API接口無法實現自動化服務上下線通知功能，因此在項目中封裝了客戶端輔助類，該類將遠程API接口封裝為服務注冊、發現、移除方法，使得RPC框架在接入注冊中心時可以自動對服務進行更新。并且該類內部使用Redis對服務注冊信息進行緩存，避免在服務發現時的多次IO操作。

功能的實現分為兩部分：

(1)系統啟動后在后臺服務端開啟一個服務注冊相關的守護線程，該線程可以保證在客戶端關閉連接時也進行關閉處理。線程對接收到的服務注冊信息進行輪循處理，將數據每隔10 s進行數據庫更新，這里主要更新該注冊信息的updateTime字段，該字段為后續服務下線做預處理；

(2)在開啟服務注冊線程的同時也采用守護線程的模式開啟服務發現線程，保證服務結束后線程的釋放。服務在第一次調用服務發現方法時會將當前服務信息的服務名稱作為key服務地址作為value存入Redis中并設置過期時間，后續的查詢操作均不需要進行本地磁盤查詢，可通過服務名稱從Redis中獲取對應地址。為防止過快訪問導致性能下降，會先判斷Redis變量中數據是否存在，若沒有數據則將線程暫停3 s。在檢測Redis中存在服務信息后，通過編寫REST風格的HTTP請求訪問服務監控API。對外服務監控API中設置了最長等待時間為30 s，HTTP在調用監控API接收到返回結果時，如果為FALSE，則讓當前線程休眠10 s再次進行調用，避免失敗重試請求次數過多。由于10 s的睡眠時間限制，在經過3次心跳檢測訪問后如果當前監控API回復默認響應則表示當前服務已經停止，此時數據庫中該服務的數據在時間上已經符合刪除條件，即心跳時間與服務UpdateTime字段的時間總和小于當前時間。系統通過調用服務查詢API，刷新當前Redis中的數據，自動將下線數據移除。系統循環執行上述操作，在提高整體查詢服務的速度的同時實現服務的自動化管理。

Redis進行服務緩存時容易出現緩存雪崩的情況，主要原因是大量的服務緩存數據在同一時間過期失效，此時大量請求直接訪問數據庫導致數據庫無法承受當前壓力而出現性能下降甚至崩潰。系統通過對key值設置不同的緩存時間來解決該問題，通過Random函數在原始默認緩存時間的基礎上添加隨機數，使得注冊的服務在內存中的失效時間散列化。

2.6 mRegistry集群設計

集群化部署可以提升系統的容災以及高可用能力，在分布式系統中注冊中心均需要以集群的形式搭建。如圖5所示，項目中采用 Nginx搭建注冊中心集群，通過更改Nginx配置文件文件中的upstream屬性為不同的注冊中心分配地址[12-14]。通過Nginx內置的負載均衡策略為不同的端口設置權重，實現后臺服務器負載的均衡分配。在該模式下若當前訪問的注冊中心出現宕機情況，Nginx會對節點進行自動切換，解決了Zookeeper集群模式選舉時間過長導致的服務不可用問題。

圖5 nginx集群框架

在搭建集群時需保證連接相同的數據庫實例，同時多個注冊中心的管理員界面登陸賬號的配置需要保持一致。在多臺服務器同時操作同一個數據庫時，數據庫中采用聯合唯一索引的方式，最終只有一臺服務器成功執行，保證了數據冪等性。

2.7 mRegistry一致性問題

mRegistry系統采用集群方式搭建，多個注冊中心共同操作同一數據庫實例時會產生數據存入本地磁盤不一致的現象。為解決mRegistry中數據一致性問題，項目基于Raft原理，采用統一處理操作變更請求。其作用是為了保證節點之間操作的日志副本一致，并通過邏輯時鐘進行定時保存，保證節點運行狀態機得到一致的結論[15]。項目中m_registry_message消息表作為統一處理分發變更請求，僅在變更數據時才產生消息，消息量相對較少，并且消息輪詢線程存在時間間隔，因此數據庫中消息表的壓力也不會過大。在服務提供者進行注冊以及修改服務時，m_registry_message表會將注冊的操作進行記錄，以順序遍歷的方式同步到本地磁盤，遍歷后清除消息表中相應數據，保證本地數據與數據庫數據一致，并內置周期性的將數據庫中注冊信息全量同步到本地磁盤，保證多個注冊中心節點的數據一致性。

3 實驗測試

3.1 系統功能測試

在本地電腦搭建注冊中心環境，項目啟動后訪問http://localhost:8080/admin進入登陸頁面，如圖6所示為輸入正確賬號密碼后進入的后臺管理界面。管理員可以通過瀏覽器便捷地查看系統當前服務數，并通過頁面上的功能按鍵進行服務的新增、查詢、修改和刪除操作。測試結果可知，該界面運行流暢，人機交互效果良好，符合預期設計需求。

圖6 后臺服務注冊管理界面

針對服務注冊以及查詢功能，需要在客戶端編寫服務注冊以及查詢的代碼，代碼中調用自定義的客戶端類發送服務注冊請求。如圖7所示，客戶端開啟后可以從控制臺看到服務注冊成功的日志信息，并且系統每隔10 s會向mRegistry發出監控請求，檢測當前注冊服務是否存在。測試代碼中設置2 s的睡眠后進行服務查詢，從圖中可知此時客戶端編寫的服務發現代碼成功獲取到了當前注冊的服務信息。

圖7 啟動后日志

通過對數據庫中key為update的服務進行修改，測試服務自動化管理功能。修改update服務的地址，等待幾秒鐘后系統基于心跳檢測機制發現當前注冊服務信息與實際注冊不符，系統將注冊表中信息清除并重新將當前服務注冊。如圖8所示，此時在服務端做出了服務更改的操作，需要在m_registry_message表中記錄一條JSON格式的變更信息。系統內部通過對記錄表中數據進行監聽將當前更改操作寫入到本地磁盤中并將該條記錄刪除。至此完成了自動化管理的功能。

圖8 m_registry_message表

3.2 系統性能測試

這一部分主要針對mRegistry注冊中心和SOAP注冊中心的響應性能進行測試。通過maven插件對注冊中心項目進行打包，將打包好的JAR文件分別上傳到服務器中。服務啟動前需要在mysql數據庫中創建mRegistry對應表結構，并對redis進行相應的部署。mRegistry注冊中心需要對注冊的服務進行本地磁盤保存，應根據不同系統修改對應存儲路徑信息。測試中選取3臺服務器，其中兩臺服務器分別部署基于SOAP風格的注冊中心和mRegistry注冊中心，第3臺作為模擬請求。3臺機器配置見表4。

表4 服務器配置

實驗中采用并發測試工具Jmeter對兩個注冊中心系統進行性能壓力測試。Jmeter模擬高并發下服務注冊與服務查詢請求，其內部通過多線程機制設置并發訪問數量，根據并發數的不同對比兩個注冊中心數據響應速度。

3.2.1 服務注冊

如圖9所示為客戶端并發模擬服務注冊請求的響應時間對比圖，橫坐標為并發用戶數量，縱坐標為平均響應時間。由圖可知，在并發數量較小的情況下兩者的服務注冊時間相近。隨著并發訪問量的提升，SOAP服務注冊中心響應時間遠大于mRegistry，可以看出在服務注冊方面mRegistry有明顯的性能優勢。

圖9 注冊服務響應時間對比

3.2.2 服務發現

測試過服務注冊功能后，兩個注冊中心所注冊的服務數量相同?？蛻舳四M高并發情況下服務發現請求，如圖10為服務發現功能的并發訪問數量與平均響應時間關系圖，從實驗結果可以看到，SOAP注冊中心的響應時間始終高于REST注冊中心。隨著并發訪問量的提高，兩者的響應時間差依然很大，最終SOAP服務注冊中心響應時間接近mRegistry響應時間兩倍。從曲線的走勢可以看出mRegistry更加平穩，這說明mRegistry系統在高并發環境下更加穩定。

圖10 服務發現響應時間對比

4 結束語

通過分析SOAP中xml格式傳輸存在的問題，設計了一種基于REST風格的輕量級注冊中心。該系統對外開放REST風格接口實現跨語言調用，同時降低了傳輸的冗余度；基于線程池技術對底層業務代碼進行封裝，提高了注冊中心的運行效率；系統采用Redis對服務進行緩存，降低數據庫訪問壓力，提升響應性能；通過對API接口封裝，實現自動化服務管理以及心跳檢測功能；系統基于Raft原理防止數據重復消費，保證了數據的一致性；最后，通過與SOAP注冊中心對比可知該框架具有良好的并發處理能力。