基于微服務架構的統一應用開發平臺①

李春陽, 劉 迪, 崔 蔚, 李曉珍, 李春岐(國網信息通信產業集團有限公司, 北京 000)(北京中電普華信息技術有限公司, 北京 009)(天津市普迅電力信息技術有限公司, 天津 009)

基于微服務架構的統一應用開發平臺①

李春陽1, 劉 迪2, 崔 蔚1, 李曉珍1, 李春岐31(國網信息通信產業集團有限公司, 北京 100031)2(北京中電普華信息技術有限公司, 北京 100192)3(天津市普迅電力信息技術有限公司, 天津 300192)

隨著信息化時代的發展, 業務系統越發龐大復雜, 系統開發及維護面臨著巨大的挑戰. 針對這一問題,提出基于微服務架構的統一應用開發平臺, 重點介紹了平臺的微服務架構設計、基于平臺的業務系統實現. 通過引入微服務構建和分布式服務注冊等相關技術, 平臺實現了生成微服務工程的標準開發框架, 解決傳統單體架構應用龐大而帶來的研發周期長, 難以快速響應用戶需求等問題, 為業務系統的開發提供了有效支撐.

微服務; 開發平臺; 分布式服務注冊中心

傳統應用架構的弊端最早在大型企業和互聯網行業中呈現, 這些公司都遇到了復雜應用的開發維護成本變高、代碼重復率增大、團隊協作效率變差、系統可靠性變低、系統水平擴展困難、新功能上線周期變長等問題. 因此眾多大型公司經過了反復實踐和嘗試,推出了各種輕量級的架構模式, 有效的解決了上述問題.

國家電網公司目前的業務應用系統是按照傳統應用架構搭建的, 但是隨著企業應用的不斷深化和業務數據的幾何級增長, 業務用戶對應用系統提出了越來越高的要求, 在這樣的背景下傳統的應用架構已無法滿足公司信息化發展的需要, 很多問題已經初露端倪,其中包括: 1)傳統的企業應用代碼龐雜并且業務組件之間耦合程度非常高, 造成了業務應用維護難度大、升級成本高; 2)業務模塊之間的循環依賴、不合理的調用、冗長復雜的業務流程等問題對新功能的上線造成極大影響; 3)系統功能組件出現無法恢復的故障時, 整個節點處于不可用狀態; 4)在擴展性方面, 由于傳統應用大多是單一部署, 在這種模式下一個應用某些部分偏I/O密集型、某些部分卻偏CPU密集型, 但應用卻只部署在一臺機器上, 很難用單一硬件來滿足應用各部分對硬件資源的不同要求, 造成無法高效的應對多用戶高并發的場景等問題.

為解決現階段信息系統建設中存在的問題,本文推出了全面支持微服務的開發框架[1], 可將高度耦合的功能分解到各個離散的微服務中以實現對應用系統的解耦. 該架構全面支持了輕量級嵌入式應用容器、輕量級IOC組件、去中心化的服務注冊中心、高性能的遠程過程調用、應用的追蹤與監控、分布式會話管理、負載均衡策略及應用可靠性保障等特性.

1 平臺簡介

平臺按照“開發標準化、系統模塊化、操作工具化、運行容器化, 應用服務化”的總體目標, 把微服務開發框架、相應的技術和工具整合到平臺中, 平臺主要包括集成開發工具、基礎服務框架、應用開發套件三大功能組件. 總體功能架構如圖1所示.

圖1 平臺功能架構

集成開發工具主要包括可視化界面設計器、編碼與調試輔助工具等與業務系統開發密切關聯的功能組件; 基礎服務框架用于屏蔽大量的底層技術細節,提供了微服務集群管理、遠程過程調用、分布式服務框架、分布式緩存、集中日志等基礎性技術組件; 應用開發套件主要包括MX展現框架、即席報表組件等高級開發套件, 基于這些套件可以快速開發出業務系統功能邏輯, 保障業務系統穩定、高效運行. 本文主要介紹平臺的基礎微服務框架.

2 平臺微服務架構設計

2.1 總體架構

平臺微服務開發框架基于約定優于配置的思想,封裝了支撐微服務構建的組件庫, 不需要繁瑣的配置即可使用Java語言開發微服務. 平臺總體技術架構如圖2所示.

圖2 平臺總體技術架構

平臺基于dropwizard提供微服務開發組件, 以Jetty作為Web容器, 引入Jersey提供標準Restful 風格的Web訪問, 集成Hibernate等數據持久層訪問組件;提供服務注冊發現功能, 自動注冊本地服務到注冊中心; 通過可選的負載均衡策略, 選擇最優的服務地址;提供輕量級的RPC組件調用, 保障高可用的服務調用.

在開發階段根據微服務框架Bundle特性, 能夠實現平臺各模塊的Bundle插件集成到微服務中, 如任務調度、大數據組件、報表和展現框架等.

同時, 平臺提供了去中心化的分布式服務注冊中心[2], 在每個節點上啟動一個注冊中心, 不同節點的多個注冊中心之間沒有主次之分, 降低了注冊中心的壓力, 其中一個注冊中心宕機, 不會影響集群中的其它注冊中心. 針對注冊中心節點的宕機問題, 提供了自動檢測失敗節點機制及周期性地恢復功能, 為注冊中心正常運行提供雙重保障.

2.2 微服務開發框架

2.2.1 微服務工程

微服務工程有三種, 服務生產者, 服務消費者和服務定義接口(API), 服務由接口定義, 服務生產者實現接口服務, 服務消費者來調用. 工程結構[3]如圖3所示.

消費者和生產者微服務通過擴展微服務開發組件實現. 微服務開發組件是對開源微服務組件dropwizard的二次封裝, 除了具有dropwizard提供的特性外, 還封裝了服務注冊, 發現, 刷新, 輕量級RPC,負載均衡. 由以下核心模塊[4]協助完成.

圖3 微服務工程結構

服務實現: 通過自定義注解@MircoService, 將RPC調用,負載均衡做了封裝, API接口的實現類和引用類必須注解為@ MircoService類型.

服務交互監聽器: 平臺提供ServerListener類, 系統啟動時加載該監聽器, 實現服務注冊刷新和發現.

(1) 服務實現

提供注解@Microservice, 將類標記為微服務的業務處理邏輯構件. 標記方式有兩種:

① 作為接口引用的標記

public class TestFrontController {

private static final Logger logger = LoggerFactory.getLogger(Bug4TestFrontController.class;

@MicroService //標記為接口引用的微服務構件

private IBugService service;

}

② 作為接口實現的標記

@MicroService //標記為微服務構件

public class TestService implements ITestService{ private static final Logger logger = LoggerFactory.getLogger(BugService.class);

@Inject

private BackDAO dao;

@Override

public String query(String params) {

return dao.query(params);

}

}

(2) 監聽器ServerListener

ServerListener在系統啟動時加載, 主要有以下功能.

① 服務注冊

發送http請求向服務注冊中心, 注冊服務數據,注冊服務數據為json格式:

{

addr: http//localhost:8080/ms,

Provider:

[com.test.api.service, com.test.api.service2],

Consumer: []

}

微服務如果是生產者, 則provider值不為空, 是消費者, 則Consumer值不為空.

② 服務刷新和發現

定時向注冊中心發送刷新服務請求, 刷新請求返回的是服務的狀態和路由列表, 如果服務狀態為死亡則重新注冊服務, 如果服務正常, 判斷本次路由表校驗碼與本地路由表校驗和是否一致, 不一致更新本地路由表.

2.2.2 去中心化的服務注冊中心

傳統的企業應用架構多采用中心化的分布式服務架構, 一旦服務注冊中心出現問題, 整個系統就會癱瘓; 同時所有應用向一個服務注冊中心進行遠程注冊,會消耗大量的網絡資源, 造成服務注冊中心壓力過大.因此, 平臺采用去中心化的服務注冊中心, 如圖4所示.

圖4 去中心化的服務注冊中心

服務注冊中心封裝了開源分布式集群框架Serf,基于Gossip協議實現集群節點之間進行通信, 同步所有的路由信息; 同時封裝go語言的Web服務框架Gin,實現服務發現[5], 注冊, 刷新的http接口服務, 供微服務和監控應用調用. 節點之間, 以事件的方式提供了信息同步功能, 實現節點信息、路由信息的同步.

(1) 服務注冊

采用Gin Web Framework, 對外提供服務注冊的Restful服務. 接收微服務傳遞來的注冊信息, 包含:微服務訪問地址、提供哪些服務的列表、消費哪些服務的列表, 然后保存到本地的哈稀表中.

接口地址: POST/GET http://注冊中心地址:端口/msd/register

參數:

{

addr:http://192.168.0.245:8082/ms,

providers:[ com.sgcc.uap.hello.api.IHelloService],

consumers:[]

}

返回值: http Code

(2) 服務刷新

服務注冊中心接收到服務發現的Rest請求后, 從本地的哈希表中獲取所有微服務的注冊信息, 拼裝成數組, 然后再對所有注冊信息計算MD5校驗碼, 將數組和校驗碼一并返回. 服務發現器接收返回數據后,將注冊信息數組保存到微服務容器的哈希表中, 作為服務提供者的列表.

接口地址: POST/GET http://注冊中心地址:端口/msd/refresh

參數: 微服務http訪問地址的base64編碼值

返回值:

{

AppStatus:true,

chckNum:h#$!@#@#hweflkj 21dja!$jild;

}

(3) 服務發現

服務注冊中心接收到該Rest請求[6]后, 解碼URL中的地址參數, 去本地的哈希表中查詢該地址是否存在, 如果存在, 服務注冊中心認為該微服務存活, 否則認為微服務已經掉線. 當微服務處于存活狀態時,還要從本地的哈希表中獲取所有微服務的注冊信息后計算MD5校驗碼, 最終將存活狀態信息和校驗碼一并返回. 服務刷新器接收返回數據后, 判斷存活狀態為掉線時, 去調用服務注冊器重新注冊, 然后拿本地保存的校驗碼與返回的校驗碼比對, 不一致時, 表明服務注冊中心的注冊信息發生變化, 調用服務發現器去注冊中心重新獲取, 保證微服務容器的服務提供者列表是最新的數據.

接口地址: POST/GET http://注冊中心地址:端口/msd / fetch

參數: 微服務http訪問地址的base64編碼值

返回值:

{

"service":"com.sgcc.bug.IBugService",

"addrs": [

{"name":"dgo-dev","addr":"http://192.168.20.3:8084/ms" },

{"name":"dgo-dev2","addr":"http://192.168.20.4:8083/m s"}

],

"checksum":"yposdfpapsdfpwerdaf=yxl$3"

}

(4) 節點同步

服務注冊中心節點之間通過Gossip協議進行周期性的消息通信[7], 傳遞節點信息, 保證最終所有節點的路由信息一致. 全局節點狀態信息同步發生在新添加節點、全局同步周期. 報文格式如下:

Version (byte) | Nonce (12 bytes) | CipherText | Tag (16 bytes) | Message Type (4 bytes)

Version: 目前總是設置為0, 允許未來改變報文使用的算法后改變版本值.

Nonce: 隨機數, 保證消息的完整性CiperText: 密文, 消息主體

Tag: 標記, 校驗消息的完整性

Message Type: 信息類型, 使用大端格式(Big Endian format)編碼.

3 平臺實現與應用

3.1 啟動注冊中心

開發微服務之前, 首先要啟動本地注冊中心程序,以支持開發環境中不同微服務之間的通信. 在Windows中執行cmd命令進入Windows控制臺環境,找到平臺提供的blued.exe組件所在的目錄, 輸入命令blued agent啟動微服務環境, 如圖5所示.

圖5 啟動注冊中心

3.2 微服務項目創建及運行

(1) 創建微服務示例項目, 在向導中輸入項目名稱, 并配置數據庫信息, 如圖6所示.

圖6 創建微服務示例項目

(2) 完成項目創建后, 在當前工作空間中創建三個代碼工程組件: API項目, 定義了微服務的項目API接口; Client項目, 微服務客戶端項目; Server項目, 微服務服務端項目. 工程結構如圖7所示.

(3) 運行微服務項目. 選中項目, 單擊右鍵, 選擇Gradle build...選項. 此時內置的Gradle插件會對項目做解析, 如圖所示, 右下角有解析進度. 隨后輸入run即可啟動項目.

(4) 打開瀏覽器, 驗證服務是否正常運行.

圖7 微服務工程結構

圖8 運行微服務項目

圖9 服務運行效果

4 平臺優勢及應用情況

平臺提供了具有容錯性和高可用性的去中心化的分布式服務注冊機制, 不需維護一個高可用的服務注冊中心, 而是將其分散到集群中的每個節點. 在每個節點上啟動一個注冊模塊, 不同節點的多個注冊模塊之間沒有主次之分, 降低了注冊模塊的壓力, 而且其中一個注冊模塊宕機, 不會影響集群中的其它注冊模塊, 有效避免了只有一個注冊模塊的宕機而導致系統癱瘓的風險. 針對注冊模塊節點的宕機問題, 提供了自動檢測失敗節點機制及周期性地恢復功能, 為注冊模塊正常運行提供雙重保障.

同時平臺微服務開發框架提供了本地化的服務注冊和發現功能, 服務只需要向本地的注冊模塊進行注冊. 集群中不同注冊模塊之間同步注冊信息, 同步過程無需應答, 有效減少了網絡資源的消耗. 從本地注冊模塊取到的注冊信息即為集群中注冊的所有服務信息, 供微服務之間調用.

本平臺自發布以來, 已在國家電網公司包含基建管控、協同研發工具在內的多個重點項目中進行了應用實踐. 基于微服務架構的統一應用開發平臺具備去中心化的服務注冊、高性能的遠程過程調用框架、穩健的負載均衡策略, 大幅提升了業務系統開發和維護的效率, 有力地提高了系統的可擴展性和可靠性.

5 結語

本文研究并實現了基于微服務架構的統一應用開發平臺. 平臺提供生成微服務的標準開發框架, 屏蔽了復雜的技術細節, 研發人員只需關注業務代碼的編寫和微服務的配置; 平臺的微服務框架強化了系統的模塊化結構, 在該架構下每一個業務模塊都是一個可以獨立部署和運行的單元, 模塊間以消息驅動API的形式定義了清晰的界限; 同時, 平臺為微服務封裝了服務注冊器、服務發現器、服務提供者列表和服務注冊中心. 通過平臺提供的微服務開發框架, 可以快速建立起一個高內聚、低耦合的微服務應用, 達到“開發標準化、系統模塊化、應用服務化”的目標.

1 王磊.微服務架構與實踐.北京:電子工業出版社,2015.

2 李林鋒.分布式服務框架原理與實踐.北京:電子工業出版社,2016.

3 溫昱.軟件架構設計.北京:電子工業出版社,2015.

4 紐曼(Sam Newman)微服務設計.崔力強,張駿,譯.北京:人民郵電出版社,2016.

5 李勇.分布式Web服務發現機制研究[博士學位論文].北京:北京郵電大學,2007.

6 顧志峰,李涓子,胡建強,許斌,王克宏.Web服務之間數據關聯的建模與應用.計算機學報,2008,31(8):3–21.

7 Videla A, Williams JJW,汪佳南.高效部署分布式消息隊列.北京:電子工業出版社,2015.

Unified Application Development Platform Based on Micro-Service Architecture

LI Chun-Yang1, LIU Di2, CUI Wei1, LI Xiao-Zhen1, LI Chun-Qi31(State Grid Information & Telecommunication Industry Co. Ltd., Beijing 100031, China)2(Beijing China Power Information Technology Co. Ltd., Beijing 100192, China)3(Tianjin Puxun Power Information Technology Co. Ltd., Tianjin 300192, China)

Business systems become larger and more complex with the development of information. System development and maintenance are facing enormous challenges. To solve this problem, this paper proposes an application development platform based on micro-services architecture, focusing on the micro-service architecture design and business system practice. This platform implements a standard development framework to generate micro-services engineering, by introducing micro-services building technology and distributed service registry technology. These technologies help to solve problems such as the long development cycle, difficulty to quickly respond to the needs of users and provide a strong support for the system development.

micro-service; development platform; distributed service registry

2016-07-26;收到修改稿時間:2016-10-12

10.15888/j.cnki.csa.005757