摘要：
現代軟件發展歷程中，微服務概念早在2014年由兩位美國學者提出，2015年雲原生也在linux基金會的推動下茁壯成長。短短几年，越來越多的公司投入研究，越來越多的技術框架孕育而生。本文通過分析和測試微服務架構下的中間件技術，得出評估結果，並指導本次數據治理平臺的案例改造。最終的案例分享，旨在對解決企業級應用的微服務化改造，遇到的技術方案與架構調整提供一定指導意義。
關鍵詞：
雲原生、微服務、數據治理、微服務架構
雲計算技術的迅速普及，提供給企業一種可基於計算資源按需分配的模型，其中CloudNative 直譯過來便是雲原生[1]，是面向雲環境而設計的軟件架構。基於微服務架構思想，以容器技術為載體，產生的一種全新的產品研發運營模式。企業級應用可以部署在IaaS、PaaS和SaaS平臺中，對於IaaS和PaaS平臺中部署的應用來說，採用傳統的單體模式，導致雲端模塊不能快速迭代更新，用戶體驗響應速度較慢等，這些都是產品質量提升的掣肘。這也是SaaS提供者一直強調“應用需微服務化”，保證較強的持續交付的重要原因。
在單體化的應用模型中，所有的服務都是由統一的代碼庫實現，由開發團隊的所有人維護，當某個開發者想要修改指定服務時，必須保證其他服務不受影響。隨著應用體量越來越大、服務越來越多、業務含義越來越複雜，擴展或修改某一個服務所需的週期變得異常艱難。除此之外，單體應用的更新部署需要重啟所有的服務，而且單體化應用具有單點失效問題，只要其中一個服務初始化階段出問題，會導致整個應用的全部宕機。
很多大型軟件公司就是因為意識到單體化架構的侷限性，提出了一種新的應用架構模型/模式：微服務架構與雲原生模式[2]。
微服務架構在2014年由Martin Fowler和ChrisRichardson兩位大神佈道，並快速的在NetFlix和Amazon等公司實踐。本著“小、獨、輕、松”微服務概念，技術框架快速迭代，各種中間件技術在開源社區中也開花結果。如阿里開源的Dubbo服務交互中間件技術[3]，從阿里社區晉升為Apache頂級，目前最新的DubboMesh也在Service Mesh領域中發展迅猛。諸如此類型的技術的引入，讓每個服務團隊可更專注於自己業務領域的拓展與迭代。
2015 年 Pivotal 公司的 MattStine 寫了一本叫做《遷移到雲原生應用架構》的文章，第一次提出了雲原生(CloudNative)的概念。Pivotal 不但是雲原生應用的提出者，同時推出了 PivotalCloud Foundry 雲原生應用平臺和Spring 開源 Java 開發框架，成為雲原生應用架構中先驅者和探路者。目前公認的雲原生生態圈由微服務（輕量級HttpApi接口）、DevOps（部署運維平臺）、持續交付、容器化（Docker）四個層面組成。由此可見微服務作為核心的重要性。
微服務架構可以幫助企業級應用對於業務的分解更聚焦、功能迭代更快速、減少開發的複雜性、降低資源消耗等，對於功能點眾多、業務邏輯複雜的大型系統，採用微服務架構升級後可提高系統開發效率與容錯性，便於集群擴展。此外服務的單獨部署，讓持續集成成為可能，對敏捷開發概念的落地提供了極大的幫助。
本篇文章從三個部分展開，第一部分介紹當前研究的背景及微服務架構優勢；第二部分通過比較使用的中間件性能測試結果，分析測試報告，證明目前框架升級用到的核心技術的優勢；第三部分分享架構升級過程的RoadMap，最終總結現有工作，展望未來發展。
一、相關研究
微服務架構是把原來的一個提供N種服務的應用模塊劃分為若干個獨立的服務模塊，原來應用的所有服務功能由這些服務模塊分別實。每一個微服務都是一個相對獨立的個體，由專門的開發團隊獨立開發、測試、部署，至於技術棧的選取完全取決於微服務模塊，不必考慮其他服務及後期集成、部署等問題，在表現層，所有微服務發佈為REST風格接口。
由於REST風格是基於HTTP協議的網絡層接口格式，在數據交互的性能上存在一定的網絡抖動與效率問題[4]。傳統的RPC調用方式也在大部分微服務實踐中廣泛使用，成為併發量大、時效要求高情景下的成熟解決方案[5]，這也造就了NIO在現有技術生態中成為核心支柱。
微服務的細粒度導致服務管理存在的碎片化問題。目前NetFlix、HashiCorp、Alibaba等公司開發的註冊中心中間件，旨在解決服務管理的問題，保證可監控、可維護、可追溯。從而保證分佈式部署下負載均衡的動態調配，增加軟件體系的靈活性和時效性[6]。
碎片化的問題同時導致這些細小的API，如何進行授權、限流管控、熔斷？如何進行網絡接入？如何進行合理的治理這些API服務？服務網關旨在解決以上問題，API Gateway做為系統統一入口，實現對各個微服務間的整合，同時又做到了對客戶端友好，屏蔽系統的複雜性和差異性。
二、關鍵技術比較
2.1 網關技術比較
2.1.1 網關簡介
微服務化是當前一大趨勢，API網關是僅次於註冊中心的存在[7]，不僅可以作為所有微服務的單一入口點，更可以分離出API令牌的授權、訪問控制實施、速率限制、日誌記錄監控等功能。
當前對API網關組件的調研維度如下：社區生態熱度、易用性、路由轉發及過濾器性能、當前維護狀態及特點等。
2.1.2 主流網關類型、特點以及測試結果
當前主流網關共有三種：Gateway，Zuul，Nginx。從定位來看，我們比較傾向於把Nginx定位為承載請求轉發的工具，因此從技術層面的角度來說，對於自定義需求的可擴展性的支持上並不是很理想。所以在產品上我們只進行Gateway和Zuul的比較。
表2.1 Gateway與Zuul對比表
基於以上調研對比結果，對Gateway、Zuul、Nginx在用默認配置下，分別以Rest接口，進行高併發和低併發的比對後可以得出：
低併發（500）下三者的差距是在4ms可接受範圍內的，Gateway和Zuul表現更佳。
圖2.1 500線程併發對比圖
高併發（6000）下，Gateway和Zuul的響應時間更短，平均在200ms-300ms。
圖2.2 6000線程併發對比圖
基於圖、表結果，首先Gateway的社區熱度高一些，相應文檔多一些；其次根據測試情況，Gateway的性能優於Zuul。除此這兩點外，Gateway的也有很多Zuul沒有的功能，比如支持http2、websocket，域名轉發等[8]。並且Gateway對於做服務轉發，而不是數據庫轉發這種高性能需求上，性能上和Nginx差距不大，所以最終我們的選擇是Gateway。
2.2 註冊中心技術比較
2.2.1 註冊中心簡介
服務註冊中心往往隱藏在服務框架背後，作為默默支持的產品[9]。優秀的服務框架支持多種配置中心，但是註冊中心的選擇依然強關聯與服務框架，現在普遍的情況是一種服務框架會帶一個默認的服務註冊中心。ZooKeeper就是一款經典的服務註冊中心產品，在很長一段時間裡，它是國人在提起RPC服務註冊中心時心裡想到的唯一選擇，這很大程度上與Dubbo在中國的普及程度有關。
2.2.2 主流注冊中心類型、特點以及測試結果
當前主流注冊中心為：Nacos，Eureka，Consul以及ZooKeeper。
由於Nacos和ZooKeeper可以無縫對接dubbo，更符合本平臺需求，所以本文只針對Nacos和ZooKeeper進行分析比對。
表2.2 Nacos與ZooKeeper對比表
通過Nacos和ZooKeeper在dubbo接口的性能的對比測試結果中，發現Nacos負載更為均衡，性能更優一些。
圖2.3 dubbo+nacos負載對比圖
圖2.4 dubbo+zookeeper負載對比圖
其次在CAP 的權衡中，我們認為註冊中心的可用性比數據強一致性更寶貴[10]，所以整體設計更應該偏向 AP，而非 CP，數據不一致在可接受範圍，而 P 下捨棄 A 卻完全違反了註冊中心不能因為自身的任何原因破壞服務本身的可連通性的原則。
而且ZooKeeper的寫是不可擴展的，當註冊節點一定時，寫性能會是瓶頸，發佈應用時會出現排隊現象，它又不可以通過加節點解決水平擴展性問題。這也不符合我們對於平臺未來的期望值。
綜上，我們最終的選擇是Nacos+Dubbo作為高併發壓力下的服務通信模型。
三、案例分享
3.1 微服務化歷程
回顧數據治理平臺的微服務改造RoadMap目前分為兩個個階段。
圖3.1 數據治理路線圖
階段一解決代碼衝突較高、產品維護不方便等問題，但由於當時業務需求較多，技術棧升級較難。因此只是將產品工程由傳統web項目改造為maven管理；由平臺分解為產品線並通過svn獨立管理；引入Servlet3.0特性解決模塊化問題，並開發周邊服務，保障各產品線可獨立發佈、應用可界面化部署、運行庫可獨立升級等。階段一為“代碼治理”。
圖3.2 階段一SVN工程分解圖
階段二解決框架老化導致維護成本過高、資源調優參數不合理、部署建議不具備等痛點。翻新底層框架進入SpringBoot2.X時代；引入服務網關、註冊中心等中間件技術；服務通信整合Dubbo與Rest共存方式；代碼使用Git集中管理。階段二為“服務治理”。
圖3.3 階段二GIT工程分解圖
3.2 框架改造成果
基於第二章核心技術的測試結果與分析報告，現階段微服務化後的產品部署邏輯如下。
圖3.4 部署邏輯圖
圖中描述兩種用戶使用平臺的方式與兩種應用間通信方式。
登錄用戶通過NG代理後的網關地址進行訪問，該請求經過登錄驗權，角色功能驗權，操作日誌審計過濾後，再通過網關路由到對應的後臺AppService，從而完成本次請求。如此次請求過程需要獲取非當前的用戶信息，則由所屬的AppService自行通信門戶獲取。
非登錄用戶通過接口簽名的驗證方式，保證請求路徑的一致性，從而滿足第三方廠商對安全紅線的硬性要求。
應用間訪問方式分為Rest方式與高併發的Rpc方式，滿足大數據壓力下應用的健壯性，如6000個調度流程同時啟動，從章節2的壓力測試結果下也能看出，Rpc調用方式的必要性。
本次微服務化的技術選型，充分評估了SpringBoot2.X升級風險，並改造Beaf模塊，最終確定Nacos引入的必要性，從而完成該階段下的框架改造。
3.3 核心產品分解
本節分別舉例數據治理平臺中的兩個經典產品線BMM（元數據）與BUW（ETL調度器）。進一步介紹微服務框架在產品中落地情況。
下圖為BUW應用結構。目前BUW共分為三個App，流程管理、調度執行器、任務執行器。該結構的確定來自於聯通總部、山西試點、移動與智慧城市等項目落地數據治理產品後，對ETL性能指標的要求。
拆分成三個應用可有效的保證諸如內存溢出、數據庫死鎖、資源佔用率篩查等問題的更精確定位，減少單點故障問題。但目前調度器與執行器上由於數據量過大，存在數據交互的壓力，傳統的Http方式，在響應延遲上不能滿足現有需求，目前依然保存Dubbo調用。
圖3.5 BUW應用與調用關係圖
下圖為BMM應用結構。目前BMM共分為三個App，元數據中心、元數據應用管理、元數據資產管理。該產品的微服務拆分思想，以元模型為驅動並作為服務組件化的最小單元，在滿足最小集元數據中心App的構建下；探索元數據能力，匯聚元數據應用管理APP；並基於多維度盤點、靈活的檢索與溯源能力，構建出元數據資產管理App。元數據之間請求相對獨立，因此在應用間調用關係中使用Rest風格接口。
圖3.6 BMM應用與調用關係圖
以上兩個產品結構均為數據治理平臺新版本框架下的應用結構，本節通過列舉產品邏輯圖，描述微服務下的組件間層次結構。
3.4 總結與展望
通過技術調研與測試結果分析，我們看到了技術並無絕對，只有更適用，由於國外社區對技術的閉環，本次改造另闢蹊徑並結合大量測試報告，摸索出屬於BONC自身特色的數據治理微服務。
下一步我們將考慮微服務在自動化部署下采用不同的策略、工具和雲服務管理器的評估，後續工作還包括，數據庫可視化部署、異構數據分佈、服務版本控制、流量控制及微服務的可靠性保證等。
四、參考文獻
[1] 劉琦 基於雲原生應用平臺實現應用服務可造性[J] 2019-03-10
[2] 鄭冰 基於微服務架構的系統設計與應用[J] 2019-09-04
[3] 陶先平;馬曉星;呂建;餘萍;周宇 軟件服務多模式交互中間件模型及其支撐技術[J] 2008-04-15
[4] 王萌;王翾 網絡抖動實時測量方法的實現與對比[J] 2016-02-29
[5] 王紀臣 異步RPC的設計與實現[J]2005-04-29
[6] 曾冠東 基於MINA構建簡單高性能的NIO應用[J] 2008-02-01
[7] 齊勇;趙季中;侯迪;沈鈞毅;曾斌異 基於Web的中間件系統集成框架——應用服務器的研究[J]2001-04-15
[8] 譚一鳴 基於微服務架構的平臺化服務框架的設計與實現[J] 2017-06-01
[9] 陶明 一種分佈式服務框架的設計與實現[J] 2013-03-08
[10] 孟小峰; 慈祥 大數據管理:概念、技術與挑戰[J] 2013-01-10
福利：關注本公眾號（ID：turingtopia）
特別推薦
如果您對工業互聯網、數據中臺、精準營銷、智能推薦、人臉識別等業務經驗和AI應用感興趣，就來@派小僧 吧！
一線專家給你：
最全面的趟坑總結；
最前沿的實踐經驗；
最新落地的行業應用案例。
立即關注，一網打盡！
（ID：python_daydayup）
1.《基於深度學習的命名實體識別算法》：
https://mp.weixin.qq.com/s/PECrDEL3l_IGPzIxDyDxjQ
2.《從理論到案例，一文讀懂微服務》：
https://mp.weixin.qq.com/s/aZ3L7amcFsLyWZUwmdO3Bg
3.《新零售業務中臺在互聯網化轉型的應用》：
https://mp.weixin.qq.com/s/qIfvDyGCC1ph0gza52-OXA
4.《淺析分佈式計算模型的發展變化》：
https://mp.weixin.qq.com/s/why798vQyRviSrDp75wLrg
5.《通俗解析工業互聯網平臺》：
https://mp.weixin.qq.com/s/_mjXkFHlmcWg-FCoern0FA
6.《大數據精準營銷平臺的挑戰與創新》：
https://mp.weixin.qq.com/s/yn_yFHE5toTa1vDs3fHGTQ
7.《基於MR指紋的多維數據融合定位》：
https://mp.weixin.qq.com/s/7gpo57lsBO0Dj-5EkbEqCQ
8.《跨平臺移動端框架UniApp的應用實踐》：
https://mp.weixin.qq.com/s/ToYoszmG5jctvGx8tHGMFg
9.《MYSQL高可用—解決紅包雨》：
https://mp.weixin.qq.com/s/Xogq6UMXSsQhpggYn4Wruw
10.《淺談JVM和常用GC策略》：
https://mp.weixin.qq.com/s/VY4EXKHEU5yZPB1jYPQr3Q
11.《Protobuf在廣告競價中的應用》：
https://mp.weixin.qq.com/s/lKYJ987KAEBOo5WwU6vcCw
12.《基於微服務框架下策略模式的應用》：
https://mp.weixin.qq.com/s/XEP7yip6VVmBdbtCduqGLA
13.《利用EOS技術實現確權中心平臺功能》：
https://mp.weixin.qq.com/s/Dnt0m4qFRlViCS-QTuyUPQ
14.《ElasticSearch技術主題》：
https://mp.weixin.qq.com/s/-g-eyAN7tIp27f8jDofF7A
15.《深度學習經典網絡—GAN》：
https://mp.weixin.qq.com/s/p66bmDFmr-81Uv6M1804gw
16.《對Memory Mapped File和SendFile的研究》：
https://mp.weixin.qq.com/s/-AitNRSt8UgsnHO9s4bteg
17.《主數據在港口行業的應用》：
https://mp.weixin.qq.com/s/GalaatGX1E0enNbLCxW9HA
閱讀更多 圖靈聯邦 的文章
