《电力行业云服务设计与技术要求》

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