中台系统建设实施方案.docx
- 文档编号:27094233
- 上传时间:2023-06-27
- 格式:DOCX
- 页数:14
- 大小:24.34KB
中台系统建设实施方案.docx
《中台系统建设实施方案.docx》由会员分享,可在线阅读,更多相关《中台系统建设实施方案.docx(14页珍藏版)》请在冰豆网上搜索。
中台系统建设实施方案
中台建立案
1总述
1.1当前问题
1.系统维护困难
2.二次开发迭代仅原厂商可以进展
3.新承建系统过多重复工作
4.同一业主下不同系统存在数据壁垒
1.2中台系统解决问题
因软件系统建立数量的日益增长,我们发现浪费了过多的时间在开发相似系统功能上,且在这些相似的系统功能,我们现实遇到的情况是:
1.相似系统功能无法通用于不同系统,难以快速接入
2.系统功能由不同语言、不同技术架构、不同标准开发,难以维护
3.相似系统功能之间数据无法通用,数据壁垒凸显
同一个轮子造100遍,对一个部门或是一家企业是没有任好处,自然一个相似的系统造100遍同样没有什么帮助。
以此我们希望建立一套可以满足大多数系统功能的、可以满足今后扩展的、有相对统一业务的、可以快速高效迭代的并可快速接入的系统,以下我们简称"中台〞。
中台解决问题:
1.相似业务无需重复开发
2.数据统一打破数据壁垒,可多系统、多行业的数据分析
3.快速迭代接入
4.统一规,降低维护难度
1.3中台系统带来的收益
工程面
减少了重复造轮子、重复建系统的现象。
对统一的业务资源统一管理。
数据面
有了统一的资源管理,如:
统一的用户、权限、订单等,就不再会有各种的数据打通问题、同步问题,不会有夸部门的数据墙。
有了公共的中台,也就有了统一的数据规。
对于大数据相关的需求,可以从相对唯一的数据出口进展业务迭代,不需要为每一个部门进展定制开发,浪费人力。
创新面
产品、开发、实施人员不再是仅对一套系统、一个行业进展业务开发。
由在"点〞上的根本感知不到问题的角色,突破到从"线〞和"面〞的平台上进展工作,更容易发现这些问题的本质,通过其自身的专业技能解决当前实际问题的同时产生全局观。
解决系统问题将不再是以前的"打补丁〞,而是转为真正意义上的"升级〞。
不谋全局者,缺乏谋一域。
有了公共的中台,意味着产品、开发、实施人员拥有相对全局的视角,更能发现单点单观察难以发现的问题,在更大的业务层后进展一定的创新
1.4中台系统达成目标系统
目前暂将中台系统的建立目标分为三个阶段:
第一阶段
(一)建立统一的开发标准,如:
1.统一技术栈〔开发语言、开发框架、开发工具、数据工具、其他中间件等〕
2.统一接入式
3.制定统一数据标准
(二)调研分析统一业务模型,如:
1.系统根底功能模型
2.行业业务功能模型
3.数据分析模型建立
(三)人才技术储藏,由于中台接入系统的增加,中台的高可用性,如:
容错容灾、负载、多中心切换、数据同步、平台平安等不可无视,所以需要早期及时规划相关人员。
(四)中台功能开发,如:
1.权限管理效劳〔RMS〕
2.根底数据效劳〔BDMS〕
3.客户管理效劳〔CMS〕
4.容管理效劳〔CMS〕
5.日志管理效劳〔LOGMS〕
6.第三接入效劳〔TPIMS〕
7.数据分析效劳〔DAMS〕
8.自定义流程效劳〔WFMS〕
在此阶段我们可以达成的目标为:
1.减少重复工作
2.快速新增功能
3.快速接入
4.中台的功能数据壁垒消除
5.二次开发可不再依赖原厂商
第二阶段
将第一阶段得到的行业业务功能模型开发转化为统一业务功能,自此将数据分析效劳〔DAMS〕升级为"数据中台〞。
在此阶段我们可以达成的目标:
1.可实现跨系统、跨行业的数据分析
2.让数据分析多元化
3.中台系统由原来的可"高效开发迭代接入管理的业务平台〞升级为"可产生超数据围的大数据分析业务综合平台〞
4.对同一行业的信息化建立实现同步开发
第三阶段
随着中台系统的功能完善,那么必不可免的产生高并发、数据量增大等性能瓶颈问题,由此在第一阶段的储藏将对现有平台的技术框架、软件构造、效劳器资源等进展持续优化,从而到达真正的稳定可高、高效。
2系统建立总体设计
2.1系统总体建立思想
在遵循整体性、法制性、规性、实用性的总体设计思想的根底上,系统采用微效劳为前端用户效劳平台。
中台的建立融合了多项当前软件开发的先进技术。
通过自有团队系统开发提供更好的可扩展性。
后端API构建在Java平台之上,管理平台实现前后端别离,以到达日益变化的前端技术,使用目前大型系统开发常用的MVC架构进展开发,前端页面展示与后端数据操作完全独立开发,通过强认证的接口进展数据的读写与交互,本系统格地定义了所有的根底业务对象与业务逻辑处理对象,统一了数据存储规那么,在此根底上又将软件细致地划分为后台数据处理层、中间业务逻辑处理层、前台业务逻辑处理层和表现层,并且配合我公司独立开发的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交互页面,其中页面操作流程中的关键业务数据提交将采用S式进展通讯。
系统可同时采用多台应用效劳器进展负载均衡保证业务处理的高并发性能及7x24小时的稳定效劳能力,保证了大数据量处理性能。
4技术设计
4.1系统总体技术架构
总体技术架构图如下:
本系统的前端为纯HTML5技术开发,无需php、aspx或者jsp等动态页面效劳技术,前端页面脚本和资源发布在独立的nginx效劳中,可以保证前端UI加载的高并发访问性能和稳定性。
系统的后端核心业务处理效劳,以独立的Java进程〔CLR〕式启动/s效劳与前端及微信公众平台进展连接通讯,通讯格式采用Json格式以提高通讯过程的可扩展性兼容性及性能,业务数据采用reids进展动态缓存以保证对前端业务请求的快速处理和响应能力,业务数据的持久化采用sqlsver数据库案。
后台管理系统以JavaWeb应用式部署在独立的Tomcat效劳器中,将前端业务处理效劳和后台管理效劳隔离开,保证了业务的处理能力和平安性。
4.2技术规及实施
●系统兼容性
1、支持IE9及以上IE浏览器,支持火狐、谷歌等主流浏览器。
●平安性要求
系统对于交互过程中的所有关键字段均采用业界公认的加密算法进展加密处理。
防止客户的关键信息的泄漏,保证客户交易的平安性。
1、使用SSL进展数据加密传输。
交易认证时交易密码、交易验证码等敏感数据采用MD5等加密算法进展加密;保证客户数据信息平安。
2、后台管理系统的登录采用s集合动态识别等多因子认证机制,并对后台管理用户进展分级权限管理,保证完整的登录管理等操作日志,防止后台用户的管理权限漏洞产生。
●用户人机交互界面要求
系统用户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网络及效劳器
此局部由开发放提出需求案,由业主提供,不计入开发费用。
包括:
效劳器、效劳器操作系统、数据库、中间件、网络带宽、数据存储等。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 建设 实施方案