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