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

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

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

（遠光軟件股份有限公司)

0引言

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

1）學習成本低：學習和入門成本比較低，可以即學即用；學習準備不會花費太長時間。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）開發(fā)一個應(yīng)用需要100 個以上開發(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ù)一個數(shù)量級，所以需要根據(jù)實際的應(yīng)用業(yè)務(wù)需求結(jié)合未來的發(fā)展趨勢，做相應(yīng)的抉擇，選擇最適合自己的軟件架構(gòu)。

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

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

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

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

3）微服務(wù)管理與監(jiān)控：提供微服務(wù)運行環(huán)境，支持擴容縮容、運行時監(jiān)控、錯誤追蹤等。

2.1　基本目標

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

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

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

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

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

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

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

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

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

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

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

2）支持擴容縮容：基于容器集群實現(xiàn)微服務(wù)擴容縮容，甚至實現(xiàn)自動擴容縮容；

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

3　微服務(wù)實踐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.4　服務(wù)接口演化

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

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

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

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

3.2　微服務(wù)部署

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2）etcd 作為注冊中心；

3）每個微服務(wù)啟動時向etcd 注冊；

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

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

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

3.4　成果展現(xiàn)

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

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

4　結(jié)語

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