智慧服务平台技术方案.docx
《智慧服务平台技术方案.docx》由会员分享，可在线阅读，更多相关《智慧服务平台技术方案.docx（144页珍藏版）》请在冰豆网上搜索。
智慧服务平台技术方案
智慧服务平台技术方案
一、总述及需求分析
1.1项目背景
xx
1.2建设目标
1.2.1总体目标
x智慧服务平台建设遵循“要素资源化、资源平台化、平台公司化”建设理念，坚持“高端化、智慧化、专业化、集约化”建设思路，按照“一年搭框架、两年见实效、三年成规模”的时间节点，努力把x先进技术x建设成为集聚科技创新资源的“大市场”、服务科技创新活动的“经纪人”、承载科技创新主体的“太空舱”，把x建设成为在国内外有重要影响的科技创新资源“集散地”、科技创新活动“密集区”、科技创新主体“聚居区”。
用“大市场”、“大物业”、“菜市场”、“蔬菜超市”的理念，逐步勾勒出x的形象。
1.2.2具体目标
本次项目围绕整合人才、技术、设备、信息、场地、政策、金融等科技创新资源，建设x智慧服务平台，从而推动基础设施感知互联、提升园区运营管理能力、提升园区安全管控水平、丰富便捷服务渠道、增强区域科技服务创新，满足人、企、园、产融合发展，服务科技创新资源引入、加强科技创新服务，打造“想到做到、细致周到”新型科技园区智慧服务示范。
x智慧服务平台建成后，使园区设施更加智能、园区更加安全、成本更加优化、产业更加互动。
能够让入驻企业和机构工作人员、园区公众办事更加高效便捷，生活更加丰富、出行更加方便、获取信息更加齐全，让高精尖人才能够更加受益。
同时x管理将更加高效、服务更加创新，x先进技术x招商更加有力、品牌更加响亮。
园区建成后，对于入驻企业、机构方面，能够使其办事更加便捷、设施更加智能、园区更加安全、成本更加优化、产业更加互动；对于园区公众方面，能够使其生活更加丰富、出行更加方便、信息更加齐全、人才更加受益；对于园区管理方面，能够使其管理更加高效、服务更加创新、招商更加有力、品牌更加响亮。
1.2.3一期目标
x智慧服务平台一期项目将完成园区综合门户网站及APP、商务服务中心综合受理平台、科研服务平台、园区一码通管理系统、智慧共享办公系统五大业务领域的建设。
园区综合门户网站及APP的建设让入驻园区的企业、机构享受轻松、高效、便捷的工作生活及增值服务。
将分散的政务服务、公共服务、社会服务、园区资讯等功能聚合到一起，成为一体化、全天候的掌上便民服务平台。
商务服务中心综合受理平台的建设不仅限于实现行政审批，其定位于“科技服务商品超市”，作为八大中心总服务台对各个“分服务台”统筹管理、协作配合。
科研服务平台的建设梳理整合八大中心服务功能，实现各类服务产品化、模块化，主要实现检验检测服务、设备共享服务、科技成果服务、人力资源服务、数据咨询服务、创意设计服务等。
园区一码通管理系统的建设使得一码通成为可能，通过园区一码通管理系统为园区内人员动态生成与之身份一一对应的二维码，实现刷码通行、支付和考勤等多种场景。
智慧共享办公系统的建设将提供工位预定、会议室预定、智能云打印、智能投屏、办公设备短租等服务。
1.2.4项目建设内容
x智慧服务平台按照国家、x省、x州市信息化建设发展思路，根据《x省智慧园区规划与建设指南（试行）》、《x市新型智慧城市建设行动计划》建设要求，围绕园区综合门户网站及APP、商务服务中心综合受理平台、智慧共享办公系统、科研服务平台四大业务领域，开展项目建设及应用
1.3需求分析
1.3.1业务需求分析
1.3.1.1人力资源管理提供人才招聘等服务
人力资源管理相关系统主要协助平台服务全区的人员，处理人事相关事务，围绕园区人员工作的各种相关场景，提供服务接口。
对接之后，为入驻园区的企业人员提供社保、招聘、人才政策、高素质人才引进、补贴、培训、求职等相关服务。
1.3.1.2专业性软件租用满足入驻企业创意设计需求
一期入驻园区的企业大约为40多家，主要有化工、机械、建筑等公司。
入驻园区企业需要较为一致的专业性软件，主要集中在化工类、机械类、建筑类等。
该类软件目前仍需采用进口方式获取且购置费用超过单独企业的承受能力，目前大多采用租用方式，但租金依然较高。
x通过统一购置专业性软件，通过专业软件使用管理功能，以更为廉价的共享或租用方式为企业提供服务。
专业软件使用管理系统需要完成使用预约、相关信息填报、权限分配、使用过程监控、使用计费、数据保护、缓存清理等功能。
x智慧服务平台支持组织设计/创意大赛等通过x平台进行组织、报名等。
1.3.1.3实现设备共享的线上宣传以及统计分析功能
科学技术局负责管理的平台为x省大型科学仪器设备协作共用网平台x区域相关业务。
该平台为x省科技厅统筹建立，为对外开放的公益平台。
主要分为供给方和应用方两类用户。
通过x智慧服务平台的建设，实现对设备共享平台的线下宣传、培训转为线上，扩大设备共享平台影响。
同时通过系统对接、数据共享，完成各类企业、设备类型、设备数量等的统计分析。
1.3.1.4为企业产品的质量检测提供简便快捷服务
系统通过接口方式对接厨具质检中心、计量所、市监管局等单位业务系统，通过数据共享目录方式实现数据资源共享与交互，最终根据检测流程的不同实现产品检测预约、相关标准查询、信息公示、检验目录更新、电子检验报告下载等功能。
1.3.1.5综合性服务中心提供园区内人员多样化服务体验
x智慧园区的服务中心采取创新应用，重点建设包括交易服务平台、APP和门户网站、智慧服务系统等服务应用。
到访客户通过智慧服务平台，线上选择办事人员。
智慧服务平台提供展示办事导航、办事人员业务范畴、是否空闲、叫号等功能。
由办事人员找到客户去提供服务。
服务中心可办事项包括法律事务、生活、商务服务等，均在平台上体现。
门户网站动态展示园区建设情况，根据不同人员关心要素不同，实现千人千面。
1.3.2系统用户分析
智慧服务平台用户主要涉及系统管理人员、入驻企业用户以及社会公众3类人员。
针对各类人员进入园区的目的不同，平台需保障其获得相应的服务。
1.3.2.1园区管理人员
一般为智慧管理平台运维管理工作人员主要管理本园区的企业，负责本园区的招商引资、企业推广、产品推广、园区内部的物业管理、文件发布、企业管理、人员管理等具体管理工作。
确保方便快捷的权限配置、完善可靠的数据保障、友好稳定的业务系统等，保障工作的顺利开展。
使用平台对园区进行精细化、简便化管理和运营。
1.3.2.2入驻企业用户
园区企业是智慧园区管理的主体，也是园区信息的来源主体。
入驻企业用户注册后使用，需要将本企业相关信息上报园区管理部门，按照其权限享有平台提供的政务、法律、科研、生活等便利服务。
园区企业也需要了解园区的公告和政策信息。
1.3.2.3社会公众
社会公众是智慧园区平台的一部分用户，门户网站是园区对外宣传的名片，为各地的求职人员和潜在投资者更好地了解园区、认识园区、考察园区、投资园区开启一个新的窗口，允许其以游客的身份访问平台，了解园区的最新动态。
1.3.3功能需求分析
1.3.3.1业务中台
通过上述业务需求分析，建议x的核心平台采用中台架构，基于微服务思想，采用基于J2EE技术的springboot技术框架和前后端分离技术，一期搭建好可扩展可扩容可分布式构建的中台架构核心平台，该业务中台主要实现自由可定制的工作流引擎，可基于x的业务需求灵活定制业务工作流，主要的业务功能工作流包括：
——商务服务工作流：
通过该工作流配置以提供业务预约、现场呼叫、服务评价等园区商务服务；
——科研服务工作流：
通过该工作流提供智慧检验检测业务流程、人力资源服务流程、数据服务流程、创意设计服务流程、学生交流服务流程、商务服务流程、展示交易服务流程、设备共享服务流程、公司登记服务流程、科技中介服务流程
——共享办公工作流：
通过该工作流实现会议室/工位预订流程、办公设备短租服务流程。
中台架构主要包含的技术有：
微服务、DevOps、持续交付、容器化、以及本方案所采用的J2EESpringBoot开发框架和可以实现自由配置流程图、流程参与者、自由配置流程环节的activitii技术。
1.3.3.2数据中台
基于上述中台架构，可以有效的实现数据共享和聚合功能的数据中台；通过数据中台各微服务子系统的数据共享和聚合，为园区管理人员提供一张图的数据呈现和数据分析。
为达到数据共享、数据分析一张图的目标，要求系统的数据中台功能必须提供：
（1）数据服务总线
负责将各业务子系统数据采集、数据抽取、清洗整合；建立统一的标准数据模型，形成统一的数据存储。
（2）数据共享交换
负责实现业务级的实时数据调取和共享，解决各部门之间的数据共享交换和互联互通；
（3）数据能力开放
负责面向园区管委、企业、公众等提供数据查询展示和业务支撑。
（4）决策分析可视化
基于大数据技术建立一张图的决策分析可视化，支持多类型任务计算模式和各类算法，实现数据的高效分布式计算、图表化展示。
（5）管理监控机制
实现入侵检测、漏洞扫描、安全审计、身份认证，确保数据中台的信息安全、数据安全。
数据平台架构图如下图所示：
数据平台架构图
1.3.3一体化门户
门户是园区各类用户访问平台接受服务的窗口，必须通过最先进的一体化门户技术，同步的一体化的提供包括：
PC网站、APP、微信公众号、小程序、H5链接等等在内的便捷的线上互联网门户，以集聚园区各类服务资源，建设园区综合门户网站及APP，让入住园区的企业、机构轻松享受高效、便捷的工作生活及增值服务，将分散的政务服务、公共服务、社会服务、园区咨询等功能聚合到一起，成为一体化，全天候的掌上便民服务平台。
该部分主要提供的业务功能包括：
（1）门户网站：
建设园区门户网站，提供统一门户、提供园区咨询、园区入驻、园区服务、园区全景等板块，支持单点登录、权限管理、园区介绍、政策发布、入住申请等功能。
（2）APP及微信H5移动端：
考虑到移动互联网的普及，本方案除了提供传统的PC端网站外也同步提供使用感受基本无差异的APP、微信公众号H5页面、微信小程序等移动端访问门户。
（3）统一认证统一鉴权：
为了方便用户的快捷访问，系统需要实现一次用户鉴权认证即可享受平台所有相应用户权限的园区服务和功能模块访问使用。
（4）科研服务：
以检验检测、人力资源、数据服务、创意设计、学术交流、商务服务、展示交易、设备共享“八大中心”服务为基础，开发科研服务模块，提供包含文献检索、专利检索、设备共享服务、计量检测检定、科技项目申报等服务。
（5）保障服务：
建设园区运营管理系统，实现意向信息管理、运营资源管理、运营入驻管理、运营统计分析；建设人才中心系统，实现人力资源管理、招聘会信息发布、劳动保障服务、就业保障服务、劳务派遣功能；建设政务服务系统，实现办事指南、预约办理、网上申请、在线查询等服务；建设法律服务系统，实现信息查询、在线咨询、服务预约等功能；建设生活服务系统，提供查询服务、约车服务、掌上购物、点餐服务、入驻服务、缴费服务、停车管理等功能；建设物业管理系统，实现收费管理、票据管理、客服管理、投诉管理等功能。
（6）管理服务：
提供第三方应用、用户认证系统、权限管理系统、访客服务、智能排班、应急管理、平安园区、统计查询、管理驾驶舱、重点项目分析等应用模块，实现访客服务、智能排班、应急管理、智能监控、统计分析等服务。
1.3.4数据需求分析
智慧服务平台由于涉及到多类用户和多种服务和管理需求，因此数据需求也比较复杂；本方案从数据分类和数据处理流程两个维度来进行数据需求分析。
1.3.4.1数据分类
根据对智慧服务平台客户需求及业务功能的分析，本方案将底层数据存储分为五个大类：
（1）用户数据：
存储系统的三大类用户数据，包括：
园区管理方用户数据、入驻企业及企业用户信息数据，公众及个体用户数据等；
（2）商务服务数据：
存储园区各类商务服务的用户订单数据、消费数据、服务内容数据、业务流程数据等等。
（3）科研服务数据：
存储园区各类科研服务的用户订单数据、服务内容数据、资讯数据、交易数据等等；
（4）办公服务数据：
存储会议室/工位预订的订单数据，办公设备租赁的可用设备信息数据、订单数据等等。
（5）其他数据：
存储其他各类上述没有涉及的数据、非结构化数据、以及和第三方平台交互所产生的临时及有必要备份存储的数据。
1.3.4.2数据处理流程
根据对智慧服务平台客户需求及业务功能的分析，本方案将整个系统的数据处理划分为以下五个步骤和流程：
（1）数据采集：
通过各个功能模块的数据交互及系统后台的批量导入功能，实现数据采集目标；
（2）ETL数据分析挖掘：
对采集的原始数据进行ETL数据抽取转换及分析挖掘，以生成高效的可用可分析数据；
（3）数据聚合：
由于平台涉及多个子系统及不同子系统的多个服务，需要多相关数据进行聚合操作，例如：
对某企业用户的商业服务消费数据及科研服务消费数据聚合以对该企业进行评估分析等等；
（4）数据共享交换：
由于平台涉及多个子系统及不同子系统的多个服务，有可能需要将一个系统的数据共享交换给另一个子系统访问及使用分析；
（5）数据服务应用：
最后将所有的数据服务通过数据中台的开放服务接口如RESTFUL等开放给各类用户，甚至第三方（如x市大数据局）使用。
数据处理流程如下图所示：
1.3.5关联系统和接口需求分析
根据前期需求调研和需求分析，本平台初期需要与以下第三方系统进行对接关联实现数据交换接口：
（1）与x市市场监督管理局平台对接
系统与x市市场监督管理局棉花与纺织品管理系统、厨具质检系统、纤检系统、质检系统、标准化系统以接口方式进行对接，对接后实现数据双向互通，将提供棉花及纺织品、厨具、纤维、化工、轻工、建筑等检验检测服务。
（2）与人力资源平台对接
系统与x市人力资源和社会保障局系统进行对接，对接后实现数据双向互通，将提供社保、招聘、人才政策、补贴、培训、求职等服务。
（3）与x市大型科学仪器设备协作共用网平台对接
系统与x市大型科学仪器设备协作共用网平台进行对接，对接后实现数据双向互通，将提供设备共享租赁服务。
（4）与其他第三方系统数据对接，可能包括：
大数据局数据共享平台，x市政府网站，12345平台等。
上述接口本平台将采取比较通用的RESTFUL数据交换接口，对于一些老系统也提供文件交互、SQL数据脚本交互等手段。
二、总体设计
2.1功能架构
智慧服务平台以满足园区核心服务功能为第一要务，在既满足用户入驻企业用户及公众用户的服务功能要求外也要全面的满足园区管理人员的管理功能、分析统计功能的业务功能要求，因此本方案提供以下平台功能架构：
图：
功能架构图
（1）数据存储层：
提供基本的数据存储功能，包括所有历史数据及各类外部接口传输的备份数据。
（2）中台支撑层：
提供数据中台的数据目录配置、数据共享、数据交换、数据聚合、ETL数据分析统计等功能；以及业务中台的工作流引擎、业务配置、表单模板配置等功能。
（3）业务功能层：
通过中台支撑的支撑实现和统一控制，提供各项具体业务功能的微服务service，具体包括：
商务服务业务功能、科研服务业务功能、共享办公业务功能、一张图数据分析呈现业务功能、园区统一管理业务功能等等
（4）一体化门户层：
采用一体化门户技术建设园区服务双门户。
即面向社会公众的公共服务门户和面向内部用户的业务协同门户，形成统一用户漫游，实现单点登录、一网通办。
2.2技术部署架构
智慧服务平台将本着融合、统一、高效、节约的原则开展“智慧服务”信息化建设，充分利用大数据、云计算等信息化技术，打造融会贯通、感知互联、便捷服务的以中台架构为核心，以提供一体化综合化全面化服务为目标的一体化大平台。
图：
部署架构图
（1）基础设施层
依托园区的基础设施，建立统一的云服务平台监管系统体系，构建双活、多中心的可靠、安全、高效、稳定、支持垂直互通和横向扩展的基础支撑环境。
（2）中台数据层
数据层以建设数据资源体系为核心，实现对基础数据生命周期的维护管理，包括各系统业务数据及系统运行日志库、数据接口、数据目录、组织架构等，实现数据质量管理，确保基础数据的一致性、完整性、相关性和精确性。
数据层是消除信息孤岛，实现各部门的业务应用的基础，同时也是同其他业务系统信息交换的基础，是整个系统成功建设和运行的基础。
（3）中台支撑层
应用支撑层是应用系统开发的基础，为各模块提供组件及服务，同时开发各系统模块的公共应用，统一架构，便于管理和功能扩展。
（4）中台应用层
在基础设施层、数据层和应用支撑层的支持下，构建综合门户网及App、园区一码通系统、商务服务中心综合受理平台等。
依赖应用支撑平台的支持，通过数据共享和协作关系将各个应用连接起来构成一个各部分既相对独立又密切协作的集成系统。
（5）门户层
依托大数据局通用资源建设园区服务双门户。
即面向社会公众的公共服务门户和面向内部用户的业务协同门户，形成统一用户漫游，实现单点登录、一网通办。
（6）用户层
园区信息系统面向：
园区管理员、入驻企业、一般访问用户等。
（7）信息化标准体系
协同大数据局会同推进信息化标准体系建设，包括总体标准、管理标准、数据标准、应用标准、安全标准等方面的内容，为信息化建设提供统一的标准支撑。
（8）安全管理体系
协同大数据局会同推进安全体系建设，包括安全管理、信任服务、系统安全、数据安全、网络安全，为信息化建设提供统一的安全管理和指导依据。
（9）运行维护体系
运行维护体系包括运维组织架构、运维管理制度、运维工作流程、运维管理技术工具等方面，确保信息化系统稳定运行。
中台架构主要包含的技术有：
微服务、DevOps、持续交付、容器化、以及本方案所采用的J2EESpringBoot开发框架和可以实现自由配置流程图、流程参与者、自由配置流程环节的activitii技术：
（1）微服务
微服务解决的是软件开发中一直追求的低耦合+高内聚。
微服务架构强调的是“业务需要彻底的组件化和服务化”，围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。
将大型的单个应用程序和服务拆分为数个甚至数十个离散的服务中以实现对解决方案的解耦，从而降低系统的耦合性，并提供更加灵活的服务支持。
各个离散的服务能够单独部署，跑在自己的进程中。
不同服务通过一些轻量级交互机制来通信。
根据业务的需求，不同的服务可以根据业务特性进行不同的技术选型，是计算密集型还是I/O密集型应用都可以依赖不同的语言编程模型。
服务在压力较大时，也可以有更多容错或限流服务。
针对x业务模式相对稳定，具备共性、共享、基础的应用，采用微服务动态组件和接口技术，重新整合升级供各业务系统调用。
主要包括：
用户管理服务、身份认证服务、证照认证管理服务、检验检测能力服务、企业数据服务、产品数据服务、从业人员数据服务等。
（2）开发运维服务统一化
开发运维服务统一化也成为DevOps。
是一组过程、方法与系统的统称，它是开发、技术运营和质量保障这三方面工作的融合，用于促进开发、技术运营和质保部门之间的沟通、协作与整合。
DevOps模式使开发和运维不再是分开的两个团队，而是一个统一体。
它强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而能够更快、更频繁地交付更稳定的软件。
（3）持续交付
持续交付是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，在不影响用户使用服务的前提下，保证软件可以稳定、持续的保持在随时可以发布的状况。
它的目标在于让软件的构建、测试与发布变得更快以及更频繁。
这种方式可以减少软件开发的成本与时间，减少风险。
（4）容器化
容器化是基于容器技术的轻量级虚拟化解决方案，每个容器内都包含一个独享的完整用户环境空间，并且一个容器内的变动不会影响其他容器的运行环境。
每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，运维的时候不需要再关心每个服务所使用的技术栈，从而提升运维效率。
（5）SpringBoot
在使用传统的Spring去做JavaEE（JavaEnterpriseEdition）开发中，大量的XML文件存在于项目之中，导致JavaEE项目变得慢慢笨重起来，，繁琐的配置和整合第三方框架的配置，导致了开发和部署效率的降低。
SpringBoot并不是用来替代Spring的解决方案，而是和Spring框架紧密结合用于提升Spring开发者体验的工具。
同时它集成了大量常用的第三方库配置，SpringBoot应用中这些第三方库几乎可以是零配置的开箱即用（out-of-the-box），大部分的SpringBoot应用都只需要非常少量的配置代码（基于Java的配置），开发者能够更加专注于业务逻辑。
SpringBoot的优点包括：
——良好的基因
因为SpringBoot是伴随着Spring4.0而生的，boot是引导的意思，也就是它的作用其实就是在于帮助开发者快速的搭建Spring框架，因此SpringBoot继承了Spring优秀的基因，在Spring中开发更为方便快捷。
——简化编码
比如我们要创建一个web项目，使用Spring的朋友都知道，在使用Spring的时候，需要在pom文件中添加多个依赖，而SpringBoot则会帮助开发着快速启动一个web容器，在SpringBoot中，我们只需要在pom文件中添加如下一个starter-web依赖即可。
org.springframework.boot
spring-boot-starter-web
我们点击进入该依赖后可以看到，SpringBoot这个starter-web已经包含了多个依赖，包括之前在Spring工程中需要导入的依赖，我们看一下其中的一部分，如下：
--.....省略其他依赖-->
org.springframework
spring-web
5.0.7.RELEASE
compile
org.springframework
spring-webmvc
5.0.7.RELEASE
compile
由此可以看出，SpringBoot大大简化了我们的编码，我们不用一个个导入依赖，直接一个依赖即可。
——简化配置
Spring虽然使JavaEE轻量级框架，但由于其繁琐的配置，一度被人认为是“配置地狱”。
各种XML、Annotation配置会让人眼花缭乱，而且配置多的话，如果出错了也很难找出原因。
SpringBoot更多的是采用JavaConfig的方式，对Spring进行配置。
举个例子：
我新建一个类，但是我不用@Service注解，也就是说，它是个普通的类，那么我们如何使它也成为一个Bean让Spring去管理呢？
只需要@Configuration和@Bean两个注解即可，如下：
publicclassTestService{
publicStringsayHello（）{
return"HelloSpringBoot!
";
}
}
importorg.springframework.con
升级会员 