中台系统建设方案.docx

中台系统建设方案.docx

《中台系统建设方案.docx》由会员分享，可在线阅读，更多相关《中台系统建设方案.docx（20页珍藏版）》请在冰豆网上搜索。

中台系统建设方案

中台建设方案

目录

中台建设方案 1

1 总述 3

1.1 当前问题 3

1.2 中台系统解决问题 3

1.3 中台系统带来的收益 4

工程方面 4

数据方面 4

创新方面 4

1.4 中台系统达成目标系统 4

第一阶段 4

第二阶段 5

第三阶段 5

2 系统建设总体设计 6

2.1 系统总体建设思想 6

2.2 系统设计原则 6

2.2.1 安全性 6

2.2.2 可靠性 8

2.2.3 扩展性 8

2.2.4 开放性 9

2.2.5 强壮性 10

3 系统的实现技术 10

系统技术平台选择 10

3.1 系统的网络结构 10

4 技术设计 11

4.1 系统总体技术架构 11

4.2 技术规范及实施 12

4.3 系统扩展性要求 13

4.4 运行状态监控 13

4.5 信息检索 13

5 中台系统开发管理 14

5.1 业务模型调研团队 14

5.2 开发团队 14

5.3 开发周期 14

5.4 网络及服务器 15

1总述

1.1当前问题

1.系统维护困难

2.二次开发迭代仅原厂商可以进行

3.新承建系统过多重复工作

4.同一业主下不同系统存在数据壁垒

1.2中台系统解决问题

因软件系统建设数量的日益增长，我们发现浪费了过多的时间在开发相似系统功能上，且在这些相似的系统功能，我们现实遇到的情况是：

1.相似系统功能无法通用于不同系统，难以快速接入

2.系统功能由不同语言、不同技术架构、不同标准开发，难以维护

3.相似系统功能之间数据无法通用，数据壁垒凸显

同一个轮子造１００遍，对一个部门或是一家企业是没有任何好处，自然一个相似的系统造１００遍同样没有什么帮助。

以此我们希望建设一套可以满足大多数系统功能的、可以满足今后扩展的、有相对统一业务的、可以快速高效迭代的并可快速接入的系统，以下我们简称“中台”。

中台解决问题：

1.相似业务无需重复开发

2.数据统一打破数据壁垒，可多系统、多行业的数据分析

3.快速迭代接入

4.统一规范，降低维护难度

1.3中台系统带来的收益

工程方面

减少了重复造轮子、重复建系统的现象。

对统一的业务资源统一管理。

数据方面

有了统一的资源管理，如：

统一的用户、权限、订单等，就不再会有各种的数据打通问题、同步问题，不会有夸部门的数据墙。

有了公共的中台，也就有了统一的数据规范。

对于大数据相关的需求，可以从相对唯一的数据出口进行业务迭代，不需要为每一个部门进行定制开发，浪费人力。

创新方面

产品、开发、实施人员不再是仅对一套系统、一个行业进行业务开发。

由在“点”上的根本感知不到问题的角色，突破到从“线”和“面”的平台上进行工作，更容易发现这些问题的本质，通过其自身的专业技能解决当前实际问题的同时产生全局观。

解决系统问题将不再是以前的“打补丁”，而是转为真正意义上的“升级”。

不谋全局者，不足谋一域。

有了公共的中台，意味着产品、开发、实施人员拥有相对全局的视角，更能发现单点单观察难以发现的问题，在更大的业务层后进行一定的创新

1.4中台系统达成目标系统

目前暂将中台系统的建设目标分为三个阶段：

第一阶段

（一）建立统一的开发标准，如：

1.统一技术栈（开发语言、开发框架、开发工具、数据工具、其他中间件等）

2.统一接入方式

3.制定统一数据标准

（二）调研分析统一业务模型，如：

1.系统基础功能模型

2.行业业务功能模型

3.数据分析模型建立

（三）人才技术储备，由于中台接入系统的增加，中台的高可用性，如：

容错容灾、负载、多中心切换、数据同步、平台安全等不可忽视，所以需要早期及时规划相关人员。

（四）中台功能开发，如：

1.权限管理服务（ＲＭＳ）

2.基础数据服务（ＢＤＭＳ）

3.客户管理服务（ＣＭＳ）

4.内容管理服务（ＣＭＳ）

5.日志管理服务（ＬＯＧＭＳ）

6.第三方接入服务（ＴＰＩＭＳ）

7.数据分析服务（ＤＡＭＳ）

8.自定义流程服务（ＷＦＭＳ）

在此阶段我们可以达成的目标为：

1.减少重复工作

2.快速新增功能

3.快速接入

4.中台内的功能数据壁垒消除

5.二次开发可不再依赖原厂商

第二阶段

将第一阶段得到的行业业务功能模型开发转化为统一业务功能，自此将数据分析服务（ＤＡＭＳ）升级为“数据中台”。

在此阶段我们可以达成的目标：

1.可实现跨系统、跨行业的数据分析

2.让数据分析多元化

3.中台系统由原来的可“高效开发迭代接入管理的业务平台”升级为“可产生超数据范围的大数据分析业务综合平台”

4.对同一行业的信息化建设实现同步开发

第三阶段

随着中台系统的功能完善，则必不可免的产生高并发、数据量增大等性能瓶颈问题，由此在第一阶段的储备将对现有平台的技术框架、软件结构、服务器资源等进行持续优化，从而达到真正的稳定可高、高效。

2系统建设总体设计

2.1系统总体建设思想

在遵循整体性、法制性、规范性、实用性的总体设计思想的基础上，系统采用微服务为前端用户服务平台。

中台的建设融合了多项当前软件开发的先进技术。

通过自有团队系统开发提供更好的可扩展性。

后端ＡＰＩ构建在Ｊａｖａ平台之上，管理平台实现前后端分离，以达到日益变化的前端技术，使用目前大型系统开发常用的ＭＶＣ架构进行开发，前端页面展示与后端数据操作完全独立开发，通过强认证的接口进行数据的读写与交互，本系统严格地定义了所有的基础业务对象与业务逻辑处理对象，统一了数据存储规则，在此基础上又将软件细致地划分为后台数据处理层、中间业务逻辑处理层、前台业务逻辑处理层和表现层，并且配合我公司独立开发的ORM框架进行数据库操作，保证了数据库的可扩展性、可迁移性。

为了适应业务发展的需求，本系统的扩展能力也是一大特色，我们在制定了统一的数据处理规则，规范了基础行业对象，也将现有的业务逻辑对象进行了统一封装，并给二次开发者提供了简单灵活的访问接口、详尽的文档说明，在进行新功能的拓展时无须对数据库进行直接操作，从而保证了数据库的完整性和安全性

2.2系统设计原则

2.2.1安全性

1）系统的结构安全性设计

系统的结构安全性在本系统中主要来源于两个方面：

数据传输的安全性与数据存储的安全性。

分级分权限管理企业资源、保密消息，有效确保消息的阅读范围。

系统的数据和信息存储，数据库服务器部署于阿里云，数据库公网无法访问，只能通过建立于ECS应用服务器访问数据，对应用服务器进行了多层安全防护与访问授权，确保数据存储的安全性。

2）系统业务安全设计

对于系统的业务安全来说，系统在以下几个方面对安全性方面进行了相应的设计：

1.对关键数据的加密存放，如用户、操作人员的密码等；

2.对关键数据的校验存放，如接口信息的校验串设计；

3.对关键数据的日志记录，系统严格的留痕设计，对于重要的操作均采用独立的流水记录，保证相关业务的发生均有相应的记录，保存处理时的关键信息；而对于一般性的操作，则通过日志记录的方式，确保重要的信息能得以保存，供后续的查证使用；

4.对业务操作的严格权限检查，任何业务的操作，在应用服务器处理层，均需进行相应的功能与权限检查，包括菜单与功能的两级权限检查、用户身份与操作权限的检查、使用人员身份与操作权限的检查、业务本身处理要求的检查等，防止一切非法的调用，确保系统的业务处理的安全性；

5.对业务操作的严格控制性检查，可设置用户、使用人员的站点限制，设置用户与使用人员可操作的对象限制等；

6.对业务可自定义审核设计，可通过对业务操作的参数化定义，来设置对业务处理的不同等级的审核要求，确保业务在处理前，通过不同使用人员的审核，来保证业务处理的合法性与合理性，防范意外事件的发生；

7.对系统的运行监控设计，可监控系统的网络状况、业务处理情况以及数据交换的情况等，从而可有效地及时发现异常事件的发生。

3）数据安全设计

在数据安全方面：

系统在设计上充分考虑到业务稽核的需要，在数据库后台表的设计中，通过对关键数据表增加校验字段来保证数据的客观公正；通过对关键数据密码类根据系统提供的加密方式加密后存放，可保证即使是数据库管理人员也无法从表中直接查询到用户或操作人员的关键数据；通过对各业务表之间的逻辑关联，确保非法的数据修改可通过数据间的关联关系得以查找。

数据安全还表现在数据的一致性和可稽核性方面：

首先系统所有操作均有留痕，这是可稽核的首要条件，另外，系统的数据记录是连续的、互相关联的，并且总分平衡的；这就为系统数据的一致性和可稽核性的必要条件。

因此数据的一致性和可稽核性是数据安全的基本保障。

对数据的访问完全隔离互联网直接访问，互联网对数据的请求必须经过授权后，通过部署于阿里云的接口访问。

通过部署与不同网段的两层接口进行数据安全防护，避免核心接口与数据存储暴露于互联网。

4）系统灾备设计

对于灾备系统来说，主系统所具有的功能均需具有，但考虑到灾备系统管理与维护的方便性，采用节点数尽可能少的高性能服务器来实现业务的接管是最为经济可行的模式。

通常，在系统中采用多服务器并行模式的情况下，灾备系统可以考虑将多应用服务器统一部署，通过采用应用与查询分离的双服务器模式来实现系统的应用部署。

多中心服务器的部署设计方式既可以满足分布式处理的要求，同时也可以满足在单物理服务器上的统一部署的需要，因此，灾备系统的建设也就变得非常简单可行。

对于本系统，将充分利用阿里云云的已有建设成果，数据的安全及备份将由阿里云系统完成。

2.2.2可靠性

系统在设计上已充分考虑提供安全可靠的技术和管理方式，保证常年不间断运行。

系统在通讯层、应用逻辑层、数据库层都实现高可靠，避免单点故障。

应用服务器应具备负载均衡的能力。

系统在长时间大容量高压力的情况下，能稳定运行。

通过组件化设计，系统任何局部性的错误不影响整个系统的正常运行。

多台应用服务器并行运行时能按组集群并具备负载均衡功能，连接断开后应用服务器能自动重连。

系统具有完善的容错功能，数据库服务器、网络设备、存储设备及相关系统和软件应有冗余设计，由于系统在数据库层采有服务器组的方式实现，中间件层采用群组方式实现，实现组内设备系统单点出现故障时，能实现自动切换。

系统容错及冗余的实现对系统性能的影响较小。

系统容错及冗余的实现不能影响系统性能。

系统有完备的系统级和应用级灾难备份的解决方案，系统对通讯链路故障、核心数据库故障、应用服务器故障有不同的解决方案和应对措施。

为简化管理，便于维护，系统在建设时在阿里云（或中心机房）安装有实时监控系统，可以实现对所有重要设备或系统进行监控，同时还可根据需要对灾备中心的指定进行实时监控。

系统有完备的在线和脱机数据备份措施。

系统备份拥有断点恢复功能，从而可以保证数据备份的完整性。

在出现灾难时，可以实现快速恢复。

2.2.3扩展性

业务系统的设计不可能完全预料到未来的发展，因此可扩展性就成为业务系统未来发展的关键设计。

良好的可扩展性设计对于业务的发展能起到积极的支撑作用，可以在尽可能少改动的情况下，保证业务系统适合业务发展的需要。

在我们的系统中，我们通过业务逻辑层流程的变更，可以方便地支持不同业务处理流程的需要，也可以通过对业务拓展层的修改满足个性化的业务处理要求的修改。

而对于处