金融行业联机交易系统分布式技术规范-征求意见稿

ICS

团体标准

CESA-2019-2-009

金融行业联机交易系统分布式技术规范

征求意见稿

Distributedtechnicalspecificationforonlinetransactionsysteminfinancialindustry

在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上。

2019--发布2019-XX-实施

中国电子工业标准化技术协会发布

CESA-2019-2-009

前言

本标准按照GB/T1.1–2009《标准化工作导则第1部分：标准的结构和编写》给出的规则起草。

本标准由中国电子工业标准化技术协会（SAC/TC180）提出并归口。

本标准起草单位：神州数码融信软件有限公司、重庆银行股份有限公司、阜新银行股份有限公司、

宁夏银行股份有限公司、石嘴山银行股份有限公司、吉林亿联银行股份有限公司、中信百信银行股份有

限公司。

本标准主要起草人：

III

CESA-2019-2-009

引言

互联网正在深刻的影响着整个社会，金融行业跟互联网的对接已经成为必然趋势，其给金融行业带

来新的机遇的同时也带来巨大的挑战，主要体现在：

•大并发：由于基于互联网上的用户没有地域的限制，所以系统的并发用户数将大大超过传统

业务；

•大数据量：用户在任何时间、任何地方都可以进行交易，这些大量交易背后又会产生大量的

数据；

•浪涌现象：一些热门的互联网产品，会造成客户交易的过度集中，最典型的就是秒杀或者是

双十一这类活动；

•快速灵活：互联网加速了行业竞争，银行要快速占领市场就需要自身快速灵活。

同时金融行业由于其自身的特点，跟一般的互联网企业又有着很大的区别，主要表现在：

•业务复杂度高：金融行业的业务不仅要满足业务本身的要求，同时还要满足各种监管的强制

约束，同时由于涉及账务处理，所以整体的复杂度相对纯互联网的业务要高很多。

•数据一致性要求高：由于大部分业务都跟账务有关，所以其对事务的一致性要求是强一致，

这点跟互联网企业中使用的最终一致等其他方式是有着本质的区别。

上述挑战在金融行业的传统架构下很难解决，云计算和大数据也主要是解决通用层面的问题，跟

金融行业联机交易系统的诉求还有一定距离。经过不断的探索，分布式技术已经被行业认为是解决上

述问题的有效手段，这里的分布式更多的是强调将分布式的理念，灵活的运用到金融领域的具体业务

场景，解决具体问题，并不是简单的引入一些现成技术。

本标准为金融行业采用分布式技术建设联机交易系统提供规范性指导，明确分布式应覆盖的层面，

以及在具体层面应具备的基础功能。

CESA-2019-2-009

金融行业联机交易系统分布式技术规范

1范围

本标准规定了分布式联机交易系统应覆盖的范围，以及在具体范围内应具备的基础功能。

本标准适用于金融行业采用分布式技术进行联机交易系统建设时使用。

本标准不适用于金融行业分析类系统的建设，以及其他非金融类行业（金融行业分析类系统的建

设，以及其他非金融类行业可参考本标准执行）。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本

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

GB/T10113—2003分类与编码通用术语

GB/T5271.1-2000信息技术词汇第1部分：基本术语

3术语和定义

下列术语和定义适用于本文件：

3.1

数据data

信息的可再解释的形式化表示，以适用于通信、解释或处理。

注：可以通过人工或自动手段处理数据。

[GB/T5271.1-2000.定义01.01.02]

3.2

网络network

由计算机或者其他信息终端及相关设备组成的按照一定的规则和程序对信息进行收集、存储、

传输、交换、处理的系统。

3.3

分布式distributed

在计算机领域中，指物理上由多个不同的机器参与执行，但在逻辑上完成的是一个任务，对

使用者来说，就像一台计算机在执行一样。

3.4

事务transaction

<计算机>访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。

注：一个事务如果执行成功就全部提交，如果有一个失败就全部回滚。

3.5

分布式事务distributedtransaction

指涉及多个不同事务资源的事务（例如：多个数据库或者多个应用系统）。

注：由于每个事务资源在物理上是完全独立的，所以其的一致性保证相对于单个数据库的事务要复杂的多。

1

CESA-2019-2-009

4分布式覆盖范围

金融行业采用分布式技术建设联机交易系统时，应将分布式技术全面的应用到系统的各个层面，

使每个层面都具备分布式的特性，当性能遇到瓶颈的时候都可以通过横向扩展的策略予以解决；并且

对于行业特有的问题（例如：分布式事务）应有具体的解决方案。具体应包括：

a)服务层分布式：主要以微服务的形式体现，可以将一个复杂系统拆分为多个微服务，不仅可

以增加多台机器提供服务，还可以快速灵活的应对的业务变化。

b)数据层分布式：可以将大数据量表中的数据进行水平切分，用多个物理库来承载，不仅降低

了单表的数据量，还增加了可用的物理资源。

c)缓存层分布式：对于大量的数据库查询请求，可以采用分布式缓存的机制进行存储，降低对

数据库的交互次数，降低服务的响应时间。

d)分布式统一调度：提供分布式的统一调度，来协调多个微服务节点及数据库节点全部参与运

行，充分利用资源，将批量处理的时间控制在有效范围内。

e)分布式事务：由于金融业务的特殊性，对事务一致性的要求比其他行业都要高，所以，在上

述的分布式体系下，还要提供跨数据库、跨微服务的事务一致性保证。

5服务层分布式

5.1概述

服务层分布式的主要目标是为联机交易系统提供服务分布式的运行机制，以及配套的管理体系，

结合行业的最新发展趋势，最终体现为完整的微服务运行体系，主要包括：微服务运行引擎、微服务

网关和运维监控三个大的部分。

5.2微服务运行引擎

微服务运行引擎应包括如下主要功能：

a)服务注册/发现：服务提供者在启动的时候将服务相关信息注册到“注册中心”，服务消费者

通过“注册中心”可以获取到最新的服务列表；同样当服务提供者下线时，注册信息可以从

“注册中心”剔除，服务消费者可以更新服务提供者列表。

b)负载均衡：服务消费者调用提供者的时候，可以根据本地的列表依据一定的负载均衡算法进

行调用。

c)自动隔离/恢复：当服务提供者出现异常情况（例如宕机），可以自动从“注册中心”删除，

当其恢复后又可以自动加入，期间消费者可以同步获取到最新的服务提供者列表。

d)集群容错：当某一次的服务调用发生异常的情况下，可以提供多种容错机制，例如：重试

（可以设定重试次数）、直接抛错等机制。

5.3微服务网关

微服务网关为外部系统访问该系统提供统一的接入及控制，应包括：

a)服务鉴权：对服务的访问进行控制，只有在一定权限范围内的才可以访问，否则将拒绝请求。

b)流量控制：对请求的总量进行控制，如果超过限制则后续的请求将会被拒接或者等待。还可

以按具体的业务维度进行更细粒度的控制，例如：按交易渠道进行控制。

c)熔断降级：如果某个服务的失败率比较高，或者发现一些明确的异常情况，有可能影响到其

2

CESA-2019-2-009

他服务的正常运行，自动切断该服务的所有请求（直接抛错或者返回约定信息），以保护系

统整体的可用性。

5.4运维监控

运维监控是微服务体系的重要组成部分，应包括：

a)灰度发布：某个不面向全部用户的微服务有新的版本要发布，可以通过灰度发布只对部分用

户开放，当运行一段时间如果效果好的话再对所有用户开放

b)统一配置：微服务涉及的部署数量比较多，如果手动一个一个修改配置文件，不仅效率比较

低，还容易出错，并且跟微服务的初衷有所背离，所以一个统一的配置中心非常必要，通过

该配置中心可以快速完成多个实例的相关参数的调整，并实时生效。同时提供配置信息的版

本管理，防止配置出现问题时的统一回退。

c)服务治理：服务治理主要对服务运行态的情况进行动态调控。

1)负载策略调整：可以对运行态的多个服务提供者的负载均衡策略进行调整，防止某个提

供者上的负载过高。

2)流控策略调整：可以根据实际需要，对流量控制的策略进行动态调整。

3)熔断降级控制：对服务的熔断及降级的策略进行调整。

4)路由控制：通过配置对服务的路由策略进行干预，例如：暂时把某一个服务提供者屏蔽。

d)调用链跟踪：有些交易涉及多个微服务之间的调用，为了更加方便定位问题，以及对服务执

行情况进行跟踪，需要提供服务的完整调用链路信息，据此可以查看某些异常情况发生时的

具体信息，以及各个子服务的调用耗时等。

e)分布式日志：把分布式系统下的相关日志信息进行采集、汇总，把跨多个系统的日志串接起

来，并提供统一的页面按不同维度查询相关日志信息。

f)监控告警：对相关的监控对象制定告警策略，当其达到告警条件的时候需要产生告警信息，

以便运维人员及时处理。监控对象应至少包括系统运行资源、服务的运行情况，当发现系统

处理资源不足（例如：CPU长时间大于80%）的情况，宜自动增加运行实例，以提升系统整体

的处理能力。

6数据层分布式

6.1概述

数据层分布式的主要目的是将大数据量的关系型表通过水平拆分的方式，将其的数据分布式的存

储到多个不同的节点，访问的时候也可以到具体的位置快速访问。行业内主要包括从技术架构层实现

和采用独立的“分布式数据库”两种主要模式。考虑到分布式数据库是一个单独的领域，该部分不包

含在本标准内，本标准仅涉及技术架构层实现模式，主要包括：数据路由、SQL兼容性及数据库无关

性三个方面。

6.2主要用语说明

数据层分布式涉及到主要术语主要包括：

a)数据分片：将一张表的数据按照一定规则进行拆分，经过拆分后的每一部分数据叫做一个数

据分片，简称分片。

b)分片键：具体的拆分过程，必须针对某一个业务属性，按照一定规则进行，这里的业务属性

就是所谓的分片键，分片键一般都是表中的字段。例如，对“客户信息”表按照“客户号”

3

CESA-2019-2-009

取模的方式进行拆分，这里的“客户号”就是分片键，有时也叫拆分键。

c)拆分算法：也叫分片算法，指用于计算相关数据在哪个分片的算法，上述示例中的取模就是

一种常用的拆分算法。

d)路由：按照拆分算法将具体的SQL发送到具体的分片上执行的过程称为路由。

e)数据节点：简称节点，其概念有点类似于上述的分片，但分片主要是从数据的视角来看的，

属于一个逻辑概念，而节点则泛指每个分片的物理体现。当然物理体现的方式又有多种，最

常用的就是一个分片对应一个数据库实例；有时候一个分片对应一个数据库实例下的一个

database或者schema。

f)分库：当一个分片对应一个数据库实例的时候，一般将这里的每一个数据库俗称为分库。

g)分表：当一个分片对应一个数据库表的时候，一般将这里的每一个表俗称为分表。

6.3数据路由

数据路由是该模式的核心功能，主要为数据的拆分提供策略性支持，应包括：

a)提供成熟的拆分算法：应包括取模、日期、范围、枚举、hash等常用算法。

b)支持自定义拆分算法：在上述基本的拆分算法之外提供扩展机制，让开发人员可以根据实际

业务需要自定义跟业务更加匹配的算法。

c)同时支持分库和分表：不仅支持分库，还支持在分库的基础上进行分表，以防止在某些情况

下分库数过多，造成运维的不可控。

d)指定路由：对某些特殊的SQL支持指定节点执行。

e)间接路由：对于一些使用率较高的SQL，但其WHERE条件又不包含分片键的情况（例如：客

户信息表按客户号分片，用手机号查询），应提供间接通过分片键路由的机制。

f)多维路由：支持同时按多个维度进行拆分及路由。

6.4SQL兼容性

该机制应支持金融行业常用的SQL语句类型，主要包括：

a)支持命中分片键的增删改查；

b)跨库的聚合函数、关联查询、排序、分页、分组、联合查询等常用组合；

c)支持常用的字符串、数学、日期类、格式化及聚合函数；

6.5数据库无关性

该机制不应跟具体的数据库绑定，应支持常用的关系型数据库。

7缓存层分布式

本标准提到的缓存层分布式主要指缓存的分布式访问，并不是指提供一个分布式的缓存服务器。

主要提供低侵入的分布式缓存（行业内目前基本以redis为主）的访问机制，但必须考虑金融场景对

数据准确性的要求。具体应包括：

a)提供基础的分布式访问的API：提供缓存分布式访问的基础API，为业务框架及特殊情况使用

提供支持。

b)提供跟数据库配合的读写支持：对于跟数据库配合的查询时，优先从缓存中查询，如果缓存

中没有再查数据库，并把结果放置到缓存中；对于写操作，提供机制保证缓存跟数据库的数

据一致性。上述操作应降低对业务的侵入，如果是基于Java的实现宜采用注解的模式。

4

CESA-2019-2-009

c)脏数据的控制：如果并发的对缓存中的同一个数据进行变更，或者一个缓存的变更跟查询交

叉在一起的极端情况下，有可能造成脏数据，需要提供完善的应对机制。

8分布式统一调度

分布式统一调度主要应对分布式系统各种任务的协同工作，最大限度发挥分布式系统的特性，以

更高效的方式完成待处理任务。具体要求应包括：

a)通过任务定义可以定义具体要执行的任务，并且定义之间的依赖关系；

b)具体执行过程，应依据上述定义的依赖关系进行执行，并对出现异常的任务提供异常信息查

看，及支持重新执行。执行过程中应将任务分配到多个执行节点上去执行，如果该节点有异

常应切换到其他节点执行。

c)调度节点应提供机制保证在任何时间都有一个调度节点可用。

d)对涉及大数据量的表的任务，应支持对数据进行分段，将其拆分为多个小的任务并行到多个

节点上执行，以提升整体处理效率。

e)应至少支持手动执行和定时执行两种方式。

f)应可视化的查看任务的执行情况，并及时进行相关控制操作。

9分布式事务

9.1概述

分布式事务是金融行业重点关注的问题，不同的业务场景对事务的关注点也有一定差异，主要体

现在隔离性、一致性保证度、风险、性能及业务复杂度几个方面，所以需要提供多种不同的分布式事

务机制，以适配不同的业务场景。另外，由于分布式事务涉及到的事务资源在物理上是独立的，所以

必须考虑物理异常对事务的影响。

9.2处理机制

分布式事务的处理机制应至少包括如下一种或几种模式：

a)冲正模式：该模式在框架级提供统一的冲正机制，避免每个开发人员重复实现，规避技术风

险。其主要应用于一个事务跨多个服务的场景，要求每个服务都提供对应的冲正服务，当后

续的服务执行失败时，框架将自动执行前面服务的冲正服务，将之前已经执行成功的服务回

退到执行前的状态。这种模式是分布式系统中最基本的一种模式，适合一些不是非常关键、

或者低频的交易，即使出现不一致造成的影响也不大，可以通过业务手段进行处理。

b)TCC模式：一个完整的TCC模式由一个主业务服务和若干个从业务服务组成，主业务服务发

起并完成整个业务活动，从业务服务需要实现如下三个接口：

•Try：完成所有业务检查、预留必须业务资源；

•Confirm：真正执行业务不作任何业务检查，只使用Try阶段预留的业务资源；Confirm

操作满足幂等性；

•Cancel：释放Try阶段预留的业务资源；Cancel操作满足幂等性。

如果所有的从业务服务的Try都执行成功，就会分别进行各自的Confirm；如果有一个失败，

则分别执行各自的Cancel。该模式主要提供总体事务的控制机制，具体的逻辑由业务实现，

其比较适合有极致性能需求的、对一致性要求比较高的业务场景。

c)无侵入模式：该模式通过模拟数据库内部的机制，对事务（跨服务、跨数据库）中的所有

SQL操作自动构建UNDO、REDO的相关信息，并对相关记录进行锁定。当后续的执行出现异常

5

CESA-2019-2-009

的时候，事务管理器通过UNDO日志对前面已经执行的SQL操作进行回滚。该模式在保证隔离

性的前提下，提供了很高的一致性，并且对业务系统无侵入，适合于大部分的业务场景，是

分布式事务在金融行业落地的一个重要模式。

9.3异常处理

由于分布式事务涉及到的事务资源在物理上是独立的，所以不管是上述哪种模式，在部分事务资

源出现物理故障的情况下，都面临不一致的风险，针对于这种情况，应提供如下的应对措施：

a)自动恢复：当上述物理故障解除后，系统可以自动检测到，并对受影响的事务提供自动处理

机制，尽最大可能保证事务的一致性，避免相关事务全部由人工处理。

b)人工干预：当出现极端异常情况，上述自动恢复机制也无法恢复的情况下，可支持人工干预，

并提供必要的事务信息（例如：全局事务状态、哪个分支出现问题、事务的上下文等）以供

分析。

6

CESA-2019-2-009

附录A

（规范性附录）

XXXX

A.1XXXX

7

CESA-2019-2-009

参考文献

[1]GB/T5271.1-2000信息技术词汇第1部分：基本术语

[2]GB/T29246-2012信息技术安全技术信息安全管理体系概述和词汇

8

CESA-2019-2-009

目次

前言................................................................................................................................................................III

引言..................................................................................................................................................................IV

1范围................................................................................................................................................................1

2规范性引用文件............................................................................................................................................1

3术语和定义....................................................................................................................................................1

4分布式覆盖范围.............................................................................................................................................2

5服务层分布式................................................................................................................................................2

5.1概述........................................................................................................................................................2

5.2微服务引擎............................................................................................................................................2

5.3微服务网关............................................................................................................................................2

5.4运维监控................................................................................................................................................3

6数据层分布式................................................................................................................................................3

6.1概述........................................................................................................................................................3

6.2主要用语说明........................................................................................................................................3

6.3数据路由................................................................................................................................................4

6.4SQL兼容性..............................................................................................................................................4

6.5数据库无关性.........................................................................................................................................4

7缓存层分布式................................................................................................................................................4

8分布式统一调度.............................................................................................................................................5

9分布式事务....................................................................................................................................................5

9.1概述........................................................................................................................................................5

9.1处理机制................................................................................................................................................5

9.2异常处理................................................................................................................................................6

附录A（规范性附录）XXXX...........................................................................................................................7

A.1XX................................................................................................................................................................8

参考文献............................................................................................................................................................8

CESA-2019-2-009

金融行业联机交易系统分布式技术规范

1范围

本标准规定了分布式联机交易系统应覆盖的范围，以及在具体范围内应具备的基础功能。

本标准适用于金融行业采用分布式技术进行联机交易系统建设时使用。

本标准不适用于金融行业分析类系统的建设，以及其他非金融类行业（金融行业分析类系统的建

设，以及其他非金融类行业可参考本标准执行）。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本

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

GB/T10113—2003分类与编码通用术语

GB/T5271.1-2000信息技术词汇第1部分：基本术语

3术语和定义

下列术语和定义适用于本文件：

3.1

数据data

信息的可再解释的形式化表示，以适用于通信、解释或处理。

注：可以通过人工或自动手段处理数据。

[GB/T5271.1-2000.定义01.01.02]

3.2

网络network

由计算机或者其他信息终端及相关设备组成的按照一定的规则和程序对信息进行收集、存储、

传输、交换、处理的系统。

3.3

分布式distributed

在计算机领域中，指物理上由多个不同的机器参与执行，但在逻辑上完成的是一个任务，对

使用者来说，就像一台计算机在执行一样。

3.4

事务transaction

<计算机>访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。

注：一个事务如果执行成功就全部提交，如果有一个失败就全部回滚。

3.5

分布式事务distributedtransaction

指涉及多个不同事务资源的事务（例如：多个数据库或者多个应用系统）。

注：由于每个事务资源在物理上是完全独立的，所以其的一致性保证相对于单个数据库的事务要复杂的多。

1

CESA-2019-2-009

4分布式覆盖范围

金融行业采用分布式技术建设联机交易系统时，应将分布式技术全面的应用到系统的各个层面，

使每个层面都具备分布式的特性，当性能遇到瓶颈的时候都可以通过横向扩展的策略予以解决；并且

对于行业特有的问题（例如：分布式事务）应有具体的解决方案。具体应包括：

a)服务层分布式：主要以微服务的形式体现，可以将一个复杂系统拆分为多个微服务，不仅可

以增加多台机器提供服务，还可以快速灵活的应对的业务变化。

b)数据层分布式：可以将大数据量表中的数据进行水平切分，用多个物理库来承载，不仅降低

了单表的数据量，还增加了可用的物理资源。

c)缓存层分布式：对于大量的数据库查询请求，可以采用分布式缓存的机制进行存储，降低对

数据库的交互次数，降低服务的响应时间。

d)分布式统一调度：提供分布式的统一调度，来协调多个微服务节点及数据库节点全部参与运

行，充分利用资源，将批量处理的时间控制在有效范围内。

e)分布式事务：由于金融业务的特殊性，对事务一致性的要求比其他行业都要高，所以，在上

述的分布式体系下，还要提供跨数据库、跨微服务的事务一致性保证。

5服务层分布式

5.1概述

服务层分布式的主要目标是为联机交易系统提供服务分布式的运行机制，以及配套的管理体系，

结合行业的最新发展趋势，最终体现为完整的微服务运行体系，主要包括：微服务运行引擎、微服务

网关和运维监控三个大的部分。

5.2微服务运行引擎

微服务运行引擎应包括如下主要功能：

a)服务注册/发现：服务提供者在启动的时候将服务相关信息注册到“注册中心”，服务消费者

通过“注册中心”可以获取到最新的服务列表；同样当服务提供者下线时，注册信息可以从

“注册中心”剔除，服务消费者可以更新服务提供者列表。

b)负载均衡：服务消费者调用提供者的时候，可以根据本地的列表依据一定的负载均衡算法进

行调用。

c)自动隔离/恢复：当服务提供者出现异常情况（例如宕机），可以自动从“注册中心”删除，

当其恢复后又可以自动加入，期间消费者可以同步获取到最新的服务提供者列表。

d)集群容错：当某一次的服务调用发生异常的情况下，可以提供多种容错机制，例如：重试

（可以设定重试次数）、直接抛错等机制。

5.3微服务网关

微服务网关为外部系统访问该系统提供统一的接入及控制，应包括：

a)服务鉴权：对服务的访问进行控制，只有在一定权限范围内的才可以访问，否则将拒绝请求。

b)流量控制：对请求的总量进行控制，如果超过限制则后续的请求将会被拒接或者等待。还可

以按具体的业务维度进行更细粒度的控制，例如：按交易渠道进行控制。

c)熔断降级：如果某个服务的失败率比较高，或者发现一些明确的异常情况，有可能影响到其

2

CESA-2019-2-009

他服务的正常运行，自动切断该服务的所有请求（直接抛错或者返回约定信息），以保护系

统整体的可用性。

5.4运维监控

运维监控是微服务体系的重要组成部分，应包括：

a)灰度发布：某个不面向全部用户的微服务有新的版本要发布，可以通过灰度发布只对部分用

户开放，当运行一段时间如果效果好的话再对所有用户开放

b)统一配置：微服务涉及的部署数量比较多，如果手动一个一个修改配置文件，不仅效率比较

低，还容易出错，并且跟微服务的初衷有所背离，所以一个统一的配置中心非常必要，通过

该配置中心可以快速完成多个实例的相关参数的调整，并实时生效。同时提供配置信息的版

本管理，防止配置出现问题时的统一回退。

c)服务治理：服务治理主要对服务运行态的情况进行动态调控。

1)负载策略调整：可以对运行态的多个服务提供者的负载均衡策略进行调整，防止某个提

供者上的负载过高。

2)流控策略调整：可以根据实际需要，对流量控制的策略进行动态调整。

3)熔断降级控制：对服务的熔断及降级的策略进行调整。

4)路由控制：通过配置对服务的路由策略进行干预，例如：暂时把某一个服务提供者屏蔽。

d)调用链跟踪：有些交易涉及多个微服务之间的调用，为了更加方便定位问题，以及对服务执

行情况进行跟踪，需要提供服务的完整调用链路信息，据此可以查看某些异常情况发生时的

具体信息，以及各个子服务的调用耗时等。

e)分布式日志：把分布式系统下的相关日志信息进行采集、汇总，把跨多个系统的日志串接起

来，并提供统一的页面按不同维度查询相关日志信息。

f)监控告警：对相关的监控对象制定告警策略，当其达到告警条件的时候需要产生告警信息，

以便运维人员及时处理。监控对象应至少包括系统运行资源、服务的运行情况，当发现系统

处理资源不足（例如：CPU长时间大于