李春陽(yáng), 劉 迪, 崔 蔚, 李曉珍, 李春岐(國(guó)網(wǎng)信息通信產(chǎn)業(yè)集團(tuán)有限公司, 北京 000)(北京中電普華信息技術(shù)有限公司, 北京 009)(天津市普迅電力信息技術(shù)有限公司, 天津 009)

基于微服務(wù)架構(gòu)的統(tǒng)一應(yīng)用開(kāi)發(fā)平臺(tái)①

李春陽(yáng)1, 劉 迪2, 崔 蔚1, 李曉珍1, 李春岐31(國(guó)網(wǎng)信息通信產(chǎn)業(yè)集團(tuán)有限公司, 北京 100031)2(北京中電普華信息技術(shù)有限公司, 北京 100192)3(天津市普迅電力信息技術(shù)有限公司, 天津 300192)

隨著信息化時(shí)代的發(fā)展, 業(yè)務(wù)系統(tǒng)越發(fā)龐大復(fù)雜, 系統(tǒng)開(kāi)發(fā)及維護(hù)面臨著巨大的挑戰(zhàn). 針對(duì)這一問(wèn)題,提出基于微服務(wù)架構(gòu)的統(tǒng)一應(yīng)用開(kāi)發(fā)平臺(tái), 重點(diǎn)介紹了平臺(tái)的微服務(wù)架構(gòu)設(shè)計(jì)、基于平臺(tái)的業(yè)務(wù)系統(tǒng)實(shí)現(xiàn). 通過(guò)引入微服務(wù)構(gòu)建和分布式服務(wù)注冊(cè)等相關(guān)技術(shù), 平臺(tái)實(shí)現(xiàn)了生成微服務(wù)工程的標(biāo)準(zhǔn)開(kāi)發(fā)框架, 解決傳統(tǒng)單體架構(gòu)應(yīng)用龐大而帶來(lái)的研發(fā)周期長(zhǎng), 難以快速響應(yīng)用戶(hù)需求等問(wèn)題, 為業(yè)務(wù)系統(tǒng)的開(kāi)發(fā)提供了有效支撐.

微服務(wù); 開(kāi)發(fā)平臺(tái); 分布式服務(wù)注冊(cè)中心

傳統(tǒng)應(yīng)用架構(gòu)的弊端最早在大型企業(yè)和互聯(lián)網(wǎng)行業(yè)中呈現(xiàn), 這些公司都遇到了復(fù)雜應(yīng)用的開(kāi)發(fā)維護(hù)成本變高、代碼重復(fù)率增大、團(tuán)隊(duì)協(xié)作效率變差、系統(tǒng)可靠性變低、系統(tǒng)水平擴(kuò)展困難、新功能上線周期變長(zhǎng)等問(wèn)題. 因此眾多大型公司經(jīng)過(guò)了反復(fù)實(shí)踐和嘗試,推出了各種輕量級(jí)的架構(gòu)模式, 有效的解決了上述問(wèn)題.

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

為解決現(xiàn)階段信息系統(tǒng)建設(shè)中存在的問(wèn)題,本文推出了全面支持微服務(wù)的開(kāi)發(fā)框架[1], 可將高度耦合的功能分解到各個(gè)離散的微服務(wù)中以實(shí)現(xiàn)對(duì)應(yīng)用系統(tǒng)的解耦. 該架構(gòu)全面支持了輕量級(jí)嵌入式應(yīng)用容器、輕量級(jí)IOC組件、去中心化的服務(wù)注冊(cè)中心、高性能的遠(yuǎn)程過(guò)程調(diào)用、應(yīng)用的追蹤與監(jiān)控、分布式會(huì)話管理、負(fù)載均衡策略及應(yīng)用可靠性保障等特性.

1 平臺(tái)簡(jiǎn)介

平臺(tái)按照“開(kāi)發(fā)標(biāo)準(zhǔn)化、系統(tǒng)模塊化、操作工具化、運(yùn)行容器化, 應(yīng)用服務(wù)化”的總體目標(biāo), 把微服務(wù)開(kāi)發(fā)框架、相應(yīng)的技術(shù)和工具整合到平臺(tái)中, 平臺(tái)主要包括集成開(kāi)發(fā)工具、基礎(chǔ)服務(wù)框架、應(yīng)用開(kāi)發(fā)套件三大功能組件. 總體功能架構(gòu)如圖1所示.

圖1 平臺(tái)功能架構(gòu)

集成開(kāi)發(fā)工具主要包括可視化界面設(shè)計(jì)器、編碼與調(diào)試輔助工具等與業(yè)務(wù)系統(tǒng)開(kāi)發(fā)密切關(guān)聯(lián)的功能組件; 基礎(chǔ)服務(wù)框架用于屏蔽大量的底層技術(shù)細(xì)節(jié),提供了微服務(wù)集群管理、遠(yuǎn)程過(guò)程調(diào)用、分布式服務(wù)框架、分布式緩存、集中日志等基礎(chǔ)性技術(shù)組件; 應(yīng)用開(kāi)發(fā)套件主要包括MX展現(xiàn)框架、即席報(bào)表組件等高級(jí)開(kāi)發(fā)套件, 基于這些套件可以快速開(kāi)發(fā)出業(yè)務(wù)系統(tǒng)功能邏輯, 保障業(yè)務(wù)系統(tǒng)穩(wěn)定、高效運(yùn)行. 本文主要介紹平臺(tái)的基礎(chǔ)微服務(wù)框架.

2 平臺(tái)微服務(wù)架構(gòu)設(shè)計(jì)

2.1 總體架構(gòu)

平臺(tái)微服務(wù)開(kāi)發(fā)框架基于約定優(yōu)于配置的思想,封裝了支撐微服務(wù)構(gòu)建的組件庫(kù), 不需要繁瑣的配置即可使用Java語(yǔ)言開(kāi)發(fā)微服務(wù). 平臺(tái)總體技術(shù)架構(gòu)如圖2所示.

圖2 平臺(tái)總體技術(shù)架構(gòu)

平臺(tái)基于dropwizard提供微服務(wù)開(kāi)發(fā)組件, 以Jetty作為Web容器, 引入Jersey提供標(biāo)準(zhǔn)Restful 風(fēng)格的Web訪問(wèn), 集成Hibernate等數(shù)據(jù)持久層訪問(wèn)組件;提供服務(wù)注冊(cè)發(fā)現(xiàn)功能, 自動(dòng)注冊(cè)本地服務(wù)到注冊(cè)中心; 通過(guò)可選的負(fù)載均衡策略, 選擇最優(yōu)的服務(wù)地址;提供輕量級(jí)的RPC組件調(diào)用, 保障高可用的服務(wù)調(diào)用.

在開(kāi)發(fā)階段根據(jù)微服務(wù)框架Bundle特性, 能夠?qū)崿F(xiàn)平臺(tái)各模塊的Bundle插件集成到微服務(wù)中, 如任務(wù)調(diào)度、大數(shù)據(jù)組件、報(bào)表和展現(xiàn)框架等.

同時(shí), 平臺(tái)提供了去中心化的分布式服務(wù)注冊(cè)中心[2], 在每個(gè)節(jié)點(diǎn)上啟動(dòng)一個(gè)注冊(cè)中心, 不同節(jié)點(diǎn)的多個(gè)注冊(cè)中心之間沒(méi)有主次之分, 降低了注冊(cè)中心的壓力, 其中一個(gè)注冊(cè)中心宕機(jī), 不會(huì)影響集群中的其它注冊(cè)中心. 針對(duì)注冊(cè)中心節(jié)點(diǎn)的宕機(jī)問(wèn)題, 提供了自動(dòng)檢測(cè)失敗節(jié)點(diǎn)機(jī)制及周期性地恢復(fù)功能, 為注冊(cè)中心正常運(yùn)行提供雙重保障.

2.2 微服務(wù)開(kāi)發(fā)框架

2.2.1 微服務(wù)工程

微服務(wù)工程有三種, 服務(wù)生產(chǎn)者, 服務(wù)消費(fèi)者和服務(wù)定義接口(API), 服務(wù)由接口定義, 服務(wù)生產(chǎn)者實(shí)現(xiàn)接口服務(wù), 服務(wù)消費(fèi)者來(lái)調(diào)用. 工程結(jié)構(gòu)[3]如圖3所示.

消費(fèi)者和生產(chǎn)者微服務(wù)通過(guò)擴(kuò)展微服務(wù)開(kāi)發(fā)組件實(shí)現(xiàn). 微服務(wù)開(kāi)發(fā)組件是對(duì)開(kāi)源微服務(wù)組件dropwizard的二次封裝, 除了具有dropwizard提供的特性外, 還封裝了服務(wù)注冊(cè), 發(fā)現(xiàn), 刷新, 輕量級(jí)RPC,負(fù)載均衡. 由以下核心模塊[4]協(xié)助完成.

圖3 微服務(wù)工程結(jié)構(gòu)

服務(wù)實(shí)現(xiàn): 通過(guò)自定義注解@MircoService, 將RPC調(diào)用,負(fù)載均衡做了封裝, API接口的實(shí)現(xiàn)類(lèi)和引用類(lèi)必須注解為@ MircoService類(lèi)型.

服務(wù)交互監(jiān)聽(tīng)器: 平臺(tái)提供ServerListener類(lèi), 系統(tǒng)啟動(dòng)時(shí)加載該監(jiān)聽(tīng)器, 實(shí)現(xiàn)服務(wù)注冊(cè)刷新和發(fā)現(xiàn).

(1) 服務(wù)實(shí)現(xiàn)

提供注解@Microservice, 將類(lèi)標(biāo)記為微服務(wù)的業(yè)務(wù)處理邏輯構(gòu)件. 標(biāo)記方式有兩種:

① 作為接口引用的標(biāo)記

public class TestFrontController {

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

@MicroService //標(biāo)記為接口引用的微服務(wù)構(gòu)件

private IBugService service;

}

② 作為接口實(shí)現(xiàn)的標(biāo)記

@MicroService //標(biāo)記為微服務(wù)構(gòu)件

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) 監(jiān)聽(tīng)器ServerListener

ServerListener在系統(tǒng)啟動(dòng)時(shí)加載, 主要有以下功能.

① 服務(wù)注冊(cè)

發(fā)送http請(qǐng)求向服務(wù)注冊(cè)中心, 注冊(cè)服務(wù)數(shù)據(jù),注冊(cè)服務(wù)數(shù)據(jù)為json格式:

{

addr: http//localhost:8080/ms,

Provider:

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

Consumer: []

}

微服務(wù)如果是生產(chǎn)者, 則provider值不為空, 是消費(fèi)者, 則Consumer值不為空.

② 服務(wù)刷新和發(fā)現(xiàn)

定時(shí)向注冊(cè)中心發(fā)送刷新服務(wù)請(qǐng)求, 刷新請(qǐng)求返回的是服務(wù)的狀態(tài)和路由列表, 如果服務(wù)狀態(tài)為死亡則重新注冊(cè)服務(wù), 如果服務(wù)正常, 判斷本次路由表校驗(yàn)碼與本地路由表校驗(yàn)和是否一致, 不一致更新本地路由表.

2.2.2 去中心化的服務(wù)注冊(cè)中心

傳統(tǒng)的企業(yè)應(yīng)用架構(gòu)多采用中心化的分布式服務(wù)架構(gòu), 一旦服務(wù)注冊(cè)中心出現(xiàn)問(wèn)題, 整個(gè)系統(tǒng)就會(huì)癱瘓; 同時(shí)所有應(yīng)用向一個(gè)服務(wù)注冊(cè)中心進(jìn)行遠(yuǎn)程注冊(cè),會(huì)消耗大量的網(wǎng)絡(luò)資源, 造成服務(wù)注冊(cè)中心壓力過(guò)大.因此, 平臺(tái)采用去中心化的服務(wù)注冊(cè)中心, 如圖4所示.

圖4 去中心化的服務(wù)注冊(cè)中心

服務(wù)注冊(cè)中心封裝了開(kāi)源分布式集群框架Serf,基于Gossip協(xié)議實(shí)現(xiàn)集群節(jié)點(diǎn)之間進(jìn)行通信, 同步所有的路由信息; 同時(shí)封裝go語(yǔ)言的Web服務(wù)框架Gin,實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)[5], 注冊(cè), 刷新的http接口服務(wù), 供微服務(wù)和監(jiān)控應(yīng)用調(diào)用. 節(jié)點(diǎn)之間, 以事件的方式提供了信息同步功能, 實(shí)現(xiàn)節(jié)點(diǎn)信息、路由信息的同步.

(1) 服務(wù)注冊(cè)

采用Gin Web Framework, 對(duì)外提供服務(wù)注冊(cè)的Restful服務(wù). 接收微服務(wù)傳遞來(lái)的注冊(cè)信息, 包含:微服務(wù)訪問(wèn)地址、提供哪些服務(wù)的列表、消費(fèi)哪些服務(wù)的列表, 然后保存到本地的哈稀表中.

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

參數(shù):

{

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

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

consumers:[]

}

返回值: http Code

(2) 服務(wù)刷新

服務(wù)注冊(cè)中心接收到服務(wù)發(fā)現(xiàn)的Rest請(qǐng)求后, 從本地的哈希表中獲取所有微服務(wù)的注冊(cè)信息, 拼裝成數(shù)組, 然后再對(duì)所有注冊(cè)信息計(jì)算MD5校驗(yàn)碼, 將數(shù)組和校驗(yàn)碼一并返回. 服務(wù)發(fā)現(xiàn)器接收返回?cái)?shù)據(jù)后,將注冊(cè)信息數(shù)組保存到微服務(wù)容器的哈希表中, 作為服務(wù)提供者的列表.

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

參數(shù): 微服務(wù)http訪問(wèn)地址的base64編碼值

返回值:

{

AppStatus:true,

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

}

(3) 服務(wù)發(fā)現(xiàn)

服務(wù)注冊(cè)中心接收到該Rest請(qǐng)求[6]后, 解碼URL中的地址參數(shù), 去本地的哈希表中查詢(xún)?cè)摰刂肥欠翊嬖? 如果存在, 服務(wù)注冊(cè)中心認(rèn)為該微服務(wù)存活, 否則認(rèn)為微服務(wù)已經(jīng)掉線. 當(dāng)微服務(wù)處于存活狀態(tài)時(shí),還要從本地的哈希表中獲取所有微服務(wù)的注冊(cè)信息后計(jì)算MD5校驗(yàn)碼, 最終將存活狀態(tài)信息和校驗(yàn)碼一并返回. 服務(wù)刷新器接收返回?cái)?shù)據(jù)后, 判斷存活狀態(tài)為掉線時(shí), 去調(diào)用服務(wù)注冊(cè)器重新注冊(cè), 然后拿本地保存的校驗(yàn)碼與返回的校驗(yàn)碼比對(duì), 不一致時(shí), 表明服務(wù)注冊(cè)中心的注冊(cè)信息發(fā)生變化, 調(diào)用服務(wù)發(fā)現(xiàn)器去注冊(cè)中心重新獲取, 保證微服務(wù)容器的服務(wù)提供者列表是最新的數(shù)據(jù).

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

參數(shù): 微服務(wù)http訪問(wèn)地址的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) 節(jié)點(diǎn)同步

服務(wù)注冊(cè)中心節(jié)點(diǎn)之間通過(guò)Gossip協(xié)議進(jìn)行周期性的消息通信[7], 傳遞節(jié)點(diǎn)信息, 保證最終所有節(jié)點(diǎn)的路由信息一致. 全局節(jié)點(diǎn)狀態(tài)信息同步發(fā)生在新添加節(jié)點(diǎn)、全局同步周期. 報(bào)文格式如下:

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

Version: 目前總是設(shè)置為0, 允許未來(lái)改變報(bào)文使用的算法后改變版本值.

Nonce: 隨機(jī)數(shù), 保證消息的完整性CiperText: 密文, 消息主體

Tag: 標(biāo)記, 校驗(yàn)消息的完整性

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

3 平臺(tái)實(shí)現(xiàn)與應(yīng)用

3.1 啟動(dòng)注冊(cè)中心

開(kāi)發(fā)微服務(wù)之前, 首先要啟動(dòng)本地注冊(cè)中心程序,以支持開(kāi)發(fā)環(huán)境中不同微服務(wù)之間的通信. 在Windows中執(zhí)行cmd命令進(jìn)入Windows控制臺(tái)環(huán)境,找到平臺(tái)提供的blued.exe組件所在的目錄, 輸入命令blued agent啟動(dòng)微服務(wù)環(huán)境, 如圖5所示.

圖5 啟動(dòng)注冊(cè)中心

3.2 微服務(wù)項(xiàng)目創(chuàng)建及運(yùn)行

(1) 創(chuàng)建微服務(wù)示例項(xiàng)目, 在向?qū)е休斎腠?xiàng)目名稱(chēng), 并配置數(shù)據(jù)庫(kù)信息, 如圖6所示.

圖6 創(chuàng)建微服務(wù)示例項(xiàng)目

(2) 完成項(xiàng)目創(chuàng)建后, 在當(dāng)前工作空間中創(chuàng)建三個(gè)代碼工程組件: API項(xiàng)目, 定義了微服務(wù)的項(xiàng)目API接口; Client項(xiàng)目, 微服務(wù)客戶(hù)端項(xiàng)目; Server項(xiàng)目, 微服務(wù)服務(wù)端項(xiàng)目. 工程結(jié)構(gòu)如圖7所示.

(3) 運(yùn)行微服務(wù)項(xiàng)目. 選中項(xiàng)目, 單擊右鍵, 選擇Gradle build...選項(xiàng). 此時(shí)內(nèi)置的Gradle插件會(huì)對(duì)項(xiàng)目做解析, 如圖所示, 右下角有解析進(jìn)度. 隨后輸入run即可啟動(dòng)項(xiàng)目.

(4) 打開(kāi)瀏覽器, 驗(yàn)證服務(wù)是否正常運(yùn)行.

圖7 微服務(wù)工程結(jié)構(gòu)

圖8 運(yùn)行微服務(wù)項(xiàng)目

圖9 服務(wù)運(yùn)行效果

4 平臺(tái)優(yōu)勢(shì)及應(yīng)用情況

平臺(tái)提供了具有容錯(cuò)性和高可用性的去中心化的分布式服務(wù)注冊(cè)機(jī)制, 不需維護(hù)一個(gè)高可用的服務(wù)注冊(cè)中心, 而是將其分散到集群中的每個(gè)節(jié)點(diǎn). 在每個(gè)節(jié)點(diǎn)上啟動(dòng)一個(gè)注冊(cè)模塊, 不同節(jié)點(diǎn)的多個(gè)注冊(cè)模塊之間沒(méi)有主次之分, 降低了注冊(cè)模塊的壓力, 而且其中一個(gè)注冊(cè)模塊宕機(jī), 不會(huì)影響集群中的其它注冊(cè)模塊, 有效避免了只有一個(gè)注冊(cè)模塊的宕機(jī)而導(dǎo)致系統(tǒng)癱瘓的風(fēng)險(xiǎn). 針對(duì)注冊(cè)模塊節(jié)點(diǎn)的宕機(jī)問(wèn)題, 提供了自動(dòng)檢測(cè)失敗節(jié)點(diǎn)機(jī)制及周期性地恢復(fù)功能, 為注冊(cè)模塊正常運(yùn)行提供雙重保障.

同時(shí)平臺(tái)微服務(wù)開(kāi)發(fā)框架提供了本地化的服務(wù)注冊(cè)和發(fā)現(xiàn)功能, 服務(wù)只需要向本地的注冊(cè)模塊進(jìn)行注冊(cè). 集群中不同注冊(cè)模塊之間同步注冊(cè)信息, 同步過(guò)程無(wú)需應(yīng)答, 有效減少了網(wǎng)絡(luò)資源的消耗. 從本地注冊(cè)模塊取到的注冊(cè)信息即為集群中注冊(cè)的所有服務(wù)信息, 供微服務(wù)之間調(diào)用.

本平臺(tái)自發(fā)布以來(lái), 已在國(guó)家電網(wǎng)公司包含基建管控、協(xié)同研發(fā)工具在內(nèi)的多個(gè)重點(diǎn)項(xiàng)目中進(jìn)行了應(yīng)用實(shí)踐. 基于微服務(wù)架構(gòu)的統(tǒng)一應(yīng)用開(kāi)發(fā)平臺(tái)具備去中心化的服務(wù)注冊(cè)、高性能的遠(yuǎn)程過(guò)程調(diào)用框架、穩(wěn)健的負(fù)載均衡策略, 大幅提升了業(yè)務(wù)系統(tǒng)開(kāi)發(fā)和維護(hù)的效率, 有力地提高了系統(tǒng)的可擴(kuò)展性和可靠性.

5 結(jié)語(yǔ)

本文研究并實(shí)現(xiàn)了基于微服務(wù)架構(gòu)的統(tǒng)一應(yīng)用開(kāi)發(fā)平臺(tái). 平臺(tái)提供生成微服務(wù)的標(biāo)準(zhǔn)開(kāi)發(fā)框架, 屏蔽了復(fù)雜的技術(shù)細(xì)節(jié), 研發(fā)人員只需關(guān)注業(yè)務(wù)代碼的編寫(xiě)和微服務(wù)的配置; 平臺(tái)的微服務(wù)框架強(qiáng)化了系統(tǒng)的模塊化結(jié)構(gòu), 在該架構(gòu)下每一個(gè)業(yè)務(wù)模塊都是一個(gè)可以獨(dú)立部署和運(yùn)行的單元, 模塊間以消息驅(qū)動(dòng)API的形式定義了清晰的界限; 同時(shí), 平臺(tái)為微服務(wù)封裝了服務(wù)注冊(cè)器、服務(wù)發(fā)現(xiàn)器、服務(wù)提供者列表和服務(wù)注冊(cè)中心. 通過(guò)平臺(tái)提供的微服務(wù)開(kāi)發(fā)框架, 可以快速建立起一個(gè)高內(nèi)聚、低耦合的微服務(wù)應(yīng)用, 達(dá)到“開(kāi)發(fā)標(biāo)準(zhǔn)化、系統(tǒng)模塊化、應(yīng)用服務(wù)化”的目標(biāo).

1 王磊.微服務(wù)架構(gòu)與實(shí)踐.北京:電子工業(yè)出版社,2015.

2 李林鋒.分布式服務(wù)框架原理與實(shí)踐.北京:電子工業(yè)出版社,2016.

3 溫昱.軟件架構(gòu)設(shè)計(jì).北京:電子工業(yè)出版社,2015.

4 紐曼(Sam Newman)微服務(wù)設(shè)計(jì).崔力強(qiáng),張駿,譯.北京:人民郵電出版社,2016.

5 李勇.分布式Web服務(wù)發(fā)現(xiàn)機(jī)制研究[博士學(xué)位論文].北京:北京郵電大學(xué),2007.

6 顧志峰,李涓子,胡建強(qiáng),許斌,王克宏.Web服務(wù)之間數(shù)據(jù)關(guān)聯(lián)的建模與應(yīng)用.計(jì)算機(jī)學(xué)報(bào),2008,31(8):3–21.

7 Videla A, Williams JJW,汪佳南.高效部署分布式消息隊(duì)列.北京:電子工業(yè)出版社,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;收到修改稿時(shí)間:2016-10-12

10.15888/j.cnki.csa.005757