（三）总体建设任务
本项目建设内容包括建设行政执法综合管理相关应用系统；建设交通运输行政执法数据中心和对外接口；建设完善智能化执法终端系统、完善软硬件支撑环境。
1. 建设行政执法综合管理相关应用系统
本项目的建设系统包括执法协同办案系统、综合移动执法办案系统、勤务管理与调派系统、执法监督与评议考核系统。系统用户覆盖通州区范围内各类执法机构的执法办案人员及管理人员。
1.1执法协同办案系统
交通运输行政执法包括执法部门及其执法人员依法实施的行政检查、行政强制、行政处罚等执法行为。依据《行政处罚法》、《行政强制法》、《行政复议法》及《交通运输行政执法程序规定》等法律法规文件，实现各类执法案件的电子化证据采集、全过程电子流转和网上办理、标准化文书制作，实现对各环节执法文书规范性、执法主体合法性、办案时限有效性、自由裁量合理性等的实时监管和自动预警，提高执法办案规范化、便捷化水平和实时监督能力，满足执法业务办理、执法监管等需要。
1.2综合移动执法办案系统
兼顾外勤执法人员、内勤执法人员、执法监督管理人员等不同用户的实际工作需要，通过移动执法终端实现监管对象的信息采集、信息查验、调查取证、法律法规查询、自由裁量基准查询、立案登记、案件审核、异常案件信息提醒、案件监督、重点监管名单管理等功能，增加执法案件信息采集能力，提高一线执法办案效率和规范化水平。
1.3勤务管理与调派系统
建设勤务管理与调派系统，集成执法车辆、人员定位信息，实现勤务计划落实情况动态分析展现、计划与实际勤务对比分析，以提升勤务安排及督查工作水平，从而进一步增强交通运输市场秩序监管的科学性和执法公正性。
接入执法人员、执法车辆、执法终端等的定位信息，可视化展示执法车辆采集的执法现场视频、图片等信息，为执法勤务安排和勤务调派提供支撑。
1.4执法监督与评议考核子系统
实现网上案件随机抽查、实时监督、特殊案件备案与督办等执法监督功能，以及执法人员的评议考核、网上评查、考核结果发布等评议考核功能。
1.5支撑环境
完善软硬件支撑环境，包括主机及存储系统、网络及安全系统、应用支撑软件等基础支撑系统。具体包括完善数据交换平台、短信服务平台、GIS平台、统一权限管理平台等应用支撑平台，完善广域网和局域网建设，确定物理环境、网络、数据、应用系统、服务器区等安全建设方案，购置必要的主机和存储设备等内容。
2. 建设交通运输行政执法数据中心和对外接口
基于已有执法机构、执法人员数据库，以“执法案件”为主线，建设完善执法案件、法律法规等数据库，形成覆盖全区范围的各执法门类的执法案件数据资源库群，实现各执法门类的案件信息汇集与整合。执法数据资源主要是满足区内、跨门类执法数据交换需求，执法业务协同与监管应用数据需求，行业决策、综合查询、统计分析数据需求。
进行接口开发实现与北京市交通运输数据资源交换共享与应用平台、与北京市行政审批系统、网约车处罚系统、北京市机动车维修管理系统、与通州区经信局大数据平台的对接；并预留接口，未来实现与市级执法平台和通州区交通局行业内相关系统的对接。
3. 建设完善执法设备
配备车载执法终端、车载打印机、手持执法终端等智能化执法终端，提高执法现场监控、证据采集的智能化水平，提升日常执法应用与勤务调派管理应用，实现违法行为的综合巡检和自动甄别。
（四）总体框架
1.逻辑架构
1.1. 系统总体架构
图四-1整体架构设计
系统包括用户层、展现层、服务层、应用层、支撑层、数据资源层、运行环境层、基础支撑层，以及标准规范体系、信息安全体系、建设与运行管理体系等三个保障体系。
（1）用户层主要包括四大类用户，分别是：交通局领导、交通局业务科室、交通局执法人员、社会公众。
（2）展现层实现应用展现，主要包括政务网站、移动终端等展现方式。
（3）服务层主要包括协同办案服务、移动执法办案、案件督办、勤务管理、勤务调派、监督考核、查询统计服务等。
（4）应用层主要包括执法协同办案系统、综合移动执法办案系统、勤务管理与调派系统、执法监督与评议考核系统等。
（5）支撑层展现应用支撑平台功能，主要实现对上层应用服务系统功能的支撑，包括统一认证系统、短信平台等。
（6）数据资源层，展现对系统各类信息资源进行定义、存储、加工和管理的设计，包括基础数据库、业务数据库、共享数据库等。
（7）运行环境层包括政务外网、移动通信网络等。
（8）基础支撑层主要包括系统软件、执法工程装备、网络及安全设备、主机存储设备、配套设施等。
（9）系统保障体系主要包括信息化标准、数据规范、信息管理制度，信息传输、保护的安全体系，建设与运行管理体系三方面保障体系。
1.2. 系统功能架构
图四-2系统功能架构图
系统建设功能主要包括执法数据中心、业务系统、智能终端设备、软硬件支撑环境和对外接口。
通过建设执法数据中心，实现执法数据的汇聚和管理；
建设综合执法业务系统，实现内业、外业执法协同办案、移动办案、勤务管理和调派，以及执法监督与评议考核的功能；
建设智能执法终端，提高证据采集、信息查验和执法办案效率。
1.3. 二级系统体系
图四-3二层架构体系图
应用软件系统分为二层架构体系，同时建设权限与用户设置管理等支撑系统，保障系统顺利运行。
（1）交通局领导及相关业务处室、执法机构领导
最上层用户为交通局领导及相关业务处室、执法机构领导。
执法协同办案系统实现对执法案件的审批、案件督办与查询等功能。
综合移动执法办案系统实现对移动执法案件审批、案件督办、查询；移动勤务安排、审批与督查等功能。
勤务管理与调派系统实现勤务安排、领导网上审核、督查、调派、查询统计等功能。
执法监督与评议考核系统实现对执法人员的日常执法监督、案件督办和年度评议考核。
（2）执法人员层面
执法协同办案系统实现证据采集与信息查验、案件办理、行政检查、双随机抽查、电子送达、查询统计等功能。
综合移动执法办案系统实现移动执法案件办理，实时查验所需信息，执法文书现场制作及打印等。
勤务管理与调派系统实现接收勤务安排指令与督查，勤务信息查询等功能。
执法监督与评议考核系统实现对领导督办任务的接收，考评结果的查询等。
1.4. 与北京市交通委现有执法系统及市级平台的关系
本系统与北京市交通委现有执法系统、北京市交通运输数据资源共享交换与应用平台，以及与委新建执法平台的关系如下图所示：
图四-4系统关系图
如上图所示：
本系统将充分利委现有执法系统的技术支撑，进行本系统的建设，同时进行对外接口开发，实现与北京市交通运输数据资源交换共享与应用平台的对接，利用交通执法总队二级平台实现信息查验和执法数据的共享交换。
进行接口预留，待委新建执法平台建设完成后实现与委执法平台的对接与集成。
2.技术架构
2.1. 整体技术架构
本项目技术架构的总体设计思路是，通过信息化基础设施的智能化，和业务流程的智能化，将信息流和执法办案的业务紧密地结合起来，持续高效地交付信息化服务，进而辅助执法参与者便捷高效地掌握业务服务水平，提高交通运输行政执法的业务智能化水平。
本项目从技术架构上，按照数据承载由物理到业务的抽象，由低到高依次分别为计算资源、中台服务和业务应用。计算资源层由政务云提供基础设施服务(IaaS)，在此依托上，基于区执法的基础数据、业务数据和共享数据，构建数据中台服务，包含若干个独立的中台服务中心。以“厚中台、薄应用”的思路为指导，在服务中心基础上通过模块化组合形成上层业务应用，满足具体的业务使用场景需求。同时，本系统涉及到对外交互和安全，需要通过结合政务云的基础安全设施和本系统的安全设计，为系统内外的业务安全、数据安全、网络安全、主机安全和账户安全提供统一的服务。
图四-5整体技术架构图
计算资源层包含了计算资源池、网络资源池、存储资源池和数据库资源池，依托于政务云的基础设施服务(IaaS)提供基础的资源支撑。计算资源池包括了以x86框架体系为代表的虚拟化主机单元，可根据业务计算的使用需求进行弹性伸缩。计算资源池以虚拟化CPU核（线程）和虚拟化内存为最小计算单元。网络资源池主要包括网络层面的相关设施服务。基础的网络服务包含了对于政务内外网以及互联网的网络支持，同时政务云包含了互联网的IP地址租用和相应的域名备案。在Web应用层面，政务云可提供负载均衡服务以保证多并发情况下执法终端对于中台服务的访问可用性。为了隔离政务网和互联网环境，基础的运维操作，需要通过政务云的IPSec VPN接入服务来完成。同时政务云提供了WAF网络应用防火墙，给执法业务中台服务提供相应的Web应用安全保障。存储资源池方面，政务云以高性能存储（SSD硬盘）提供虚拟化主机的系统盘和数据盘，支撑虚拟化主机的操作系统和业务应用。普通性能存储被用于进行数据备份，包括业务数据层面的全量、增量冗余备份，和操作系统快照层面的主机备份。数据库资源池的构建则相对灵活，可使用政务云服务提供的数据库集群服务，也可以自建数据库集群用于满足基础数据、业务数据和共享数据的存储使用需求。
整体技术架构中，最核心的部分为中台服务层。中台服务层由若干个相对独立的服务中心组成，以中台持续治理进化的思路为指导，在系统的开发、运营层面始终遵循技术开发规范，不断迭代服务中心的服务能力集合，为上层应用提供规范化的服务中心服务。
使用中台服务形式，能从数据和技术两个层次提升系统开发、运营的效率。在数据层面，中台服务可以通过不断的数据累积，将各个种类的业务数据都沉淀在同一套中台服务中，由量变引起质变，联立发挥大数据威力。同时，中台服务能够提高对于数据质量的保障，通过各个业务系统对同一套中台数据的使用，业务人员能多维度校核数据准确性，进而倒逼一线业务流优化，确保一线工作流机制上对于数据质量的保障。在技术层面，上层业务应用能够通过服务重用，通过组合服务中心的服务能力来获得业务扩展，以松耦合的形式带来业务应用的复用，减少开发部署压力，更快地通过共享服务的组合响应业务优化。
随着业务数据的不断沉淀，各个服务中心从提供单一业务功能到支持更广泛的业务场景，不断地实现自我进化。为此，需要遵循如下的设计循环，不断深化服务中心能力。
在服务中心规划阶段，由业务需求对应的具体业务场景，抽象出具体的执法业务用例，从而形成执法业务模型。对于执法业务模型需要的业务功能，根据既有的服务中心规划，提取必要的服务中心应用，并结合增量的服务能力需求，形成满足业务应用的接口。在服务识别与设计阶段，通过多个业务应用对服务中心服务的需求抽象和精炼，组合形成服务能力模型。
为了实现中台服务中心的循环迭代，需要在开发和运营阶段对于中台服务的演进进行严格的质量控制，需要按照各个层面的设计规范，做好开发管理，以保障平台持续改进的滚动迭代进行。需要遵循的规范，主要包括技术架构、开发规范、接口规范、部署规范、日志规范等方面。
1)技术架构主要涉及到规范化的基础设施、架构分层和技术组件。基础设施在本项目中统一使用政务云的虚拟化主机和共享网络得以实现，架构分层则主要体现在前后端具体代码实现中，需要遵循统一的分层抽象逻辑，如DTO、VO、DO、PO、Entity等对象，从存储、后端到前端的需要保证一致统一。
2)技术组件则体现在不同服务中心的同种技术需求场景下，需要使用统一的组件构型，以保证数据一致性和开发兼容性，如选用统一的Web容器、消息队列、缓存服务等。
3)开发规范方面，首先需要各服务中心开发团队遵循统一的命名规范，包括对象名、函数名、常数名的命名方式和大小写，以保证团队内部无歧义的含义理解。其次，需要遵循统一的注释规范，包括行注释、块注释的统一形式，注释的作者、变更时间、用途等信息，以减少团队内部开发协作带来的理解障碍。对于各个层次会涉及到的异常，则需要统一异常的触发条件和报错结构，方便开发人员能够一致性地进行异常定位。涉及到后端的数据即席计算和指标数据提取，则尤其要注意SQL编写规范，以保证统一的性能表现和开发组内的可理解性。
4)接口标准方面，要同时兼顾系统内部的数据流传递，和对外数据共享接口。其中，URI规范包括URI地址的大小写、分段方式和业务逻辑对应方式。请求规范需要包括统一的请求体类型(MIME Type)、请求方式(POST, GET, DELETE, OPTION)、参数格式、编码格式，响应规范需要包括统一的返回体类型(MIME Type)、响应体格式（状态码、数据体、异常消息等）。同时，在错误码规范中，需要明确不同类型错误的错误码形式，以明确开发人员调试时的检查方向。
5)部署规范覆盖的是部署运维阶段，中台服务中心需要遵循的标准。资源规划方面，不同的中间件、应用需要根据实际业务需求的吞吐量和响应速度，兼顾平峰和高峰的业务量波动，形成基础资源配置加弹性资源增减的资源规划模式。在部署方案方面，需要结合自动化持续部署工具（如Jenkins），形成自动化部署流水线，做好服务配置的版本化管理，以保证服务中心部署的可查可追溯。网络安全方面，则需要保证网络通信层的安全加密机制和证书可靠性，并一定程度上抵御DDoS、SQL注入的安全风险。在运维监控层面，则能够根据预定义阈值或是自动态势感知，对于应用部署层面的各项指标进行持续监控，并对风险异常进行消息报警，通知到业务、技术运维关联人员。
6)日志规范要求服务中心的日志输出保证统一的格式和序列化方式，以供下游的运维和运营分析人员，查错定位和提取执法业务决策支持导向。首先，所有的日志格式应该保持一致，包括输入的时间戳样式、类名称格式、消息体结构、日志消息级别、日志内容顺序等，只有统一的日志格式，才能极大程度上减轻下游业务日志分析的压力。对于日志的采集点设置，则需要有统一的埋置方案，包括针对前端、后端的，不同类型业务的前埋点、后埋点统计方式，以支撑丰富的下游分析需要。在持久化方案方面，日志规范需要兼顾到不同场景下，各个服务中心的日志采集频率和存储介质，综合考虑读写性能和存储成本，保障日志数据的完整存储，不重不漏。最后，对于日志采集工具，需要在规范上统一日志组件，以保证日志数据能够以配置的形式快速汇聚，减少由于数据在不同日志组件间的迁移带来的开发成本。
在中台服务体系的支撑下，业务应用层整合了技术中台和业务中台的能力，整体为执法协同办案系统、综合移动执法办案系统和勤务管理与调派系统提供业务服务。
关注我的技术公众号，每个工作日都有优质技术文章推送和电子版方案下载。
文件下载地址：
https://download.csdn.net/download/llooyyuu/87611273
https://t.zsxq.com/0cCJbajO2