中台系统建设方案.docx
《中台系统建设方案.docx》由会员分享，可在线阅读，更多相关《中台系统建设方案.docx（11页珍藏版）》请在冰豆网上搜索。
中台系统建设方案
中台建设方案
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扩展性
业务系统的设计不可能完全预料到未来的发展,因此可扩展性就成为业务系统未来发展的关键设计。
良好的可扩展性设计对于业务的发展能起到积极的支撑作用，可以在尽可能少改动的情况下，保证业务系统适合业务发展的需要.在我们的系统中，我们通过业务逻辑层流程的变更,可以方便地支持不同业务处理流程的需要，也可以通过对业务拓展层的修改满足个性化的业务处理要求的修改。
而对于处理容量的扩展性考虑，我们支持多服务器的业务处理与多服务器的数据分割处理，确保系统的处理能力能随着业务量的增加平稳地扩展，另外在业务上可以同步支持多业务中心的平行部署，满足业务扩展需求。
同时，我们的可扩展性还表现在对不同的业务系统的支持,由于我们对底层数据分离的依据是以企业统一的用户与组织机构管理的基础来设计,因此所有其他业务系统的应用，可以通过调用接口，无缝地集成接入系统,形成一个统一的业务系统平台,真正发挥集中式业务系统的优势。
首先,从用户数据量的增加来说,与系统直接相关的是系统处理性能能否达到用户应用的峰值要求.对于确定的硬件环境来说，如何尽可能地提高其并发用户的量，需要我们从系统业务处理的设计方式和对业务处理能力的扩展两方面来考虑。
对于业务处理的设计来说,我们通过业务逻辑的前移，减少后台数据库的处理压力，从而将相当的处理压力分担到服务器异步来处理，从而可以通过对服务器的线性扩展来提高业务的处理能力。
同时，考虑到相当多的数据是静态的数据或者是相对变动较小的数据，因此,我们在数据处理上可以进一步考虑实现内存数据库、数据缓存等，通过将某些与静态数据或变化较小数据的访问在前端服务器上来处理掉，从而减少与后台数据库服务器的交互,进而减少对后台数据库服务器的处理压力，从而提高系统本身的处理能力；
对于业务处理能力的扩展来说,无论通过何种方式来实现对数据库压力的分担,数据库本身最终仍然是处理的一个基础，在这种模式下，每一台数据库服务器始终会有一个处理的极限。
因此，当数据库服务器达到处理极限的情况下，如何来扩展其处理能力,也是我们需要考虑的一个方面。
在这里,我们考虑通过对数据库服务器的扩展来提高服务器的数据能力。
数据库服务器的扩展分两个方面。
一方面我们可以从业务上将不同的数据分布在不同的物理数据库服务器上来进行不同的业务处理，从而利用多台服务器实现某一个业务处理流程,这样就相当于将一台物理服务器的处理能力分摊在多台服务器上，从而扩展了单一服务器的数据能力；另一方面，我们还可以对用户的数据根据用户的属性来加以区分，如根据用户所属的机构属性来进行分割数据,实现多业务中心并行处理,进而可以保证不同的用户的交易在不同的物理服务器上得到处理，从而实现后台数据库服务器的处理能力的扩展。
另外,在前端服务器层面，应用本身是业务逻辑前移设计方式,并且支持群组部署和负载平衡，可以满足扩展性的需要。
在处理能力的并行扩展中，我们根据业务特点，考虑采用将多种方式结合使用，提供系统最佳的处理性能。
2.2.4开放性
系统设计采用业界开放的技术标准,使用统一技术标准，如SOA，WS-Security,HTML5等，采用面向对象的分析和设计,组件化技术等,从根本上增强了和企业现有系统的互操作性，降低了消除信息孤岛的复杂性,使得将企业现有各种业务系统互联成为一种可能。
系统整体结构具有很好的模块化设计,模块之间有明确的，遵循开放标准的服务接口，平台之间有明确的面向服务的规范；
软件产品优先选择成熟的,主流的软件平台，这类产品具有更好的开放性和更标准的接口设计;
技术路线选择大多数厂商，主流产品均支持的技术路线，将对平台的依赖性减至最低。
在应用设计上注重开放性设计,遵循国际的开放标准，组件之间的可配置程度要好,可连接性要好.同时兼顾实用性，系统具有良好的实用价值，界面友好采用互联网的UI设计，业务灵活可调整，产品的稳定高效.
2.2.5强壮性
系统具有完整的备份方案和数据备份机制以及相应的恢复方案，充分考虑核心数据库、业务中间件等故障时的处理机制。
系统具有良好的断点恢复功能，对系统出现地各类故障,可以实现断点快带恢复功能；通过数据备份记录实现数据的快速恢复和灾难重建工作；保障系统运行安全。
3系统的实现技术
系统技术平台选择
本系统是基于Java技术研发,接口采用key+token进行保护，行业应用实践证明,在稳定性、扩展性等方面都有可靠保障。
●服务器及终端环境
网络服务器操作系统：
CentOS或windows
PC端浏览器支持IE9及以上IE浏览器,火狐、谷歌等主流浏览器
●数据库
SqlServer,Redis
3.1系统的网络结构
系统网络拓扑图如下图所示:
如上图所示,系统主要部署在阿里云服务器上，通过数据接口服务完成数据安全、网络安全，系统高可用性、网络高可用性的保证。
后台管理用户可通过部署的Web服务器组的UI交互页面，其中页面操作流程中的关键业务数据提交将采用HTTPS方式进行通讯。
系统可同时采用多台应用服务器进行负载均衡保证业务处理的高并发性能及7x24小时的稳定服务能力，保证了大数据量处理性能。
4技术设计
4.1系统总体技术架构
总体技术架构图如下：
本系统的前端为纯HTML5技术开发，无需php、aspx或者jsp等动态页面服务技术,前端页面脚本和资源发布在独立的nginx服务中,可以保证前端UI加载的高并发访问性能和稳定性.
系统的后端核心业务处理服务,以独立的Java进程（CLR）方式启动http/https服务与前端及微信公众平台进行连接通讯，通讯格式采用Json格式以提高通讯过程的可扩展性兼容性及性能，业务数据采用reids进行动态缓存以保证对前端业务请求的快速处理和响应能力，业务数据的持久化采用sqlsver数据库方案。
后台管理系统以JavaWeb应用方式部署在独立的Tomcat服务器中,将前端业务处理服务和后台管理服务隔离开，保证了业务的处理能力和安全性。
4.2技术规范及实施
●系统兼容性
1、支持IE9及以上IE浏览器，支持火狐、谷歌等主流浏览器。
●安全性要求
系统对于交互过程中的所有关键字段均采用业界公认的加密算法进行加密处理。
避免客户的关键信息的泄漏，保证客户交易的安全性。
1、使用SSL进行数据加密传输.交易认证时交易密码、交易验证码等敏感数据采用MD5等加密算法进行加密；保证客户数据信息安全。
2、后台管理系统的登录采用https集合动态识别等多因子认证机制,并对后台管理用户进行分级权限管理，保证完整的登录管理等操作日志，防止后台用户的管理权限漏洞产生。
●用户人机交互界面要求
系统用户UI界面设计会遵循快捷简明人性化的原则，同时会提供简明扼要的帮助信息来方便新用户的业务操作。
●性能要求
1、平均页面响应时间：
页面响应时间是指用户点击该页面（交易）的链接到该页面完全加载完毕所需要的时间，原则上要求平均页面响应时间不超过3秒；
2、并发用户数：
并发操作用户数是指在同一时刻与服务器进行了交互的在线操作用户数量。
在满足交易响应时间要求的前提下,该系统并发操作用户数不少于100人,因架构为成熟分布式架构，可随时通过实施人员拆分部署，因此具体并发数在于购买的阿里云服务的具体配置；
3、日终批处理接口文件及报表处理时间<1小时;
4、实时报表查询的时间<1分钟;
5、系统资源占有率：
为了保证系统能够正常、稳定运行,推荐的服务器的CPU占有率和内存使用率均不应超过60%。
4.3系统扩展性要求
本系统的设计会充分考虑到扩展性,可以预留业务的扩展接口和Json形式的业务参数配置入口，对于新系统业务，技术人员或开发人员只需通过简单配置或编写即可完成新业务的添加测试以及上线部署.
4.4运行状态监控
保证系统能够正常、稳定运行，系统会即时对服务运行状态进行扫描监测并能够在后台系统随时查看，包括系统资源占有率CPU占有率和内存使用率、存贮空间占用、服务进程状态、服务端口状态等关键运行数据。
4.5信息检索
对于系统数据提供灵活的查询检索功能，具体的格式及项目可按要求输入，统计出表格、图标等不同需求的结果,可以以Excel等格式下载。
5中台系统开发管理
5.1业务模型调研团队
业务模型调研团队需要由业主方与开发方共同派出相关工作人员
1
业务产品
1
熟悉已建立再建系统业务
对现有业务进行文档式的归纳提交中台产品
2
中台产品
1
综合现有业务规划业务功能
制定中台具体功能及实现
3
开发产品
1
拥有产品架构及研发工作经验
给予中台产品规划及技术性建议
5.2开发团队
我们针对此方案配置包含了7个岗位的共计10人的开发团队，全程负责此项目的开发
1
项目经理
1
把控开发进度,实施管理等
2
系统架构师
1
根据业务模型调研团队以文档形式提交的产品详细设计说明书设计系统整体架构和公共业务功能
3
软件工程师
3
系统代码实现
4
大数据工程师
2
数据分析模型建立
5
UI工程师
2
实现系统用户交互界面设计
6
数据库工程师
2
配合系统结构是对数据结构进行设计
7
测试员
2
负责单元测试、并发测试、自动测试等
5.3开发周期
项目开发预计耗时107工作日
1
需求分析
15
形成需求分析文档
2
系统设计
15
形成概要设计方案
3
系统编码实现及测试
60
源代码
4
系统资源初始化
5
5
系统上线试运行
8
含发布环境建设
6
系统上线
2
含发布环境建设
7
验收
2
5.4网络及服务器
此部分由开发放提出需求方案，由业主方提供，不计入开发费用。
包括:
服务器、服务器操作系统、数据库、中间件、网络带宽、数据存储等。
升级会员 