DQZHAN技術訊：基于開源框架及容器技術的微服務架構研究
摘要：隨著軟件系統越來越龐大，單點應用模式無法適應大型企業(yè)軟件的開發(fā)與部署，為了解決日益增加的應用復雜度，迫切需要引入微服務架構。文中使用開源框架和容器技術進行微服務開發(fā)，將服務統一發(fā)布、自動化構建、獨立分發(fā)等微服務組件應用在實際生產環(huán)境中，這種微服務架構具有學習成本低、使用簡單、高可移植性、易于測試、性能高、部署簡單和易于監(jiān)控的特點。實踐證明，微應用架構不但對開發(fā)人員屏蔽了技術細節(jié)，還提高了開發(fā)人員對業(yè)務的關注度，提升了開發(fā)效率，具有較高的參考和推廣價值。
關鍵詞：微服務；微應用；容器；服務發(fā)現；服務注冊
作者：劉輝軍，劉培鋒，邱鈺鋒，戴桂灶
0引言
微服務（Microservices）是目前業(yè)界非常受歡迎的架構模式，企業(yè)和服務提供商正在尋找更好的方法將應用程序部署在云環(huán)境中，微服務被認為是未來的方向。通過將應用分解成更小的、松散耦合的微服務，這些微服務更加容易升級和擴展，主要特點如下。
1）學習成本低：學習和入門成本比較低，可以即學即用；學習準備不會花費太長時間。
2）使用簡單：微服務開發(fā)樣例清晰，很容易上手，不會出現開發(fā)一個簡單的樣例比開發(fā)一個功能還艱難。
3）高可移植性：微服務體量較小，功能較單一，這使得移植工作更容易。
4）易于測試：微服務依賴比較少，主要聚焦在功能測試，由于功能單一，代碼對測試友好，無需過度測試。
5）高性能：不會出現性能瓶頸，引入的相關依賴很小。
6）部署簡單：微服務相關應用可以獨立進行開發(fā)和部署，使用微服務架構和平臺，這些應用的部署和功能交付將非常簡單。
7）易于監(jiān)控：完善的日志記錄，出現問題能被監(jiān)控、告警，對系統運行狀態(tài)及各種指標能隨時掌握。
8）易于運維：對突發(fā)事件有運維調度能力，防止雪崩效應。能夠對系統進行彈性三維伸縮，快速開啟和優(yōu)雅關閉等。
1微服務架構
1.1微服務架構優(yōu)點
首先，微服務架構本身就是一個化繁為簡的過程。傳統軟件架構是集中部署一套大的Web應用，將各類服務方法集中到整個應用中，所有的開發(fā)人都在一個整體應用環(huán)境下開發(fā)各個功能模塊。微服務架構開創(chuàng)了全新的理念，提供了系統的模塊化的解決方案，該架構將整個系統的每個服務方法單獨拆解出來，獨立成一個模塊，這樣拆解每個服務單獨開發(fā)、部署和測試，大大提高擴展性與可維護性。
其次，微服務架構是一個技術**的過程，由于每個服務獨立，這就可以使服務實現的技術更加靈活，不拘束原有的技術實現，可以自由選擇*新技術，只要對外保持一致的服務即可。
再次，微服務部署簡單快速。由于每個服務都是獨立的，體量較小，每個服務可以單獨部署，可以告別整套系統應用部署的尷尬局面，更加靈活快速地部署到位。
*后，微服務架構是具有高性能的分布式架構模式。微服務中每個服務都是獨立部署，部署時可以按需部署分布，可以選擇適合服務部署的軟件環(huán)境與硬件資源。
1.2微服務架構不足
微服務架構的每個服務是獨立的、分布的，給服務間的通信與服務的管理帶來挑戰(zhàn)，開發(fā)人要編寫代碼實現不同服務間的進程或網絡通信，同時，要面對不同服務間通信所帶來的問題，如網絡時延、網絡故障等問題，這相對一個大系統內的不同服務通信略顯復雜。
微服務架構的每個服務都是獨立的，允許采用不同的語言來實現、不同的數據庫存儲，這樣對數據庫架構要求也很高。針對數據時效要求高、更新頻度高的業(yè)務場景，由于要針對不同的服務實現，更新不同數據庫中的數據，勢必是一個挑戰(zhàn)，要求數據庫支持分布性。因此，設計人員與開發(fā)人員在微服務的設計與技術選型上要考慮分布式的問題，需要相關人員有一定的技術積累。
微服務架構的測試，由于分布式與獨立的特點，需要針對不同的服務進行測試，相比傳統集中式部署的風格，測試的復雜度提高。
1.3微服務架構應用場景
通常來講單體應用是更好的選擇，對于簡單和中等復雜程度的應用，無論是長期還是短期來看其成本開銷都好于微服務架構，但對于非常復雜的應用，微服務架構長期來看會有回報，但是需要經歷很長時間來彌補前期的巨大投資。如果企業(yè)出現了下面的問題，則可以嘗試采用微服務架構進行應用設計。
1）開發(fā)一個應用需要100個以上開發(fā)人。
2）應用的源代碼超過10M。
3）需要按照月份或者季度發(fā)布應用。
1.4架構抉擇
微服務架構并不是萬能的，不能解決全部問題，而且沒有一種開發(fā)模式，在技術和管理領域，可以承諾在10年內，無論是生產效率、可靠性還是簡化程度可以**其他技術一個數量級，所以需要根據實際的應用業(yè)務需求結合未來的發(fā)展趨勢，做相應的抉擇，選擇*適合自己的軟件架構。
2ECP微服務架構平臺介紹
遠光企業(yè)云平臺(EnterpriseCloudPlatfrom，ECP)微服務架構平臺滿足下列要求。
1）微服務開發(fā)：允許使用各種語言/工具/框架開發(fā)微服務；在JavaEE/Spring體系的微服務開發(fā)中可以復用其他ECP基礎服務；考慮已有的企業(yè)應用系統（財務管控）接入方式。
2）微服務調用：服務發(fā)現、負載均衡、限流與容錯、不同語言/框架都可以支持的調用方式等。
3）微服務管理與監(jiān)控：提供微服務運行環(huán)境，支持擴容縮容、運行時監(jiān)控、錯誤追蹤等。
2.1基本目標
ECP微服務架構平臺的*初目標主要包括：
1）服務調用：依托服務注冊與發(fā)現機制，通過反向代理實現動態(tài)的負載均衡；
2）服務監(jiān)控：提供必要的服務監(jiān)控能力，即便不是應用級的服務監(jiān)控（調用次數、平均耗時等），也需要系統級的服務運行狀態(tài)監(jiān)控（當前服務實例個數以及每個服務實例CPU/內存/網絡等系統資源占用情況）。
2.2微服務調用
案例實現的微服務架構運行時，服務調用相關的技術方案實現方式如下。
1）所有微服務均暴露為RestAPI，任何語言/框架均可以用來實現微服務；同時所有對微服務的調用都是直接訪問RestAPI，無需針對不同的語言/框架提供相應的API；
2）服務注冊：每個微服務啟動時向注冊中心進行自注冊。負載均衡：反向代理（負載均衡器）通過注冊中心動態(tài)感知微服務變化情況，并基于微服務示例運行狀態(tài)動態(tài)更新自己的負載均衡策略；服務發(fā)現：微服務客戶端（包括遠程客戶端和集群內的微服務）以固定地址訪問所需微服務對應的反向代理（負載均衡器），無需關心反向代理（負載均衡器）后面的微服務運行狀態(tài)。在上述方案中沒有網關（APIGateway）的存在，但此方案中的反向代理（負載均衡器）可以在后期被APIGateway取代，在提供上述功能的同時，并不對微服務的調用方產生影響。
通過HTTP+REST對開發(fā)使用友好。但是治理起來較困難，連接無狀態(tài)，以及附帶的服務端推送、調用鏈路監(jiān)控埋點等，增強了系統的附加能力，對調用方提出了新的要求。綜合來看，遠程方法調用(RemoteProcedureCall，RPC)從性能、契約優(yōu)先來說具有優(yōu)勢，引入gateway層，讓REST與RPC的優(yōu)點進行融合，在gateway層提供REST的接入能力。
2.3微服務監(jiān)控
運行環(huán)境基于容器集群管理產品/項目，通過運行環(huán)境實現下列功能。
1）統一軟件交付形式：以鏡像作為軟件交付形式，便于DevOps的實施；
2）支持擴容縮容：基于容器集群實現微服務擴容縮容，甚至實現自動擴容縮容；
3）運行時監(jiān)控：可以通過容器集群實現容器運行狀態(tài)監(jiān)控，當容器與服務一一對應時，容器運行狀態(tài)可以被認為近似于服務運行狀態(tài)。
3微服務實踐
上述微服務運行環(huán)境依賴容器集群管理，建議選擇GoogleKubernetes或者DaoCloud產品實現。
3.1微服務開發(fā)
微服務可以通過各種協議暴露其接口，并允許使用任何語言/框架實現?；贓CP微服務架構平臺只開發(fā)包含符合下列特征的微服務：服務接口為基于http(s)的RestAPI；語言/框架基于JavaEE/SpringOSGi體系。
另外，所有RestAPI都應該滿足分布式部署（實現無狀態(tài)）并保證業(yè)務功能正確（*終一致性）。
3.1.1基于ECP平臺(OSGi)的微服務架構
基于ECP平臺OSGi版本的軟件開發(fā)工具包(SoftwareDevelopmentKit，SDK)微服務，就是將RestController暴露為微服務（RestAPI），但通過ECP平臺SDK實現微服務，有下列優(yōu)勢：
1）重用ECP中涵蓋的基礎設施（消息、緩存、調度、流程等），無需自行集成這些能力；
2）簡化**認證：微服務所需的**認證機制，可以重用。
與此對應，基于ECP微服務架構開發(fā)的微服務將被構建為war，需要打包部署到JavaEEServlet容器中（Tomcat/Jetty等）。
3.1.2基于ECP平臺(SpringBoot)的微服務架構
SpringBoot提供了實現RestAPI的良好支持，并極大地簡化了配置和部署。在無需WebUI而僅僅只為了提供RestAPI的情況下，是JavaEE/Spring體系下實現RestAPI的優(yōu)選框架。
SpringBoot實現的RestAPI將被構建為jar，其中內置了Tomcat/Jetty，可以直接部署運行，無需外部的JavaEEServlet容器。
3.1.3原有舊系統接入
已有的應用系統（如財務管控），通常不可能大規(guī)模重構為微服務應用系統，還需要復用已有系統的部分服務并接入微服務運行環(huán)境。對于此類需求，建議采用下述方法實現：
基于SpringBoot實現微服務，這些微服務將調用已有系統的API實現其功能，如果這些服務有嚴格的性能要求，也可以直接訪問原系統的數據庫實現這些服務?？傊?，新實現的微服務進行接入，這些微服務的實現依賴已有系統，這些微服務適配已有系統的功能進行接入。
3.1.4服務接口演化
在日常開發(fā)的過程中，服務端對外開放的接口API會有一個變化的過程。
單體應用處理服務端接口的變化，直接修改對應的接口，然后再修改所有接口的調用即可。
微服務對于接口變化的處理，由于各個微服務的獨立性，很難實時更新服務調用實現。在這種情況下，在不影響原有調用又要提供新的服務供調用的前提下，服務的提供者有可能提供2套服務，一套是新的接口API服務；另一套是舊的API服務。
當微服務的發(fā)布者對原接口進行修改時，考慮的是改動的大小及舊的服務API的兼容性。進程間使用輕量級通信機制進行通信對接口改造幫助很大，建議使用在*初的設計過程中，每個服務的設計都遵循健壯性的原則，比如：只是對某個特定場景設計API，調用API的服務使用舊的接口，能同時兼容調用新的接口一起工作，API服務仍然提供原有的默認響應值，調用服務忽略即可。有時接口改造涉及的改動很大并且與舊接口不兼容，由于不能強制所有調用服務進行升級，所以存在新老服務并存的情況，服務端調用會針對新老不同API服務，這就要求服務的API具有多版本概念，針對不同調用進行處理。
3.2微服務部署
微服務架構是由一組小但是獨立的服務組成，各服務有獨立的進程，需要獨立部署，服務部署需要快速、可靠并且性價比高。選擇基于容器部署的方式能滿足上述需求，ECP微服務部署架構如圖1所示。
圖1ECP微服務部署架構
3.2.1基于GoogleKubernetes架構
GoogleKubernetes提供了完整的微服務運行環(huán)境，完全滿足前述微服務調用、微服務管理與監(jiān)控的要求。
1）APIServer/etcd：作為注冊中心，微服務實例將在其中注冊；
2）kube-proxy：實現反向代理，能夠自動根據服務實例的運行狀態(tài)調整其代理策略；
3）通過KubernetesService定義，保證集群中指定Service的實例數量；
4）具備完整的容器運行狀態(tài)監(jiān)控能力。
Kubernetes提供了完整的微服務架構實現方案，但其概念及實現方式與原生的Docker解決方案并不一致，與Docker版本的更新時間上不同步。
3.2.2基于DaoCloudDCE架構
DaoCloud提供的運行環(huán)境以及集群監(jiān)控能力能滿足前述基本目標中監(jiān)控相關的要求。
DaoCloud基于原生Docker提供容器集群管理方案，僅作為容器管理產品使用，自動的服務發(fā)現和負載均衡需要通過HAProxy+etcd自行實現。
因此具體實現為：
1）微服務調用均通過HAProxy進行，HAProxy作為反向代理（負載均衡器）；
2）etcd作為注冊中心；
3）每個微服務啟動時向etcd注冊；
4）HAProxy自動發(fā)現etcd中微服務實例的變化并透明代理。
3.3微服務研發(fā)過程
微服務架構模式容易實現敏捷開發(fā)，將開發(fā)和運維高度協調，提高生產率。通過流程和工具自動化，更敏捷的交付產品。ECP微服務持續(xù)交付過程如圖2所示。
3.4成果展現
*終通過ECP微服務架構平臺，將現有應用的基礎組件拆分為多個微服務，如緩存服務、消息服務、調度服務、非結構化服務、流程服務、接入服務、配置服務、認證授權服務、日志服務等。各個服務自治，服務之間協同，所有服務調用都使用統一的HTTP服務通信框架，達到標準化。提供開發(fā)人中心和微應用發(fā)布中心，實現了服務注冊、服務自動發(fā)現、負載均衡、容錯、會話跟蹤、訪問控制、灰度發(fā)布、數據可視化。
圖2ECP微服務持續(xù)交付過程
4結語
本文研究微服務架構平臺實現，通過ECP微服務架構平臺快速完成了應用源碼構建、鏡像打包和應用部署，實現了微服務的高效運營，在該平臺下，研發(fā)人員可以快速構建微服務。微服務技術架構和底層實現代碼全部由平臺提供，屏蔽了復雜的技術細節(jié)，研發(fā)人員只需要關注業(yè)務代碼編寫即可。實踐證明，該平臺能夠大幅加快開發(fā)速度，有較高的應用價值。
