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

關鍵詞：微服務；微應用；容器；服務發(fā)現(xiàn)；服務注冊

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

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

0引言

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

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

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

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

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

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

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

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

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

1　微服務架構

1.1　微服務架構優(yōu)點

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

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

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

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

1.2　微服務架構不足

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

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

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

1.3　微服務架構應用場景

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

1）開發(fā)一個應用需要100 個以上開發(fā)者。

2）應用的源代碼超過10 M。

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

1.4　架構抉擇

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

2　ECP 微服務架構平臺介紹

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

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

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

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

2.1　基本目標

ECP 微服務架構平臺的最初目標主要包括：

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

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

2.2　微服務調(diào)用

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

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

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

通過HTTP+REST 對開發(fā)使用友好。但是治理起來較困難，連接無狀態(tài)，以及附帶的服務端推送、調(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　微服務監(jiān)控

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

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

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

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

3　微服務實踐

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

3.1　微服務開發(fā)

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

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

3.1.1　基于ECP 平臺(OSGi) 的微服務架構

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

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

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

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

3.1.2　基于ECP 平臺(Spring Boot) 的微服務架構

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

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

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

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

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

3.1.4　服務接口演化

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

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

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

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

3.2　微服務部署

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

圖1 ECP 微服務部署架構

3.2.1　基于Google Kubernetes 架構

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

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

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

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

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

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

3.2.2　基于DaoCloud DCE 架構

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

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

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

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

2）etcd 作為注冊中心；

3）每個微服務啟動時向etcd 注冊；

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

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

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

3.4　成果展現(xiàn)

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

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

4　結語

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