王明珠 張曉慧 宋鵬飛 張偉 王翠

摘 要：基于Java EE規(guī)范的單體架構(gòu)已經(jīng)很難滿足渠道不斷拓展、線上業(yè)務(wù)量持續(xù)增加的電子渠道統(tǒng)一接入服務(wù)的需求，因此對原服務(wù)平臺進行技術(shù)改造，提出了基于微服務(wù)設(shè)計思想實現(xiàn)95598全渠道統(tǒng)一接入平臺。比較了單體架構(gòu)與微服務(wù)架構(gòu)的設(shè)計思想，并提出了微服務(wù)架構(gòu)的優(yōu)勢;對95598全渠道統(tǒng)一接入平臺系統(tǒng)架構(gòu)中涉及到的關(guān)鍵步驟進行了描述;結(jié)合基于Spring Boot開發(fā)的Spring Cloud微服務(wù)框架的解決方案詳細(xì)闡述了在開發(fā)過程中解決的進程間通信、服務(wù)治理等關(guān)鍵技術(shù)點。

關(guān)鍵詞：微服務(wù)架構(gòu);95598全渠道統(tǒng)一接入平臺;Spring Boot;Spring Cloud

Abstract：Monolithic architecture based on Java EE is hard to meet the requirement of the electronic channel unified access service whose channels continue expanding and the quantity of online business continues increasing. Therefore， this paper intends to reform 95598 full channel unified access platform based on microservices architecture. By comparing the design idea of monolithic architecture and microservices architecture， it is analyzed the advantages of the microservices architecture. Furthermore， committed steps of constructing 95598 full channel unified access platform are mentioned. Ultimately， the paper puts forward key technical points such as IPC and service governance by combining Spring Cloud based on Spring Boot.

Key words：microservices architecture;95598 full channel unified access platform;Spring Boot;Spring Cloud

0 引言

近年來，隨著社會主義市場經(jīng)濟的發(fā)展和電力體制改革的逐漸推進，用電客戶的消費習(xí)慣和消費需求也在不斷變化，為適應(yīng)互聯(lián)網(wǎng)時代移動式、碎片化、智能型、互動化的客戶消費需求，落實公司“互聯(lián)網(wǎng)+”電力營銷服務(wù)理念，構(gòu)建線上業(yè)務(wù)滲透率高、服務(wù)信息充分融合與共享的電子渠道一體化運營體系勢在必行[1]。

本文提出一種基于微架構(gòu)95598全渠道統(tǒng)一接入服務(wù)，將95598智能互動網(wǎng)站、95598手機wap、移動App等多種電子渠道進行一體化整合，積極拓展渠道線上服務(wù)業(yè)務(wù)內(nèi)容，健全優(yōu)化渠道業(yè)務(wù)受理功能，向客戶提供信息查詢、業(yè)務(wù)辦理、充值繳費等用電服務(wù)，并且實現(xiàn)了電子渠道間的互通互聯(lián)，有效減少客戶臨柜次數(shù)。然而，如此龐大、復(fù)雜的應(yīng)用程序為敏捷開發(fā)和持續(xù)交付帶來了挑戰(zhàn)。傳統(tǒng)的單體架構(gòu)有很大的局限性，隨著電子渠道的不斷拓展和線上業(yè)務(wù)量的持續(xù)增加，單體架構(gòu)會變得越來越臃腫，這不可避免地會引起邏輯復(fù)雜、版本迭代效率低下、可伸縮性差等問題。而基于微服務(wù)的方式在實施敏捷開發(fā)和企業(yè)應(yīng)用持續(xù)交付方面有著明顯的優(yōu)勢。

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

“微服務(wù)架構(gòu)”是一種獨立部署的軟件應(yīng)用設(shè)計方式，最早由Martin Fowler和James Lewis在自己的博客中提出：“微服務(wù)是將一個獨立的應(yīng)用程序拆分成多個小型服務(wù)，這些小型服務(wù)都在各自獨立的進程中運行，并通過輕量級的通信協(xié)議保持通信。這些服務(wù)要基于業(yè)務(wù)場景，并且每個服務(wù)都維護著自身的數(shù)據(jù)存儲、業(yè)務(wù)開發(fā)、自動化測試案例以及獨立部署機制”[2]。與單體架構(gòu)相比，微服務(wù)可以滿足快速高效的軟件交付方式。

傳統(tǒng)的95598全渠道系統(tǒng)采用的單體架構(gòu)，如圖1所示。

由數(shù)據(jù)層、業(yè)務(wù)應(yīng)用層、頁面展示層三層架構(gòu)組成。這種方式的弊端是應(yīng)用程序是緊耦合的，所有功能都在一個進程中，基于整個系統(tǒng)擴展。微服務(wù)的設(shè)計思想，如圖2所示。

各個微服務(wù)之間是松耦合的，功能在不同的進程中，單體應(yīng)用被分解成多個更小的服務(wù)，每個服務(wù)有自己的歸檔文件，單獨部署，然后共同組成一個應(yīng)用程序，各個服務(wù)按需擴展。

本文將基于單體架構(gòu)的系統(tǒng)構(gòu)建成圖2中所示的基于微服務(wù)的方式，這種設(shè)計思想的優(yōu)勢在于[3]：

1） 迭代速度快

在業(yè)務(wù)需求快速發(fā)展的模式下，研發(fā)過程中開發(fā)人員不需要費時協(xié)調(diào)其他應(yīng)用對其應(yīng)用的影響，為持續(xù)集成和快速交付提供基礎(chǔ)性技術(shù)支撐。

2） 容錯性高

故障的影響可以控制在單個應(yīng)用中，不會對其他服務(wù)造成影響，而且微服務(wù)中有多種故障保護機制可以保證系統(tǒng)運行的穩(wěn)定性。

3） 擴展性好

整體微服務(wù)架構(gòu)內(nèi)部有成熟的軟路由、負(fù)載均衡、容錯機制，容易水平擴展。同時每個微服務(wù)獨立，可根據(jù)壓力情況，靈活選擇擴展，可節(jié)省硬件成本。

2 基于微服務(wù)的95598全渠道統(tǒng)一接入服務(wù)

基于微服務(wù)的95598全渠道統(tǒng)一接入服務(wù)系統(tǒng)架構(gòu)，如圖3所示。

該架構(gòu)將業(yè)務(wù)應(yīng)用的前端和后端進行分離，按拆分原則拆分成多個獨立運行的微應(yīng)用和微服務(wù)，由接入層門戶提供統(tǒng)一前端集成。95598全渠道統(tǒng)一接入服務(wù)在邏輯上分為接入層、應(yīng)用層、服務(wù)層和持久層，主要包括以下幾個關(guān)鍵步驟：

1） 95598全渠道統(tǒng)一接入

將95598智能互動網(wǎng)站、95598手機wap、移動app等多種電子渠道一體化整合到95598全渠道統(tǒng)一接入服務(wù)，由門戶提供統(tǒng)一集成，為用電客戶提供用電、停電等信息查詢，新裝、增容、暫停、減容等業(yè)務(wù)辦理，充值繳費等用電服務(wù)。

2） 服務(wù)訪問

95598全渠道統(tǒng)一接入服務(wù)注冊至網(wǎng)上國網(wǎng)共享服務(wù)中心，通過網(wǎng)上國網(wǎng)共享服務(wù)中心實現(xiàn)內(nèi)外網(wǎng)數(shù)據(jù)交互，與各省電力公司業(yè)務(wù)系統(tǒng)交互。網(wǎng)上國網(wǎng)共享服務(wù)中心由微服務(wù)、注冊中心、配置中心、服務(wù)網(wǎng)關(guān)和服務(wù)監(jiān)控組成，通過分布式總線將業(yè)務(wù)請求準(zhǔn)確分發(fā)至具體微服務(wù)。微服務(wù)提供業(yè)務(wù)邏輯處理;注冊中心提供微服務(wù)信息儲存，實現(xiàn)微服務(wù)間解耦;配置中心提供分布式環(huán)境下統(tǒng)一動態(tài)配置管理;服務(wù)網(wǎng)關(guān)為微服務(wù)提供統(tǒng)一訪問入口;服務(wù)監(jiān)控提供微服務(wù)狀態(tài)和調(diào)用鏈路監(jiān)控。

3） 微應(yīng)用和微服務(wù)拆分

微服務(wù)微應(yīng)用如何拆分是微服務(wù)架構(gòu)業(yè)務(wù)應(yīng)用建設(shè)過程中的難點和重點，需要對業(yè)務(wù)、技術(shù)、數(shù)據(jù)等特征進行全面綜合分析。在以下拆分原則基礎(chǔ)之上，結(jié)合實際應(yīng)用場景，進行一步完善修正，形成相關(guān)業(yè)務(wù)應(yīng)用的最終拆分原則。

a） 微應(yīng)用拆分原則

完整單一的業(yè)務(wù)邏輯單元可以拆分為獨立微應(yīng)用。該單元建議為二級或二級以下應(yīng)用功能。

建議業(yè)務(wù)應(yīng)用包含的微應(yīng)用數(shù)量是二級應(yīng)用功能的1/3倍到3倍。

b） 微服務(wù)拆分原則

業(yè)務(wù)完整、職責(zé)單一的應(yīng)用功能單元應(yīng)當(dāng)拆分為獨立微服務(wù)。該單元建議為三級或三級以下應(yīng)用功能。

建議業(yè)務(wù)應(yīng)用包含的微服務(wù)數(shù)量是三級應(yīng)用功能的1/3倍到5倍。

具有重用性特點的公共功能應(yīng)當(dāng)拆分為獨立微服務(wù)。

訪問量較大、資源消耗較大、耗時較長的功能，應(yīng)拆分為獨立微服務(wù)。

一組強關(guān)聯(lián)的數(shù)據(jù)對象的所有增刪改操作，不要拆分到多個微服務(wù)中。

耦合性強、事務(wù)強一致性的業(yè)務(wù)，不要拆分到多個微服務(wù)內(nèi)，盡可能避免分布式事務(wù)。

4） 數(shù)據(jù)庫維護

95598全渠道統(tǒng)一接入服務(wù)的數(shù)據(jù)由全業(yè)務(wù)統(tǒng)一數(shù)據(jù)中心進行維護，主數(shù)據(jù)庫采用Oracle，緩存數(shù)據(jù)庫使用的是Redis，通過調(diào)用一個或多個微服務(wù)實現(xiàn)業(yè)務(wù)邏輯和數(shù)據(jù)庫訪問，而不是應(yīng)用層直接訪問，因此模塊間數(shù)據(jù)庫表無緊密耦合關(guān)系。

3 關(guān)鍵技術(shù)點

95598全渠道統(tǒng)一接入服務(wù)的技術(shù)改造是采用Spring Cloud微服務(wù)框架實現(xiàn)的。Spring Cloud是一個基于Spting Boot的微服務(wù)架構(gòu)實施綜合性解決方案[4]。Spring Cloud將基礎(chǔ)組件Zuul、Ribbon、Hystrix、Eureka都集成在Netflix中。

Netflix的幾個重要工具在微服務(wù)架構(gòu)中的總體應(yīng)用情況，如圖4所示。

結(jié)合Spring Cloud的解決方案，下面的內(nèi)容介紹了基于微服務(wù)架構(gòu)的95598全渠道統(tǒng)一接入系統(tǒng)中的關(guān)鍵技術(shù)點，包括進程間通信、服務(wù)治理機制、負(fù)載均衡機制以及容錯保護機制。

3.1 進程間通信

在單體應(yīng)用程序中，組件之間是通過語言級別的方法或者函數(shù)相互調(diào)用的方式進行通信，但是基于微服務(wù)架構(gòu)的應(yīng)用程序是一個運行在多臺機器上的分布式系統(tǒng)，因此，服務(wù)必須使用進程間通信（IPC）機制進行交互[6]。在設(shè)計服務(wù)間通信時主要需要考慮兩個問題：使用什么通信協(xié)議構(gòu)建服務(wù)體系和如何為服務(wù)定義API調(diào)用接口。下面對這兩方面的問題進行詳細(xì)介紹。

1） IPC通信機制

基于微服務(wù)的應(yīng)用支持更簡單、輕量級的協(xié)議，RESTful和RPC是微服務(wù)架構(gòu)中最常用的通信機制，這兩種機制在應(yīng)用上各有優(yōu)勢。

以Apache Thrift為代表的RPC采用二進制協(xié)議，支持多種語言，性能高，節(jié)省寬帶，但是這種協(xié)議的最大缺點是無法穿透防火墻。以Spring Cloud為代表所支持的RESTful協(xié)議，優(yōu)勢在于使用方便，語言無關(guān)，基本支持各種開發(fā)語言實現(xiàn)的系統(tǒng)，另一個優(yōu)點在于它能夠穿透防火墻。但是與RPC相比其性能和寬帶占用上有劣勢。各大互聯(lián)網(wǎng)公司在微服務(wù)實踐中多采用RPC方式[7]，本文介紹的系統(tǒng)也采用支持RESTful協(xié)議的Spring Cloud Netflix中的 Zuul網(wǎng)關(guān)組件來實現(xiàn)此種通信機制。

2） 為服務(wù)定義API調(diào)用接口

API網(wǎng)關(guān)是系統(tǒng)的單點入口，是一個更為智能的應(yīng)用服務(wù)器。各個服務(wù)之間的通信首先要通過一個稱為API 網(wǎng)關(guān)（API Gateway）的中介，然后API 通過路由將請求分發(fā)到到適當(dāng)?shù)姆?wù)，如圖5所示。

API是服務(wù)和客戶端之間的契約，因此，無論選擇何種IPC機制，使用接口定義語言嚴(yán)格定義服務(wù)API都是很有必要的，而定義API調(diào)用接口的方式取決于應(yīng)用程序使用何種IPC機制，如采用HTTP協(xié)議，則API由URL、請求和響應(yīng)格式組成。

3.2 服務(wù)治理機制

服務(wù)治理可以說是微服務(wù)架構(gòu)中最核心和基礎(chǔ)的模塊，它主要用來實現(xiàn)各個微服務(wù)實例的自動化注冊與發(fā)現(xiàn)[8]。在95598全渠道統(tǒng)一接入系統(tǒng)中，微服務(wù)的服務(wù)注冊與服務(wù)發(fā)現(xiàn)機制的實現(xiàn)過程，如圖6所示。

服務(wù)實例通過POST請求將自己的網(wǎng)絡(luò)位置（IP地址與端口）注冊于服務(wù)注冊中心（可用服務(wù)實例的數(shù)據(jù)庫），客戶端從服務(wù)注冊中心查詢可用的網(wǎng)絡(luò)地址并利用負(fù)載均衡算法選擇一個合適的服務(wù)實例進行調(diào)用。

本文采用Spring Cloud核心組件Netflix中的服務(wù)治理組件Eureka來實現(xiàn)服務(wù)注冊與服務(wù)發(fā)現(xiàn)機制。Eureka既包含服務(wù)端組件也包含客戶端組件，Eureka服務(wù)端也稱為服務(wù)注冊中心，它提供了一個用于注冊和查詢服務(wù)實例的REST API。Eureka客戶端主要處理服務(wù)的注冊與發(fā)現(xiàn)，服務(wù)實例負(fù)責(zé)在服務(wù)注冊中心進行自己注冊和注銷，在必要的情況下，服務(wù)實例會發(fā)送心跳請求來防止其注冊信息過期。

3.3 負(fù)載均衡機制

為了擴展網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬、增加吞吐量、加強網(wǎng)絡(luò)數(shù)據(jù)處理能力、提高網(wǎng)絡(luò)的靈活性和可用性，基于微服務(wù)的95598全渠道統(tǒng)一接入服務(wù)體系中采用了負(fù)載均衡機制[9]。

負(fù)載均衡分為服務(wù)端負(fù)載均衡和客戶端負(fù)載均衡，本文中服務(wù)端負(fù)載均衡采用了高性能的HTTP和反向代理服務(wù)器Nginx，通過Nginx進行負(fù)載均衡，先發(fā)送請求，然后通過負(fù)載均衡算法在多個服務(wù)器之間選擇一個進行訪問?？蛻舳素?fù)載均衡采用基于Netflix Ribbon實現(xiàn)的客戶端負(fù)載均衡工具。在客戶端負(fù)載均衡中，每一個客戶端節(jié)點都維護著要訪問來自于服務(wù)注冊中心的服務(wù)端清單。當(dāng)客戶端發(fā)送請求到負(fù)載均衡設(shè)備的時候，該設(shè)備按某種算法（如線性輪詢、按權(quán)重負(fù)載、按流量負(fù)載等）從維護的可用服務(wù)端清單中取出一臺服務(wù)端的地址，然后進行轉(zhuǎn)發(fā)。Ribbon不像服務(wù)注冊中心、配置中心、API網(wǎng)關(guān)那樣需要獨立部署，但它幾乎存在于每一個微服務(wù)和基礎(chǔ)設(shè)施中，因為服務(wù)間的調(diào)用，API網(wǎng)關(guān)的請求轉(zhuǎn)發(fā)等內(nèi)容實際上都是通過Ribbon實現(xiàn)的。

3.4 容錯保護機制

在微服務(wù)架構(gòu)中，應(yīng)用程序由多個服務(wù)單元構(gòu)成，這樣的架構(gòu)相較傳統(tǒng)架構(gòu)更加不穩(wěn)定。因為若一個服務(wù)單元出現(xiàn)故障，很容易因依賴關(guān)系而引發(fā)故障的蔓延，最終甚至導(dǎo)致整個系統(tǒng)癱瘓。為避免出現(xiàn)這樣的技術(shù)故障，本文采用基于Spring Cloud Hystrix實現(xiàn)的容錯保護技術(shù)。Hystrix實現(xiàn)了斷路器、依賴隔離等一系列的服務(wù)保護機制，具備服務(wù)降級、服務(wù)熔斷、線程和信號隔離、請求緩存等強大功能。

1） 斷路器保護機制

斷路器的工作邏輯，如圖7所示。

正常情況下，斷路器關(guān)閉，可正常請求依賴的服務(wù);

當(dāng)一段時間內(nèi)，請求失敗率達到一定閥值，斷路器就會打開，此時，不會再去請求依賴的服務(wù);

斷路器打開一段時間后，會自動進入“半開”狀態(tài)。此時，斷路器可允許一個請求訪問依賴的服務(wù)。如果該請求能夠調(diào)用成功則關(guān)閉斷路器，否則繼續(xù)保持打開狀態(tài)。

2） 依賴隔離

在95598全渠道統(tǒng)一接入服務(wù)體系中，需要用到很多依賴，在訪問并發(fā)量很高的情況下，這些依賴的穩(wěn)定性可能直接影響著系統(tǒng)的健壯性。當(dāng)依賴阻塞大時，大多數(shù)服務(wù)器的線程池就會出現(xiàn)阻塞，影響整個線上服務(wù)的穩(wěn)定性，高并發(fā)的依賴失敗時如果沒有隔離措施，當(dāng)前應(yīng)用服務(wù)就有被拖垮的風(fēng)險。為了防范這個風(fēng)險，Hystrix采用隔離線程池的機制來對依賴進行隔離[10]。

Hystrix實會為每一個依賴服務(wù)創(chuàng)建一個獨立的線程池，這樣就算某個依賴服務(wù)出現(xiàn)延遲過高的情況，也只是對該依賴服務(wù)的調(diào)用產(chǎn)生影響，而不會拖慢其他的依賴服務(wù)。

4 總結(jié)

本文在基于單體架構(gòu)實現(xiàn)渠道不斷拓展、線上業(yè)務(wù)量持續(xù)增加的電子渠道統(tǒng)一接入服務(wù)平臺時具有開發(fā)效率低、迭代速度慢、難于擴展、容錯性差等缺點的背景下，采用微服務(wù)的設(shè)計思想對95598全渠道統(tǒng)一接入平臺進行了技術(shù)改造。

改造后的95598全渠道服務(wù)后臺具備支持微服務(wù)拆分設(shè)計后的高內(nèi)聚、低耦合服務(wù)的管理及調(diào)度，并可依托云環(huán)境進行服務(wù)發(fā)現(xiàn)、服務(wù)彈性伸縮、服務(wù)異步協(xié)同，增強網(wǎng)站服務(wù)后臺的可靠性及服務(wù)部署的靈活性;平臺使用了科學(xué)有效的容錯保護機制，有效提升了容忍技術(shù)故障的能力以及系統(tǒng)的健壯性。改造后的95598全渠道統(tǒng)一接入平臺能夠滿足公司持續(xù)開展95598全渠道功能優(yōu)化工作以及互聯(lián)網(wǎng)時代移動式、碎片化、智能型、互動化的客戶消費需求，落實公司“互聯(lián)網(wǎng)+”營銷服務(wù)模式的決策部署，提升了公司服務(wù)效能和服務(wù)水平。

參考文獻

[1] 韓碩辰，白雪，董世安.“互聯(lián)網(wǎng)+電力營銷”電子渠道一體化運營體系構(gòu)建[J].通信技術(shù)，2018，35 （1）：101-103.

[2] Fowler M，Lewis J. Microservices-a definition of this new architectural term[EB/OL]. （2014-03-25）， [2017-06-18]. http：∥martinfowler.com/articles/ microservices. html.

[3] 李紅健.微服務(wù)架構(gòu)和容器技術(shù)應(yīng)用分析[J].無線互聯(lián)科技，2018（8）：134-135.

[4] 馬雄.基于微服務(wù)架構(gòu)的系統(tǒng)設(shè)計與開發(fā)[D].南京：南京郵電大學(xué)，2017.

[5] Sourabh Sharma. Java微服務(wù)[M].盧濤， 譯.北京：電子工業(yè)出版社，2017.

[6] Richardson C，Smith F，著.微服務(wù)：從設(shè)計到部署[M].Oopsguy.譯，2017.

[7] 作者？.微服務(wù)在電力交易系統(tǒng)中的應(yīng)用研究[J] .電網(wǎng)技術(shù)，2018，42（2） ：441-446.

[8] T，Johannes.Microservies，IEEE Trans， on Software. 2015，32（1）：1-116.

[9] 負(fù)載均衡：百度百科，https：//www.zhihu.com/question/61783920.

[10] 翟永超. Spring Cloud微服務(wù)實戰(zhàn)[M].北京：電子工業(yè)出版社，2017.

（收稿日期：2019.08.25）