基于開源框架及容器技術(shù)的微服務(wù)架構(gòu)研究

摘要：隨著軟件系統(tǒng)越來越龐大，單點(diǎn)應(yīng)用模式無法適應(yīng)大型企業(yè)軟件的開發(fā)與部署，為了解決日益增加的應(yīng)用復(fù)雜度，迫切需要引入微服務(wù)架構(gòu)。文中使用開源框架和容器技術(shù)進(jìn)行微服務(wù)開發(fā)，將服務(wù)統(tǒng)一發(fā)布、自動(dòng)化構(gòu)建、獨(dú)立分發(fā)等微服務(wù)組件應(yīng)用在實(shí)際生產(chǎn)環(huán)境中，這種微服務(wù)架構(gòu)具有學(xué)習(xí)成本低、使用簡單、高可移植性、易于測試、性能高、部署簡單和易于監(jiān)控的特點(diǎn)。實(shí)踐證明，微應(yīng)用架構(gòu)不但對開發(fā)人員屏蔽了技術(shù)細(xì)節(jié)，還提高了開發(fā)人員對業(yè)務(wù)的關(guān)注度，提升了開發(fā)效率，具有較高的參考和推廣價(jià)值。

關(guān)鍵詞：微服務(wù)；微應(yīng)用；容器；服務(wù)發(fā)現(xiàn)；服務(wù)注冊

作者：劉輝軍，劉培鋒，邱鈺鋒，戴桂灶

（遠(yuǎn)光軟件股份有限公司)

0引言

微服務(wù)（Microservices） 是目前業(yè)界非常受歡迎的架構(gòu)模式，企業(yè)和服務(wù)提供商正在尋找更好的方法將應(yīng)用程序部署在云環(huán)境中，微服務(wù)被認(rèn)為是未來的方向。通過將應(yīng)用分解成更小的、松散耦合的微服務(wù)，這些微服務(wù)更加容易升級和擴(kuò)展，主要特點(diǎn)如下。

1）學(xué)習(xí)成本低：學(xué)習(xí)和入門成本比較低，可以即學(xué)即用；學(xué)習(xí)準(zhǔn)備不會(huì)花費(fèi)太長時(shí)間。

2）使用簡單：微服務(wù)開發(fā)樣例清晰，很容易上手，不會(huì)出現(xiàn)開發(fā)一個(gè)簡單的樣例比開發(fā)一個(gè)功能還艱難。

3）高可移植性：微服務(wù)體量較小，功能較單一，這使得移植工作更容易。

4）易于測試：微服務(wù)依賴比較少，主要聚焦在功能測試，由于功能單一，代碼對測試友好，無需過度測試。

5）高性能：不會(huì)出現(xiàn)性能瓶頸，引入的相關(guān)依賴很小。

6）部署簡單：微服務(wù)相關(guān)應(yīng)用可以獨(dú)立進(jìn)行開發(fā)和部署，使用微服務(wù)架構(gòu)和平臺(tái)，這些應(yīng)用的部署和功能交付將非常簡單。

7）易于監(jiān)控：完善的日志記錄，出現(xiàn)問題能被監(jiān)控、告警，對系統(tǒng)運(yùn)行狀態(tài)及各種指標(biāo)能隨時(shí)掌握。

8）易于運(yùn)維：對突發(fā)事件有運(yùn)維調(diào)度能力，防止雪崩效應(yīng)。能夠?qū)ο到y(tǒng)進(jìn)行彈性三維伸縮，快速開啟和優(yōu)雅關(guān)閉等。

1　微服務(wù)架構(gòu)

1.1　微服務(wù)架構(gòu)優(yōu)點(diǎn)

首先，微服務(wù)架構(gòu)本身就是一個(gè)化繁為簡的過程。傳統(tǒng)軟件架構(gòu)是集中部署一套大的Web 應(yīng)用，將各類服務(wù)方法集中到整個(gè)應(yīng)用中，所有的開發(fā)者都在一個(gè)整體應(yīng)用環(huán)境下開發(fā)各個(gè)功能模塊。微服務(wù)架構(gòu)開創(chuàng)了全新的理念，提供了系統(tǒng)的模塊化的解決方案，該架構(gòu)將整個(gè)系統(tǒng)的每個(gè)服務(wù)方法單獨(dú)拆解出來，獨(dú)立成一個(gè)模塊，這樣拆解每個(gè)服務(wù)單獨(dú)開發(fā)、部署和測試，大大提高擴(kuò)展性與可維護(hù)性。

其次，微服務(wù)架構(gòu)是一個(gè)技術(shù)創(chuàng)新的過程，由于每個(gè)服務(wù)獨(dú)立，這就可以使服務(wù)實(shí)現(xiàn)的技術(shù)更加靈活，不拘束原有的技術(shù)實(shí)現(xiàn)，可以自由選擇最新技術(shù)，只要對外保持一致的服務(wù)即可。

再次，微服務(wù)部署簡單快速。由于每個(gè)服務(wù)都是獨(dú)立的，體量較小，每個(gè)服務(wù)可以單獨(dú)部署，可以告別整套系統(tǒng)應(yīng)用部署的尷尬局面，更加靈活快速地部署到位。

最后，微服務(wù)架構(gòu)是具有高性能的分布式架構(gòu)模式。微服務(wù)中每個(gè)服務(wù)都是獨(dú)立部署，部署時(shí)可以按需部署分布，可以選擇適合服務(wù)部署的軟件環(huán)境與硬件資源。

1.2　微服務(wù)架構(gòu)不足

微服務(wù)架構(gòu)的每個(gè)服務(wù)是獨(dú)立的、分布的，給服務(wù)間的通信與服務(wù)的管理帶來挑戰(zhàn)，開發(fā)者要編寫代碼實(shí)現(xiàn)不同服務(wù)間的進(jìn)程或網(wǎng)絡(luò)通信，同時(shí)，要面對不同服務(wù)間通信所帶來的問題，如網(wǎng)絡(luò)時(shí)延、網(wǎng)絡(luò)故障等問題，這相對一個(gè)大系統(tǒng)內(nèi)的不同服務(wù)通信略顯復(fù)雜。

微服務(wù)架構(gòu)的每個(gè)服務(wù)都是獨(dú)立的，允許采用不同的語言來實(shí)現(xiàn)、不同的數(shù)據(jù)庫存儲(chǔ)，這樣對數(shù)據(jù)庫架構(gòu)要求也很高。針對數(shù)據(jù)時(shí)效要求高、更新頻度高的業(yè)務(wù)場景，由于要針對不同的服務(wù)實(shí)現(xiàn)，更新不同數(shù)據(jù)庫中的數(shù)據(jù)，勢必是一個(gè)挑戰(zhàn)，要求數(shù)據(jù)庫支持分布性。因此，設(shè)計(jì)人員與開發(fā)人員在微服務(wù)的設(shè)計(jì)與技術(shù)選型上要考慮分布式的問題，需要相關(guān)人員有一定的技術(shù)積累。

微服務(wù)架構(gòu)的測試，由于分布式與獨(dú)立的特點(diǎn)，需要針對不同的服務(wù)進(jìn)行測試，相比傳統(tǒng)集中式部署的風(fēng)格，測試的復(fù)雜度提高。

1.3　微服務(wù)架構(gòu)應(yīng)用場景

通常來講單體應(yīng)用是更好的選擇，對于簡單和中等復(fù)雜程度的應(yīng)用，無論是長期還是短期來看其成本開銷都好于微服務(wù)架構(gòu)，但對于非常復(fù)雜的應(yīng)用，微服務(wù)架構(gòu)長期來看會(huì)有回報(bào)，但是需要經(jīng)歷很長時(shí)間來彌補(bǔ)前期的巨大投資。如果企業(yè)出現(xiàn)了下面的問題，則可以嘗試采用微服務(wù)架構(gòu)進(jìn)行應(yīng)用設(shè)計(jì)。

1）開發(fā)一個(gè)應(yīng)用需要100 個(gè)以上開發(fā)者。

2）應(yīng)用的源代碼超過10 M。

3）需要按照月份或者季度發(fā)布應(yīng)用。

1.4　架構(gòu)抉擇

微服務(wù)架構(gòu)并不是萬能的，不能解決全部問題，而且沒有一種開發(fā)模式，在技術(shù)和管理領(lǐng)域，可以承諾在10 年內(nèi)，無論是生產(chǎn)效率、可靠性還是簡化程度可以領(lǐng)先其他技術(shù)一個(gè)數(shù)量級，所以需要根據(jù)實(shí)際的應(yīng)用業(yè)務(wù)需求結(jié)合未來的發(fā)展趨勢，做相應(yīng)的抉擇，選擇最適合自己的軟件架構(gòu)。

2　ECP 微服務(wù)架構(gòu)平臺(tái)介紹

遠(yuǎn)光企業(yè)云平臺(tái)(Enterprise Cloud Platfrom，ECP) 微服務(wù)架構(gòu)平臺(tái)滿足下列要求。

1）微服務(wù)開發(fā)：允許使用各種語言/ 工具/ 框架開發(fā)微服務(wù)；在Java EE/Spring 體系的微服務(wù)開發(fā)中可以復(fù)用其他ECP 基礎(chǔ)服務(wù)；考慮已有的企業(yè)應(yīng)用系統(tǒng)（財(cái)務(wù)管控）接入方式。

2）微服務(wù)調(diào)用：服務(wù)發(fā)現(xiàn)、負(fù)載均衡、限流與容錯(cuò)、不同語言/ 框架都可以支持的調(diào)用方式等。

3）微服務(wù)管理與監(jiān)控：提供微服務(wù)運(yùn)行環(huán)境，支持?jǐn)U容縮容、運(yùn)行時(shí)監(jiān)控、錯(cuò)誤追蹤等。

2.1　基本目標(biāo)

ECP 微服務(wù)架構(gòu)平臺(tái)的最初目標(biāo)主要包括：

1）服務(wù)調(diào)用：依托服務(wù)注冊與發(fā)現(xiàn)機(jī)制，通過反向代理實(shí)現(xiàn)動(dòng)態(tài)的負(fù)載均衡；

2）服務(wù)監(jiān)控：提供必要的服務(wù)監(jiān)控能力，即便不是應(yīng)用級的服務(wù)監(jiān)控（調(diào)用次數(shù)、平均耗時(shí)等），也需要系統(tǒng)級的服務(wù)運(yùn)行狀態(tài)監(jiān)控（當(dāng)前服務(wù)實(shí)例個(gè)數(shù)以及每個(gè)服務(wù)實(shí)例CPU/ 內(nèi)存/ 網(wǎng)絡(luò)等系統(tǒng)資源占用情況）。

2.2　微服務(wù)調(diào)用

案例實(shí)現(xiàn)的微服務(wù)架構(gòu)運(yùn)行時(shí)，服務(wù)調(diào)用相關(guān)的技術(shù)方案實(shí)現(xiàn)方式如下。

1）所有微服務(wù)均暴露為Rest API，任何語言/框架均可以用來實(shí)現(xiàn)微服務(wù)；同時(shí)所有對微服務(wù)的調(diào)用都是直接訪問Rest API，無需針對不同的語言/框架提供相應(yīng)的API；

2）服務(wù)注冊：每個(gè)微服務(wù)啟動(dòng)時(shí)向注冊中心進(jìn)行自注冊。負(fù)載均衡：反向代理（負(fù)載均衡器）通過注冊中心動(dòng)態(tài)感知微服務(wù)變化情況，并基于微服務(wù)示例運(yùn)行狀態(tài)動(dòng)態(tài)更新自己的負(fù)載均衡策略；服務(wù)發(fā)現(xiàn)：微服務(wù)客戶端（包括遠(yuǎn)程客戶端和集群內(nèi)的微服務(wù)）以固定地址訪問所需微服務(wù)對應(yīng)的反向代理（負(fù)載均衡器），無需關(guān)心反向代理（負(fù)載均衡器）后面的微服務(wù)運(yùn)行狀態(tài)。在上述方案中沒有網(wǎng)關(guān)（API Gateway）的存在，但此方案中的反向代理（負(fù)載均衡器）可以在后期被API Gateway 取代，在提供上述功能的同時(shí)，并不對微服務(wù)的調(diào)用方產(chǎn)生影響。

通過HTTP+REST 對開發(fā)使用友好。但是治理起來較困難，連接無狀態(tài)，以及附帶的服務(wù)端推送、調(diào)用鏈路監(jiān)控埋點(diǎn)等，增強(qiáng)了系統(tǒng)的附加能力，對調(diào)用方提出了新的要求。綜合來看，遠(yuǎn)程方法調(diào)用(Remote Procedure Call，RPC) 從性能、契約優(yōu)先來說具有優(yōu)勢，引入gateway 層，讓REST 與RPC 的優(yōu)點(diǎn)進(jìn)行融合，在gateway 層提供REST 的接入能力。

2.3　微服務(wù)監(jiān)控

運(yùn)行環(huán)境基于容器集群管理產(chǎn)品/ 項(xiàng)目，通過運(yùn)行環(huán)境實(shí)現(xiàn)下列功能。

1）統(tǒng)一軟件交付形式：以鏡像作為軟件交付形式，便于DevOps的實(shí)施；

2）支持?jǐn)U容縮容：基于容器集群實(shí)現(xiàn)微服務(wù)擴(kuò)容縮容，甚至實(shí)現(xiàn)自動(dòng)擴(kuò)容縮容；

3）運(yùn)行時(shí)監(jiān)控：可以通過容器集群實(shí)現(xiàn)容器運(yùn)行狀態(tài)監(jiān)控，當(dāng)容器與服務(wù)一一對應(yīng)時(shí)，容器運(yùn)行狀態(tài)可以被認(rèn)為近似于服務(wù)運(yùn)行狀態(tài)。

3　微服務(wù)實(shí)踐

上述微服務(wù)運(yùn)行環(huán)境依賴容器集群管理，建議選擇Google Kubernetes或者DaoCloud 產(chǎn)品實(shí)現(xiàn)。

3.1　微服務(wù)開發(fā)

微服務(wù)可以通過各種協(xié)議暴露其接口，并允許使用任何語言/ 框架實(shí)現(xiàn)?；贓CP 微服務(wù)架構(gòu)平臺(tái)只開發(fā)包含符合下列特征的微服務(wù)：服務(wù)接口為基于http(s) 的Rest API；語言/ 框架基于Java EE/Spring OSGi 體系。

另外，所有Rest API 都應(yīng)該滿足分布式部署（實(shí)現(xiàn)無狀態(tài)）并保證業(yè)務(wù)功能正確（最終一致性）。

3.1.1　基于ECP 平臺(tái)(OSGi) 的微服務(wù)架構(gòu)

基于ECP 平臺(tái)OSGi 版本的軟件開發(fā)工具包(Software Development Kit，SDK) 微服務(wù)，就是將Rest Controller 暴露為微服務(wù)（Rest API），但通過ECP 平臺(tái)SDK 實(shí)現(xiàn)微服務(wù)，有下列優(yōu)勢：

1）重用ECP 中涵蓋的基礎(chǔ)設(shè)施（消息、緩存、調(diào)度、流程等），無需自行集成這些能力；

2）簡化安全認(rèn)證：微服務(wù)所需的安全認(rèn)證機(jī)制，可以重用。

與此對應(yīng)，基于ECP 微服務(wù)架構(gòu)開發(fā)的微服務(wù)將被構(gòu)建為war，需要打包部署到Java EE Servlet 容器中（Tomcat/Jetty 等）。

3.1.2　基于ECP 平臺(tái)(Spring Boot) 的微服務(wù)架構(gòu)

Spring Boot 提供了實(shí)現(xiàn)Rest API 的良好支持，并極大地簡化了配置和部署。在無需Web UI 而僅僅只為了提供Rest API 的情況下，是Java EE/Spring體系下實(shí)現(xiàn)Rest API 的首選框架。

Spring Boot 實(shí)現(xiàn)的Rest API 將被構(gòu)建為jar，其中內(nèi)置了Tomcat/Jetty，可以直接部署運(yùn)行，無需外部的Java EE Servlet 容器。

3.1.3　原有舊系統(tǒng)接入

已有的應(yīng)用系統(tǒng)（如財(cái)務(wù)管控），通常不可能大規(guī)模重構(gòu)為微服務(wù)應(yīng)用系統(tǒng)，還需要復(fù)用已有系統(tǒng)的部分服務(wù)并接入微服務(wù)運(yùn)行環(huán)境。對于此類需求，建議采用下述方法實(shí)現(xiàn)：

基于Spring Boot 實(shí)現(xiàn)微服務(wù)，這些微服務(wù)將調(diào)用已有系統(tǒng)的API 實(shí)現(xiàn)其功能，如果這些服務(wù)有嚴(yán)格的性能要求，也可以直接訪問原系統(tǒng)的數(shù)據(jù)庫實(shí)現(xiàn)這些服務(wù)?？傊?，新實(shí)現(xiàn)的微服務(wù)進(jìn)行接入，這些微服務(wù)的實(shí)現(xiàn)依賴已有系統(tǒng)，這些微服務(wù)適配已有系統(tǒng)的功能進(jìn)行接入。

3.1.4　服務(wù)接口演化

在日常開發(fā)的過程中，服務(wù)端對外開放的接口API 會(huì)有一個(gè)變化的過程。

單體應(yīng)用處理服務(wù)端接口的變化，直接修改對應(yīng)的接口，然后再修改所有接口的調(diào)用即可。

微服務(wù)對于接口變化的處理，由于各個(gè)微服務(wù)的獨(dú)立性，很難實(shí)時(shí)更新服務(wù)調(diào)用實(shí)現(xiàn)。在這種情況下，在不影響原有調(diào)用又要提供新的服務(wù)供調(diào)用的前提下，服務(wù)的提供者有可能提供2 套服務(wù)，一套是新的接口API 服務(wù)；另一套是舊的API 服務(wù)。

當(dāng)微服務(wù)的發(fā)布者對原接口進(jìn)行修改時(shí)，考慮的是改動(dòng)的大小及舊的服務(wù)API 的兼容性。進(jìn)程間使用輕量級通信機(jī)制進(jìn)行通信對接口改造幫助很大，建議使用在最初的設(shè)計(jì)過程中，每個(gè)服務(wù)的設(shè)計(jì)都遵循健壯性的原則，比如：只是對某個(gè)特定場景設(shè)計(jì)API，調(diào)用API 的服務(wù)使用舊的接口，能同時(shí)兼容調(diào)用新的接口一起工作，API 服務(wù)仍然提供原有的默認(rèn)響應(yīng)值，調(diào)用服務(wù)忽略即可。有時(shí)接口改造涉及的改動(dòng)很大并且與舊接口不兼容，由于不能強(qiáng)制所有調(diào)用服務(wù)進(jìn)行升級，所以存在新老服務(wù)并存的情況，服務(wù)端調(diào)用會(huì)針對新老不同API 服務(wù)，這就要求服務(wù)的API 具有多版本概念，針對不同調(diào)用進(jìn)行處理。

3.2　微服務(wù)部署

微服務(wù)架構(gòu)是由一組小但是獨(dú)立的服務(wù)組成，各服務(wù)有獨(dú)立的進(jìn)程，需要獨(dú)立部署，服務(wù)部署需要快速、可靠并且性價(jià)比高。選擇基于容器部署的方式能滿足上述需求，ECP 微服務(wù)部署架構(gòu)如圖1 所示。

圖1 ECP 微服務(wù)部署架構(gòu)

3.2.1　基于Google Kubernetes 架構(gòu)

Google Kubernetes 提供了完整的微服務(wù)運(yùn)行環(huán)境，完全滿足前述微服務(wù)調(diào)用、微服務(wù)管理與監(jiān)控的要求。

1）API Server/etcd：作為注冊中心，微服務(wù)實(shí)例將在其中注冊；

2）kube-proxy：實(shí)現(xiàn)反向代理，能夠自動(dòng)根據(jù)服務(wù)實(shí)例的運(yùn)行狀態(tài)調(diào)整其代理策略；

3）通過Kubernetes Service 定義，保證集群中指定Service 的實(shí)例數(shù)量；

4）具備完整的容器運(yùn)行狀態(tài)監(jiān)控能力。

Kubernetes 提供了完整的微服務(wù)架構(gòu)實(shí)現(xiàn)方案，但其概念及實(shí)現(xiàn)方式與原生的Docker解決方案并不一致，與Docker 版本的更新時(shí)間上不同步。

3.2.2　基于DaoCloud DCE 架構(gòu)

DaoCloud 提供的運(yùn)行環(huán)境以及集群監(jiān)控能力能滿足前述基本目標(biāo)中監(jiān)控相關(guān)的要求。

DaoCloud 基于原生Docker 提供容器集群管理方案，僅作為容器管理產(chǎn)品使用，自動(dòng)的服務(wù)發(fā)現(xiàn)和負(fù)載均衡需要通過HAProxy+etcd 自行實(shí)現(xiàn)。

因此具體實(shí)現(xiàn)為：

1）微服務(wù)調(diào)用均通過HAProxy 進(jìn)行，HAProxy作為反向代理（負(fù)載均衡器）；

2）etcd 作為注冊中心；

3）每個(gè)微服務(wù)啟動(dòng)時(shí)向etcd 注冊；

4）HAProxy 自動(dòng)發(fā)現(xiàn)etcd 中微服務(wù)實(shí)例的變化并透明代理。

3.3　微服務(wù)研發(fā)過程

微服務(wù)架構(gòu)模式容易實(shí)現(xiàn)敏捷開發(fā)，將開發(fā)和運(yùn)維高度協(xié)調(diào)，提高生產(chǎn)率。通過流程和工具自動(dòng)化，更敏捷的交付產(chǎn)品。ECP 微服務(wù)持續(xù)交付過程如圖2 所示。

3.4　成果展現(xiàn)

最終通過ECP 微服務(wù)架構(gòu)平臺(tái)，將現(xiàn)有應(yīng)用的基礎(chǔ)組件拆分為多個(gè)微服務(wù)，如緩存服務(wù)、消息服務(wù)、調(diào)度服務(wù)、非結(jié)構(gòu)化服務(wù)、流程服務(wù)、接入服務(wù)、配置服務(wù)、認(rèn)證授權(quán)服務(wù)、日志服務(wù)等。各個(gè)服務(wù)自治，服務(wù)之間協(xié)同，所有服務(wù)調(diào)用都使用統(tǒng)一的HTTP 服務(wù)通信框架，達(dá)到標(biāo)準(zhǔn)化。提供開發(fā)者中心和微應(yīng)用發(fā)布中心，實(shí)現(xiàn)了服務(wù)注冊、服務(wù)自動(dòng)發(fā)現(xiàn)、負(fù)載均衡、容錯(cuò)、會(huì)話跟蹤、訪問控制、灰度發(fā)布、數(shù)據(jù)可視化。

圖2 ECP 微服務(wù)持續(xù)交付過程

4　結(jié)語

本文研究微服務(wù)架構(gòu)平臺(tái)實(shí)現(xiàn)，通過ECP微服務(wù)架構(gòu)平臺(tái)快速完成了應(yīng)用源碼構(gòu)建、鏡像打包和應(yīng)用部署，實(shí)現(xiàn)了微服務(wù)的高效運(yùn)營，在該平臺(tái)下，研發(fā)人員可以快速構(gòu)建微服務(wù)。微服務(wù)技術(shù)架構(gòu)和底層實(shí)現(xiàn)代碼全部由平臺(tái)提供，屏蔽了復(fù)雜的技術(shù)細(xì)節(jié)，研發(fā)人員只需要關(guān)注業(yè)務(wù)代碼編寫即可。實(shí)踐證明，該平臺(tái)能夠大幅加快開發(fā)速度，有較高的應(yīng)用價(jià)值。