机关后勤综合管控平台项目投标方案（技术方案）

机关后勤综合管控平台项目投标方案

目录

第一章技术方案及说明6

1.1.技术方案措施6

1.1.1.项目背景6

1.1.2.项目目标6

1.1.3.建设内容7

1.1.4.建设原则9

1.1.5.安全要求10

1.1.6.总体要求15

1.1.7.系统架构16

1.1.8.架构的主要优势16

1.1.9.关键技术26

第二章系统安全方案49

2.1.方案设计目标49

2.1.1.方案设计框架49

2.2.安全技术体系设计51

2.2.1.物理安全设计51

2.2.2.机房选址51

2.2.3.机房管理51

2.2.4.机房环境51

2.2.5.设备与介质管理52

2.3.计算环境安全设计53

1

2.3.1.身份鉴别53

2.3.2.访问控制54

2.3.3.系统安全审计55

2.3.4.入侵防范56

2.3.5.主机恶意代码防范57

2.3.6.软件容错58

2.3.7.数据完整性与保密性59

2.3.8.SSL无需终端用户配置61

2.3.9.备份与恢复61

2.3.10.资源控制62

2.4.区域边界安全设计64

2.4.1.边界访问控制64

2.4.2.边界完整性检查66

2.4.3.边界入侵防范66

2.5.通信网络安全设计69

2.5.1.网络结构安全69

2.5.2.网络安全审计69

2.5.3.网络设备防护70

2.6.安全管理中心设计72

2.6.1.系统管理72

2.6.2.审计管理73

2.7.不同等级系统互联互通76

第三章实施方案77

3.1.质量保证体系77

2

3.2.项目实施管理78

3.2.1.项目实施管理目标78

3.2.2.项目实施管理内容79

3.2.3.项目实施管理方式82

3.2.4.工程组织结构82

3.2.5.系统开发与实施控制88

3.2.6.成本与进度控制89

3.2.7.项目实施计划89

3.2.8.项目质量保证体系96

第四章测试与验收97

4.1.测试97

4.1.1.测试目标97

4.1.2.测试流程说明97

4.1.3.测试需求分析97

4.1.4.测试方法与规范98

4.1.5.测试计划104

4.1.6.测试附件105

4.1.7.缺陷管理流程和缺陷级别定义105

4.1.8.测试实施110

4.1.9.测试评估110

4.1.10.测试报告111

4.2.验收112

4.2.1.目的112

4.2.2.验收范围112

3

4.2.3.验收依据112

4.2.4.验收内容112

4.2.5.验收小组及职责114

4.2.6.验收工作流程115

4.3.服务团队整体情况119

4.4.质量保证措施125

4.4.1.质量管理体系标准125

4.4.2.质量控制过程125

4.4.3.质量评定计划125

4.4.4.质量管理措施127

4.4.5.软件质量控制127

第五章进度保证措施130

5.1.项目实施计划130

5.1.1.开发方案130

5.1.2.系统分析阶段131

5.1.3.系统总体结构设计131

5.1.4.应用软件概要设计131

5.1.5.系统详细设计与实施阶段132

5.2.培训计划133

5.2.1.平台培训方案133

5.2.2.培训方式133

5.2.3.培训计划表133

5.2.4.培训对象134

5.2.5.培训方式和内容135

4

5.3.培训教学方案137

5.3.1.培训质量保障137

第六章售后服务140

6.1.售后服务机构140

6.1.1.售后服务团队140

6.2.服务宗旨141

6.2.1.售后服务承诺内容及措施后服务方案.141

6.2.2.特殊技术服务和支持方式141

6.2.3.日常管理制度和故障处理流程图146

6.2.4.故障处理流程图147

6.3.系统运行与维护方案148

6.3.1.服务目标148

6.3.2.信息资产统计服务149

6.3.3.网络、安全系统运维服务149

6.3.4.主机、存储系统运维服务155

6.3.5.数据库系统运维服务157

6.3.6.中间件运维服务160

6.3.7.运维服务流程161

6.4.应急服务响应措施168

6.4.1.应急基本流程168

6.4.2.维护服务应急处理流程168

6.4.3.突发事件应急策略170

5

第一章技术方案及说明

1.1.技术方案措施

1.1.1.项目背景

十四五以来，中共中央多次提出加快转变政府职能，建

设法治政府和服务型政府。党中央和国务院的八项规定和

“约法三章”,对节约型机关建设有了更高的要求。为全面

规范机关事务管理工作，国务院出台了《机关事务管理条

例》,行业也印发了相关条例。尤其强调推进政务服务标准

化、规范化、便利化，深化政务公开，围绕节俭节约，弘扬

绿色机关文化，为建设节约型社会发挥示范引领作用。从信

息化发展角度看，以物联网、数字孪生、人工智能、云平台

为代表的信息技术发展，已使后勤信息建设具备信息基础和

产业基础；同时，不断提升的设备智能化水平，也为后勤信

息建设创造了良好的技术支撑。

1.1.2.项目目标

后勤服务综合管理平台主要是根据省局(公司)服务中

心后勤管理的内容(如资产、食堂、公车、物业、安保、日

常办公等业务),拟实现资产管理、食堂管理、公车管理、

物业管理、安保管理、日常事务管理等功能，利用物联网、

三维数字化、移动终端等技术，建设一体化、一站式的后勤

可视化管理平台，服务于后勤管理和企业员工，实现智慧后

勤、精益后勤、节俭后勤、平安后勤、廉洁后勤。

6

1.1.3.建设内容

3.1资产管理

借助物联网技术实现覆盖后勤资产档案、计划、采购、

出入库、借用、调拨、租借、维修、盘点、耗材、检测等业

务需求。应包含固定资产管理、耗材管理、维修管理等。

3.2食堂管理

通过人脸识别技术和信息化管理系统搭载不同智能硬

件，打造便捷的食堂就餐模式，实现进销存等多模板管理，

同时收集多维度数据分析助力后勤经营管理优化。包括菜谱

管理、计划管理、采购管理、消耗管理、库存管理、就餐管

理、评价管理等。

3.3公车管理

通过北斗定位、移动应用等技术方案为企业提供便捷派

车、车辆监控、实时查询等解决方案。包括车辆档案管理、

车辆费用管理、车辆调度管理、驾驶员管理、智能提醒等。

3.4物业管理

集成多种智能化设备，全面覆盖企业物业服务的各个方

面包括：宿舍管理、环境管理、停车管理(授权)、快递收

发、内部物流、订水、场地预约、工具借用等场景。

3.5安保管理

通过接入视频监控、报警检测、梯控等系统的设备，获

取边缘节点数据，结合门禁、巡检、访客等业务功能实现数

7

据集成与联动。

3.6日常管理

包括会议室管理、考勤管理、合同管理、供应商管理、

项目进度管理等。

3.7移动办公

分为后勤管理人员、后勤服务人员、机关单位员工3种

角色，配合后端系统的各个业务模块实现全流程的无纸化办

公，用户和后勤员工不再奔波于各种流程的人工审批。

3.8三维可视化展示

实现园区三维立体化数字展示。对公司园区及大楼内部

进行三维展示结合采集的资产、车辆、食堂、门禁、监控等

数据，实现数据与三维界面相结合的动态数据展示。

3.9与其他系统的接口

实现数字化后勤业务全场景覆盖，不仅仅要完成业务流

程梳理和建设，还需实现已有业务系统(如财务系统、0A系

统、数据中台等)的集成、数据交互、场景联动等问题。此

外还需要与门禁系统、道闸设备、视频监控系统、食堂消费

系统、会议室系统、车辆导航系统等做出相应的接口联动。

3.10本项目所包含的移动应用要兼容钉钉、企业微信等

主流移动平台产品，支持钉钉、企业微信等主流移动平台的

核心功能。

3.11兼容性要求

8

系统需对各类常见浏览器进行兼容性优化，保障系统能

在各类浏览器下正确打开与使用，支持主流软、硬件。系统

应同时支持但不限于x86、飞腾、鲲鹏等产品；应同时支持

火狐、安全360、谷歌和IE等主流浏览器；应支持金山、永

中、微软等主流流式办公软件；应支持数科、福昕、书生和

PDF等版式软件，其涉及的外接控件等应用运行环境应同时

通过相应生态的兼容性验证和现有windows环境兼容性验

证，确保终端适配；应对移动端Android系统和I0S系统、pc

端windows系统及银河麒麟、统信等主流操作系统等进行兼

容性支持；应支持国产主流、国内主流打印机等外设。

系统支持web类系统，根据业务需要，需对移动与PC端

进行双端支持，保证各设备不同屏幕尺寸下、不同系统下能

够合理、正确的展示与使用各项功能。移动端应同时支持

SaaS版和私有化版企业微信、钉钉等主流移动平台的核心功

能，后台管控子系统要求按照互联网架构，基于数字中台共

享服务中心设计和开发。

3.12数据对接一些要求

和其他应用系统进行数据对接时，应符合招标方总体技

术路线，符合招标方相关技术要求，支持多种数据对接方式，

并充分利用现有数据接口完成数据对接。

1.1.4.建设原则

河北烟草后勤服务综合管理平台的建设遵循以下基本

9

原则：

4.1.坚持统筹规划。统一领导，统一步调，协调有序推

进，打造统一平台，实现统一标准，确保后勤服务效能全面

提升。

4.2.遵循平台战略。先进性：采用先进的、符合标准的

平台软件开发技术。稳定性：鉴于平台应用需求，平台需7*24

小时稳定运行。可靠性：平台运行具有极高的可靠性，平台

应该有足够的手段来保证在严重故障后的恢复能力。

4.3.注重用户体验。以用户为中心，注重用户体验及用

户真实需求，全面增加各个环节各个参与方的黏性。建立全

渠道、全业务、全触点的用户服务模式，重点提升用户体验，

使得用户在任何时间、任何地点、任何终端都能获得适合自

己的服务。

4.4.重视信息安全。建立严格有效的安全管理制度，运

用先进的信息安全技术，提高系统防护能力，确保信息授权

访问，确保信息公开依法合规，保证系统稳定、可靠、高效

运行。

1.1.5.安全要求

5.1基本原则

5.1.1、本项目要按照安全开发生命周期进行开发。

5.1.2、按照国家信息系统安全等级保护防护要求，信

息系统在软件开发过程中要同步梳理、同步防护相关的安全

10

技术措施、管理措施，在本项目建设中须严格执行、不得遗

漏。

5.1.3、系统建设要符合行业及河北烟草信息系统建设

安全管理规定求。

5.1.4、安全防护中需要另行投资建设的安全防护措施，

不在本项目建设范围之内。

5.2具体要求

本系统必须做到的安全措施包括：在编码阶段，要具体

安全的开发框架供开发人员使用，同时要求开发人员严格遵

循安全编码规范；在测试阶段，通过渗透测试和代码审计发

现漏洞；在发布阶段，要经过安全测试并通过后，系统才能

发布到线上环境，以防止产品携带安全漏洞在生产环境运

行；发布过程按照安全上线规范对系统进行整体加固。具体

分类要求如下：

5.2.1人员安全

投标人及其项目人员需要签订“信息安全保密协议”,

项目人员进出信息机房须按有关规定进行登记。

5.2.2管理安全

项目相关介质要进行分类标识，并提交信息中心统一归

档保管。硬件设备和主要部件安装要进行固定，并设置明显

的不易除去的标记，使用的通讯线须按有关规定铺设。

5.2.3安全域

11

设计建设时，应考虑将应用服务与数据存储服务划分在

不同安全组，不同网段之间的传输要采取访问防护措施。

5.2.4身份鉴别

对于操作系统和数据库系统管理用户要采用两种或两

种以上组合的鉴别技术进行身份鉴别，不同的用户要分配不

同的用户名，确保用户名具有唯一性；登录口令必须满足长

度8位以上且必须字母数字和特殊符号的组合，并要求定期

更换。主机、数据库、应用系统的口令应完全独立性，任何

一个口令的更改，不得影响其它相关系统的正常运行。

5.2.5访问控制

对服务器重要的文件、资源设置合理的访问权限；根据

实际岗位分配用户权限，仅授予管理需要的最小权限；操作

系统和数据库系统特权用户要权限分离；要限制终端登录接

入方式、网络地址范围，登录终端要设置超时锁定功能；要

限制单个用户对系统资源的最大或最小使用限度。

5.2.6安全审计

开启操作系统、数据库和应用系统安全审计功能。管理

员、使用人员的操作日志必须可审计、可提供给第三方审计

平台。

5.2.7软件容错

系统具备数据有效性检验和自我保护功能，保证通过人

机接口输入或通过通信接口输入的数据格式或长度符合系

12

统设定要求，当故障发生时自动保护当前所有状态，保证系

统能够进行恢复。

5.2.8资源控制

系统具备当通信双方中的一方在一段时间内未作任何

响应，另一方应能够自动结束会话；能限制系统的最大并发

会话连接数；能限制单个帐户的多重并发会话；能限制一个

时间段内可能的并发会话连接数；能对一个访问帐户或一个

请求进程占用的资源分配最大限额和最小限额；对以系统服

务水平降低到预先规定的最小值进行检测和报警；有服务优

先级设定功能，并根据优先级分配系统资源。

5.2.9数据安全及其备份

①、数据完整性：应提供数据传输和存储过程中完整性

校验功能，并有必要的恢复措施；②、数据保密性：对数据

的传输和存储要采用加密措施，保证数据传输和存储保密

性；③、备份和恢复：进行异地数据备份；采用网络负载均

衡、链路冗余备份、设备双机热备等措施保证系统的高可用

性。

5.2.10等级保护要求

1、按照国家信息系统安全等级保护第二级防护要求，

进行全面梳理、管理和防护。

2、安全防护中需要另行投资建设的安全防护措施，不

在本项目建设范围之内。

13

3、有关“二级”系统相关技术措施、管理措施，在本

项目建设中严格执行、不得遗漏

5.2.11安全测评要求

以下评测的评测报告将作为本项目验收的组成部分。

5.3、信息安全等级保护的评测

5.3.1系统上线前应由具有专业资质的机构进行系统安

全性测试，测试内容至少应包含漏洞扫描、代码审计等，其

测试报告作为本项目验收的组成部分。安全性测试启动、整

改直至测试通过所产生的相关费用均包含在本次招标中。

5.3.2本项目建设全过程应严格落实网络安全工作各项

要求，应做好网络安全要求的各项测试、整改等工作。

5.4、信息安全风险评估的评测

5.4.1本项目须由专业的第三方单位从风险管理角度，

评估系统面临的威胁以及脆弱性导致安全事件的可能性，并

结合安全事件所涉及的资产价值进行安全评测，提出有针对

性的抵御威胁的方法措施，为保证项目的安全建设、稳定运

行提供技术参考，将风险控制在可接受的范围内，达到系统

稳定运行的目的。

5.4.2信息安全风险评估测评后需要及时对信息系统进

行整改。

5.4.3信息安全风险评估的评测费用含在本次招标中。

14

1.1.6.总体要求

本项目建设必须紧密结合河北省局(公司)管理的需要，

突出重点，稳步推进。系统开发与集成应遵循《烟草行业信

息化建设统一技术平台要求》及行业信息化总体技术架构中

的相关规定，做到“统一平台、统一网络、统一数据库、统

一标准”,遵循国际上先进、成熟的技术标准，构建应用平

台。以提高开发效率和系统的可扩展性，降低系统升级、维

护成本并切实加强个人信息安全管理，在传输和存储个人敏

感信息时应采取加密措施，设置信息数据复制、下载、打印

限制等功能。项目建设将采用已有的企业标准、行业标准和

国家标准，遵循但不仅限于以下标准体系和要求：

《烟草行业信息化建设统一技术平台要求》、《烟草行

业数字证书应用接口规范》、《烟草行业信息系统安全等级

保护定级指南》等行业规范及国标、《烟草行业网络安全基

线安全规范》、《个人信息安全规范》(GB/T35273-2017)。

15

1.1.7.系统架构

数字中台

开发及运营管理

iPaaS层

业务中台数据中台平台

PaaS层数据库缓存微服务治理消息队列大数据处理

laaS层云管理平台公有云&私有云&混合云

1.1.8.架构的主要优势

常用的B/S系统开发，一般是基于单体应用架构，例如

Java技术开发的B/S系统，一般选用SSH,(Struct2、Spring、

Hibernate)或者SSM,(SpringMVC、Spring、Mybatis)框架，

开发出一个war包后将其部署到Tomcat中发布。单体应用架

构的开发、部署、测试较为容易，但随着需求的不断增加，

每一次系统的更新，都需要将war包重新部署，并且war包如

同滚雪球一般越滚越大，系统的可维护性、可靠性、灵活性

逐渐降低，维护成本越来越高，任何一个bug都会导致系统

崩溃，随着时间的推移，整个程序的代码量变得越来越大，

使得已有的系统设计和代码变得难以维护，系统的构建和部

署时间也不断增加，单体应用中每次功能变更、bug修复都

会导致整个项目需要进行重新部署，增加了项目部署时间、

16

成本和风险。

为解决单体应用的缺陷，Fowler,M提出了微服务架构，

它完全不同于单体应用架构，将应用程序逻辑拆分、设计、

开发为一组小型服务，这些小型服务只关注自身所负责的功

能，不关心其他服务及其内部实现。这些服务可以独立部署

在平台即服务PaaS(PlatformasaService)上，或者运行在自

己的进程中，进程与进程之间相互隔离，降低各服务的耦合

性，服务间通信采用轻量级通信机制REST风格，REST是资源

表现层状态转换(REpresentationalStateTransfer),所有

独立的服务构成了一个完整的软件系统，这些服务由于部署

在各自独立的进程中，各服务间内聚性大，耦合性小，可以

采用不同的编程语言、不同的数据存储技术实现系统功能，

微服务架构由于将服务分割专注化，因此不会像传统的单体

应用程序一样，修改一个bug或增加一个功能就要重新进行

部署，只需要将修改的服务重新部署，不会影响其他服务的

运行

本项目是基于微服务架构的B/S应用系统，后端使用

SpringCloud技术，前端使用JQueryBootstrap以及

Thymeleaf模板，数据库使用MySQL,并采用非关系内存数据

库Redis进行Session模拟和部分基础功能的实现，使用

Intellij,IDEA集成开发环境，由于SpringCloud内部集成

了Tomcat,所以只需要运行启动类，通过相应地址就可以访

17

问相关服务，系统使用了Jmeter测试工具，对单体应用和微

服务架构进行不同级别的测试，性能指标上微服务系统架构

体现出明显优势

1、微服务技术

系统前端技术采用开源的Bootstrap和JQuery框架，用

户输入字符验证采用JQueryvalidate框架，Bootstrap已经

处于github上星级项目(starredproject)前列，利于技术人

员编写用户体验良好的前端组件和动作。

后端采用SpringCloud框架实现微服务的基本框架搭

建，数据连接与操作采用Mybatis,用户密码采用Shiro的MD5

加密，防止被非法人员侵入数据库后得到用户密码后进行非

法活动，系统后端与前端之间的数据交互采用json字符串格

式，方便前端解析后端传递的内容，数据方面，选用MySQL

来存储用户以及系统等的基本数据，由于各微服务运行于各

自隔离的进程中，无法将HTTP,Session交于统一的Servlet

容器，因此采用内存数据库Redis模拟实现Session,系统选

用Maven进行Java的依赖包管理和项目的搭建，并使用Git进

行项目的版本控制。

1)SpringCloud是在Java快速开发框架SpringBoot基础

上构建的一个开发框架，它在SpringBoot便利性的基础上很

好地降低了微服务系统实现的门槛，如实现微服务的注册与

发现，实现负载均衡，实现REST通信，构建微服务网关等一

18

系列功能，都可以使用SpringCloud通过最简单的配置或者

几行编码就完成实现与部署。

2)Redis是一个非关系数据库，它可以存储键与其他五

种不同类型的值之间的映射关系，因为Redis数据库本身是

基于内存存储的，所以redis的处理与运行速度相比于传统

的数据库快速高效，Redis还可以通过简单的设置就将存储

在内存的数据持久化到硬盘中，使之下次读取的时候就可以

直接从硬盘中获取数据，因为Redis不使用关系表结构来进

行数据的存储，所以Redis的数据库不会强制要求用户对

Redis存储不同的数据进行相应的关联，使用Redis使得用户

要求进行数据持久化时，才将这些数据存储在硬盘中，从而

提高整个系统代码的运行效率，给用户提供更好的运行体

验。

3)REST是一种软件架构风格，并不是一种软件设计的标

准，REST提供了一组设计原则和约束条件，以寻求降低开发

的复杂性，提高系统的可伸缩性的目的。

4)Mybatis封装了系统与数据库的连接、校验、操作实

现等底层代码的实现，使得用户可以使用ML配置或者

Mybatis注解完成数据库的连接，操作，关闭数据连接池等

基本操作，相比于JDBC、Hibernate操作数据库，Mybatis代

码更具易读性优势。

5)Git是目前软件开发领域中最好的分布式版本控制工

19

具，是Linu之父为了帮助管理Linu内核开发所制作的一个开

源版本控制软件。

6)Maven是一个项目管理工具，开发团队可以通过Maven

自动完成项目的基础工具建设，Maven使用标准的目录结构

和默认构建生命周期，基于Maven的Java项目中，其项目的

依赖包是统一管理的，有效避免Java项目的依赖包因为版本

原因而产生冲突。

7)Zuul是微服务网关组件，微服务网关是介于客户端和

服务器端的中间层，用户提交的所有外部请求都会先经过微

服务网关的处理和过滤，可以实现用户身份认证与安全、审

查与监控、动态路由、压力测试、负载分配、静态响应处理

等功能，使用Zuul微服务网关后，实际上封装了系统内部的

所有服务，用户只需要和微服务网关交互，不必直接调用微

服务的相关接口。

8)Eureka是用于实现微服务架构中的服务注册与发现

的组件，服务提供者在服务启动时，将自身以及URL等一些

信息注册到注册组件中，而服务注册组件会存储各个服务提

供者的这些基本信息，各个微服务与服务发现组件之间通过

一定机制进行通信，例如心跳机制，即各个微服务每隔一定

的时间向服务发现组件发送信息，表示自己还在运行中，可

以被调用，若持续一段时间未向服务发现组件提供信息，则

服务发现组件会认为该服务出现故障或者已被关闭，则从注

20

册表中注销该服务。

2、系统整体采用微服务架构，如图所示

Zuul

客户端

请求

注册

EurekaZuul

serverserver

获取服务列表

注册请求

RESTREST

类别用户文章REST管理员REST评论

服务服务服务服务服务

每一个服务采用MVC架构并拥有自己独立数据源，每个

服务不需要其他服务的支持就可以独立运行，同时这些服务

都注册到Eureka组件中，相互之间使用REST进行通信，充分

降低了各服务之间的耦合度，增加了系统的内聚性。

3、微服务性能分析

雪崩效应处理机制

微服务之间是使用轻量级通信机制进行通信，当某一个

服务提供者因为网络原因无法被调用时，其后的服务消费者

都会出现“级联故障”,即雪崩效应，如下图

21

服务C调用成功调用成功

服务B服务A正常

服务D

服务C调用成功调用失败

服务B服务AA不可用时

服务D间

推

服务C调用失败调用失败移

服务B服务AA、B不可用

服务D

服务C调用失败

调用失败服务B服务A系统不可用

服务D

表1

使用Spring,Cloud的Hystri提供的熔断机制，一旦服

务提供者出现错误导致服务消费者无法调用，系统会立即根

据编码人员的设置，对请求失败、超时执行回退代码，防止

雪崩效应，从而提升整个系统的可用性

性能测试

使用Jmeter测试工具，在近似相同环境下对基于微服务

架构系统与基于单体应用的系统进行测试，为了尽可能保持

测试数据的客观性，两个系统的业务功能逻辑代码实现基本

相同，微服务系统测试结构如下图所示

22

JMeter

测试软件

测试。

客户端

获取自

Zuul网

关

调用

UserAdminHomeDiscussArticleCategory

主机1主机2主机3主机4主机5主机6

表2

部署时间分析

微服务架构相较于单体应用的最大优势就是部署效率

较高，传统单体应用每修改一个功能或者缺陷就必须关闭服

务器重新部署整个项目，随着需求的不断增大，项目代码量

不断增多，重新部署耗费更多时间，微服务由于采用领域驱

动设计，每个微服务之间相互隔离，低耦合、高内聚性使得

微服务每修改一个功能或者缺陷只需要重新部署相对应的

微服务，其他服务可以继续运行不必停止。

1、分别对单体应用和微服务架构系统进行部署，记录

不同服务修改的部署平均时间，每个服务修改一个功能，部

署时间下表

23

不同服务数修改一个功能部署平均时间(ms)

功能1个服务2个服务3个服务

微服务223442276346

单体应用595158276023

表3

2、分别修改单体应用和微服务架构系统中的同个服务

中的多个功能，平均部署时间数据见下表所示，修改并部署

较少服务的时候，相比于单体应用架构的系统，微服务架构

在部署时间上花费更少，节省了约60%的部署时间

同个服务中修改不同功能后部署平均时间(ms)

功能1个功能2个功能3个功能

微服务2222.672139.672088.67

单体应用5971.6759295868.3

表4

24

基于微服务架构的测试系统共由8个不同服务构成，由

表3数据可得，当修改服务数不超过两个时，即修改服务数

占总系统服务数的20%左右时，微服务部署时间少于单体应

用架构的部署时间，实验结果也符合软件故障80/20原则，

依据表4可知，当所有修改的功能模块是位于同个服务中时，

微服务架构的部署的时间相比于单体应用架构明显加快，原

因在于微服务修改功能模块都在同一个服务中，只要部署该

服务而不必重新部署整个系统，所以避免花费许多不必要的

部署时间和资源，相反，单体应用架构的系统，无论修改的

功能是否在同一个模块中，都得重新部署整个系统，大大浪

费了部署资源和时间，因此，微服务架构对于软件系统的维

护与部署有着很好的性能优势。

微服务是一个细粒度的S0A,(Service-Oriented,

Architecture,面向服务架构),服务的划分基于领域驱动

设计，每个微服务只专注自己的职责，符合软件设计高内聚、

低耦合原则，微服务单独部署，服务之间使用REST风格通信

机制，各个微服务部署在不同主机并采用分布式管理机制。

传统单体应用程序在项目变得越来越庞大时，任意一个

bug将导致整个应用系统重新部署，微服务架构只需要部署

更新的微服务，任何一个功能修改，只需要停止对应的微服

务，不需要暂停整个系统，解决了bug修复和系统更新需要

停止整个系统访问的问题，从实验结果看，系统的性能在微

25

服务架构系统上具有明显优势。

未来将使用容器引擎Docker更快地将微服务进行打包、

测试以及部署，基于进程隔离技术的Docker,将缩短从编码

到部署运行的周期。

1.1.9.关键技术

4.1基于B/S/D三层体系结构的运行环境

浏览器Browser/WEB服务器Server/数据库服务器

Database是解决公共信息服务以及交互相应动态服务最适

用的一种应用模型。实现了真正意义上的瘦客户，大大简化

了应用系统的分发、配置管理和版本管理工作。

必见叩

欧

各器生

请请求输

库

响应响应

基于B/S/D三层体系结构的运行环境示意图

其中，WEB客户端是WEB浏览器，例如NetscapeNavigator

或者MicrosoftInternetEplorer。WEB服务器是任何基于

HTML的服务器，例如NetscapeEnterpriseServer或者

26

SybaseApplicationServer等。应用服务器是对WEB服务器功

能的一种扩展，负责权限，组件，事务，数据库连接等管理。

最终用户可以通过WEB浏览器发出请求，通过HTTP协议与WEB

服务器进行通信。如果是数据请求，WEB服务器(应用服务

器)与数据库服务器通信，将返回数据构造成浏览器页面返

回给用户。

三层体系结构特别适用于电子商务：

1.在前台，客户并不需要安装特别复杂和庞大的应用

系统，只需要使用操作系统集成的网络浏览器即可，这使得

前台系统非常方便的推广，适用于存在非常庞大的客户群的

情况。

2.商务处理完全放在中间的应用服务层。客户通过浏

览器发出命令(比如说：查询，下订单等),应用服务层获

得命令，进行相应的处理，并以HTTP的形式返回用户结果。

这同样适合于分散用户，集中处理的特性。

3.数据一般存放于一个强大的数据服务器中，所有用

户可以通过应用服务器访问数据服务器。这样可以使用数据

集中存放，便于维护和管理。这也是当前数据管理形式的发

展方向。

由以上叙述可知，如果用户系统是一个多用户但又需

要集中处理，数据需要集中存放的情况的话，三层结构将是

一个不错的软件模型。

27

4.2数据后台MySQL的技术特点

1、MySQL的定义

MySQL是一个真正的多用户、多线程SQL数据库服务器。

SQL(结构化查询语言)是世界上最流行的和标准化的数据

库语言。MySQL是以一个客户机/服务器结构的实现，它由一

个服务器守护程序mysqld和很多不同的客户程序和库组成。

SQL是一种标准化的语言，它使得存储、更新和存取信

息更容易。例如，你能用SQL语言为一个网站检索产品信息

及存储顾客信息，同时MySQL也足够快和灵活以允许你存储

记录文件和图像。

MySQL主要目标是快速、健壮和易用。最初是因为我们

需要这样一个SQL服务器，它能处理与任何可不昂贵硬件平

台上提供数据库的厂家在一个数量级上的大型数据库，但速

度更快，MySQL就开发出来。自1996年以来，我们一直都在

使用MySQL,其环境有超过40个数据库，包含10,000个表，

其中500多个表超过7百万行，这大约有100个吉字节(GB)的

关键应用数据。

2、主要特征

下表描述MySQL一些重要的特征：

1、使用核心线程的完全多线程。这意味着它能很容易

地利用多CPU资源，以及对大量开发语言的支持，如C、C++、

Eiffel、Java、Perl、PHP、Python、和TCLAPI等等。

28

2、可运行在不同的平台上，适合作为以Linu为后台服

务器和Windows环境为通用客户端的本系统数据后台。

3、支持多种列类型：1、2、3、4、和8字节长度的有符

号/无符号整数。

4、完全支持SQL结构化查询语言的方法，在查询的

SELECT和WHERE部分支持全部运算符和函数。通过一个高度

优化的类库实现SQL函数库并且像他们能达到的一样快速，

通常在查询初始化后不应该有任何内存分配。全面支持SQL

的GROUPBY和ORDERBY子句，支持聚合函数。

5、支持ODBC语法和JDBC语法。

6、灵活且安全的权限和口令系统。并且它允许基于主

机的认证。口令是安全的，因为当与一个服务器连接时，所

有的口令传送被加密。

7、客户端可使用TCP/IP连接或Uni套接字(socket)或

NT下的命名管道连接MySQL。MySQL特有的SHOW命令可用来检

索数据库、表和索引的信息。

3、稳定性要求

MySQL以多层结构和不同的独立模块编写，在本系统中，

对涉及其中有限的模块所作的测试表明其稳定性可以信赖：

1、ISAM表处理器--稳定

它管理所有在MySQL3.22和早期版本中的数据的存储和

检索。在所有MySQL版本中，代码中已经没有一个单独(报

29

告的)错误。得到一个损坏的数据库表的唯一已知方法是在

一个更新中途杀死服务器，即使这样也不大可能破坏任何数

据而不能挽救，因为所有数据在每个查询之间被倒入(flush)

到磁盘，而且从来没有一个有关由于MySQL中的错误而丢失

数据的错误报告。

2、语法处理器和词法分析器--稳定

3、标准客户程序--稳定

这些包括mysql、mysqladmin和mysqlshow、mysqldump

及mysqlimport。

4、基本结构式查询语言--稳定

基本SQL函数系统、字符串类和动态内存处理，实际测

试中未发现错误。

5、Linu线程--Gamma

唯一发现的问题是fcnt1()调用，它通过使用mysqld的

--skip-locking选项解决。但不影响相关操作的执行。

6、考虑JDBC与ODBC互连的操作

MyODBC(使用ODBCSDK2.5)使用良好，在通过JSP页面

的JDBC语法通过0DBC调用后台MySQL的试验中表现良好。

4.3JSP技术一跨平台的网络开发语言

何为JavaServerPage?

ApplicationServer支持一种功效强大的制作动态Web

页面方法：JavaServerPages(JSP)。JSP的优点之一就是它

30

们使您能在Web页面中有效地分离HTML编码和商业逻辑。JSP

规范的IBM扩展中包括类似HTML标记的JSP标记，并且便于

HTML编程人员将Java的强大功能添加到Web页面中。

缺乏程序设计技巧的HTML编程人员可开发用于访问数

据库和可重用Java组件的JSP,例如小服务程序和

JavaBeans。程序员创建了可重用Java组件，并为HTML编程

人员提供组件名称和属性。数据库管理员则为HTML编程人员

提供数据库访问和表名信息。

4.4Java技术的应用

1、Servlet技术一灵活的服务器端应用程序

1.1何为Servlet技术

Servlet是是JAVA2.0中新增的一个全新功能。他是与

Applet相对应的，Applet是运行在客户端的浏览器，而

Servlet是运行在服务器端的。JAVAServlets是运行在请求/

面向请求服务器上的模块，一个servlet可以从一个HTML订

单表中获取数据然后用一些商业上的算法来更新公司相应

的订单数据库。

也就是说：servlet能够象CGI脚本一样扩展WEB服务器

功能，但是servlet占用很少密集资源，当一个服务器装载

servlet时，它运行servlet的init方法.这个方法不能反复

调用，一旦调用就是再装载servlet.直到服务器调用

destroy方法卸载servlet后才能再调用.每个新的CGI要求

31

在服务器上新增一个进程。如果多个用户并发地访问该程

序，这些进程将消耗该Web服务器所有的可用资源，并且系

统性能降低到极其低下的地步。有很多用CGI脚本编制的一

些站点由于访问量剧增，性能迅速下降，这是CGI脚本一个

缺点。同时由于servlet是用java编写的，因此是跨平台的。

1.2Servlet工作原理

与小应用程序在浏览器上运行并扩展了浏览器的功能

相似，HTTP小服务程序在启用Java的Web服务器上运行并扩

展了Web服务器的功能。小服务程序是使用Java小服务程序

应用程序设计界面(API)以及关联的类和方法的Java程序。

除了JavaServletAPI外，小服务程序还可以使用扩展API的

Java类软件包。

HTTP小服务程序通过创建在Web上提供请求和响应服务

的框架，扩展了Web服务器的功能。当客户机发送请求至服

务器时，服务器可以将此请求信息发送给小服务程序，并让

小服务程序构造客户机响应。

小服务程序可在装入应用程序时自动装入，也可以在客

户机第一次请求它提供服务时装入。装入完成后，小服务程

序仍继续运行，以等待其它客户机请求。通过使用小服务程

序别名(小服务程序URL),您可以装入小服务程序的多个

实例(每个别名都有不同的实例)。

小服务程序可执行的功能范围很广。例如，它能够：

32

根据客户机请求的性质，创建并返回一个包含相应动态

内容的HTML页面。

创建可嵌入到现有HTML页面中的部分HTML页面(HTML片

段)。

与其它服务器资源(包括数据库和基于Java的应用程

序)进行通信。

与其它小服务程序进行通信。例如，您可以使用

“WebSphere管理控制台”来定义小服务程序过滤(一系列

小服务程序，也称为小服务程序链)。

对特殊处理采用MIME类型过滤数据，例如图像转换和服

务器端包括(SSI)。

处理与多个客户机的连接，接收来自多个客户机的输

入，并将结果广播到多个客户机上。例如，一个小服务程序

可以是多参与者的游戏服务器。

1.3Servlet的生命周期

如下图中所说明的，小服务程序的生命周期始于将它装

入Web服务器的内存，结束于小服务程序终止或重新装入时。

33

创红

初女白化

(初女白化失文)

可用于务不可用于服务

不可用

4天弃

服务请求皮不

年p载

Servlet的生命周期

ServletAPI,是用来写servlet的，编写servlet是已没

有CGI脚本那样诸如关心一个servlet是这样被装载，

servlet运行的服务器环境是什么,或者用来传输数据的协

议是什么等等，这样servlets就可以融合在不同的web服务

器中。

Servlet可以相当有效地替代CGI脚本：它可以方便地产

生容易编写而且运行快的动态文本。可以很方便的调试寻找

出程序问题。Servlet程序是用JavaServletAPI开发的。

1.4Servlet应用范围

下面是一些Servlet应用范围：

?用于处理HTML表单通过HTTPS产生POST数据。包括买卖

订单或信用卡数据。因此Servlet可以成为订单处理系统的

一部分，和产品存货数据库一道工作，也许可以用在在线支

34

付系统上。

?允许人们之间的合作。一个Servlet能并发处理多个请

求；他们可以使用在诸如在线会议这样的同步请求支持系

统。

?转送请求。Servlet可以转送请求给其他的服务器和

Servlets,这就允许在镜象同样内容的几个服务器之间平衡

负载，按照任务类型或组织范围，可以允许被用来在几个服

务器中划分逻辑上的服务器。

?Servlet编写者们可以定义彼此之间共同工作的激活

代理，每个代理者是一个Servlet,而且代理者能够在他们

之间传送数据。

1.5JavaApple技术一实现统计数据在网页上的动态显

示

JavaApplet是专门用于Web页面中运行的程序。当一个

JavaApplet嵌入在Web页面并且当用户访问该页面时，

Applet被下载到用户的计算机中并开始执行。

系统的重要功能之一是统计的功能，具体到网页设计

中，即统计数据的图形化显示，如chart表，饼状图等，通

过这些图表在网页上的自动生成可以为企业的管理提供直

接的帮助。

图表的生成完全可以通过JavaApplet小程序实现在网

页上。通过JavaGraphics类，我们可以方便的画出任何给定

35

数据的图表，从而对企业的决策提供重要的帮助。

1.5JavaBeans技术一组件开发概念

JavaBeans是为了重用目的而专门设计的Java类。这种

可重用类在许多程序设计语言中都被应用，称为软件组件。

在本系统的开发上，应用JavaBeans技术，可以简化后

台应用程序的开发，通过定义组件，可以将开发的对象由40

个简化为10多个基类，通过定义可重用的类，提高了开发效

率，也提高了后台服务程序的可读性和可维护性。

4.5通过ML语言实现Internet上的数据交换

1ML会带来什么

SGML(通用标记语言标准IS08879:1986)是HTML的前身

技术。它是文件和文件中信息的构成主体。SGML与HTML不同，

它允许用户扩展tag集合，允许用户建立一定的规则。SGML

所产生的tag集合是用来描叙信息段特征的。而HTML仅仅只

是一个tag集合。所以我们可以说HTML是一个SGML的子集。

ML开发者源于SGML的设计和应用者。他们已经在SGML上

投入了大量精力。但他们却发现SGML并没有完全发挥它的作

用，他们当然有其充分的理由。我们可以列举以下几个重要

方面给大家.在这些方面SGML带来的影响可以说是一场革

命。

对EDI的支持

EDI就是电子数据交换。它是网络发展的一个主要目的

36

市场。结构化信息的一个主要目的就要使数据交换成为可

能。不同的工业都制定本工业统一的模型.就像是不同的国

家有着不同的语言，这便于本国文化的交流。不同的工业内

部信息用统一的模型标识，便能方便和高效地共享。这样一

个统一的模型就是DTD(文件类型定义)。当然DTD已经落伍

了，它正被ML的Schema(模式)所替代。很明显的，网络是一

个理想的电子数据的集散地。在这里HTML是显然有缺陷的数

据形式.HTML不能完全表示不同工业中所需的不同的令人满

意的模型和它的语义。能不能有一种新的语言来解决这个问

题呢?答案就是ML。

对Java技术的帮助

Java技术是本世纪最重要的技术发展之一.Java使浏览

器工作时就像在通用的应用平台上，而平台与平台之间却是

独立的.但固定的tag集合和HTML语义上的贫瘠使得Java的

应用受到了极大的限制.正如前面提到的，在HTML中不同的

语义无法表现.故数据元中丰富的信息得不到一种统一的表

示.ML却能完全胜任这份工作.

HTML页面要依赖网络服务器上的CGI脚本来表现几乎每

一个编程函数.这显然使服务器工作量太大.有了ML和Java

技术，更多的应用软件处理起来将不占用多少网络通信量.

这使得网络更加快捷，客户可以同时应用多个应用软件.

2、ML的应用

37

最初ML的目标是让各种结构的文件都作为统一的网络

文件的一部分在网上传输。HTML允许指定明确的元素类型说

明，比如特定的商品标号，文档标识，或是可测量的数值。

和HTML相比，ML允许客户定义他们自己的文件元素集合，同

时也可以指示这些素元在屏幕上如何按指定的要求表现。

为了解决怎样在固定的目标之间传输数据元，ML被定义

为一种自然的编码形式。一种被称为RDF(资源描叙框架)的

方案倍受亲睐。RDF为ML提供了数据元编码定义，这就像是

一个公用的翻译器，为不同的固定目标之间的数据提供翻

译。

ML支持更加专业的数据语言。比如说0SD(开放软件描

叙).0SD是由Microsoft和Marimba提出的一种新的格式描叙

语言。在这种格式下，软件在网上能时时检查，时时刷新版

本。不是等用户自己更新，或由是软件提供商提供类似的服

务。当0SD镶嵌于ML支持的CDF(频道定义格式)中时，0SD更

能使支持频道的桌面自动地更新。

ML的应用弥补了许多HTML的缺陷，我们把它在网上的应

用总结为四点：

1.当网络客户必须在不同的数据库之间传递信息时的

应用.

2.当需要把大部分从网络服务器载下的数据在用户端

处理时的应用.

38

3.当相同的数据对于不同的用户需要有不同的界面时

的应用.

4.当网络情报供货商要把发现的信息精心裁减，并发送

给不同的个人用户时的应用.

4.6中台

一、中台的诞生

中台战略是企业数字化转型过程中的一个热门话题。说

到中台转型，企业大多对标阿里巴巴。

2015年阿里巴巴提出了“大中台，小前台”的中台战略，

提出之初阿里有近4亿用户，为超过1000万各类企业提供服

务，业务种类繁多，业务之间相互网状依赖。同时，阿里部

门也越来越多，分工越来越细，沟通过多，相互依赖，创新

成本非常高，对业务响应也越来越慢。阿里需要找到能够对

外界变化快速反应，整合阿里各种基础能力，高效支撑业务

创新的机制。

相信很多公司或多或少都遇到过类似的问题，或者随着

企业规模越来越大，也正面临着同样的问题。

二、中台与平台

阿里业务中台的发展历程。

阿里中台从业务中台和数据中台开始，后来发展出移动

中台、技术中台、研发中台等。

39

企业中台典型架构

互联属(移动)社交甲台体检式量销通传统营销通道

营销

客推广云商运nt体情广告每深体电话，位，

户

前

开台

练下同点

而转化大障h棉动

营和交享商城商门户需a直ga

信机在服务

者

电订单口

中营

业务中台数据中台

营台责撑

人

赞

管3户管薄管钢理

后内部

台管理

台及后务管

人勤支

胜替人

语偶公管

有的企业十多年前就已经完成了大一统的集中式系统

拆分，将公共能力和核心能力分开建设，解决了公共模块重

复投入和重复建设的问题。有的企业共享平台建设时间甚至

比阿里还要早，但并没有发展成为像阿里一样的中台。

阿里这十年经历了光速发展，同时业务领域快速扩张也

增加了业务的复杂性，这种业务发展也只有像阿里这样的互

联网企业才会遇到。可以说：业务的发展和复杂性推动了阿

里中台的诞生。

我们再进一步来了解阿里业务中台的目标。

“业务中台是把核心服务链路(会员、商品、交易、营

销、店铺、资金结算等)整体当作一个平台产品来做，为前

端业务提供的是业务解决方案，而不是彼此独立的系统。”

平台化只是将部分公共模块独立为共享平台。虽然平台

通过API接口或者数据共享对外提供公共服务，解决了重复

40

建设的问题，但由于这类平台并没有与企业内其他平台或应

用实现页面、业务流程和数据从前端到后端企业级的全面融

合，没有将核心业务服务链路作为一个整体方案考虑，各平

台仍然是独立和分离的，本质上仍然为竖井式建设模式。

三、中台

“中台是一个基础的理念和架构，我们要把所有的基础

服务用中台的思路建设，进行联通，共同支持上端的业务。

业务中台更多的是支持在线业务，数据中台提供了基础数据

处理能力和很多的数据产品给所有业务方去用。业务中台、

数据中台、算法中台等等一起提供对上层业务的支撑。”

我们提炼几个中台的关键词：“共享、联通、融合和创

新”。联通是前台以及中台之间的联通，融合是前台流程和

数据的融合，以共享的方式支持前端一线业务发展和创新。

中台首先体现的是一种企业级的能力，它提供的是一套

企业级的整体解决方案，解决小到企业、集团、大到生态圈

的能力共享、联通和融合的问题，支持业务和商业模式创新。

通过平台联通和数据融合为用户提供一致的体验，更敏捷的

支撑前台一线业务。

中台源于平台，但中台与平台比，它更多的体现在一种

理念的转变，它更主要体现在三个关键能力上：

1.对前台业务的快速响应能力；

2.企业级能力的复用能力；

41

3.从前台、中台到后台的设计研发、页面操作、流程服

务和数据的无缝联通和融合能力。

其中最关键的是第3点：企业级的无缝联通和融合能力，

尤其对于集团化的超大企业而言，这一点至关重要。

四、如何做中台

传统企业有别于互联网企业，阿里、腾讯等公司是互联

网生态圈的创造者和流量入口，传统企业作为生态圈种群中

的个体，除了需要做好原有的传统渠道业务外，还需要融入

互联网生态圈，其商业模式、个体能力、与其他个体共生的

能力决定了它的发展潜力。

为了适应不同业务和渠道的发展，过去很多企业的做法

是开发很多独立的应用或APP。但由于IT系统建设初期没有

企业级的整体规划，平台之间融合不好，导致用户体验不好，

关键的是用户也并不想装那么多APP!

为了提高用户体验，实现统一运营，很多企业开始缩减

APP数量，通过一个APP集成企业内所有能力，联通前台所有

核心业务链路。

由于传统企业的商业模式和IT系统建设发展的历程与

互联网企业不完全一样，因此传统企业的中台建设策略与阿

里中台战略也应该有所差异。

由于渠道多样化，传统企业不仅要将通用能力中台化

(对应领域驱动设计的通用域或支撑域),以实现通用能力

42

的沉淀、共享和复用。还需要将核心能力中台化(对应领域

驱动设计的核心域),以满足不同渠道的核心业务能力复用

的需求，避免传统核心和互联网不同渠道应用出现“后端双

核心、前端两张皮”的问题。这属于业务中台的范畴，需解

决核心业务链路的联通和不同渠道服务共享的问题。

前台

业务中台

1

通用能核心能数据中台

力中台力中台

后台

除了核心业务链路的联通和服务共享，还需要解决系统

微服务分拆后的数据孤岛、数据融合和业务创新的问题。这

属于数据中台的范畴。采用分布式架构后更应关注微服务拆

分后的数据融合。

在中台设计和规划时，需要整体考虑企业内前台、中台

以及后台应用的协同，实现不同渠道应用的前端页面、流程

和服务的共享，实现核心业务链路的联通以及前台流程和数

据的融合，支持业务和商业模式的创新。

43

中台转型要做到：前台流程融合、中台服务共享、数据

融合创新。

五、中台建设共享

分布式和云原生等开源技术的逐步成熟，阿里、腾讯等

互联网企业也从互联网业务主战场转型为面向企业的2B技

术能力输出。这些成熟的云计算技术将为传统企业中台战略

转型赋能，也为传统企业中台建设的技术路线选择提供了多

种可能。

1.前台

传统企业早期系统有不少是基于业务领域或组织架构

来建设的，每个系统都有自己的前端，相互独立，用户操作

是竖井式，需要登录多个系统才能完成完整的业务流程。

中台后的前台建设要有一套综合考虑业务边界、流程和

平台的整体解决方案，实现各不同中台前端操作、流程和界

面的联通和融合。不管后端有多少个中台，前端用户感受只

有一个前台!

前台设计中可以借鉴微前端的设计思想，在企业内不仅

实现前端解耦和复用，还可以根据核心链路和业务流程，通

过对微前端页面的动态组合和流程编排，实现前台业务的融

合。

2.中台

业务中台和数据中台。

44

传统企业核心业务大多基于集中式架构开发，单体系统

存在扩展性和弹性伸缩能力差的问题，无法适应忽高忽低的

互联网业务场景。而数据类应用也多数通过ETL工具抽取数

据实现数据建模、统计和报表分析功能，但由于数据时效和

融合能力不够，再加上传统数据类应用本来不是为前端而

生，难以快速响应前端一线业务。

业务中台的建设可采用领域驱动设计方法，通过领域建

模，将可复用的公共能力从各单体剥离，沉淀并组合，采用

微服务架构模式，建设成为可共享的通用能力中台。同样的

将核心能力采用微服务架构模式，建设成为可面向不同渠道

和场景的可复用的核心能力中台。业务中台面向前台、第三

方和其它中台提供API服务，实现通用能力