信息系统集成共享建设方案Word文件下载.doc
- 文档编号:229882
- 上传时间:2023-04-28
- 格式:DOC
- 页数:13
- 大小:244.04KB
信息系统集成共享建设方案Word文件下载.doc
《信息系统集成共享建设方案Word文件下载.doc》由会员分享,可在线阅读,更多相关《信息系统集成共享建设方案Word文件下载.doc(13页珍藏版)》请在冰点文库上搜索。
主要关键技术包括微服务,SOA,服务总线,BPM等。
1.4流程集成
流程集成是将工作流引擎从单体的应用系统中剥离,形成具有有安全、可靠、稳定、可灵活应用的统一流程微服务,实现图形化工作量定义、统一流程监控、流程的灵活配置。
第二章建设现状
2.1现状
为贯彻落实《国务院办公厅关于印发政务信息系统整合共享实施方案的通知》(国办发〔2017〕39号)要求,2018年生态环境部开展了政务信息系统集成整合工作,以“集成整合、互联互通”为主要目标,建设了基于专网的统一应用集成服务管理框架,以统一应用集成服务管理框架为载体,集成、组织和管理应用系统,为应用系统统筹利用、统一接入提供集成整合平台,为应用系统对外服务、深度应用、协同共享提供服务平台,为应用系统统筹建设、备案监督提供管理平台。
目前生态环境部已经完成了统一应用、统一用户、统一认证、统一日志、统一权限、统一待办、统一展现、统一消息、统一分享九个微服务的建设,完成了60个应用系统与统一门户的集成工作,初步实现系统集成共享框架。
同时由于生态环境部信息系统建设规模小、建设标准不一等因素,当前信息化仍存在“小散多”的特征,数据共享和业务协同不符合信息化发展形势,距离“用数据决策”和“挂图作战”要求还有较大差距,尚不符合国家统筹发展电子政务要求。
2.2规划对标
方案
重点任务
任务点
说明
任务完成情况
生态环境大数据建设总体方案
生态环境大数据总体架构为“一个机制、两套体系、三个平台”。
一个机制即生态环境大数据管理工作机制,两套体系即组织保障和标准规范体系、统一运维和信息安全体系,三个平台即大数据环保云平台、大数据管理平台和大数据应用平台。
一个机制:
生态环境大数据管理工作机制包括数据共享开放、业务协同等工作机制,以及生态环境大数据科学决策、精准监管和公共服务等创新应用机制,促进大数据形成和应用。
1.方案中应用支撑层没有进行重点设计。
2.根据政务信息系统整合共享要求,基于专网建设了综合业务门户(专网门户),以统一应用集成服务管理框架为载体,集成、组织和管理应用系统,为应用系统统筹利用、统一接入提供集成整合平台。
根据政务信息系统整合要求,梳理系统清单情况,基于专网综合业务门户目前已完成60个系统的集成工作,完成现有符合的系统集成工作,初步实现部分应用系统一门式登录、一站式办公、一页式展现服务。
两套体系:
组织保障和标准规范体系为大数据建设提供组织机构、人才资金及标准规范等体制保障;
统一运维和信息安全体系为大数据系统提供稳定运行与安全可靠等技术保障。
三个平台:
生态环境大数据平台分为基础设施层、数据资源层和业务应用层。
其中,大数据环保云平台是集约化建设的IT基础设施层,为大数据处理和应用提供统一基础支撑服务;
大数据管理平台是数据资源层,为大数据应用提供统一数据采集、分析和处理等支撑服务;
大数据应用平台是业务应用层,为大数据在各领域的应用提供综合服务。
第三章未来规划
3.1建设目标
以改善生态环境质量坚决打好污染防治攻坚战的生态环境战略为导向,以现有基础设施、应用系统、数据资源建设与应用情况为基础,围绕“四统一、五集中”,深化微服务设计体系,逐步构建“大中台、小前台”的服务架构,打造共享服务平台,提升服务重用能力。
利用一体化微服务框架,实现标准落地、集中应用、统一管理、可视化监控,提升业务流程整合能力,改善生态环境应用开发效率,实现跨组织、跨业务、跨流程、跨部门间的业务协同和数据资源共享,提高信息化对生态环境业务的响应能力要求,实现业务办理的统一管控,业务数据的统一管理,对信息化应用的统一支撑。
3.2建设内容
一、建设基础中台
基础设施层
二、建设数据中台
数据层
三、建设业务中台
(1)升级现有微服务组件,构建业务中台
结合生态环境部微服务集成框架,对已建微服务组件进行升级重构,采用“大中台、小前台”的服务策略,构建统一的共享服务平台,打通应用壁垒,实现业务协同。
(2)新建微服务组件,深化基础支撑微服务平台建设
新建统一审计微服务、统一工作流微服务、统一报表微服务、统一表单微服务、统一版式微服务,支撑信息共享、智能办公的各项应用,提供更便捷、更有效、更精准的服务。
(3)基于微服务设计理念,重构已有应用系统,提高资源重用能力。
3.3建设方案
3.3.1设计原则
应用系统的建设是一个循序渐进的过程,在不同阶段开发的应用系统,由于不同厂商的参与,使得这些应用系统之间很难进行融合。
要解决这些问题,必须严格地遵循标准规范、控制总体规划、加强顶层设计来进行总体上的协调。
综上,采用模块设计、分层构件的指导思想,实现业务应用支撑平台的一体化建设,统筹规划建设任务,按照如下设计原则开展建设工作。
(1)统一标准规范、统一架构设计
通过采取有效的技术手段来约束不同的开发商遵循统一的、标准化的应用架构进行开发,确保不同时期、不同厂商开发的业务应用系统彼此之间能够有效整合。
(2)微服务组件松散耦合、粗粒度集成
微服务组件的设计应强调微服务组件之间的集成采用松散耦合的接口模式,确保组件具有高度的扩展性。
同时,采用服务分级手段,通过建立不同的粗粒度等级来创建服务,提供完整的业务功能,通过一次调用实现既定功能。
(3)加强功能组件封装,降低开发复杂性
基于成熟的构件封装的设计理念,将经过验证的软件成果,形成业务应用构件库,在业务应用系统建设中能够进行复用,从而降低开发复杂性,提高开发效率,实现快速响应需求。
(4)采用分层模式,专注业务需求
为业务应用系统提供统一、稳定、可靠的分层框架,有效地屏蔽底层的复杂技术,把技术细节全部封装到了构件内部,开发人员通过复用成熟的构件,从技术细节中解脱出来,更加专注在如何更好地实现业务需求上。
(5)先进性和实用性并重原则
在兼顾技术先进性的基础上,坚持以需求为导向,讲求实际应用效果,不片面追求高、尖技术的尝试,尽可能采用成熟技术,以保证架构设计的可靠性和稳定性。
(6)标准化和规范化原则
严格遵循国家、行业的有关技术标准和规范,为不同业务应用系统之间集成提供前提条件,实现各类业务信息资源的共享和利用。
(7)可扩展性和可维护性原则
充分考虑信息化建设需求,微服务组件应基于模块化思想设计,采用分布式部署方式,通过标准接口快速扩充、灵活插拔,确保支撑平台的可扩展性和可维护性。
3.3.2技术路线
基于微服务平台架构设计理念,在基础环境上基于国产化软硬件设施、Docker容器、Redis和MQ技术,采用Restful接口协议,并对交换数据使用SM4国密算法进行加密,实现微服务组件的开发、注册、整合、管理和服务,形成统一的业务应用支撑平台,为业务应用系统开发、部署、应用和运维提供全面服务。
(1) 以面向微服务架构为基础搭建业务应用支撑
建立整体系统的框架性、服务性结构,基于面向微服务的架构思想和方法进行建设,做到高内聚、松耦合和系统构架层次化,降低信息数据层、业务应用层、用户交互层资源间的耦合度(同层间及不同层间),从而使业务应用灵活地被组合和封装,快速应对业务服务的变化和发展需要。
(2) 采用组件式开发技术框架来进行业务应用的快速开发
按照松散耦合的组件规范,整合业务应用,不同开发商可在一个系统内开发不同的业务应用系统,并保证运转良好,形成一体化的应用平台。
(3) 统筹兼顾,多种技术实现方式共存
项目的建设需要考虑兼容原有应用系统的技术架构以及微服务环境,实现技术层面的无缝对接。
通过充分利用原有资源,实现多种技术方式并存,保护原有投资。
(4) 利用成熟的集成方法论
在项目的建设过程中,需要借助成熟的集成方法论和平台组件技术实现与其他应用系统在界面、应用和数据三方面的集成工作,实现无缝集成。
3.3.3总体架构
以微服务架构为技术支撑,遵循面向业务、面向构件的思想,按照开放的业界标准,通过微内核和扩展性,保障平台强壮性、稳定性,形成业务导向,业务驱动和业务建模的业务应用支撑平台,来构建、整合、扩展、管理业务应用系统。
功能总体框架如下图所示,自下而上分为三个部分:
图:
功能架构图
1.基础设施层
基础设施层:
每一个微服务组件可以独立部署在虚拟机或Docker容器中。
不像传统多个服务共享一个数据库,微服务架构每个服务都有独立的数据库,实现架构的松耦合。
2.微服务中心层
包括统一用户、统一授权、统一认证、统一审计、统一分享、统一门户、统一工作流、统一报表、统一资源、统一消息、电子签章、统一版式等微服务组件,并可以根据业务应用要求进行扩充,实现统一设计、统一架构和横向扩展。
平台为各应用提供统一支撑服务,对外提供标准的Web服务,所有的接口服务统一使用RESTful接口和RPC两种模式接口。
3.微服务支撑平台
通过业务应用系统管理功能实现对业务应用系统的注册、接入及安全管理;
通过注册管理功能实现的对微服务组件的注册、心跳等管理;
通过平台运行管理功能开展微服务管理、存活验证管理、软负载均衡管理,最终采集、汇聚微服务组件和业务应用系统的运行状况、组件状态等数据信息并通过平台综合展示功能来实时展现。
4.业务应用层
业务应用层通过业务应用支撑平台,定制应用、实现集成、发出请求、获取服务。
3.3.4技术架构
技术架构图
自下而上包括:
(1)基础设施层:
提供各类计算、存储、网络、监控安全等基础设施服务。
(2)服务提供层:
微服务组件资源池包括统一用户、统一权限、统一认证、统一审计、统一分享、统一待办、统一工作流、统一报表、统一日志、统一消息、统一应用、统一版式等微服务组件,并可以根据业务应用要求进行扩充,实现统一设计、统一架构和横向扩展。
(3)支撑服务层:
(4)接入层:
通过RESTFUL规范表示流程元素/资源的对象。
(5)业务应用层:
通过调用支撑服务层的各类微服务组件构建各类业务服务。
3.3.5微服务框架
为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范开发,提升效率,通过提供微服务框架,解决微服务的各类注册、发现、服务、调度、容错等各类通用性服务功能,业务开发人员只要实现业务逻辑即可。
微服务框架如下图所示:
服务框架图
(1)基础服务功能:
包括服务注册、发现、负载均衡和健康检查等。
(2)监控日志,框架提供框架层日志、metrics和调用链数据,并提供日志、metrics等接口,方便业务层记录业务日志数据,并进行统一分析和处理。
(3)REST/RPC和序列化,框架层针对当前多样化的设备类型(浏览器、普通PC、无线设备等),提供REST/RPC等多种序列化机制,如:
针对浏览器支持输出Ajax友好的JSON消息格式。
(4)配置,除了支持配置文件,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。
(5)管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。
(6)统一错误处理,统一处理框架层和服务的内部异常。
(7)安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。
(8)文档自动生成,为方便开发和测试,框架层支持文档的自动生成和同步,框架层提供支持RestfulAPI的文档方案。
3.3.6部署架构
采用虚机化技术和Docker容器技术将微服务组件部署在Docker容器中形成微服务组件实例,通过增加微服务组件实例数量实现微服务的横向扩展。
同时将微服务组件打包为Docker镜像,实现跨主机运行和管理Docker容器,提供容器的多地部署、自动发布、服务发现和复制控制功能。
微服务组件通过管理中心实现统一的对外服务接口,对于业务应用系统来说,看到的是统一的服务接口,而看不到微服务组件实例;
对于内部微服务组件实例来说,管理中心实现了服务发现、负载均衡、熔断、权限控制等功能。
部署架构图
3.3.7统一接口设计
统一采用Restful通信。
(1)单个微服务组件接口调用,采用同步通信方式
(2)多个微服务组件接口间调用,采用异步通信方式
(3)无状态协议HTTP,扩展能力强。
采用成熟方案HTTPS实现安全加密可用。
(4)JSON报文序列化,轻量简单,人与机器均可读,学习成本低,搜索引擎友好。
(5)各类语言都提供成熟的RestfulAPI框架,框架生态完善。
统一接口设计
3.4建设步骤
一、第一阶段(基础阶段,计划2019年完成)
(1)开展需求调研:
了解现有系统情况以及未来2年内系统建设情况,确定可以被分拆作为组件的业务功能,明确系统的用户数、并发量等指标数据,确定每个组件的实际部署的实例数量。
(2)制定技术架构、微服务开发与测试规范、系统集成规范。
(3)完成微服务管理中心的建设。
二、第二阶段(完善阶段,2019-2020年完成)
(1)完善技术架构和相关规范文件,编制基于业务中台的项目实施方法论。
(2)启动业务功能组件开发,在总结集成应用试点经验的基础上,全面开展系统集成工作。
三、第三阶段(深化阶段,2020年完成)
(1)持续进行平台优化与更新。
(2)持续完善业务应用。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信息系统 集成 共享 建设 方案
![提示](https://static.bingdoc.com/images/bang_tan.gif)