政务服务一件事建设方案.docx

政务服务一件事建设方案-最新二零二二年政务服务一件事建设方案用户及服务层用户及服务层自然人法人标准规范于管理制度业务应用层应用支撑层数据资源层I基础一件事网上服务系统一件事申报网上预约服务评价一件事业务管理平台单事项精细I TW精细I统一受理工j T牌窗口综合窗口配I智除识库I主题监化管理 化管理 作台受理 置管理 管理 督、资源共享目录与数据交换接口政务服务人口库法人库办件过程 信息库翼褥平安与运维保障体系电子政务网络互联网计算及存储设施I信息平安设施1 .基础设施层基础设施包括网络、服务器、平安等硬件基础设施，优先依托政务云平台进 行集约化部署建设。网络方面，政务服务的预审、受理、审批、决定等依托统一 电子政务网络，政务服务的咨询、预约、申报、反应等依托互联网。政务服务数 据共享平台依托电子政务网络建设。2 .数据资源层数据资源层基于政务服务资源目录和数据交换，汇聚政务服务事项库、办件 信息库、监管信息共享库等业务信息库，共享利用人口、法人、电子证照等基础 信息资源库，实现数据资源共建共享，为政务服务提供统一的数据支撑。3 .应用支撑层应用支撑包括CA和电子印章、工作流引擎、电子表单、消息服务等各种通 用组件服务。4 .业务应用层业务应用包括事项精细化管理功能、“一件事”网上服务系统、“一件事” 受理系统、系统对接。5 .用户及服务层第6页共63页政务服务一件事建设方案用户及服务层包括政务服务门户、移动服务、智慧型政务大厅。总体框架设计以深度融合为核心思想，为推动服务型政府转型，使管理模式 优化、业务流程再造、信息技术升级等工作能够科学有序地实施，形成一个有机 整体，防止重复建设、消除信息孤岛、系统功能滞后等问题，推动全行业电子政 务的良性开展。同时在云计算架构及应用模式之下，“一件事”服务管理系统的 架构、应用及服务模式也将发生深刻的变化，本钱更节约、整合更便捷、服务更 高效。3.3 技术应用体系主流技术架构分析目前在Internet/Intranet/Extranet环境中，企业级应用系统大多采用三 层或多层应用模式。为了方便开发、部署、运行和管理基于多层结构的应用，需 要以网络和分布式计算的底层技术为基础，构建一个完整的应用框架，提供相应 的支撑平台作为多层应用的基础设施，这一支撑平台的关键就是位于中间层的应 用服务器。应用服务器是一个创立、部署、运行、集成和维护多层分布式企业级 应用的平台。如果应用服务器与Web服务器相结合，或者包含了 Web服务器的功 能，那么称之为Web应用服务器。在应用系统建设中，采用应用服务器可以提供如下好处：提高应用开发的有 效性，保障业务逻辑和组件的重用性；提高应用的性能，如高运行性能、可伸缩 性、可靠性及更短的响应时间等；使整个应用更易于监控和管理，降低系统维护 和升级本钱。由于应用服务器的重要作用和关键地位，它已经成为当今业界的一 个执占 I 八、八、。系统采用组件化、面向对象的开发技术，可灵活扩展。网络传输采用TCP/IP 协议，支持FTP、HTTP、SMTP等协议。3.3.1 三层架构三层架构（3-tier application）通常意义上的三层架构就是将整个业务应 用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次 的目的即为了 “高内聚，低耦合”的思想。1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统第7页共63页政务服务一件事建设方案的时候他的所见所得。2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作， 对数据业务逻辑处理。3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、 删除、修改、更新、查找等。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。推 荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又 或成为领域层）、表示层。三层结构原理：3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行 处理。所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫 组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器 就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的 三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规那么、数据访问、合法性校验等工作放到了中间 层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM 通讯与中间层建立连接，再经由中间层与数据库进行交互。表示层位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据， 为用户提供一种交互式操作的界面。业务逻辑层业务逻辑层（Business Logic Layer）无疑是系统架构中表达核心价值的部 分。它的关注点主要集中在业务规那么的制定、业务流程的实现等与业务需求有关 的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候， 也将业务逻辑层称为领域层。例如Martin Fowler在Patterns of Enterprise Application Architecture一书中，将整个架构分为三个主要的层：表示层、 领域层和数据源层。作为领域驱动设计的先驱Eric Evans,对业务逻辑层作了 更细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑 的解决方案别离。业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，第8页共63页政务服务一件事建设方案起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依 赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底 层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这 种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想 的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此， 业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同 的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。 依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，那么是除 了实现业务逻辑之外留给设计师的任务。数据层数据访问层有时候也称为是持久层，其功能主要是负责数据库的访问，可以 访问数据库系统、二进制文件、文本文档或是XML文档。简单的说法就是实现对数据表的Select, Insert, Update, Delete的操作。 如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping,以及对象 实体的持久化。3.3.2 SOA 体系SOA是一种松耦合的系统，它要求开发者从服务集成的角度来设计应用软件, 它将应用程序的不同功能组件定义为“服务”，通过“服务”之间的良好接口联 系起来。（也就是“服务”之间的松耦合。）接口是采用中立方式进行定义的， 独立于实现“服务”的硬件平台、操作系统和编程语言。而且这些构建在各种各 样系统中的“服务”可以以一种统一和通用方式进行交互。保证系统灵活性， 另外，还可以保证“服务”的重复利用。由此可以看出，SOA的核心概念是“重用”和“互操作”，从而使企业的IT 系统拥有极大的灵活性。SOA的另一层意义就是整合，它将企业的IT资源整合 成标准的、可操作的服务，使其能被重新组合和应用。在这种架构下，IT系统的 复杂性并没有增加，相反，随着系统的不断完善，整个系统的架构将变得更加清 晰。SOA架构定义了搭建企业级软件架构的一种新方法，它的出现使所有应用在 交换数据和处理过程中，不需要考虑应用软件是用什么编程语言开发的或在什么第9页共63页政务服务一件事建设方案操作系统下运行。在这种模式下，一个应用或应用的一局部其实是一种服务，其 他的应用和客户都可以在无需编写大量代码的情况下使用这些服务，这一切都使 在地理上分布范围比拟广的开发队伍能够更好地合作，因为这些SOA架构下的中 间件业务模块都能够被重新配置或以新方式优化来满足新的需求。正是SOA的 重用性和互操作性所带来的灵活性实现了企业IT资源整合，使企业IT资源真正 面向于服务。一个典型的SOA实现通常依赖于多个服务。调用这些服务需要知道位置（即 服务端点的地址）信息。最简单的方法就是在实现中将端点地址硬编码。但这造 成了方案实现和服务位置的紧密耦合（位置耦合）。将端点地址放到配置文件中 可以改善这种情况。因为这样地址的改变就不会引起代码的改动。但是，随着服 务或服务消费者（或者说是配置文件）增多，这种方法会带来扩展性问题。在SOA架构的设计中，规划有三个主要组成局部:服务注册与管理中心（SRC）、服务提供方、服务调用方，这三者的关系如下列图所示:服务定义衲Schema（1）服务注册中心的基础是一个注册服务数据库。其包含系统中所有 WebService服务的信息和一个注册中心WebService服务。数据库中记录了所有 关于服务的位置、方法说明和调用权限等信息；注册中心服务封装了这个数据库第10页共63页政务服务一件事建设方案并提供了一套访问这些信息的“标准” API。并约定了在此平台上发布的所有服 务必须遵循的规范标准。（2）服务提供方根据注册中心的接口规范开发标准的WebService,并为其 中的每个方法提供一个唯一的标识。（3）服务提供方调用注册中心的“服务添加接口”把开发好的服务注册到 “服务注册中心”。（4）服务消费方（客户端）到注册中心查找和发现需要使用的服务（5）服务消费方根据找到服务的调用规范，传入参数，取得服务的返回值。 在调用服务的时候能够根据服务的WDSL地址和接口名称动态创立代理。电子政务基础支撑平台提供的WebService分成两大类：服务注册中心（SRC）的核心WebService：提供服务注册库的相关功能。电子政务应用支撑类WebService：提供组织架构、工作流、消息平台、日志 管理和具体应用相关的WebServiceoB/S软件结构B/S （浏览器/服务器）结构是当前国际流行的趋势，有利于集中式管理，可 以形成统一的数据库和系统结构，可消除因区域、部门引起的差异，确保系统的 统一性、连续性和未来对结构变动的要求。客户端方式：客户端采用浏览器，不需安装数据库引擎，客户端不含处理逻 辑，系统升级或变化客户端一般也不用更改，大大减轻了系统安装和维护的工作 量；用户上手非常容易，培训本钱很低。对客户端设备而言只要可以运行浏览器 即可，现有的PC设备完全可以利用，保护了投资；弹性增大：处理逻辑和用户接口逻辑别离开来，各子系统不再重复相同的逻 辑，改变处理逻辑时，只需修改和更换服务器程序，各子系统不用改，客户端不 用换；网络通讯量减小：每个客户端都只需和服务器交换少量的数据，大大减小对 网络的压力；平安性提高：各工作站不存放数据库，减少了数据库登录点的数目，有利于 平安管理和控制。第11页共63页政务服务一件事建设方案对象/组建开发技术在工程中，应用系统的开发模式将采用基于循环迭代模型的快速原型法。分 析设计技术将主要采用面向对象的方法。具体讲，在设计阶段采用面向对象的方 法，适当结合结构化分析方法。在软件实现阶段，采用面向对象的程序设计方法。 结合工程经验，将软件开发过程分为初始阶段、细化阶段、构建阶段、实施阶段， 每个阶段又具体为一个个的循环迭代的过程。为了提高系统开发的规范性和系统开发效率，将采用统一建模语言UML和成 熟的面向对象的CASE工具。3.3.3 Web Service 技术Web Service是下一代的WWW技术，它允许在Web站点上放置可编程的元 素，能进行基于Web的分布式计算和处理，把Internet/Intranet变成一个虚拟 计算环境的技术。在Web Service组成的虚拟环境中，使用者可以为任何的客户 端软件，例如浏览器，一般的Windows或是Java应用程序或是电子行动设备等， 来调用Web Service提供的服务。这一点非常有利于系统对信息的有效利用。Web Service是建立在开放和标准的规格之上，允许异质的客户端调用以使 用它提供的服务。因此各种异质的客户端必须使用一种共通的沟通标准才能够顺 利的和由各种不同技术编写的Web Service互通。Web Service涉及到一些新的 规范，如：UDDI （统一描述、发现和集成）、WSDL（Web Service描述语言）、WSFL（Web Service Flow Language） > SOAP （Simple Object Access Protocol 简单对象访 问协议）等。目前最流行而且最具潜力的沟通标准当属SOAP 了。SOAP获得IBM, Microsoft, Lotus和UserLand等大型公司支持而成为W3C 标准之一的通讯协议规格。SOAP以XML标准封装调用远程服务的格式，有别于 其它分布式对象模型调用特定的调用格式。由于SOAP以XML封装调用格式，因 此它可以使用任何的实体传输层来传送，例如HTTP, TCP或是SMTP等。下列图所示为Web Service的整体架构：第12页共63页政务服务一件事建设方案WSFLWSFLUDDI-静态UDDI-动态WSDLSOAPHTTP, FTP,电子邮件服务流服务目录服务发布服务基于XML的消息网络（Web Service的整体架构图）通过这样一个层次清楚的架构，Web Service将实现动态的应用集成，将系 统推向智能、更加实用的阶段。Web Service具有以下一些主要优点：1）完好的封装性和松散耦合；2）使用协约的规范性、使用标准协议规范；3）高度可集成能力；4）开放性、普遍性和互操作性；5）易于使用；6）广泛的行业支持。在工程中运用Web Service技术，将充分体系出应用系统的先进性和实用 性，充分发挥应用系统的开放性和可扩展性，保证系统的完整统一和数据资源的 共享利用。3.3.4 XML 技术XML （extensible Markup Language,可扩展标记语言），是当前最热门的 网络技术之一，被称为“第二代Web语言”、“下一代网络应用的基石”。自它 被提出以来，几乎得到了业界所有大公司的支持。XML具有卓越的性能，它具有 四大特点：优良的数据存储格式、可扩展性、高度结构化、方便的网络传输，以 XML技术作为支持，为用户自定义应用界面和业务数据结构，并将其与底层数据 库定义格式、界面标准输入、输出的接口转换作了实现，可实现分布式、异构应第13页共63页政务服务一件事建设方案用系统之间的数据交换。国家电子政务标准指南中也把XML列为重要内容， 国家电子政务总体组将基于XML的电子公文格式、XML在电子政务中的应用指南 作为第一批6个电子政务标准制定工程。3.3.5 基于构建化的软件开发基于构件化开发的思想改变了传统软件的生产方式，通过构件化的业务基础 平台帮助用户构建整体的信息系统；提供了完善的基于互联网应用的构件化开发、 运行及维护环境，能充分支持业务构件的管理与集成。它不仅提供了可视化开发 和集成环境，用户只需“拖拉拽”相应的构件即可“画”出新的业务和应用要求； 还提供了部署、监控、管理等工具，实现了从软件开发到发布、运行、升级的全 程可视化。3.4 系统非功能设计高可用性设计xx市“一件事”服务管理系统是一个大型互联网应用。一般来说，平台一项 服务的提供，需经过很多环节，任何一个环节出现问题，都可能导致系统不可用。 DNS被劫持、服务器宕机、交换机失效、硬盘损坏、网卡故障、机房停电、程序 BUG、黑客攻击等各种情况都有可能发生，因此，要保证平台完全可用难度非常 之大。3.4.1.1 高可用的架构衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或 者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。因此，高可用架构设计的目标就是当服务器硬件故障时服务或者应用依然可 用、数据依然保存并能够被访问。实现系统高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦 某些服务器宕机，就自动将服务切换到其他可用的服务器上，如果磁盘损坏，就 从备份的磁盘读取数据。系统总体上采用分层的架构，采取如下手段保证架构的高可用：系统支持别离部署的模式，各子系统可以独立部署在各服务器（虚拟机）集 群上。第14页共63页政务服务一件事建设方案对于应用服务器（虚拟机）集群而言，为了应对高并发的请求，通过负载均 衡使得集群统一对外提供服务，任何一台应用服务器（虚拟机）宕机，请求会自 动切换到其他服务器（虚拟机）就可实现应用的高可用。系统通过Docker镜像实现应用的持续交付和容器化部署。可根据负载压力 实现相应应用服务容器的自动上线、下线。基于应用交付负载均衡设备，实现多链路网络环境中流量分担的问题,充分 提高多链路的带宽利用率，节约企事业单位对通信链路的投资;通过为用户和应 用系统分配最正确的通信线路，使用户获得绝佳的访问体验。3.4.1.2 高可用的数据对于存储服务器（虚拟机）而言，由于其上存储着数据，为了保证服务器宕 机时数据不丧失，数据访问服务不中断，主要手段就是数据备份和失效转移机制。 数据备份是保证数据有多个副本，任意副本的失效都不会导致数据的永久丧失, 从而实现数据完全的持久化。而失效转移机制保证当一个数据副本不可访问时, 可以快速切换访问数据的其他副本，保证系统可用。需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据 冗余备份。当服务器宕机时，应用程序将访问切换到有备份的数据的服务器上。3.4.1.3 软件质量保障系统高可用的保障，除了网络、服务器等硬件故障导致的系统可用性风险外, 还有来自软件系统本身的风险。在本工程设计中，采用基于Docker容器的持续交付方案，最大程度地提高 软件交付的质量。Docker可以把任何应用及相关依赖项打包成一个轻量、可移植、自包涵式的 容器，该容器拥有标准的操作，从而能够实现自动化。与此同时，所有的应用都 可以运行在任何Linux服务上。相同的容器，开发者可以在笔记本上有规模的运 行、生产，也可以在虚拟机、逻辑服务器、公有云、或以上所有结合（的方式） 上运行。换句话说，开发者构建的应用只需一次构建即可多平台运行。运营人员只需 配置他们的服务，即可运行所有的应用。第15页共63页政务服务一件事建设方案目录第一章工程简介11.1 建设目标11.2 建设规模11.3 建设内容1第二章需求分析22.1 建设背景22.2 需求分析22.2.1 业务需求22.2.2 性能需求32.2.3 平安需求32.3 工程建设必要性4第三章总体建设方案53.1 建设原那么和策略53.1.1 坚持对标先进、全面突破53.1.2 坚持整体协同、用户导向53.1.3 坚持解放思想、敢于创新53.2 总体架构53.3 技术应用体系73.3.1 主流技术架构分析73.3.2 三层架构73.3.3 SOA 体系93.3.4 B/S软件结构113.3.5 对象/组建开发技术123.3.6 Web Service 技术123.3.7 XML 技术133.3.8 基于构建化的软件开发143.4 系统非功能设计143.4.1 高可用性设计14政务服务一件事建设方案3.4.2 可扩展性设计系统在设计上采用分布式技术支撑可扩展的部署，采用平台化的设计理念实 现功能服务的可扩展，来应对不断上升的用户并发访问能力、不断增长的存储需 求、不断调整的业务要求。3.4.2.1 部署架构可扩展设计“一件事”服务管理系统需要面对大量用户的高并发访问和存储海量数据， 不可能只用一台服务器就处理全部用户请求，存储全部数据。因而，需要通过集 群的方式将多台服务器组成一个整体共同提供服务，通过引入虚拟化技术，将物 理服务器虚拟化成资源池进行集中管理，可大大提供物理服务器的利用率，而且 向集群中增加服务器变得更加容易；同时通过应用Docker容器技术，使集群化 的持续交付难度降得更低，运维起来也更加方便。系统架构的可扩展性设计可以分成两类：（1）模块的微服务化别离设计根据功能模块进行别离式开发和部署，并通过微服务的方式进行集成。采用 微服务的设计方式，将不同功能进行物理别离实现伸缩，实现不同的服务器部署 不同的服务，提供不同的功能，比方用户管理、附件存储、运维管理等。（2）每个功能模块都支持集群化部署针对政务服务平台的应用需求，单一的服务器肯定不能满足业务规模的需求。 因此必须使用服务器集群，即将相同的服务部署在多台服务器上构成一个集群整 体对外提供服务。系统在设计实现时采用无状态模式，所有功能模块都可以支持集群化部署， 通过服务器资源的增减来满足用户请求的变化。上面二种方式，前者是不同的服务器部署不同的服务，提供不同的功能；后 者是集群内的多台服务器部署相同的服务，提供相同的功能。3.4.2.1.1 应用服务器的可扩展性应用服务器应该设计成无状态的，即应用服务器不存储请求上下文信息，如 果将部署相同应用的服务器组成一个集群，每次用户请求都可以发送到集群中任 意一台服务器上去处理，任何一台服务器的处理结果都是相同的。这样只要能将第16页共63页政务服务一件事建设方案用户请求按照某种规那么分发到集群的不同服务器上，就可以构成一个应用服务器 的集群，每个用户的请求都可能落在不同的服务器上。通过虚拟化技术实现应用服务器集群的弹性部署，组成一个虚拟机集群，可 大幅提升应用服务器的资源利用率，并可轻松实现向应用服务器集群增加服务器, 实现弹性的扩展能力。动态基础设施环境中对应用资源供给符合按需、动态的原 那么，一切部署到动态环境中的程序，均由环境统一地、动态地分配各类资源，动 态基础设施环境中应用实例部署在随机分配的虚拟机中。3.4.2.1.2 分布式缓存的可扩展性设计传统环境下的缓存通常内嵌入应用内部，与应用共享存储空间，其容量受到 制约。应用集群后，通常采用类似于“内存复制”的方式进行多节点间的数据同 步。当节点较多时会造成大量网络流量，降低应用运行效率。分布式缓存采用独立的缓存集群，为应用提供一个大容量、高速、可靠的存 储介质。分布式缓存容量由集群规模决定，不受应用服务器内存限制。由于实现 了缓存数据的集中存储，因此不存在传统缓存的“多节点数据同步”的场景，不 会因同步数据产生网络流量。由于分布式缓存具有很大的容量，且速度极快， 应用可以将业务上“读多写少”的业务对象或数据存入缓存，极大提升应用的响 应速度。此外，分布式缓存还可以作为异步写入队列，临时数据中转站等等， 有效缓解数据库等其他中间件的压力。分布式缓存方案其底层实现主要有两种架 构，适用于不同环境。本工程中，将基于Redis来实现分布式缓存的支撑方案。3.4.2.1.3 分布式文件存储的可扩展性设计本工程数据交换时须存储海量的文件，因此需要有一套容量无上限、可无限 扩展、高性能、高吞吐率的分布式文件存储系统。3.4.2.2 功能架构可扩展设计根据工程要求，系统功能应当具备可持续扩展或提升的能力。表现在系统基 础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响 应。它是系统架构设计层面的开闭原那么（对扩展开发，对修改关闭），架构设计 考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行第17页共63页政务服务一件事建设方案修改。衡量系统功能架构扩展性的主要标准就是在系统增加新的业务时，是否可以 实现对现有业务透明无影响，不需要任何改动或者很少改动既有业务功能就可以 上线新业务。不同业务之间是否很少耦合，一项业务的改动对其他业务无影响, 其他业务和功能不需要受牵连进行改动。开发低耦合的系统是软件设计的终极目标之一。低耦合的系统更容易扩展, 低耦合的模块更容易复用，一个低耦合的系统设计也会让开发过程和维护变得更 加轻松和容易管理。设计本系统可扩展功能架构的核心思想是平台化设计、服务化集成，并在此 基础上，降低模块间的耦合性，提高模块的复用性。3.4.2.2.1 模块别离分层、分割是模块化设计的重要手段，纵向上，将系统分为基础设施层、数 据存储层、技术支撑层、业务运行层和综合管理层，各层之间相互独立，每个层 次可独立进行扩展和演化，下层为上层提供服务，不允许隔层调用，层间通过消 息及依赖调用的方式合成一个完整的系统。通过分层和分割手段，将系统模块化、Docker容器化，这些模块通过分布式 部署的方式，通过Docker镜像部署在独立的服务器（集群）上，从物理上别离 模块之间的耦合关系，进一步减低耦合性提高复用性。3.4.2.2.2 通过消息队列解耦如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影 响最小，这样系统的可扩展性无疑更好。本工程设计中采用云平台MQ消息队列组件支持来实现模块解耦、异步交互, 通过在模块之间传输消息，以保持模块的松散耦合，借助消息的通信完成模块间 的合作。消息队列利用发布一订阅模式进行工作，消息发送者将消息发送至分布式消 息队列，一个或者多个消息接收者从分布式消息队列订阅消息，可以看到消息发 送者和消息接收者之间没有直接耦合。对新增业务，只要对该类消息感兴趣，即 可订阅该消息，对原有系统和业务没有任何影响，从而实现业务的可扩展设计。第18页共63页政务服务一件事建设方案3.4.2.2.3 微服务设计使用微服务设计是降低系统耦合性的另一个重要手段。微服务设计模式通过 接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。利用微服 务的整合可以打造可复用的业务平台。通过拆分，将模块独立部署，降低系统耦合性。拆分可以分为横向拆分和纵 向拆分。纵向拆分是指将一个大应用拆分为多个小应用，如果新增业务较为独立，那 么就直接将其设计部署为一个独立的Web应用系统。横向拆分是指将复用的业务拆分出来，独立部署为分布式服务，新增业务只 需要调用这些分布式服务,不需要依赖具体的模块代码，即可搭建一个应用系统, 而模块内业务逻辑变化的时候，只要接口保持一致就不会影响业务程序和其他模 块。对于横向拆分，不但需要识别可复用的业务，设计服务接口，规范服务依赖 关系，还需要一个完善的分布式服务管理框架。3.4.3 高性能设计衡量系统性能有一系列指标，重要的指标包括响应时间、TPS、并发处理能 力等，通过这些指标来确定系统设计是否到达了性能目标。从最终用户视角看，系统性能就是用户在浏览器上直观感受到的网站响应速 度快还是慢。在实践中，采取优化页面HTML式样、利用浏览器的并发和异步特 性、调整浏览器缓存策略、反向代理等手段，使浏览器尽快地显示用户感兴趣的 内容、尽可能近地获取页面内容，即使不优化应用程序和架构，也可以很大程度 地改善用户视角小的网站性能。从平台开发人员视角看，他们更多关注接口服务程序本身的性能，包括响应 延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标。主要的优化手段有 使用缓存加速数据读取，通过数据压缩提高传输效率，使用集群提高吞吐能力, 使用异步消息加快服务请求响应，使用代码优化手段改善服务程序性能。从运维人员视角看，他们关注的是基础设施性能和资源利用率。主要优化手 段有系统一体化运维监控，云计算资源快速扩展。第19页共63页政务服务一件事建设方案3.4.3.1 WEB前端性能优化浏览器访问优化减少HTTP请求，主要手段有合并CSS、合并JavaScript、合并图片。将浏 览器一次访问需要的JavaScript、CSS合成一个文件，这样浏览器就只需要一次 请求。图片也可以合并，多张图片合并成一张,如果每张图片都有不同的超链接， 可通过CSS偏移响应鼠标点击操作，构造不同的URL。使用浏览器缓存，CSS、JavaScript、Logo,图标等这些静态资源文件更新 的频率较低，而这些文件又几乎是每次HTTP请求都需要的，如果将这些文件缓 存在浏览器中，可以极好地改善性能。通过设置HTTP头中的Cache-Control和 Expires属性，可设定浏览器缓存，缓存时间可以是数天，甚至是几个月。启动压缩，在服务器端对文件进行压缩，在浏览器端对文件解压缩，可减少 通信传输的数据量。文本文件的压缩效率可到达80%以上，因此，对HTML、CSS、 JavaScript文件启用GZip压缩可到达较好的效果。CSS放在页面最上面、JavaScript放在页面最下面，因为浏览器会在下载完 全部的CSS之后才对整个页面进行渲染，因此最好的做法是将CSS放在页面的最 上面，让浏览器尽快下载CSS；而JavaScript正相反，浏览器在加载JavaScript 后立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此JavaScript最 好放在页面的最下面。但如果页面解析时需要用到JavaScript,这是放在底部就 不合适了。减少Cookie传输，Cookie包含在每次请求和响应中，太大的Cookie会严 重影响数据传输,因此哪些数据需要写入Cookie需要慎重考虑，尽量减少Cookie 中传输的数据量。3.4.3.1.1 CDN 力口速CDN（内容分发网络）的本质是一个缓存，将数据存放在距离用户最近的地 方，使用户以最快的速度获取数据。由于CDN部署在网络运营商的机房，这些运营商又是终端用户的网络服务提 供商，因此用户请求路由的第一跳就到达了 CDN服务器，当CDN中存在浏览器请 求的资源时，从CDN直接返回给浏览器,最短路径返回响应,加快用户访问速度， 较少数据中心负载压力。第20页共63页政务服务一件事建设方案反向代理反向代理是在Web服务器之前，代理Web服务器处理客户端HTTP请求的技 术。客户端的HTTP请求首先经过反向代理服务器处理，再由反向代理服务器根 据配置的策略，将请求转发给后面的Web服务器处理。由于反向代理服务器处于客户端与Web服务器之间，因此反向代理服务器的 主要可以实现三类功能：访问控制、前端缓存和负载均衡。所谓前端缓存，就是将客户端的HTTP请求中有关的静态内容缓存在反向代 理服务器上，当客户端的请求访问这些内容时，反向代理服务器直接将这些数据 返回给客户端，而不必将请求转发给后台的Web服务器，加速了 Web请求的响应 速度。3.4.3.2 应用服务端性能设计应用服务端负责处理业务逻辑，是系统开发最复杂，变化最多的地方，保障 性能的主要手段是缓存、集群和异步等。3.4.3.2.1 缓存缓存工作机制缓存主要是用来保存那些读取操作远大于写入操作的数据，以及变化很少的 数据。应用程序使用缓存的方式如下：应用程序读取数据时，先尝试从缓存中读取，如果读取到了那么直接返回；如果没有读到数据，那么应用程序转向从数据库（或者文件系统）读取数据, 并将数据写入到缓存中，以便下次访问时可以直接从缓存中读取。缓存类型缓存有两种类型：在应用服务器上的本地缓存以及在远程服务器上的远程缓 存。本地缓存由于没有网络访问开销，因此访问速度上更快一些，但受到应用服 务器内存的限制，数据量会有限，并且存在与应用程序争用内存的情况。远程缓 存会有网络开销，性能上比本地缓存要差一些，但由于可以采用专门的用于缓存 服务的大内存服务器，因此在缓存容量上比拟大，并且如果通过集群的方式部署 分布式缓存系统的话，理论上是没有容量上限的。本地缓存与远程缓存可以配合使用，类似于处理器的缓存机制，使用本地缓第21页共63页政务服务一件事建设方案存作为一级缓存,放置最近经常访问的最热点数据；使用远程缓存作为二级缓存, 放置次热点数据。如何设计两级缓存之间的缓存策略，保证最优化的使用效果, 需要在具体的实施过程中根据应用对数据访问的特点来进行优化。分布式缓存采用分布式缓存的主要原因是在单台缓存服务器的能力无法承当业务，需要 多台缓存服务器共同来承载压力。对于政务服务平台这样大型的应用来说，分布 式缓存采取独立部署模式，由多台独立的缓存服务器构成的集群为应用系统提供 整体的缓存服务，缓存服务器是互相独立的，之间没有数据复制等依赖关系。 集群通过分布式实现了计算和存储的独立部署，需要通过负载均衡技术实现对这 些资源的整合，形成服务能力的集群化管理。通过集群技术，实现网站的高可用 性和高性能。3.4.3.2.3 异步异步技术能够降低软件的耦合性。业务之间的信息传递不是同步调阅，而是 通过共享消息管理，并通过消息队列进行业务之间的信息传递。通过异步能够加 快用户请求的响应速度，提高系统的性能。3.4.3.2.4 分布式计算分布式意味着可以使用多台计算机完成统一的功能，通过分布式，能够处理 大并发、大数据量的业务，使得系统具有良好的高性能，能够为更多的用户提供 服务。常用的分布式可以分为：分布式计算、分布式缓存、分布式数据库、分布 式文件系统等。3.4.3.2.5 基于组件的设计应用系统的设计应利用基于构件的开发理念，程序应使用简单的逻辑和算法 来获取结果，防止复杂以及深层次的对象调用，提高运行效率，以获得快速的典 应速度。3.4.3.2.6 代码质量开发工程师编写的代码的质量直接关系到系统的性能，根据一般经验，在多第22页共63页政务服务一件事建设方案层体系结构的业务应用系统的开发中，关键是数据库的操作编程以及涉及到中间 件的编程将对系统性能影响很大。3.4.3.2.7 存储性能设计充分利用分布式存储技术，来满足本次工程对多种类型、数据量大、性能要 求高的数据存储要求。包括分布式文件系统、分布式数据库、NoSQL数据库等。第23页共63页政务服务一件事建设方案第四章工程建设内容4.1 事项梳理或培训服务事项梳理服务4.1.1.1 单事项精细化梳理针对各部门服务事项，提供事项精细化梳理服务，以事项标准化为基础，围 绕政务服务事项办理过程中的二级材料、办理情形等开展精细化梳理工作，为支 撑网上办理及一窗受理等业务提供基础支撑。4.1.1.1.1 梳理思路以政务服务事项标准化梳理为基础，以政务服务事项业务支撑为重点，梳理 事项二级材料及办理情形，结合事项精细化梳理平台应用，形成覆盖地区各部门 政务服务事项的精细化梳理成果，为下一步政务服务平台升级扩展打下基础。4.1.1.1.2 梳理内容二级材料梳理依托地区各部门事项标准化梳理成果，针对各事项申请材料中的模糊表述和 兜底条款，开展二级材料梳理，明确模糊表述和兜底条款具体涉及的申请材料内 容，并借助事项精细化梳理平台，实现动态化管理。4.1.1.1.2.1 事项多情形梳理由于政务服务业务内生的复杂性，服务事项在办理过程中可能会遇到多种复 杂的情形，在不同的情形下，申请人所需填写的表单、提交的材料有所不同，部 门的审查要求也不同。所以，有必要对基于现有事项梳理成果进行精细化，将复 杂的、多样化的办理条件标准化,多个办理条件组合成办理情形，自助选择办理情 形，