统计平台项目总体架构设计方案
1 总体规划
1.1 设计原则
按照本项目的建设目标，结合本项目具有涉及范围广、建设规模大、数据构成复杂等特点，在设计阶段需遵循一些重要原则，以保障后续建设的顺利衔接和有效执行。
1、规范性
系统设计开发遵循通用的国际规范及各系统间接口标准，保障中台基础信息数据库及应用系统之间能够根据业需要实现有效的互连。
2、开放性
系统设计的各种接口在遵循规范性原则的基础上，保证其可以集成不同系统或平台供应商、软件供应商的产品。
3、先进性与成熟性相结合
系统设计采用先进成熟的技术和手段，以保障系统具有高效、全面和稳定等良好品质。系统采用先进成熟的总体构架，数据采集、整合、应用服务等采用目前主流J2EE、中间件等技术。
4、实用性
系统设计要切实保证实用性，能够解决项目的实际需求。
5、可扩展性
系统设计应充分保证系统容量、处理能力和业务范围具有良好的扩展能力；具有适应业务变化的能力，对于系统用户数量及业务量的增长、规则或代码的变化、业务单据的变更、业务流程重组等，应保证业务变化对系统运行不造成影响。
6、可靠性
保证系统具有较高的可靠性和完善的错误处理机制和自动失效转移，保证系统能够提供7x24小时不间断访问服务。
7、易用性
系统设计需要保证系统软件容易使用，一方面是方便各类服务对象，另一方面是方便系统管理员和业务管理员。功能界面风格和操作流程一致，突出用户的中心地位，保证用户使用习惯。
8、可维护性
采用面向服务的架构设计，以及结合动态流程建模，增强系统的可配置能力。
9、可移植性
采用轻量级J2EE技术体系，保障系统能跨不同平台进行移植。
10、可管理性
保证系统应该具有完善的管理机制，保证所选产品应具有良好的可管理性和可维护性。
11、安全保密性
保证系统在运营过程中管理的各种信息的安全，保证系统与其它相关系统信息交换过程的安全；保证系统应用服务的安全。对系统的操作需严格按照操作权限进行，并对每项操作留下完整的日志记录备查。
12、自主可控
遵循自主可控的原则建设本项目。
1.2 技术特点
根据本项目总体设计要求，本平台将采用SOA设计思想、服务总线+组件的技术方法，数据采集交换采用组件化方式实现各种场景下的信息交换，解决信息服务多元化，以及系统之间的信息共享、一致性等问题。在实现技术上，采用基于Springboot的微服务技术体系、运用Rest Full应用技术、Json数据交换技术，业务系统为B/S模式等。数据中台提供各部门系统接入的接口，实现数据资源中心与各信息系统的有机结合，以统一的接口规范实现不同数据库、不同数据格式的数据提取。
在遵循系统设计原则的基础上，在本项目中还将采用如下技术：
1.2.1 大数据技术
大数据技术，就是从各种类型的数据中快速获得有价值信息的技术。大数据领域已经涌现出了大量新的技术，它们成为大数据采集、存储、处理和呈现的有力武器。大数据处理关键技术一般包括：数据采集、数据预处理、数据存储及管理、数据分析及挖掘、数据展现和应用（数据检索、数据应用、数据安全等）：
1、大数据采集技术
大数据是指通过共享数据交换平台从各业务系统采集过来而形成产生的各种类型的结构化、非结构化的海量数据，是大数据知识服务模型的根本。本项目建设重点要突破分布式高速高可靠数据采集交换、高速数据全映像等大数据收集技术；突破高速数据解析、转换与装载等大数据整合技术；设计质量评估模型，开发数据质量技术。
2、大数据预处理技术
主要完成对已接收数据的辨析、抽取、清洗等操作。
抽取：因获取的数据可能具有多种结构和类型，数据抽取过程可以帮助我们将这些复杂的数据转化为单一的或者便于处理的构型，以达到快速分析处理的目的。
清洗：对于大量的数据，面临着数据不一致和冲突的问题，因此要对数据通过过滤“去噪”等方式提取出有效数据。
3、大数据存储及管理技术
大数据存储与管理要用存储器把采集到的数据存储起来，建立相应的数据库，并进行管理和调用。重点解决复杂结构化、非结构化大数据管理与处理技术。主要解决大数据的可存储、可表示、可处理、可靠性及有效传输等几个关键问题。对于结构化数据，建议采用主流可控的开源关系数据库，非结构化数据采用可靠的分布式文件系统或者网络文件系统。
1.2.2 面向服务的技术架构（SOA）
SOA架构随着互联网应用技术的深入，完全可以看作是B/S模型、Web Service技术的自然延伸，现如今基于Json数据格式的Restful标准接口已经成为SOA架构接口标准在互联网应用环境下的最佳实践。业务系统可以采用组件化的方式灵活组装配置在一起，实现统计平台各个业务间的解耦，较之以往各部门面临业务协同时紧耦合地绑定关系，SOA将能够更加从容地面对业务的急剧变化。SOA架构图如下。
SOA具有重用、松耦合、标准接口和基于开放标准等特征，如下图。
图表 2 SOA特性
在本平台中，统计分析等业务应用将被拆分成一个个的微服务，原本紧密耦合的业务将被分解成松耦合的独立业务组件，通过对微服务的组装，完成位置应用系统的构建。微服务在运行状态上独立，每个微服务也只是业务流程中的一个节点，因此，在具体应用系统中，需要多个微服务的集合才能表达完整的业务流程，点、线、面、体的结合在整体上实现流程端到端、业务全景联动的业务一体化系统。为此，必须构建起由数据模型、业务模型和集成模型所构成的领域模型，用于表达完整的业务流程。
微服务的核心是避免单体系统庞大复杂、可维护性、可扩展性、可复用性差等问题；模型的核心是解决微服务间的业务流和数据流问题，缺乏模型支撑的微服务将如同一堆规格不一的散乱零件，比单体系统更容易造成数据孤岛和流程断裂。而完全通过写定制代码实现的微服务调用及业务集成模式，将随着微服务数量的增加，出现服务间调用关系和集成关系越来越乱，越来越复杂等问题，从而导致最终应用系统的不可维护。公安数据统计综合应用平台基于用模型驱动的微服务设计架构，正是基于为了解决这个问题而考虑。
1.2.3 报表引擎复杂
基于报表引擎的复杂性，结合项目人员、周期实际情况，建议采购第三方成熟的报表分析引擎，比如SmartBI、帆软、网易数帆等，以下架构设计报表集成选取的是与事业部之前有过合作的SmartBI产品作为集成示例。
1.2.3.1 BI自研风险
《统计平台实施方案》中关于报表BI相关功能需求，项目团队整体评估后，基于项目组和部门人员无对应相关产品和项目经验，我们尚无完善的BI设计方案，导致存在设计及开发风险，具体涉及到有风险的自研内容包含但不限于如下几点：
1）平台支持根据预设好的信息自动生成制式统计报表，并根据统计数据服务中心数据自动填充统计数据。
2）制式报表：根据配置信息和基本信息制成一个成型的报表。数据来源为每个展现内容与数据库数据字段之间的映射关系，按照展现内容号、展现名称、来源数据表名、来源字段、统计方式进行设定。模型公式是展现内容中一些不是直接来源于数据表，而是经过条件判定后需要进行计算的计算公式。按照展现内容号、展现名称、模型公式、公式说明进行设定。模型间关联有两种：主表+续表，父表+子表。模型配置：对制式统计报表模型的配置信息和基本信息进行设定，从而实现制式统计报表统计功能。
3）自定义分组报表。由基层民警基于WEB方式使用拖动字段等方式，直接完