ICS點擊此處添加ICS號

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

DL

中華人民共和國電力行業標準

XX/TXXXXX—XXXX

電力行業云應用設計與技術要求

RequirementofDesignandTechniqueforCloudApplicationsinElectricPower

Industry

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

（征求意見稿）

XXXX-XX-XX發布XXXX-XX-XX實施

發布

XX/TXXXXX—XXXX

I

XX/TXXXXX—XXXX

電力行業云應用設計與技術要求

1范圍

本標準規定電力行業可部署運行在云環境中、能統一適配云計算特性的業務應用和服務的設計和技

術要求，制定本標準。

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

2規范性引用文件

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

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

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

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

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

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

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

GB/T29831.3-2013系統與軟件功能性第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信息技術云計算云服務級別協議基本要求

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

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

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

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

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

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

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

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

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

DL/T860.2-2006變電站通信網絡和系統第2部分：術語

DL/T1729-2017電力信息系統功能及非功能性測試規范

DL/T1731-2017電力信息系統非功能性需求規范

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

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

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

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

行獨立擴展。

3.4云平臺cloudplatform

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

[GB/T35301-2017，定義3.1.2]

3.5基礎設施即服務infrastructureasaservice；IaaS

云服務提供商向云服務用戶提供計算、存儲、云內網絡連接服務（如虛擬局域網、防火墻愛、負載

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

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

分的網絡組件。

[YD/T2806-2015，定義2.1.3]

3.6平臺即服務platformasaservice；PaaS

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

[GB/T35301-2017，定義3.1.1]

4縮略語

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

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

CS：云服務（CloudService）

HTTP：超文本傳輸協議（HyperTextTransferProtocol）

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

J2EE：Java2平臺企業版（Java2PlatformEnterpriseEdition）

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

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

2

XX/TXXXXX—XXXX

OSGI：Java語言動態模塊化系統的一系列規范（OpenServiceGatewayInitiative）

PaaS：平臺即服務（PlatformasaService）

REST：表述性狀態傳遞（RepresentationalStateTransfer）

URI：統一資源標識符（UniformResourceIdentifier）

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

5業務應用通用的設計和技術要求

5.1導則

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

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

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

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

d)運行實現快速部署和服務監控等功能。

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

5.2功能要求

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

統功能及非功能性測試規范。

5.3非功能要求

非功能要求應滿足DL/T1731-2017電力信息系統非功能性需求規范。

5.4設計要求

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

a)支持多實例集群。宜采用無中心節點的無狀態對等集群方式，并基于無狀態對等集群實現應用

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

實例節點的生命周期進行管理。

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

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

等其它方法實現對API接口的調用。

d)避免操作本地文件系統。

e)緩存數據宜進行集中存儲。

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

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

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

用。

h)配置數據統一管理。和部署環境相關的配置信息不應直接固化在程序包的配置文件中，應通過

統一配置方式設置相關配置項，如將應用的配置存儲于環境變量中。

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

5.5開發要求

3

XX/TXXXXX—XXXX

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

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

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

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

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

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

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

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

5.6運行要求

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

5.6.1部署

對業務應用的部署要求如下：

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

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

輯。

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

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

e)運行環境是內網、外網。

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

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

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

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

命名格式

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

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

表1應用描述信息要素

屬性說明備注

應用名稱應用的名稱應符合信息系統命名規范

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

應用版本應用的當前版本號應符合信息系統版本規范

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

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

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

application1.gif、application2.gif規則延續

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

4

XX/TXXXXX—XXXX

開發單位開發單位全稱開發單位

開發聯系人項目開發負責人開發聯系人

開發聯系方式開發聯系方式開發聯系方式

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

測試聯系人項目測試負責人測試聯系人

文件目錄結構

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

#應用名稱

=xxx

#英文名稱

app.englishName=xxx

#應用版本

app.version=V3.0.0

#應用圖標

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

#應用截圖

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

#應用描述

app.desc=xxxxxxxxxxx

#開發單位

app.developCompany=xxx

#開發聯系人

app.developer=xxx

#開發聯系方式

app.developerPhone=xxxxxxxxxxx

#測試單位

app.testCompany=xxx

#測試聯系人

app.tester=xxx

#測試聯系方式

app.testerPhone=xxxxxxxxxxx

應用本身

.1應用要求

對業務應用本身要求如下：

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

5

XX/TXXXXX—XXXX

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

統創建數據源；

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

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

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

.2部署準備

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

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

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

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

5.6.2監控

監控設計要求除滿足通用軟件對業務應用系統監控數據采集要求外，運行在云平臺上的應用或服務

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

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

監控方式

監控接口宜某段固定時間提取一次日志數據。單體架構是通過查看日志或利用SSH方式登錄到系統

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

相應的告警策略。

資源占用

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

應的接口供云平臺調用。

運行狀態

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

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

追蹤報告中錯誤出現的次數。

5.7安全要求

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

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

5.7.1通用安全要求

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

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

31915-2015。

5.7.2應用安全要求

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

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

6

XX/TXXXXX—XXXX

全等級進行防護。業務系統根據應用系統的安全等級，按照信息安全等級保護要求提供應用安全方案。

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

32399-2015。

5.8數據要求

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

接口。

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

6.1適用場景

單體應用架構模式下，所有業務邏輯在同一個進程內實現，功能間相互調用不需要網絡通信，性能

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

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

大；數據庫表之間緊耦合、多表關聯操作多、不易分庫的業務應用。

6.2設計要求

6.2.1設計原則

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

a)應用統一上云原則。單體應用部署在內網或外網，或同時部署。

b)數據統一存儲原則。數據庫選擇依據業務特性一般采用關系型數據庫。

6.2.2總體架構

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

a)接入門戶類型：企業門戶和移動門戶，實現用戶交互；

b)單體架構的業務應用基于云平臺實現相應功能。

7

XX/TXXXXX—XXXX

圖1單體架構的總體架構

6.2.3系統架構

系統架構推薦采用分層架構風格，宜上層調用下層，禁止下層調用上層，限制同層調用。包括展現

層、控制層、業務邏輯層、數據訪問層和數據存儲層，各層功能，如圖2所示：

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

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

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

務層、公共業務組件層、公共技術組件層等；

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

據庫的SQL語句執行的操作等；

e)數據存儲層：負責實現數據的永久存儲，根據業務需求選擇數據庫類型，一般推薦關系型數據

庫；負責實現數據庫端的存儲過程、表索引，不推薦實現觸發器。

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

a)控制層、業務邏輯層、數據訪問層的部署/運行在應用服務器端，實現業務邏輯；

b)數據存儲層的部署/運行在數據庫端，實現數據存儲和部分數據計算。

圖2單體架構的系統架構

6.2.4部署設計

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

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

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

c)物理拓撲設計。適用于事務處理類應用在云上環境部署場景，描述業務應用系統物理部署拓撲

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

邏輯部署

.1部署單元

部署單元要求如下：

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

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

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

8

XX/TXXXXX—XXXX

.2部署節點

部署節點要求如下：

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

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

c)禁止單節點部署。

物理部署

物理部署拓撲包括內網獨立部署、內外網結合部署，具體要求如下：

a)內網獨立部署（將應用、數據庫等全部部署在內網）；

b)內外網結合部署（數據庫部署在內網，應用部署在外網；數據庫部署在內網，應用同時部署在

內網和外網）。

6.3技術要求

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

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

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

應用服務器部署動態資源；并發要求不高的應用可動靜合并部署；

b)業務應用系統禁止單節點部署、數據庫禁止單節點部署，所有的部署均需要考慮高可用、負載

均衡，以及內存數據庫、緩存數據和高性能計算場景要求。

6.4安全要求

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

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

7.1適用場景

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

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

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

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

耦合關系。

7.2設計要求

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

7.2.1設計原則

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

a)通信方式

1)無狀態通信原則。Restful通信風格與開發語言無關，使用無狀態協議HTTP和JSON報文

序列化；

2)無狀態服務原則。把有狀態的業務服務改變為無狀態的計算類服務。

b)設計原則

9

XX/TXXXXX—XXXX

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

數據分區：按照用戶請求地區進行數據分區，增加集群數量；拆分模式：基于不同的業務

設計拆分；

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

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

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

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

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

9)需訪問全業務統一數據中心處理域數據庫的微服務，宜為每個微服務設計獨立數據庫；

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

c)拆分原則

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

負載、高計算負載、數據庫負載、文件操作負載等；

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

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

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

傳（四級）”；

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

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

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

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

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

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

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

d)開發原則

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

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

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

的解耦。

7.2.2總體架構

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

a)接入門戶類型：企業門戶和移動門戶，實現用戶交互；

b)微服務架構的業務應用基于云平臺實現相應功能。

10

XX/TXXXXX—XXXX

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

7.2.3系統架構

系統架構設計宜采用分層架構風格，微服務間訪問依賴不宜超過5層；微服務間禁止出現循環依賴。

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

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

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

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

業務規則，訪問數據庫；

d)數據存儲層：負責實現數據的永久存儲，根據業務需求選擇數據庫類型，宜選擇關系型數據庫；

負責實現數據庫端的存儲過程、表索引，不宜選擇實現觸發器。

圖4微服務架構的系統架構

7.2.4部署設計

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

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

11

XX/TXXXXX—XXXX

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

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

邏輯部署

.1部署單元

部署單元要求如下：

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

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

.2部署節點

微服務部署基于云平臺部署，包含微服務部署節點和數據庫部署節點。

物理部署

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

a)內網獨立部署（將應用、數據庫等全部部署在內網）；

b)外網獨立部署（數據庫、應用全部部署在外網）；

c)內外網同時部署（數據庫部署在內網，應用部署在外網；數據庫部署在內網，應用分別部署在

內網和外網）。

7.3技術要求

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

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

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

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

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

7.4安全要求

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

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

8.1設計要求

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

供應，PaaS服務消費者使用云平臺服務部署運行應用程序以及PaaS協作者基于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，服務接口要求適用于服務和應用的規劃、設計、建設、開發、

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

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

與業務應用系統之間、業務應用系統與業務應用系統之間的互相操作和調用；

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

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

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

消費者提供服務；

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

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

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

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

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

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

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

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

或DELETE）。

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

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

a)以遵循信息化架構中確定的業務應用系統名稱實現對資源標識名稱的標準化；

b)制定了RESTfulWebServices設計原則；

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

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

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

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

IT系統（資源）層次模型

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

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

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

定義的組件名稱；

13

XX/TXXXXX—XXXX

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

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

型中定義的組件名稱；

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

圖6資源層次模型

RESTful服務設計原則

.1資源標識與版本管理

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

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

{協議}//{域名}/{版本}/{請求操作}

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

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

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

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

統或云平臺技術組件自行確定。

e)例如創建流程：/v1.0.0/createProcess。

.2資源數據格式約定

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

.3資源請求方式約定

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

表2HTTP請求方法

狀態碼含義

14

XX/TXXXXX—XXXX

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

GET用于查詢操作，不應產生數據的修改或變更

PUT用于新增操作

PATCH用于更新操作

DELETE用于刪除操作

POST