中台建设方案目录框架

中台建设方案
1综述
1.1 概述
随着企业的信息化实践逐渐落地，市场需求持续增加，中台行业正处于快速发展阶段。当前，数据中台正向多领域、多行业拓展。数据中台是构建在与业务深度结合的运作机制之上，因此企业在数据中台的实际建设过程中更需要掌握方法才能发挥其真正效能。产出方向为企业基础架构和统一研发云平台，为企业提供统一研发平台， 低代码开发平台。整体平台从基础规范- 组织结构- 基础架构- 业务开发- 持续集成- 自动化部署- 自动化测试- 运维监控- 在线升级 全方位企业级研发平台开发解决方案，具有统一授权、 认证后台管理系统，其中包含具备用户管理、资源权限管理、网关API 管理等多个模块， 结合多个组件，为开发提供基础开发架构和支持。为什么要建设研发中台，企业面临的痛点问题，解决了什么场景化的问题，要做到什么程度，带来的哪些业务价值。以下围绕这几个要素展开
1.2. 背景
随着平台业务的多样化以及各类支撑平台和信息管理系统增多，数据规模不断扩大，业务越来越复杂。从技术上来看，随着业务的发展，很多企业在前期搭建了很多的IT系统，系统间像烟囱一样相互独立。在面对着越来越复杂的业务，越来越多的数据，企业IT在扩展旧系统上出现了一定的局限，从而产生不断的重复建设的问题，企业需要制定数字转型改革的战略，来解决复杂业务系统之间的解耦问题，从而降低产品各个模块的依赖，提高复用程度。从管理架构上来看，随着公司业务的不断壮大，每个团队都需要技术，产品，市场等方面的基础支持，各个团队开展业务时需要的支持有很大程度上的重复，但是由于从制度上每个业务部门都是进行独立考核的，导致业务部门往往从自身利益出发，互相之间争夺资源，隔阂不断上升，资源无法高效利用。企业在这样的背景下，需要寻求可以打破这样困境的方法。研发中台，主要关注与开发效能管理，软件开发是一项工程，涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情。
。急需中台的建设来解决企业内部的降本增效，复用，赋能。丰富卫士通内部的背景。
1.3. 现状与分析
1.3.1. 产品现状
各个产品线现状和共性需求，数据孤岛问题，标准化组件等问题是否具备业务属性的共性能力组织
1.3.1.1. 内部现状
各个产品线产品架构单一，没有下沉共性能力，生态没有整合，业务种类繁多，业务之间相互网状依赖。团队众多，相互依赖，对业务响应也越来越慢，这是内部原因
1.3.2. 场景需求
公司的战略规划，各个产品线的业务梳理，技术梳理。
各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。java

1. 应用间数据复制严重，数据不一致性严重
2. 基础组件薄弱，日志，监控系统不完善
3. 功能模块定义混乱，包含大量接口，接口定义重复
4. 大容量访问下没法提供可靠性服务

1.3.1. 痛点问题
1）重复功能建设和维护带来重复投资；大量的功能和业务在多个系统中同时存在，是很显性的成本和资源浪费
2）打通“烟囱式”系统间交互的集成和写作成为必然；成本高昂；随着企业的发展，打通这些“烟囱式”系统之间的连接
3）不利于业务的沉淀和持续发展。系统上线几年后，由于无法满足业务发展不得不推到重建，这将会大大影响多年业务的沉淀保留
1.4. 中台建设思考

1.4.1. 针对痛点
系统痛点
各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。
应用间数据复制严重，数据不一致性严重
基础组件薄弱，日志，监控系统不完善
功能模块定义混乱，包含大量接口，接口定义重复
大容量访问下无法提供可靠性服务
开发SaaS功能的产品迫在眉睫，需要满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。
后台支撑系统已经不堪重负，吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求；
生产故障频发，有快速蔓延的趋势，大量人员参与救火已经影响到新需求开发进度，开发效率低，无法满足公司高速发展的需要；
新员工需要快速入手，如果没有老员工的传帮带，频繁试错式成长成本太高，而老员工救火之余也希望有新的机会成长，无暇顾及培养新人；
新的商业模式要求开放内部业务能力，需要重构应用和服务。
待解决问题
核心系统全面服务化：系统分解为核心服务和基础服务。
基础组件：服务化框架，分库分区，缓存组件。
加强监控，日志系统。
步化并行，限流，分流，降级，压力测试，异地灾备。
数据库统一规划优化。

1.4.2. 解决方案
平台实现
这个基础平台以先进的技术作为依撑，采用服务架构实现一个共享可复用的统一框架，是具有扩展性、兼容性、前瞻性的底层平台， 满足快速开发、避免重复开发的需求，开创产品创新的新模式和新途径，更好的为产品开发和部署、运维提供服务。
平台共享数据为各个子系统共同调用的数据，减少各子系统间数据的调用，减少系统间的耦合性，达到“强内聚，低耦合”的效果；
可实现数据一次输入，多个子系统使用，消除信息孤岛，减少数据库服务器工作量，提高整体使用性能；
提供统一的开发框架，提高开发效率，避免重复开发，节约成本；
便于部署，实施和运维；
形成一个产品，用于后期产品的开发和管理。
服务模块化设计，便于根据需求组合使用。
服务统一注册、发现、治理。
便于集群部署和负载均衡，提供强大的并发支持和高可用。
约束条件
系统稳定、高效，可支持企业内外各种不同使用场景下的并发操作。
系统有良好的扩展性：在增加新的功能时旧有模块不做改动或稍作改动即可完成集成，部署更新不影响其他业务。
提供数据接口：便于其他产品或第三方厂商系统进行集成。
模块化：各个功能部分按模块开发，模块彼此解耦。
配置化：可根据客户实际需求，配置不同参数。
支持6大平台的开发和运行，支持Windows和Linux系统。
采用B/S架构，与外部业务系统之间使用RestfulAPI进行交互，使用spring MVC、java、c#语言进行开发。
需要支持高性能、高并发、高可用和高稳定的需求。

1.4.3. 中台建设前提
大中台基于的一个前提是，大量的积累。在这个前提下进行的提炼抽取才是有价值的，如果没有足够的积累，盲目的进行抽取，抽取出的接口没有通用性，不但无法提升效率，反而会一些无用功。那什么样的企业适合中台呢？
1、业务线多且复杂，通过搭建中台，可以有效的将业务线统一，将数据打通。
2、快速发展的企业，通过搭建中台，可以快速搭建新的业务线，避免重复造轮子。
那什么样的企业不适合中台呢？
1、初创型企业，初创型企业，业务线单一，没有足够的积累，搭建的中台无法发挥作用，反而会浪费人力物力，拖慢开发的进度。

1.4.4. 行业标准与规范
什么是中台？
业务、数据“双中台：业务中台将后台资源进行抽象包装整合，转化为前台友好的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化
数据中台从后台及业务中台将数据流入，完成海量数据的存储、计算、产品化包装过程，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑”
企业为什么要建中台？
如何建设中台？
不做中台会怎么样？
满足条件后，做了带来哪些业务价值？
1.5. 产品边界
1.5.1. 业务边界

做成什么样子，解决什么问题，近期目标。产品的核心功能:再从结果倒推出需求边界,清晰界定自己的边界,以及需要遵守的边界。毕竟客户只是需要解决问题,而如何解决,功能如何呈现
1.5.2. 产品形态
描述中台的产品形态应该包含哪些核心关键要素：评估过程中的能力地图，需求结构化。业务身份标识的业务清单和业务度量。数据治理中的数据生命周期和数据安全。
1.6. 设计目标与原则
1.6.1. 设计目标
在满足自身内部中台的需求的同时满足外部企业中台需求，提炼前台共性需求，把后台产品做成标准化组件供前台部门使用。
描述近期目标：
第一，我们这个体系里有什么样的能力，可以让各业务很清楚的知道，也可以让前台业务方更快的理解、选择和使用中台能力，
第二、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。
1.6.2. 设计原则
 按“重中台”+"轻应用"设计，业务应用逻辑思路放在前端应用，推荐是尽可能减小或不拆分前端服务;
 重中台的建设，在于前端应用共性部分的抽取和后期的沉淀，造成中台业务服务;
 中台服务调用基础服务，或者其它同级服务，中台服务为服务的中层，用于业务共性(共享)抽取；
 同一级服务之间能够互相调用，只能自下往下调用，平级调用，禁止自下往上调用，以免服务混乱及维护混乱。
 基础服务只为调用设计，位于服务的底层或者中间层，基础服务禁止调用中台服务；
 服务单库设计,以减小迁移，服务以前影响等，每种服务目录按999个服务规划。
 模块间的解耦: 如果模块之间相互影响太大，牵一发而动全身是不可取的。
 单一职责原则: 模块承担的能力跟其他模块职责隔离，便于水平扩展。
 数据解耦原则: 不同的平台应将数据剥离解耦，借此形成独立数据，针对不同的业务场景和分析工具都能共享同一份数据来达成数据打通或应用目的。
 组件适当性原则:每个组件都有自己擅长的领域，要考虑数据的结构（结构化还是非结构化），处理的时效性（毫秒级或分钟级），以及吞吐量和访问模式等方面原则
 高内聚、低耦合原则：高内聚是从服务中心的业务界域来说的，在一个服务中心内的业务应该是相关度很高、依赖性很高的；而服务中心之间应该是业务隔离性比较大的，追求尽可能的低耦合。
 数据完整性原则：服务化架构一个很重要的业务价值就是数据模型统一，不光只是业务逻辑的关键数据，还要考虑到业务的相关性的数据；不光是实时在线数据，还要考虑到离线计算的数据。
 业务可运营性原则：我们期望服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。一是指业务本身的活力，当业务处于快速生长期，这时候的运营目标是满足上层的业务需求，这个时候属于沉淀阶段；第二个层面的运营是业务内部孕育出来的创新想法，比如淘宝基于大数据分析技术生长起来的商品巡检技术、前台类目自动聚合推荐技术等。
 演化的建设原则：服务化架构本来就是一种敏捷的实践，我们的方式逐步推进，不要推翻重构。
结论：总体规范遵循TOGAF标准框架
1.6.3. 场景适配
适配于： 生态复杂
数据孤岛
研发效率

1.6.4. 如何演进
建设路线是怎么样的？服务化架构本来就是一种敏捷的实践，我们也是逐步推进，集合自身内部的现状和目标，不断进行优化。描述分阶段目标，近期目标所具备的能力全景，远期目标能力规划。每次规划能解决哪些痛点问题，降本增效。
1.7. 总体规划

1.7.1. 服务规划规范
目录说明
序号 目录名称 说明 备注
1 公共服务 基础公共包,所有工程的基础，包括配置，页面，核心包等
2 组件服务 基础组件包，用于第三方等，组件包不能单独运行，只能被依赖
3 平台服务 包括注册中心，配置中心等
4 基础服务 公用基础组件，只能被调用或者调用公共或者组件包,不能主动调用其它服务
5 业务服务 处理业务服务，可以服务之间互相调用，或者调用基础服务
6 门户服务 与业务服务同级，用于统一门户服务
7 网关服务 对外网关服务,与平台组件同级，但仅做为网关部分
8 应用服务 前端应用或者手机应用
9 监控服务 监控平台，用于运维平台，目前仅规划,有可能与平台服务合并一起
10 示例服务 做示例工程，包含有所有服务调用示例 略
目录规划
序号 目录名称 目录规划 端口规划 权限 备注
1 公共服务 alinesno-cloud-common 研发
2 组件服务 alinesno-cloud-component 研发
3 平台服务 alinesno-cloud-platform 24000+ 研发
4 基础服务 alinesno-cloud-base 25000+ 研发
5 中台服务 alinesno-cloud-business 26000+ 开发
6 门户服务 alinesno-cloud-portal 27000+ 研发
7 网关服务 alinesno-cloud-gate 28000+ 开发
8 应用服务 alinesno-cloud-web 34000+ 开发
9 监控服务 alinesno-cloud-monitor 35000+ 研发
10 示例服务 alinesno-cloud-demo 30000+ 研发 置于guide基线

1.7.2. 基础服务规划
1.7.3. 中台服务规划
1.7.4. 应用服务规划
1.7.5. 运维整体规划
运维设计
方向 描述 工具 备注
自动部署 用于应用自动化部署管理 Jenkins
自动化运维管理 可视化运维和自动化批量操作管理 ansible+CMDB+ 自研平台
监控体系+预警 服务器性能及各个系统监控,网络监控，主机监控工具等 Prometheus
服务网关 网关用于限流、降级、监控等等 Nginx + 自研平台
应用监控 布式日志中心 EFK 适当场景考虑
应用监控 分布式链路跟踪 zikpin 待考虑
应用监控 Kubernetes Prometheus 适当场景考虑
应用监控 应用监控预警 美团cat 适当场景考虑
Devops运维管理平台
主要用于机器管理、资源管理、网络管理、架构基础设施、资源申请、自动化操作等管理，用于公司或者现场数据库，资产与主机管理，监控维护等
功能 描述 备注
仪盘表 总体监控及信息管理
资产管理 所有硬件资产管理和记录，资源申请
主机管理 物理机管理，虚拟管理
数据管理 数据库配置、数据库管理
参数配置 预警参数、参数管理、机房管理
用户管理 权限分配、用户管理

1.8. 总体设计
整体架构支撑是为了整体平台的流程，从管理、开发、测试、运维、生产几条线，实现整体平台的落地和管理。

1.8.1. 设计思路
设计考虑: 结合自身需求和目标，必须充分需求结合场景考虑以下几个要素：
1)考虑产品模块化的思想（解耦），数据打通的原则以及对外数据交互的方式
3）考虑数据格式化和数据标准化，数据生命周期安全性等问题
设计依据：标准，规范，法律法规
设计思路：适应数据管理的要求，满足业务发展的要求，符合信息化建设发展的趋势
1.8.2. 总体技术架构

1.8.1. 总体业务架构
1.8.2. 总体应用架构

1.8.1. 总体安全设计

1.9. 安全和可靠性设计
1.1 系统安全
管理员口令需满足复杂性要求，如长度最少8位，且含数字、大小写字母及其他特殊符号等；允许登陆失败次数按保密要求设定。超出次数后，锁定该用户并生成审计事件，该账号需管理员后台进行解锁方可再次使用，系统在规定时间内设有操作和访问系统自动锁屏，待用户重新输入登陆密码后方可继续操作。
系统实行“三权分立”，具有系统管理员、安全管理员和审计管理员三个管理员角色。系统管理员主要负责系统维护，可以对网络和系统的用户增加或删除，用户权限的授予与撤销、运行管理、维护升级等；

1.2 数据安全
数据对象主要包括安全设备日志、网络设备日志、操作系统日志、管理系统、业务应用系统等数据，在传输中采用SSL/TLS协议进行加密传输，无HTTP/TCP/UDP/明文传输数据。
用户按分工或级别分为不同的角色，按照权限最小原则，详细规划权限。发起不能定义高于自身权限的数据对象；管理员能够设置不同角色的授权范围；发起者能够将要授权的数据对象上传至系统，高密级数据对象不能授权给低密级用户，且不能授权给管理制定范围之外的用户，且能够制定用户的操作范围；授权者不能将自身不具有的权限授权给其他用户；授权用户能够将对应数据对象下载到本地；数据对象内容你那个不能监控，且非授权身份不能进行查看、拷贝和下载等操作。
建立数据分类分级和数据共享负责人制度，有效落实上述制度规范
数据发布阶段
数据申请阶段
数据审核阶段
数据调用阶段
数据运维阶段

1.3 可靠性设计
支持快速恢复业务，将系统组件故障对业务整体运行的影响降低到最小程度。
保持业务高稳定性，不会无故宕机，在高压下仍然能正常工作。
支持快速定位故障，以尽快处理问题，防止进一步影响业务。
应用层采用中间件集群架构，实现容灾、负载均衡和无中断服务，集群的节点分布在不同主机，即使一台主机故障，服务也不会中断。
数据层采用主从数据库或数据库集群技术，保障故障容错和无缝切换功能，将硬件和软件错误造成的影响最小化。
网络层和主机层采用双机或集群架构，任何一台主机或者一台主机的网络中断，均不会出现单点失败造成整个系统故障的问题。

1.10. 方案特点
1.10.1. 环境适配、策略灵活

1. 内外网、网中网环境自适应
2. 元数据策略结合业务需求自定义
3. 支持分布式部署，弹性扩展
4. 智能调整业务规则策略
   1.10.2. 覆盖业务广度、数据深度
   1.10.3. 数据准确性、实时性

1.10.4. 数据安全性
1.11. 平台价值
这个基础平台以先进的技术做为依撑，采用服务架构实现一个共享可复用的统一框架，是具备扩展性、兼容性、前瞻性的底层平台，知足快速开发、避免重复开发的需求，开创产品创新的新模式和新途径，更好的为产品开发和部署、运维提供服务。web

1. 平台共享数据为各个子系统共同调用的数据，减小各子系统间数据的调用，减小系统间的耦合性，达到“强内聚，低耦合”的效果；
2. 可实现数据一次输入，多个子系统使用，消除信息孤岛，减小数据库服务器工做量，提升总体使用性能；
3. 提供统一的开发框架，提升开发效率，避免重复开发，节约成本；
4. 便于部署，实施和运维；
5. 造成一个产品，用于后期产品的开发和管理。
6. 服务模块化设计，便于根据需求组合使用。
7. 服务统一注册、发现、治理。
8. 便于集群部署和负载均衡，提供强大的并发支持和高可用。
   约束条件spring
9. 系统稳定、高效，可支持校园内外各类不一样使用场景下的并发操做。
10. 系统有良好的扩展性：在增长新的功能时旧有模块不作改动或稍做改动便可完成集成，部署更新不影响其余业务。
11. 提供数据接口：便于其余产品或第三方厂商系统进行集成。
12. 模块化：各个功能部分按模块开发，模块彼此解耦。
13. 配置化：可根据客户实际需求，配置不一样参数。
14. 支持6大平台的开发和运行，支持Windows和Linux系统。
15. 采用B/S架构，与外部业务系统之间使用RestfulAPI进行交互，使用spring MVC、java、c#语言进行开发。
16. 须要支持高性能、高并发、高可用和高稳定的需求

1.12. 系统维护和升级
1.12.1. 系统升级

1.12.2. 系统检查和维护