信息化系统功能需求非功能需求性能需求技术路线安全需求运维服务需求数据库架构通用设计.pdf

《信息化系统功能需求非功能需求性能需求技术路线安全需求运维服务需求数据库架构通用设计.pdf》由会员分享，可在线阅读，更多相关《信息化系统功能需求非功能需求性能需求技术路线安全需求运维服务需求数据库架构通用设计.pdf（17页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、系统设计通用模块 1.1.1 系统非功能需求 1.1.1.1 系统可靠性“xxxx 项目”采用数据集中处理模式，业务覆盖养护管理各层级，系统可用性要求较高，要求信息系统 724 小时连续运行；系统的可用性（A=MTBF（平均无故障工作时间）/（MTBF+MTTR（平均维修时间）100%）至少为 99.99%。公路交通应急装备物资管理信息系统实现全天候运行维护保障制度，具备 724 小时的系统保障能力，并派驻现场值班人员进行现场 724 小时安全保障。1.1.1.2 系统响应时间 根据项目心理学的相关理论，考虑到不同类型用户对响应时间的忍耐程度，结合业务对系统响应时间的要求，数据统计、决策分析等

2、功能，简单分析平均响应时间一般不超过 3 秒；复杂查询平均响应时间一般不超过 5 秒；信息检索、数据录入、业务流程操作等功能操作，简单功能操作平均响应时间一般不超过 1 秒，复杂功能操作平均响应时间一般不超过2 秒。系统 CPU 平均利用率不超过 70%，内存平均使用率不超过 80%。1.1.1.3 系统存储能力 根据国家、行业的对业务数据存储的最低要求，考虑业务系统生命周期通常为 5 年，确定本次项目业务数据存储 5 年，备份存期 5 年。1.1.1.4 系统兼容性和可扩展性 随着公路管理体制从管理型向服务型转化，公路事业发展势必出现新的管理需求，因此在系统设计开发过程中，应采用模块化设计理

3、念，避免今后由于新增功能导致重新开发。硬件设备不但要考虑到和现有设备的兼容，还应考虑到今后公路网扩展、车辆保有量的增加、流动监测站以及巡查人员单兵设备接入的需要，服务器、交换机、存储备份设备以及网络带宽应具备一定的超前性和兼容性。本项目的页面在设计实现时，需要考虑采用多种浏览器兼容的网页设计技术，保障网站页面支持各种操作系统和多种浏览器在浏览时的无障碍。需要考虑和适配现在多种系统的不同浏览器如 IE、360、谷歌等。1.1.1.5 系统易用性 根据不同层级的用户的管理需求，提供不同的界面。APP 应与 PC 协同工作，优化软件界面、操作逻辑保证软件运行速度。系统应提供友好的人机操作界面，系统设

4、计应以用户为中心，符合不同类型的用户角色固有的管理和使用习惯，能使用户以较快的速度找到自己最关注的功能操作和数据信息，方便用户学习和掌握，提高系统使用效率。1.1.2 项目建设技术路线 1.1.2.1 微服务架构技术路线 SOA 去中心化的实现方式的根本诉求是扩展性，实现方式就是微服务。微服务架构为所有业务系统服务提供统一管理，包括服务注册、服务配置、断路器、链路追踪、日志分析、消息队列等。特别是在异常服务的监控、访问限流、服务故障熔断方面，能有效提升系统的稳定性和可用性，有效解决当前单点故障导致整个系统崩溃的问题。微服务具体技术选型如下：微服务中间件：Spring Cloud Nacos、S

5、entinel、Sleuth、RocketMQ、ES、Kibana、Logstash。微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个 HTTP 的资源 API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。实现微服务技术架

6、构，现有产品需要进行技术上的改进以及相关配套服务的实现，采用分阶段实施、以及试点产品优先实施的策略，主要包括如下：技术上的改进：1、前后端分离，web 前端通过 Http/Https 协议调用微服务的 API 网关，由API 网关再经过路由服务调用相应的微服务 2、不同微服务之间通过 REST 方式互相调用 3、微服务之间通过消息中间件实现消息交互机制 配套服务与功能实现：1、需要进行相应的自动化服务实现，包括自动化构建、自动化安装部署、自动化测试、自动化平台发布（Docker 实现）2、管理服务，对于微服务架构，必须配套相应的监控与管理服务、日志管理服务等 3、协作服务，运用 DevOps

7、思想提升开发、测试、运维的高效沟通与协作，实现开发与运维的一体化 在微服务治理体系下，各个微服务交付期间也是各自独立交付的，从而使得每个微服务从开发到交付整条链路上都是独立进行，这大大加快了微服务的迭代和交付效率。服务交付之后需要部署运行，对微服务来说，它们运行期间也是各自独立的。实现基于微服务的技术架构，并采用业务流程管理 BPM、单点登录SSO、商业智能 BI 等成熟、先进的技术，构建一个架构灵活、功能实用、界面友好、便于扩展、安全可靠的公路事业发展综合管理平台。1.1.2.2 应用系统层技术路线 业务应用层的设计应服从于目标架构与业务架构，有利于各项业务功能的实现；业务应用层要基于统一支

8、撑平台建设，应采用构件的设计方法，便于功能的复用；业务应用层应注重考虑使用便捷、协同快捷、功能人性化等方面因素。基于目前各业务单位应用系统建设现状，新建业务应用系统统一采用微服务柔性敏捷开发技术路线；已建系统升级改造时应综合评估，具备条件的应用系统应统一过渡至微服务技术架构。1.1.2.2.1 业务应用层建设基本要求（1）业务应用层的建设要基于统一的网络基础设施、数据环境、应用支撑平台开发部署部门业务系统，充分利用支撑层资源。（2）开放与政务信息共享平台的互操作接口，满足信息交换和业务协同需要。（3）严格按照标准组织建设；结合项目建设应用需要，完善制定相关标准；支持开放标准，开发开放支持互操作

9、的标准接口，确保互联互通和集成应用。1.1.2.2.2 业务应用层建设规范（1）业务应用层应采用成熟的、通用的技术进行建设，以便于应用系统与统一支撑平台联通，以及各部门应用系统之间协同。（2）业务应用层在设计建设时应充分复用服务构件库所提供的服务构件，对于服务构件库已经提供的服务构件不得再自行建设，服务构件未能完全满足的功能需求应向统一支撑平台提交需求，由统一支撑平台完善服务构件功能。（3）统筹全系统的业务需求，充分考虑基层应用需求，统一开发全系统都能够使用的应用软件，避免基层单位重复开发应用系统。1.1.2.2.3 应用系统整合技术路线 对目前已建、在建的各类普通公路行业应用系统进行整合，实

10、现统一应用；实现统一的用户管理、权限管理、身份认证、审计管理、单点登录以及信息综合展示。其中，公路事业发展综合管理门户可在计算机、显示大屏、移动设备等终端上展现和访问，实现“三屏合一”。（1）功能整合 已建系统基于统一用户管理实现基于某一用户的功能整合；新建系统基于统一的微服务、数据中台等技术规范进行功能服务开发。（2）统一用户管理 建立统一用户管理平台，对接公内外网统一身份认证系统，实现对市 xxxxx单位内部组织机构信息、用户信息、角色信息的统一管理。（3）统一授权管理 根据不同业务功能的访问要求，通过平台可为用户分配相应角色和权限，所有用户须经过授权才可以访问业务系统和功能。（4）统一认

11、证管理 集中管理用户帐号和相关审批、操作流程，实现“组织-用户-角色-权限”的统一管理，为实现“单点访问权限授权、多点使用权限授权和一点清权”提供基础，所有用户登入平台都须通过统一认证才能够办理相关业务。（5）统一审计管理 对平台用户使用平台的过程进行全生命周期的管理，所有用户操作都应有日志记录，留迹存痕。（6）统一界面展现 为市 xxxxx 单位人员等提供统一的门户展现界面，实现统一访问入口、统一菜单展现、统一工作台栏目和综合信息展示发布等功能。公路事业发展综合管理统一访除可以计算机上访问外，还可在路网指挥中心大屏幕和移动设备上进行访问。1.1.2.3 应用支撑层技术路线 1.1.2.3.1

12、 服务接口技术路线 应用支撑层是是整体系统建设核心。沿用 WebService 技术来定义数据库元数据，使用基于 XML 的消息处理作为基本的数据通信方式，以解决使用不同组件模型、操作系统和编程语言的系统之间存在的差异。建议采用的技术路线归纳如下：（1）采用多层架构的 B/S 结构；（2）采用 Web Service 技术；（3）利用 XML 作为系统接口的数据交换标准，进行信息资源整合；（4）采用应用服务器和模块组件化技术，提高系统的灵活性和可扩展性；（5）支持不同的数据库：Oracle、SQL Server 和 My SQL 等；（6）采用信息开放等级划分、权限许可和角色认证的方法，建立系

13、统安全机制，基于 PKI/CA 基础安全服务机制，提供基于安全 XML 技术的 PKI 基础安全服务和 PKI/PMI 证书服务的统一调用接口。（7）采用工作流引擎技术提供系统的快速开发和更新。1.1.2.3.2 服务构件技术路线 系统的技术方针可概括为“业务驱动、持续治理；资源池化、弹性伸缩；协同交换、物联整合”，技术方针的技术实现策略简略地阐述如下：业务驱动、持续治理 这主要针对业务应用开发部署环境。业务应用开发应遵循业务驱动原则，技术实现可以自主研发的“业务建模及服务转换平台”和“业务服务集成及治理环境”等为核心。资源池化、弹性伸缩 这主要针对交通云计算平台的运行和运行管理环境。“多租户

14、、共享的资源池、弹性、动态伸缩、自服务、按需使用、基于 Internet、快速供应、IT 资源利用率等”是云计算的常见关键字。协同交换、共建共享 这主要针对 SaaS 层的业务应用领域。协同交换是本期数据中心项目建设的主要内容，包括业务协同和数据交换两大部分。建设充分借鉴协同交换设计，为上层的各类应用服务提供业务协同、数据交换服务。1.1.2.4 数据层技术路线设计 1.1.2.4.1 数据存储和交换格式类型 本系统数据交换采用 XML 数据格式。XML 提供了一种连接关系数据库和面向对象数据库以及其它数据库管理系统之间的纽带。XML 文档本身是一种由若干节点组成的结构，这种特点使得数据更适宜

15、于用面向对象格式来存储，同时也有利于面向对象语言（C+、Java 等）调用 XML 编程接口访问 XML 节点。1.1.2.4.2 数据库开发技术 本项目将采用云计算架构来开发，由于平台的数据库服务器将要承载极大的用户访问量，数据库不仅要保证数据的安全性，稳定性，还要保证性能，以足够支撑应用服务器的访问量。建议本项目的数据库管理系统采用 Oracle l1g，依靠Oracle 提供的强大软件与技术支持，来保证数据库服务器的访问效率以及数据的安全。采用 PL/SQL 进行数据查询开发，JOB 调用存储过程实现数据同步。采用 Java EE 多层构架来开发本项目，与数据库的交互，现在比较流行的方式

16、有：Hibernate，Spring JDBC Template(或是 JDBC)和 ibatis。在实际设计开发过程中，可以根据具体的需求，选择其中之一。1.1.2.4.3 数据资源目录和交换系统对接技术方案 数据交换服务、行业公共服务和行业专业服务相关的服务接口注册在服务注册中心，行业公共服务、行业专业服务，通过数据交换服务在服务注册中心注册的服务进行相应的数据校验、协议转换、安全验证、路由转发，以完成相应数据交换，并驱动相应业务流程，以实现交通业务协同服务。逻辑架构图如下：图：逻辑结构图 接口描述：数据交换服务行业公共服务行业专业服务交通业务协同服务服务注册中心SaaS应用服务PaaS层

17、服务SaaS 层应用软件服务间的数据交换通过采用统一的数据交换标准以及应用与数据存储的隔离，实现 SaaS 层的不同业务应用软件服务之间和同一业务应用软件服务的不同企业实例之间的数据的无缝交换和共享访问，保证各服务之间的有效协同。接口设计：模块接口提供 Java API（Java 接口）和 WSDL（Web Service 接口）两种方式。1.1.3 系统接口开发联调设计 1.1.3.1 数据接口设计内容 本项目建设过程中，本着充分利用现有数据资源、网络资源、通信资源、存储资源等已有设备，需要制定各类接口和这些已经建设完成的信息系统或资源进行信息共享、业务互通；另外本项目对上负责向市局报送相关

18、数据，对下需要指导所属数据资源的建设和区县 xxxxx 单位下数据资源的管理。本工程所建的综合管理平台一方面要从外部相关数据获取所需数据，同时也对其他业务部门提供数据接口，共享部分数据。1.1.3.1.1 项目外部接口 外部接口指本工程所建系统与其他系统之间的接口，要实现的外部接口：公路基础数据库接口 xx 系统接口 xx 平台接口 xx 共享系统接口 xx 系统接口 1.1.3.1.2 项目内部接口 xxxxx 单位各系统间的业务流转和数据通信需要制定一套统一的接口规范来约束和指导应用系统开发。1、数据统一访问接口 本项目内部在应用系统设计过程中，设计和开发一套统一的数据访问接口。其他应用系

19、统所有的数据库访问操作都通过统一的接口进行，包括对数据检索、查询、修改、删除等操作。数据统一访问接口通过 Hibernate 中间件进行开发，开发一套共用的 DAO（数据访问对象）接口，在 DAO 中封装了各类数据库操作的事务，（对象创建，更新、或删除数据）都是和事务相关联的。在 DAO 中无需关注具体的业务逻辑，它只负责和数据库打交道。所有的业务逻辑都在应用系统中进行实现，应用系统需要查询数据、修改数据、删除数据时，只需要调用公共的 DAO 接口就可以。2、业务流转接口 各应用系统间业务流转调用时，采用标准的 webservice 接口。系统提供对webservice 接口管理涉及以下几个方

20、面的内容：1）、接口注册 各个应用系统数据按照 UDDI 规范将 Web 服务发布到 UDDI 注册中心，完成服务的注册。2）、接口更新 当接口需求变化时，各个应用系统只需要在其 WSDL 文档的操作组中添加新的操作定义，并且更新在注册中心的相关信息，即可实现新增服务功能。3）、接口注销方式 当服务的发布方要求注销其发布的某一个接口时，只需要在注册中心中取消以前登记的有关服务信息（如有关该服务的 WSDL 描述文档信息）即可注销该服务。1.1.3.2 共享接口 基于以上的接口设计思路与原则，充分考虑数据交换平台对共享数据的集成模式的实现，数据共享接口中设置三个抽象层操作，分别是：getSche

21、maList：获取某部门所有共享数据的模式信息；getMapping：获取某部门的某一个特定的模式信息；searchData：获取某个特定模式下的共享数据信息。该共享数据接口不是完整的 Web 服务定义。按照 WSDL1.1 规范定义的 web服务描述文档的格式，必须在该组抽象的操作定义的基础上添加具体的绑定信息和端口定义，才能构成某一具体 Web 服务的 WSDL 的描述文档。1、编码方式与命名空间 SOAP 消息信封命名空间 SOAP 消息编码命名空间 XML 模式定义命名空间 WSDL 规范命名空间 WSDLSOAP 绑定 2、命名规则 实现该服务的程序中的方法名称以及相应的参数名称，必

22、须与本标准中共享接口的 WSDL 描述中的对应的 OPERATION（操作）名称及 MESSAGE（消息）名称一致。比如，服务的发布城市采用 JAVA 实现，那么类方法的名称也应该与此标准中共享接口中定义的三个操作分别一致，方法的输入和输出参数的命名必须和接口的 WSDL 描述中 MESSAGE 定义的名称一致。3、可扩展性 规范保证数据共享接口具有良好的可扩展性。由于定义的仅仅是共享数据接口的抽象层操作，不涉及到具体的端口绑定，如果出现以后数据集成平台对共享数据需求的更新，各个数据局不需要改变本地具体的端口设置，只需要在其WSDL 文档的操作组中添加相应新的操作定义部分（比如采用 JAVA

23、语言发布的服务程序，就只需要增加一个实现相应功能 JAVA 方法的定义，然后重新生成WSDL 描述文档，或者手工修改 WSDL 文档），就可以方便地实现新增服务功能。1.1.3.3 接口技术实现 本项目的系统接口实现方式，在硬件体系、软件结构、系统接入、专题定制等方面预留了标准化的接口，具备良好的可扩展性。在硬件体系上采用基于云计算的架构，可通过增加或更新硬件进行平滑扩展，提高平台的计算和存储能力。在软件方面采用基于 SOA 架构的服务组件化设计，软件功能实现可根据业务的变化进行灵活扩展。在系统接入上，采用标准化的数据交换中心架构和可扩展的应用接口设计，可同步接入市局现有信息系统，实现全方位的

24、资源协调和整合。在专题定制方面，可根据不同时期不同场合的功能进行灵活定制，满足数据中心的管理的需求。一、数据库直接访问接口设计实现 系统间交换数据，可采用数据库直接访问方式，这种方式实际上只需要在数据库中为相应应用授予读取或者写入的权限，使得对方应用可以直接读取或者写入应用数据库即可。表：通过数据库直接访问接口设计实现接口列表 序号 接口名称 1 采集客户端模板自动更新接口 2 采集客户端批量导入接口 3 采集客户端导出接口 二、API 接口设计实现 应用系统向其他业务系统提供服务的过程中，API 调用方式被广泛应用。应用系统提供基于 SOCKET 的服务端，基于 SOCKET 的 API，供

25、其他应用系统调用。其过程为：1、业务系统通过其在本地程序调用应用系统的 API，提交数据请求；2、应用系统收到请求后，对调用者进行身份及权限认证；3、应用系统判断用户身份，并验证是否具有该项数据的访问权限；5、如果该用户为合法用户，且拥有该项数据的访问权限，则提供服务。三、Webservice 接口设计实现 系统应提供统一的数据交换接口和应用服务接口，服务调用接口采用WebService 方式。WebService 的接口实现方式如下图所示。图：WebService 接口实现方式图 接口提供方开发部署 Webservice 接口，此接口连接本系统得业务数据库，读取或者写入数据，并对外提供业务功

26、能调用。调用方根据接口提供方的接口定义，开发和部署 WebService 接口调用程序，业务数据库调用接口程序WebService接口业务数据库调用接口系统提供接口系统WebService调用提供方发布的 WebService 接口，获取或者发送业务数据，并读取或者写入本系统业务数据库。四、数据库同步接口实现 应用系统之间交互也有采用数据库直接访问，直接同步数据的方式。这种方式可以保证数据的实时性，对接口提供方没有开发部署需求，相对较为简单。具体的实现方式如下图所示。图：数据库同步接口实现方式图 目标系统可以不开发和部署任何程序，只需要对调用系统开放数据库访问权限，具体权限根据不同系统的需求可

27、以提供只读权限和写权限。调用系统需要开发和部署数据同步调度程序，触发或者定时访问目标系统得业务数据库，将本系统的业务数据写入对方数据库，或者从对方数据库获取需要的业务数据写入本系统得业务数据库内。表：数据库同步接口列表 序号 接口分类 接口名称 1 数据库同步接口 基础数据与信息交换库同步接口 五、数据交换平台接口扩展 对信息资源整合服务工程中建设的数据资源共享交换平台接口进行调用和扩展，开发符合本项目需要的数据交换接口。六、数据接口管理 各个部门数据在本地的 WSDL 文档定义中将自己具体的端口信息绑定到这个抽象的共享数据接口定义中，实现自己的 Web 服务包装。对数据共享接口的管理涉及以下

28、几个方面的内容：1、共享接口的注册 各个部门数据按照 UDDI 规范将 Web 服务发布到数据交换平台的 UDDI 注册中心，完成服务的注册。业务数据库数据同步调度程序业务数据库调用系统目标系统授权访问数据直接读/写2、共享接口更新 当数据交换平台对共享数据需求变化时，各个数据部门不需要更改本地具体的端口设置，只需要在其 WSDL 文档的操作组中添加新的操作定义，并且更新在注册中心的相关信息，即可实现新增服务功能。3、共享接口注销方式 当服务的发布方要求注销其发布的某一个共享接口时，只需要在注册中心中取消以前登记的有关服务信息（如有关该服务的 WSDL 描述文档信息）即可注销该服务。1.1.3

29、.4 接口服务的调用 1.1.3.4.1 AIP 网关调用 所有服务通过 Zuul 网关进行调用，不允许直接调用微服务提供者。Zuul 可能会成为系统瓶颈，在项目中考虑为 Zuul 进行主备或负载均衡处理。1.1.3.4.2 同步调用 采用 HTTP REST 方式进行调用，针对业务需求可以进行负载均衡，负载均衡的调用方式有两种：1、FeignClient 2、RestTemplate 建议使用 FeignClient 方式进行服务调用，通过 REST 接口调用服务的 http接口，参数和结果默认都是通过 Jackson 序列化和反序列化。因为 Spring MVC的 RestControll

30、er 定义的接口，返回的数据都是通过 Jackson 序列化成 JSON 数据。1.1.3.4.3 异步调用 rabbitMq、kafka、Spring Cloud Stream 均是可以选择的方案。Spring Cloud Stream，基于 Redis、Rabbit、Kafka 实现的消息微服务，简单声明模型用以在 Spring Cloud 应用中收发消息。1.1.3.4.4 服务间调用的权限验证 一般 API 接口都需要某种授权才能访问，登陆成功以后，然后通过 token 或者 cookie 等方式才能调用接口。使用 Spring Cloud Netfix 框架的话，登录的时候，把登录请

31、求转发到相应的用户服务上，登陆成功后，会设置 cookie 或 header token 等。然后客户端接下来的请求就会带着这些验证信息，从 Zuul 网关传到相应的服务上进行验证。Zuul 网关在把请求转发到后台的服务的时候，会默认把一些 header 传到服务端，如：Cookie、Set-Cookie、Authorization。这样，客户端请求的相关 headers就可以传递到服务端，服务端设置的 cookie 也可以传到客户端。1.1.3.4.5 服务编排 服务编排，主要的作用是减少项目中的相互依赖。一个核心的业务处理项目，负责和各个微服务打交道。减少方法之间的一层层嵌套调用，而采取一

32、个方法进行业务流程的串联，如方法 W 实现一个完整的业务处理，则采取下面方式：function w（）1、调用方法 a；2、调用方法 b；3、调用方法 c；1.1.4 当前各系统之间协同联动存在的问题进行深入剖析及可行性改造方案 1.1.4.1 存在的问题 当前 xxxxx 单位应用系统众多，业务错综复杂，部分业务需要与其他系统进行联动，例如养护系统的审批信息需要流转到建设管理系统，建设管理系统处理完之后再将结果返回至养护系统。当前各系统首先将数据存入各自的业务库，再根据其他系统需要将部分数据通过 ETL 或者其他数据接口的方式同步至数据中心，数据中心数据再通过 ESB（企业服务总线）发布接口

33、对外提供服务。当前协同方式存在的主要问题如下：1.1.4.1.1 缺乏统一数据服务标准 由于缺乏顶层规划和统一标准，各业务系统都自建一套数据库，导致同一种数据出现不同的版本，表命名、字段命名、长度、类型都不统一。如养护系统、建设管理系统、路网管理系统、交调管理系统都有对于路段数据的需求，但都是各自维护，无法确立唯一标准。表现形式为，各系统路段数量不统一、数据项不相同，对业务应用上造成了较大影响。1.1.4.1.2 系统无法有效协同 当前业务系统数据流转都是先到业务库，然后通过 ETL 工具抽取到数据中心，再由 ESB 企业服务总线发布服务，由于同一种数据从业务库到其他系统调用存在一定的延迟，导

34、致同一种数据在不同系统中看到的结果不相同。如养护系统的审批数据每 5 分钟同步至数据中心，建设管理系统看到的是养护系统 5 分钟前的数据，在这段时间范围内，可能养护系统数据已经被修改，此时建管系统审批结果就会出现问题。诸如此类情况，都给业务上带来极大的困扰，排查问题起来也比较麻烦。1.1.4.1.3 接口服务不稳定 数据从产生到其他系统使用，经过了太多环节，包括 ETL 同步作业、接口调用、数据库更新等，对于这些中间环节，都缺乏统一监控预警，基本上都是业务部门，甚至是企业、公众发现之后，告知技术部门，技术部门再进行问题排查和数据修复。由于都是被动发现问题，不仅对业务上造成重大影响，同时运维保障

35、部门压力也非常大。1.1.4.2 解决方案 全面梳理各业务应用系统协同联动场景，各业务将对外提供的数据通过服务的方式进行固化，其他业务系统直接访问该服务获取数据，改变由数据中心中转的方式提供数据。有效提升了数据的及时性和准确性，全面提升各系统协同联动效果。方式如下：1、建设统一服务标准 梳理每个系统需要对外发布的服务，建立统一对外服务的标准，包括调用方式、调用频率、返回结果、异常处理机制等，各系统按照统一标准发布服务。2、建设统一的 API 微服务管理平台 将所有标准的服务都注册到 API 微服务管理平台，平台提供服务注册、参数定义、返回结果定义、服务导入、服务运行监控等功能。需要调用其他系统服务时，通过 API 平台直接调用第三方系统服务，由于第三方系统与原系统都是调用同一服务，返回数据与业务系统本身保持完全一致。在保证业务协同及时准确的同时，为了降低第三方调用对本系统的影响，平台对调用次数、频率等做了相关限制，还提供了超负荷熔断机制，从而有效保障了整个平台的稳定运行。