《電力行業(yè)云服務設計與技術要求》

ICS點擊此處添加ICS號

點擊此處添加中國標準文獻分類號

DL

中華人民共和國電力行業(yè)標準

XX/TXXXXX—XXXX

電力行業(yè)云應用設計與技術要求

RequirementofDesignandTechniqueforCloudApplicationsinElectricPower

Industry

點擊此處添加與國際標準一致性程度的標識

（征求意見稿）

XXXX-XX-XX發(fā)布XXXX-XX-XX實施

發(fā)布

XX/TXXXXX—XXXX

I

XX/TXXXXX—XXXX

電力行業(yè)云應用設計與技術要求

1范圍

本標準規(guī)定電力行業(yè)可部署運行在云環(huán)境中、能統(tǒng)一適配云計算特性的業(yè)務應用和服務的設計和技

術要求，制定本標準。

本標準適用于電力行業(yè)相關的單體架構和微服務架構的業(yè)務應用系統(tǒng)的整個全生命周期。

2規(guī)范性引用文件

下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅所注日期的版本適用于本文

件。凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。

GB/T17859-1999計算機信息系統(tǒng)安全保護劃分準則

GB/T22239-2008信息安全技術信息系統(tǒng)安全等級保護基本要求

GB/T22240-2008信息安全技術信息系統(tǒng)安全等級保護定級指南

GB/T28452-2012信息安全技術應用軟件系統(tǒng)通用安全技術要求

GB/T29263信息安全技術面向服務的體系結構（SOA）應用的總體技術要求

GB/T29831.3-2013系統(tǒng)與軟件功能性第3部分：測試方法

GB/T31168-2014信息安全技術云計算服務安全能力要求

GB/T31915-2015信息技術彈性計算應用接口

GB/T32399-2015信息技術云計算參考架構

GB/T32400信息技術云計算概覽與詞匯

GB/T32430-2015信息技術SOA應用的服務分析與設計

GB/T35279-2017信息安全技術云計算安全參考架構

GB/T35301-2017信息技術云計算平臺即服務(PaaS)參考架構

GB/T36325-2018信息技術云計算云服務級別協(xié)議基本要求

GB/T36326-2018信息技術云計算云服務運營通用要求

GB/T36327-2018信息技術云計算平臺即服務(PaaS)應用程序管理要求

GB/T36463.1-2018信息技術服務咨詢設計第1部分：通用要求

GB/T36610-2018用于微博客的法人和其他組織統(tǒng)一社會信用代碼實名認證服務接口規(guī)范

GB/T36623-2018信息技術云計算文件服務應用接口

GB/T36639-2018信息安全技術可信計算規(guī)范服務器可信支撐平臺

GB/T33780.1-2017基于云計算的電子政務公共平臺技術規(guī)范第1部分：系統(tǒng)架構

GB/T34080.1-2017基于云計算的電子政務公共平臺安全規(guī)范第1部分：總體要求

GB-T5271-1-2000信息技術詞匯第1部分：基本術語

DL/T860.2-2006變電站通信網(wǎng)絡和系統(tǒng)第2部分：術語

DL/T1729-2017電力信息系統(tǒng)功能及非功能性測試規(guī)范

DL/T1731-2017電力信息系統(tǒng)非功能性需求規(guī)范

YD/T2806-2015云計算基礎設施即服務(IaaS)功能要求與架構

1

XX/TXXXXX—XXXX

3術語和定義

GB-T5271-1-2000、DL/T860.2界定的以及下列術語和定義適用于本文件。

3.1服務service

提供給用戶滿足其應用需求的有形或無形的活動。

[GB/T33780.1-2017，定義3.1]

3.2云服務cloudservice

通過云計算已定義的接口提供的一種或多種能力。

[GB/T32400-2015，定義3.2.8]

3.3微服務microservice

把一個大型的單個應用程序和服務拆分為若干個服務模塊，每個服務模塊承擔單一職責、模塊化、

相對獨立的一段業(yè)務邏輯，可獨立部署、獨立運行，并采用輕量級的通信機制互相配合,實現(xiàn)一組同類

型的或緊密耦合的單一業(yè)務目標或業(yè)務場景的功能邏輯組合軟件包。每個微服務可根據(jù)業(yè)務性能需要進

行獨立擴展。

3.4云平臺cloudplatform

能夠按需提供具有應用程序部署、管理和運行能力的操作系統(tǒng)。

[GB/T35301-2017，定義3.1.2]

3.5基礎設施即服務infrastructureasaservice；IaaS

云服務提供商向云服務用戶提供計算、存儲、云內(nèi)網(wǎng)絡連接服務（如虛擬局域網(wǎng)、防火墻愛、負載

均衡、應用加速）等資源和其他基礎計算資源，云服務用戶可以在上面部署和運行任意的應用程序。云

服務用戶不能夠管理和控制底層資源，但是可以管理和控制操作系統(tǒng)，已部署的應用程序，以及控制部

分的網(wǎng)絡組件。

[YD/T2806-2015，定義2.1.3]

3.6平臺即服務platformasaservice；PaaS

云計算中能夠提供部署、管理和運行應用程序能力的服務模式。

[GB/T35301-2017，定義3.1.1]

4縮略語

下列縮略語適用于本文件。

API：應用程序編程接口（ApplicationProgrammingInterface）

CS：云服務（CloudService）

HTTP：超文本傳輸協(xié)議（HyperTextTransferProtocol）

IaaS：基礎設施即服務（InfrastructureasaService）

J2EE：Java2平臺企業(yè)版（Java2PlatformEnterpriseEdition）

JNDI：Java命名和目錄接口（JavaNamingandDirectoryInterface）

JSON：Java腳本對象標記（JavaScriptObjectNotation）

2

XX/TXXXXX—XXXX

OSGI：Java語言動態(tài)模塊化系統(tǒng)的一系列規(guī)范（OpenServiceGatewayInitiative）

PaaS：平臺即服務（PlatformasaService）

REST：表述性狀態(tài)傳遞（RepresentationalStateTransfer）

URI：統(tǒng)一資源標識符（UniformResourceIdentifier）

XML：可擴展性標記語言（ExtensibleMarkupLanguage）

5業(yè)務應用通用的設計和技術要求

5.1導則

業(yè)務應用完整的生命周期包括需求、設計、開發(fā)、運行和下線。具體要求如下：

a)需求應關注功能和非功能方面的要求。

b)設計需要服務化的方法、理論。

c)開發(fā)基于特定的開發(fā)框架，對應用和服務開發(fā)、測試和發(fā)布。

d)運行實現(xiàn)快速部署和服務監(jiān)控等功能。

e)下線通過卸載或關機完成。

5.2功能要求

功能要求應由業(yè)務應用系統(tǒng)自身能提供的功能決定，具體測試可參考DL/T1729-2017電力信息系

統(tǒng)功能及非功能性測試規(guī)范。

5.3非功能要求

非功能要求應滿足DL/T1731-2017電力信息系統(tǒng)非功能性需求規(guī)范。

5.4設計要求

參考GB/T35301和GB/T32399，部署并運行在云環(huán)境上的業(yè)務應用應滿足以下設計原則：

a)支持多實例集群。宜采用無中心節(jié)點的無狀態(tài)對等集群方式，并基于無狀態(tài)對等集群實現(xiàn)應用

的水平動態(tài)伸縮。通過負載均衡服務把用戶請求分發(fā)到任意一個實例節(jié)點，并對集群中的任意

實例節(jié)點的生命周期進行管理。

b)應用的進程宜無狀態(tài)且無共享（低耦合）、易處理，應用采用多種進程運行方式。

c)共享HTTP會話數(shù)據(jù)。應通過HTTP協(xié)議的HEAD方法獲取API接口的附加信息，通過GET、POST

等其它方法實現(xiàn)對API接口的調用。

d)避免操作本地文件系統(tǒng)。

e)緩存數(shù)據(jù)宜進行集中存儲。

f)應用到數(shù)據(jù)庫或其它服務的訪問發(fā)生中斷時，應有重試和熔斷機制。

g)應用通過端口綁定來提供服務，并監(jiān)聽發(fā)送至該端口的請求。端口綁定也意味著一個應用可成

為另外一個應用的后端服務，調用方將服務方提供的相應URL當作資源存入配置以備將來調

用。

h)配置數(shù)據(jù)統(tǒng)一管理。和部署環(huán)境相關的配置信息不應直接固化在程序包的配置文件中，應通過

統(tǒng)一配置方式設置相關配置項，如將應用的配置存儲于環(huán)境變量中。

i)統(tǒng)一日志輸出方式。應用系統(tǒng)日志應通過相應軟件的日志接口輸出日志。

5.5開發(fā)要求

3

XX/TXXXXX—XXXX

單體架構或微服務架構的業(yè)務應用應滿足的技術要求，具體如下：

a)容器鏡像：提供Linux和Windows等操作系統(tǒng)需要的基礎容器鏡像，應用鏡像需在基礎鏡像基

礎上制作,而且需按照一定的鏡像制作規(guī)范進行鏡像制作。

b)操作系統(tǒng)版本：RHEL6.8、Centos6.8、Windows2008及以上。

c)開發(fā)語言：微服務架構開發(fā)語言要求符合服務注冊、訂閱規(guī)范；消息總線發(fā)送/接收消息。

d)開放端口：微服務提供者的TCP監(jiān)聽端口不能與特定的端口沖突。

e)微服務命名規(guī)范：所有命名必須為小寫字母，命名中除了字母和數(shù)值外只允許使用“.”和英文

的句號來進行分隔，所有微服務名字中必須包含最少一個“.”分隔符。

5.6運行要求

運行要求主要針對一鍵部署和運行監(jiān)控這兩個功能進行闡述。

5.6.1部署

對業(yè)務應用的部署要求如下：

a)宜考慮高可用和負載均衡。

b)宜采用分層的部署結構，前端應用集群主要運行Web應用；后端應用集群主要運行核心業(yè)務邏

輯。

c)部署環(huán)境是虛擬機、容器或物理機。

d)部署方式一般采用手動、自動。

e)運行環(huán)境是內(nèi)網(wǎng)、外網(wǎng)。

對部署的要求具體應包括如下方面：

a)對應用部署包命名格式進行約束。

b)對目錄結構中應包括的文件夾和文件及用途進行說明。

c)對業(yè)務應用本身進行要求。

命名格式

應用提供方應通過固定格式說明應用部署包的應用名稱、編碼、版本、應用說明（描述）、開發(fā)單

位、測試單位等信息，見表1。其中應用描述文件、應用圖標和應用截圖均存儲在部署包的根目錄下。

表1應用描述信息要素

屬性說明備注

應用名稱應用的名稱應符合信息系統(tǒng)命名規(guī)范

英文名稱應用的英文名稱宜不超過20個字符，不應重名

應用版本應用的當前版本號應符合信息系統(tǒng)版本規(guī)范

應用圖標應用的圖標64*64像素，命名為appIco.gif

1024*1024像素，不超過8個截圖，宜2-4個截圖，按

應用截圖應用的典型頁面截圖

application1.gif、application2.gif規(guī)則延續(xù)

應用描述應用功能的詳細描述包含所有功能描述，命名為perties

4

XX/TXXXXX—XXXX

開發(fā)單位開發(fā)單位全稱開發(fā)單位

開發(fā)聯(lián)系人項目開發(fā)負責人開發(fā)聯(lián)系人

開發(fā)聯(lián)系方式開發(fā)聯(lián)系方式開發(fā)聯(lián)系方式

測試單位測試單位全稱測試單位

測試聯(lián)系人項目測試負責人測試聯(lián)系人

文件目錄結構

應用描述文件目錄結構如下：

#應用名稱

=xxx

#英文名稱

app.englishName=xxx

#應用版本

app.version=V3.0.0

#應用圖標

app.login=/**/**/LOG.PNG

#應用截圖

app.picture=/**/**/a.jpg;b.jpg;c.jpg

#應用描述

app.desc=xxxxxxxxxxx

#開發(fā)單位

app.developCompany=xxx

#開發(fā)聯(lián)系人

app.developer=xxx

#開發(fā)聯(lián)系方式

app.developerPhone=xxxxxxxxxxx

#測試單位

app.testCompany=xxx

#測試聯(lián)系人

app.tester=xxx

#測試聯(lián)系方式

app.testerPhone=xxxxxxxxxxx

應用本身

.1應用要求

對業(yè)務應用本身要求如下：

a)采用J2EEServer的應用程序對數(shù)據(jù)庫的訪問應采用JNDI方式，JNDI名稱應采用英文名稱_

5

XX/TXXXXX—XXXX

數(shù)據(jù)庫類型_jndi方式（如monitor_mysql_jndi），自動化部署過程中應采用此規(guī)則為應用系

統(tǒng)創(chuàng)建數(shù)據(jù)源；

b)應用程序的配置信息與應用包部署位置無關；

c)應用程序的日志數(shù)據(jù)應配置存儲到/var/log/英文名稱/英文名稱.log位置（如：

/var/log/bpm/task.log）。

.2部署準備

應用部署運行前，應完成以下準備操作后才可一鍵部署，再供業(yè)務人員訪問：

a)應用打包由應用開發(fā)軟件完成；

b)應用部署前應經(jīng)過相關的測試，再發(fā)布到相應軟件的鏡像倉庫；

c)將應用包部署到應用中間件并啟動應用，供業(yè)務人員使用。

5.6.2監(jiān)控

監(jiān)控設計要求除滿足通用軟件對業(yè)務應用系統(tǒng)監(jiān)控數(shù)據(jù)采集要求外，運行在云平臺上的應用或服務

應提供健康檢查的URL，云平臺主動調用URL檢查應用或服務的運行狀態(tài)；同時云平臺上的應用或服務應

輸出到控制中心或指定文件，用于云平臺收集和監(jiān)控。

監(jiān)控方式

監(jiān)控接口宜某段固定時間提取一次日志數(shù)據(jù)。單體架構是通過查看日志或利用SSH方式登錄到系統(tǒng)

的主機上查看，而微服務架構是通過日志組件實時抽取和檢索，供監(jiān)控組件為已部署的應用和服務設置

相應的告警策略。

資源占用

服務和應用運行占用的資源情況（如CPU、內(nèi)存、網(wǎng)絡等信息）的具體獲取方式需業(yè)務應用提供相

應的接口供云平臺調用。

運行狀態(tài)

應用和服務運行狀態(tài)（如響應時間、錯誤率和緩存命中率等指標）的監(jiān)控宜添加相關管理腳本和配

置文件；可查看運行服務的Web服務器或服務本身的日志監(jiān)控服務的響應時間（最低限度），進一步可

追蹤報告中錯誤出現(xiàn)的次數(shù)。

5.7安全要求

業(yè)務應用的安全要求除應滿足GB/T22239、GB/T22240、GB/T28452、GB/T31168、GB/T

35279、GB/T36639，還需滿足如下具體要求。

5.7.1通用安全要求

按照國家及電力行業(yè)相關的安全要求，信息系統(tǒng)分為二級和三級系統(tǒng)。系統(tǒng)總體安全防護應滿足物

理、邊界、網(wǎng)絡、應用、數(shù)據(jù)、主機和終端等7個層面的要求。具體要求參見GB/T31168-2014、GB/T

31915-2015。

5.7.2應用安全要求

云上的業(yè)務應用除遵循傳統(tǒng)通用的應用安全防護要求外，還應提供一些API接口供云平臺上的安全

防護組件調用。應按照“同級系統(tǒng)統(tǒng)一成域”的原則將信息系統(tǒng)部署到相應級別的安全域中，并按照其安

6

XX/TXXXXX—XXXX

全等級進行防護。業(yè)務系統(tǒng)根據(jù)應用系統(tǒng)的安全等級，按照信息安全等級保護要求提供應用安全方案。

還需重點考慮云平臺存在的混合架構應用的安全，云平臺應提供安全即服務。此外，參考GB/T

32399-2015。

5.8數(shù)據(jù)要求

在數(shù)據(jù)架構層面需要從業(yè)務角度對數(shù)據(jù)進行垂直或水平切分，并梳理出微應用需要對外暴露的服務

接口。

6單體架構應用和服務設計和技術要求

6.1適用場景

單體應用架構模式下，所有業(yè)務邏輯在同一個進程內(nèi)實現(xiàn)，功能間相互調用不需要網(wǎng)絡通信，性能

更高；無分布式事務、易于運維維護、不存在跨域問題等優(yōu)點。因此，單體應用適用于業(yè)務需求穩(wěn)定、

無需頻繁迭代；代碼相對簡單、易理解、易維護；編譯、部署、啟動、迭代周期要求不高；負載變化不

大；數(shù)據(jù)庫表之間緊耦合、多表關聯(lián)操作多、不易分庫的業(yè)務應用。

6.2設計要求

6.2.1設計原則

單體應用的設計要點如下：

a)應用統(tǒng)一上云原則。單體應用部署在內(nèi)網(wǎng)或外網(wǎng)，或同時部署。

b)數(shù)據(jù)統(tǒng)一存儲原則。數(shù)據(jù)庫選擇依據(jù)業(yè)務特性一般采用關系型數(shù)據(jù)庫。

6.2.2總體架構

總體架構的各層，如圖1所示。

a)接入門戶類型：企業(yè)門戶和移動門戶，實現(xiàn)用戶交互；

b)單體架構的業(yè)務應用基于云平臺實現(xiàn)相應功能。

7

XX/TXXXXX—XXXX

圖1單體架構的總體架構

6.2.3系統(tǒng)架構

系統(tǒng)架構推薦采用分層架構風格，宜上層調用下層，禁止下層調用上層，限制同層調用。包括展現(xiàn)

層、控制層、業(yè)務邏輯層、數(shù)據(jù)訪問層和數(shù)據(jù)存儲層，各層功能，如圖2所示：

a)展現(xiàn)層：負責頁面交互，運行在客戶端瀏覽器中；

b)控制層：負責接收前端請求并分發(fā)給業(yè)務邏輯層，將處理結果反饋給前端應用；

c)業(yè)務邏輯層：負責實現(xiàn)業(yè)務邏輯，業(yè)務邏輯可以進一步拆分為多層，如：服務層、接口層、業(yè)

務層、公共業(yè)務組件層、公共技術組件層等；

d)數(shù)據(jù)訪問層：負責實現(xiàn)數(shù)據(jù)訪問和持久化操作，包括對非結構化數(shù)據(jù)的操作，如針對關系型數(shù)

據(jù)庫的SQL語句執(zhí)行的操作等；

e)數(shù)據(jù)存儲層：負責實現(xiàn)數(shù)據(jù)的永久存儲，根據(jù)業(yè)務需求選擇數(shù)據(jù)庫類型，一般推薦關系型數(shù)據(jù)

庫；負責實現(xiàn)數(shù)據(jù)庫端的存儲過程、表索引，不推薦實現(xiàn)觸發(fā)器。

其中架構各層部署/運行設計如下：

a)控制層、業(yè)務邏輯層、數(shù)據(jù)訪問層的部署/運行在應用服務器端，實現(xiàn)業(yè)務邏輯；

b)數(shù)據(jù)存儲層的部署/運行在數(shù)據(jù)庫端，實現(xiàn)數(shù)據(jù)存儲和部分數(shù)據(jù)計算。

圖2單體架構的系統(tǒng)架構

6.2.4部署設計

部署設計主要包括如下方面：

a)邏輯部署單元設計。宜采用動靜分離設計；

b)物理部署節(jié)點設計。節(jié)點類型包括Web應用服務器、數(shù)據(jù)庫服務器等；

c)物理拓撲設計。適用于事務處理類應用在云上環(huán)境部署場景，描述業(yè)務應用系統(tǒng)物理部署拓撲

結構，以及邏輯部署單元在物理部署節(jié)點的分布。

邏輯部署

.1部署單元

部署單元要求如下：

a)可映射為一個或多個部署包；

b)部署單元大小宜小于500M；

c)部署單元類型可通過功能/模塊/組件進行劃分。

8

XX/TXXXXX—XXXX

.2部署節(jié)點

部署節(jié)點要求如下：

a)部署節(jié)點是部署單元所在的宿主系統(tǒng)，可通過部署單元的需求劃分類型；

b)一個部署節(jié)點包含多個部署單元（部署包）；

c)禁止單節(jié)點部署。

物理部署

物理部署拓撲包括內(nèi)網(wǎng)獨立部署、內(nèi)外網(wǎng)結合部署，具體要求如下：

a)內(nèi)網(wǎng)獨立部署（將應用、數(shù)據(jù)庫等全部部署在內(nèi)網(wǎng)）；

b)內(nèi)外網(wǎng)結合部署（數(shù)據(jù)庫部署在內(nèi)網(wǎng)，應用部署在外網(wǎng)；數(shù)據(jù)庫部署在內(nèi)網(wǎng)，應用同時部署在

內(nèi)網(wǎng)和外網(wǎng)）。

6.3技術要求

技術要求除應遵循5.1功能要求之外，還應滿足附錄A；非功能要求除滿足通用5.2非功能要求的

要求之外，還應滿足如下幾點：

a)部署對性能、可靠性要求高的大型系統(tǒng)時，推薦動靜分離部署，即Web服務器部署靜態(tài)資源，

應用服務器部署動態(tài)資源；并發(fā)要求不高的應用可動靜合并部署；

b)業(yè)務應用系統(tǒng)禁止單節(jié)點部署、數(shù)據(jù)庫禁止單節(jié)點部署，所有的部署均需要考慮高可用、負載

均衡，以及內(nèi)存數(shù)據(jù)庫、緩存數(shù)據(jù)和高性能計算場景要求。

6.4安全要求

單體架構的業(yè)務應用應遵循5.7安全要求。

7微服務架構應用和服務設計和技術要求

7.1適用場景

微服務架構模式下，每個微服務體量較小，代碼易于開發(fā)、維護、編譯、部署；開發(fā)迭代周期短，

運行故障隔離性好，利于彈性伸縮、頻繁部署，持續(xù)交付能力強。因此，微服務適用于隨著業(yè)務發(fā)展業(yè)

務，業(yè)務需求變動頻繁；代碼邏輯復雜、耦合度高、不易維護；編譯、部署、啟動、迭代周期要求高；

局部功能模塊有高并發(fā)、提供公共服務、故障隔離、快速頻繁迭代等特殊要求；模塊間數(shù)據(jù)庫表無緊密

耦合關系。

7.2設計要求

與傳統(tǒng)單體架構應用相比，微服務架構應用應更多地關注業(yè)務和技術層面的設計。

7.2.1設計原則

設計拆分微服務的原則如下：

a)通信方式

1)無狀態(tài)通信原則。Restful通信風格與開發(fā)語言無關，使用無狀態(tài)協(xié)議HTTP和JSON報文

序列化；

2)無狀態(tài)服務原則。把有狀態(tài)的業(yè)務服務改變?yōu)闊o狀態(tài)的計算類服務。

b)設計原則

9

XX/TXXXXX—XXXX

3)按不同服務功能的設計拆分原則；水平復制：運行多個實例時，使用集群+負載均衡模式；

數(shù)據(jù)分區(qū)：按照用戶請求地區(qū)進行數(shù)據(jù)分區(qū)，增加集群數(shù)量；拆分模式：基于不同的業(yè)務

設計拆分；

4)宜保持業(yè)務單一、高內(nèi)聚、松耦合：一個服務實現(xiàn)一個完整的獨立業(yè)務功能；

5)具有重用性特點的公共功能應設計拆分為獨立微服務；

6)訪問量較大、資源消耗較大、耗時較長的功能，應設計拆分為獨立微服務；

7)耦合性強、存在事務強一致性的業(yè)務，不要拆分到多個微服務內(nèi)，宜避免分布式事務；

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

9)需訪問全業(yè)務統(tǒng)一數(shù)據(jù)中心處理域數(shù)據(jù)庫的微服務，宜為每個微服務設計獨立數(shù)據(jù)庫；

10)保持微服務架構簡單性、避免分布式數(shù)據(jù)庫事務、減少非必要的聚合服務。

c)拆分原則

1)高負載服務拆分原則。根據(jù)已存在的業(yè)務服務，拆分出高負載點，分析并發(fā)負載、長連接

負載、高計算負載、數(shù)據(jù)庫負載、文件操作負載等；

2)避免業(yè)務應用過度拆分原則。避免業(yè)務應用系統(tǒng)過度拆分為大量的微服務；

3)業(yè)務完整、職責單一的應用功能單元應當拆分為獨立微服務。該單元建議為三級或三級以

下應用功能，例如“物資管理（一級）->采購管理（二級）—>投標管理（三級）->標書上

傳（四級）”；

4)建議業(yè)務應用包含的微服務數(shù)量是三級應用功能的1/3倍到5倍（拆分過細維護困難、影

響性能；拆分過粗達不到解耦目的?？紤]到實際應用中個別模塊之間耦合度比較高或引起

分布式事務，可以合并成一個微服務，或某個模塊過大，可以拆分為多個微服務）。

5)具有重用性特點的公共功能應當拆分為獨立微服務；

6)訪問量較大、資源消耗較大、耗時較長的功能，應拆分為獨立微服務；

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

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

d)開發(fā)原則

1)前后端分離原則。技術分離：前后端代碼分離，物理分離：部署方式；

2)采用面向接口的設計，需遵循接口穩(wěn)定性和向前兼容的原則；

3)接口定義推薦遵循“單一職責”原則，采用外觀模式，實現(xiàn)微服務對外接口和內(nèi)部邏輯組件

的解耦。

7.2.2總體架構

總體架構的各層功能，如圖3所示：

a)接入門戶類型：企業(yè)門戶和移動門戶，實現(xiàn)用戶交互；

b)微服務架構的業(yè)務應用基于云平臺實現(xiàn)相應功能。

10

XX/TXXXXX—XXXX

圖3微服務架構的總體架構

7.2.3系統(tǒng)架構

系統(tǒng)架構設計宜采用分層架構風格，微服務間訪問依賴不宜超過5層；微服務間禁止出現(xiàn)循環(huán)依賴。

分為微應用層、微服務層、數(shù)據(jù)存儲層，各層功能如圖4所示：

a)展現(xiàn)層：瀏覽器提供微應用訪問入口；

b)微應用層：采用的技術框架決定了架構模式；

c)微服務層：包括公共服務和業(yè)務處理服務。公共服務提供日志等公共服務；業(yè)務處理服務處理

業(yè)務規(guī)則，訪問數(shù)據(jù)庫；

d)數(shù)據(jù)存儲層：負責實現(xiàn)數(shù)據(jù)的永久存儲，根據(jù)業(yè)務需求選擇數(shù)據(jù)庫類型，宜選擇關系型數(shù)據(jù)庫；

負責實現(xiàn)數(shù)據(jù)庫端的存儲過程、表索引，不宜選擇實現(xiàn)觸發(fā)器。

圖4微服務架構的系統(tǒng)架構

7.2.4部署設計

部署設計主要包括如下方面：

a)邏輯部署單元設計。每個部署單元宜包括一個到多個微服務；

11

XX/TXXXXX—XXXX

b)物理部署節(jié)點設計。節(jié)點類型包括：微服務部署節(jié)點、數(shù)據(jù)庫部署節(jié)點；

c)發(fā)布設計。宜采用多版本共存的灰度發(fā)布方式。

邏輯部署

.1部署單元

部署單元要求如下：

a)每個部署單元包括一個或多個微服務；

b)高負載服務,宜單獨部署。

.2部署節(jié)點

微服務部署基于云平臺部署，包含微服務部署節(jié)點和數(shù)據(jù)庫部署節(jié)點。

物理部署

物理部署拓撲包括三類部署模式，具體要求如下：

a)內(nèi)網(wǎng)獨立部署（將應用、數(shù)據(jù)庫等全部部署在內(nèi)網(wǎng)）；

b)外網(wǎng)獨立部署（數(shù)據(jù)庫、應用全部部署在外網(wǎng)）；

c)內(nèi)外網(wǎng)同時部署（數(shù)據(jù)庫部署在內(nèi)網(wǎng)，應用部署在外網(wǎng)；數(shù)據(jù)庫部署在內(nèi)網(wǎng)，應用分別部署在

內(nèi)網(wǎng)和外網(wǎng)）。

7.3技術要求

技術要求除應遵循5.1功能要求之外，還應滿足附錄B；非功能要求除滿足通用5.2非功能要求

之外，還應滿足如下幾點：

a)在承載業(yè)務應用運行的服務器發(fā)生故障時，自動啟動新服務器，恢復故障服務器所有信息，保

障業(yè)務應用不間斷運行的故障自愈時間；

f)每個部署單元包括一個到多個微服務，高負載服務建議部署為單獨的部署單元。

7.4安全要求

微服務架構的業(yè)務應用應遵循5.7安全要求。

8對外的公共服務的設計與技術要求

8.1設計要求

業(yè)務應用系統(tǒng)的服務接口設計過程中要考慮到與PaaS應用程序管理相關的PaaS服務提供者的服務

供應，PaaS服務消費者使用云平臺服務部署運行應用程序以及PaaS協(xié)作者基于PaaS應用程序管理的功

能提供第三方服務的場景的接口設計。

8.2技術要求

8.2.1單體架構的服務

單體架構的服務技術要求應滿足GB/T29263和GB/T32430。

8.2.2微服務架構的服務

12

XX/TXXXXX—XXXX

微服務架構的服務技術要求應遵循7.2.2微服務設計原則,主要闡述接口要求。

概述

參考GB/T36623和GB/T36610-2018，服務接口要求適用于服務和應用的規(guī)劃、設計、建設、開發(fā)、

測試、使用和維護等相關過程，如圖5所示：

a)服務接口是一系列RESTful風格的API，用于云平臺環(huán)境中技術平臺組件之間、技術平臺組件

與業(yè)務應用系統(tǒng)之間、業(yè)務應用系統(tǒng)與業(yè)務應用系統(tǒng)之間的互相操作和調用；

b)對于業(yè)務應用系統(tǒng)和云平臺組件的私有用途的API不做要求；

c)服務消費者包括最終用戶或者其它系統(tǒng)實例；

d)服務提供者（業(yè)務應用系統(tǒng)和云平臺組件）基于服務接口要求通過HTTPRESTful接口為服務

消費者提供服務；

e)REST(RepresentationalStateTransfer)從資源的角度來觀察整個IT系統(tǒng)，分布在各處

的資源位置和名稱由URI指定，對資源的操作包括獲取、創(chuàng)建、修改和刪除資源，這些操作對

應HTTP協(xié)議提供的GET、POST、PUT和DELETE方法；

f)RESTfulWeb服務（也稱為RESTfulWebAPI）是一個使用HTTP并遵循REST原則的Web

服務。它從以下三個方面定義資源的管理：

1)URI資源位置，比如：/resources/；

2)Web服務接受與返回的數(shù)據(jù)類型，比如：JSON，XML等；

3)Web服務在該資源上所支持的一系列請求方法（比如：GET、HEAD、POST、PUT、PATCH

或DELETE）。

圖5服務接口在服務提供者架構中的定位

本部分描述的服務接口要求建立了信息系統(tǒng)IT資源層次模型，參考GB/T36325，具體如下：

a)以遵循信息化架構中確定的業(yè)務應用系統(tǒng)名稱實現(xiàn)對資源標識名稱的標準化；

b)制定了RESTfulWebServices設計原則；

c)并規(guī)定了業(yè)務應用系統(tǒng)為使用云平臺提供的故障自愈等能力需要提供的公共接口；

d)為云服務提供者和云服務客戶（簡稱：雙方)建立云服務級別協(xié)議提供指導；

e)為客戶對提供者交付的云服務進行考評提供參考依據(jù)；

f)為第三方進行云服務級別協(xié)議評估提供參考依據(jù)。

IT系統(tǒng)（資源）層次模型

RESTfulWebAPI采用面向資源的架構。信息系統(tǒng)資源層次模型共分為三層，如圖6所示：

a)下面兩層級可根據(jù)管理需求進行擴展；

b)在資源層次模型的第三層中，具體的技術平臺組件和應用系統(tǒng)資源標識均需采用信息化架構中

定義的組件名稱；

13

XX/TXXXXX—XXXX

c)技術平臺組件包括云平臺中的IaaS和PaaS的各組件；

d)業(yè)務應用系統(tǒng)包括電力行業(yè)各業(yè)務域中的應用系統(tǒng)，這些組件的命名均需采用企業(yè)信息架構模

型中定義的組件名稱；

e)技術平臺組件和業(yè)務應用系統(tǒng)包含的更詳細的資源信息由它們自行定義。

圖6資源層次模型

RESTful服務設計原則

.1資源標識與版本管理

一個資源應具有一個或多個標識，采用URI作為資源標識。為保證URI的“可尋址性”和“可讀性”，采

用路徑變量來表達資源層次結構，URI的目錄結構約定如下：

{協(xié)議}//{域名}/{版本}/{請求操作}

a)協(xié)議：服務接口與用戶請求之間的通信協(xié)議，宜使用HTTPS協(xié)議；

b)域名：采用8.2IT系統(tǒng)（資源）層次模型中約定的系統(tǒng)的域名，例如：；

c)版本：API的版本信息，例如：/v1.0.0；

d)請求操作：代表API服務的業(yè)務操作名稱，采用動名詞組合的方式，具體內(nèi)容由各業(yè)務應用系

統(tǒng)或云平臺技術組件自行確定。

e)例如創(chuàng)建流程：/v1.0.0/createProcess。

.2資源數(shù)據(jù)格式約定

資源請求參數(shù)格式與服務器返回的數(shù)據(jù)格式，應使用標準的JSON格式。

.3資源請求方式約定

HTTP請求方法的具體含義，見表2：

表2HTTP請求方法

狀態(tài)碼含義

14

XX/TXXXXX—XXXX

HEAD用于數(shù)據(jù)類（如結構化數(shù)據(jù)和非結構化數(shù)據(jù)）請求的元數(shù)據(jù)獲取

GET用于查詢操作，不應產(chǎn)生數(shù)據(jù)的修改或變更

PUT用于新增操作

PATCH用于更新操作

DELETE用于刪除操作

POST