邵黎明
摘? 要:長期擴展性系統具有獨立模塊成型快、系統發展時間長、模塊迭代頻繁的特點。因此將獨立模塊服務化、采用可插拔的服務注冊機制并通過完善的權限控制和認證實現新舊服務之間的通訊,進而在提高數據和服務的復用性避免重復開發的同時保證了每個獨立服務的高可用性。分布式系統的CAP理論要求在架構的設計前期對CP和AP作出抉擇,而由于民航的領域特性,對于高可用和分區容錯性的要求遠大于一切,因此以AP為原則的去中心化設計成為首選。
關鍵詞:服務注冊;微服務;高可用;去中心化;民航領域
中圖分類號:TP302? ? ? ? 文獻標志碼:A? ? ? ? ?文章編號:2095-2945(2019)09-0069-02
Abstract: The long-term extensibility system has the characteristics of fast independent module forming, long system development time and frequent module iteration. Therefore, the independent module is serviced, the pluggable service registration mechanism is adopted, and the communication between the old and the new services is realized through perfect authority control and authentication. In turn, it can improve the reusability of data and services to avoid repeated development while ensuring the high availability of each independent service. The CAP theory of distributed systems requires a choice between CP and AP in the early stage of architecture design, but because of the domain characteristics of civil aviation, the requirements for high availability and partition fault tolerance are far greater than anything else. Therefore, the decentralized design based on the principle of AP has become the first choice.
Keywords: service registration; micro-service; high availability; decentralization; civil aviation field
基于關系性數據庫開發的傳統單機應用不存在分區所以不需要考慮分區容錯性、僅有一個可用服務、數據通過單個數據庫訪問具備強一致性。但是隨著業務的拓展,這種單機應用將會越來越多,系統之間的相互通信一般采取接口方式,而接口的增加無疑會導致系統風險的增加并且對各個不同系統和不同系統的接口維護將會異常困難,并且維護的工作量也是隨著系統的增加不斷的加大;如果把各個獨立系統集成為單個系統則需要考慮:(1)系統是
否能承載各終端訪問壓力;(2)各個獨立應用的開發時間
是否可以在接近的時間內完成;(3)當系統容量達到某個
量級時,是否具備完善的監控管理機制。
1 基于微服務的民航基礎服務系統的研究
本文介紹以大數據為依托的微服務架構應用,構建高效、用戶體驗良好、抗壓能力強、能滿足用戶多元化需求的民航基礎服務系統,并介紹對碎片化系統的整理方案。該方案在對微服務深入研究的基礎上運用其對服務的注冊與發現機制有效管理服務層的依賴關系并結合實際業務完成對服務的授權與鑒權,方案包括數據呈量級增長時的處理辦法和對數據的有效利用。在滿足民航基礎服務系統向公網方向發展的安全、穩定等必要條件下,實現了系統的可伸縮、多終端兼容。
1.1 行業需求
民航相關服務越來越多,服務的管理越來越困難,小服務資源的浪費等問題逐漸顯現,此時行業迫切需要增加一個調度中心基于訪問壓力實時管理集群容量,整合應用服務,使系統之間互聯互通,提高資源的利用率。
1.2 民航基礎服務系統建設方案
微服務架構對管轄內的服務進行有效的治理是它有別于RPC或其他分布式系統架構的關鍵特點,為適應未來民航IT系統的不斷增長而建立基于微服務的民航基礎服務系統。
系統設計方面以微服務的“去中心化”為核心思想,按照業務對系統進行分類管理,根據依賴關系對服務分層下層應用不允許逆向調用,嚴格把控數據流向。整個架構分為基礎服務、接入服務、調用服務、業務系統、統一門戶、數據服務六個版塊,各個版塊之間統一采用rest風格的http協議通信。
(1)基礎服務包含服務的注冊“中心”和配置“中心”,注冊服務通過將自身注冊到其他的注冊服務上創建副本去中心化,配置服務通過自我復制創建副本集去中心化,同時將自身注冊到注冊服務的副本集為其他各部提供啟動時的配置;可以由運維人員切換生產環境和開發環境的配置,統一的環境配置使系統管理更加高效,開發人員也無需知曉具體的數據庫連接密碼等敏感信息。
(2)接入服務負責對接入應用的鑒權與授權以及通過配置中心的相關配置限制接入應用的調用頻次以保障被調用服務的安全。權限控制可以采用完美契合rest無狀態特性的OAuth2和JWT的組合方案,在應用申請接入時可在后臺配置一個Token來控制當前接入應用的訪問權限、時效和訪問頻次;當前應用在調用其他服務時攜帶自己的Token,同時也要擁有解析允許訪問本應用Token的能力。服務網關在Nginx+Lua和spring cloud的Zuul中選擇后者,因為Nginx雖然以單線程多路復用提供了比Zuul更加高效的服務但是Zuul擁有Spring生態的支持,開發和維護都更加方便。
(3)負載均衡和容錯保護是提高系統可用性的措施之一,負載均衡也可以使用Nginx和Lua來實現,但同樣選用spring cloud中集成了負責負載均衡的Ribbon,同時Ribbon還帶來對非spring boot應用的支持,作為一個民航基礎系統,應該具備對其他rest風格應用的兼容特性以確保盡可能的接入如ASP.Net開發的應用服務。容錯保護又包括服務熔斷和服務降級等措施,當系統協同運行過程中出現某個服務整體無法調用或響應時間長的時候,為保障用戶能在可接受時間內得到回饋需要對服務分情況的進行降級或熔斷;降級是將當前服務在路由節點中的位置向后推移,熔斷則是當超時或無法調用時路由到其他服務中。
(4)數據服務提供緩存、關系型數據庫、分布式文件系統的支持,如果后期數據量確實很大,也有大數據計算的需求還可以加入Spark。緩存采用K-V內存數據庫Redis提高數據層的并發處理能力;關系型數據庫可選擇開源的MySql配合應用層數據分片框架Sharding-Jdbc做數據庫的讀寫分離、分庫分表集群,也可以選擇MyCat作為關系型數據庫中間件來提供分庫分表和讀寫分離的功能,前者的好處是不需要單獨維護一個數據庫中間件,也不用考慮中間件的可用性和并發處理能力,后者的好處是開發方無需關心數據庫存儲能力問題,兩種方案都解決了持續增長數據的存儲問題;分布式文件系統使用MongoDB,后續如果集成Spark則構成一個完整的大數據解決方案。
(5)業務系統是需要協同工作的服務的整合,各個應用服務集群提供各自相對獨立的功能,同時也需要考慮響應時間和運營維護的復雜程度。
(6)統一門戶在微服務架構中具有對業務應用生命周期的支撐作用,當相對獨立的業務應用越來越多時,這些微服務程序都將不再依賴應用服務器,不依賴傳統應用服務器則會導致應用服務器提供管理控制臺無法正常工作,所以微服務的運行管理需要有統一的管理門戶。統一集中的微服務門戶,可以支撐應用開發、業務處理、應用管理、系統監控等。
1.3 民航基礎服務的接入方案
根據不同的接入需求,基礎服務系統提供Server和Client兩種接入方案。
(1)Server接入必須以Restful API的形式并符合微服務設計原則,必須歸入到基礎服務系統的服務治理體系中,服務的響應時間必須在基礎服務方案規定的響應時間范圍內。Server接入方案開發方不需要考慮服務的治理問題,同時也能申請調用其他服務,是一種高度定制化的接入方式。Server接入前須在門戶申請并登錄帳號,填寫接入應用的類型為Server、用途、接入方、需要調用的服務等基本信息后提交接入申請,由系統管理員確認后發放測試環境的接入Token,上線前提交到系統進行測試,測試通過后由系統管理員發放生產環境Token上線該服務到申請人賬戶并自動開通當前賬戶的暫停服務,刪除服務功能。
(2)Client接入用于適配外部應用,當舊系統的響應越來越慢且當前基礎服務中已經包含了部分可以被舊系統使用的功能時可以把這部分功能的提供方轉換為基礎服務。仍需在門戶登錄的狀態下申請接入,填寫接入應用類型為Client、需要訂閱的消息、接收消息的地址、驗參公鑰等信息,提交申請后獲得對應應用的app key,系統管理員確認后當前app key擁有接入權限填入的接收消息地址將會實時收到訂閱的消息,消息的傳輸基于http協議,數據格式為json,同時為保障接入的客戶端數據安全,接收到消息時必須對參數進行簽名驗證。
1.4 技術優勢
分布式系統是當用戶量攀升、數據量增大時的一種處理方法,基于微服務的民航基礎服務符合去中心化的設計規范并具備以下優勢:
(1)業務可伸縮。系統搭建完成后,可快速響應行業內多種需求,業務應用開發完成后,系統管理員可通過門戶頁面快速發布,同時對業務應用的升級與下線也是一鍵操作。
(2)故障可隔離。在系統發生嚴重故障(例如某業務應用的所有副本發生網絡故障)時,系統會自動啟用應急措施將用戶請求路由到其他服務中,并產生警報信息。如果發生輕微故障(例如某業務應用下的個別副本響應時間長),系統會自動選擇響應時間較短的服務來響應用戶請求。
(3)系統好管控。引入門戶對系統的業務應用統一管控,可以有效的復用基礎應用,從架構上控制業務應用之間的依賴關系,使業務應用的開發和上線更為高效。
2 結束語
從單一的數據庫架構,到主從讀寫分離的數據庫架構,再到垂直拆分、水平拆分的數據庫架構,當民航領域垂直應用越來越多,應用之間交互不可避免,將核心業務抽取出來,作為獨立的服務,逐漸形成穩定的服務中心,使前端應用能更快速地響應多變的市場需求,使民航領域集成系統具備可持續迭代的能力,促進行業的發展。
參考文獻:
[1]黃志誠.數據中心建設中服務器虛擬化的應用研究[J].科技資訊,2018.
[2]汪文彬.高校數據中心服務器虛擬化研究及應用[D].浙江工業大學,2013:22-23.