不谈虚的，给传统企业一份代码级 中台落地实践 ? 先给理解混乱的中台下一个较精准的定义 什 么 是 中 台 ？ 中 台 是 为 了 体 现 IT 技 术 ， IT 系 统 ， IT 部 门 的 业 务 价 值 而 诞 生 的 概 念 通过将 后台应用 在 技术平台 的支撑下进行 封装 或者 重构 从 而形成 面向业务场景 的服务以支撑 业务快速迭代 的平台 ERP，SAP，CRM等 微服务平台，容器平台等 传统企业在采购外部系统 的情况下可采用此模式 互联网企业在研发力量充 足的情况下可采用此模式 从技术语言到前台业务语言 从内部管理语言到前台业务语言 中台最终的效果，没有 这个效果无所谓中台 ? 要点：快速迭代 中台是企业已有系统积淀，解决了业务温饱问题，要进一步解决业务创新问题时候用的 ? 创 业 公 司 No. ? 中台是业务想创新，并且有 N 条路可以走，但不知道应该走哪条路的时候用的 ? ? 原 来 的 路 走 的 high ， 不 想 创 新 No. 业 务 想 不 出 路 No. ? ? 中台不是现有的系统集成，你改不了 中台不是技术平台，帮不了业务 业务创新模式 高层决策 管理监督 分析决策 产品创新 用户体验 产品孵化 业务模式 业务流程 盈利模式 组织协同 成本控制 效率提升 以业务为核心 领导层可控制可观测 逐步快速迭代 中台体系建设总图 中台建设所涉及的架构和流程 业务架构 技术架构 数据架构 研发流程 组织架构 单体架构 > 服务化架构 > 微服务架构 物理机 / 虚拟机 > 云计算 (IaaS+PaaS) > 容器 +SpringCloud/Dubbo > Service Mesh 简单统计分析 > 支持管理决策 > 数据运营驱动创新 测试发布手工化 > 测试发布脚本化 > 测试发布平台化 > DevOps 研发运维隔离 > 建立中台组衔接研发运维 > 建立架构委员会融合研发运维 中台体系的逐步演进过程 开发 运维 DevOps 规划 试点 服务化 微服务化 (1) 业务流程梳理 (2) 划分核心领域 (3) 确定界限上下文 及相互关系 (4) 输出按照领域横 向拆分架构 (5) 持续集成流程及 工具 (6) 选取试点业务， 横向拆分 (9) 业务拆分，灰度 发布，逐渐迁移 (10) 保障质量属性， 纵向分层拆分 (11) 试点业务拆分完 毕，总结服务化规范 (7) 注册中心及 API 规范与知识库 (8) API 网关保障平滑 拆分 (12) 质量看板，流程 保障，绩效考核 (13) 架构委员会进行 服务化分组，各组制 定拆分计划 (14) 各组按照里程碑 计划，逐步拆分 (15) 服务多，运维压 力大，容器平台 (16) 服务多，定位问 题难，全链路监控 (17) 统一日志中心 (18) 统一配置中心 (19) 为支撑高并发， 进一步拆分 (22) 多服务一致性， 使用 TCC ，事务消息 (20) 服务治理，防止 服务雪崩，请求堆积 (21) 服务多，去 Oracle ，使用分布式 数据库，分布式事务 (23) 容器化之后，测 试环境多，流量染色 (24) 全 链 路 压 测 (25) 多 机 房， 单 元 化 应用层服务数 激 云原生 促 活 体系 进 技术底座灵活性 信息拉通 数据集成 协同管理 仅做集成 很难修改 难快速响应需求 从源头寻找：是什么阻碍了快速迭代？ 企业消息总线 数据交换工具 CRM 客户 关系 管理 MES 制造 执行 系统 ERP 企业 资源 计划 HR 人力 资源 系统 PLM 产品 生命 周期 管理 SCM 供应 链管 理 ? 架 构 腐 化 问 题 ， 重 构-> 腐 化-> 重 构-> 腐 化 是什么影响了单体软件的迭代速度？ 《重构：改善代码的既有设计》 架构为什么会不断腐化？ 没时间搞 因不可观测，领导重视功能和 Bug ， 不重视架构，不给留足够时间 没动力搞 代码可理解性差，反正 Code Review 不出来，所以头疼医头 没胆量搞 代付复杂，耦合性高，核心逻辑不 敢动，只好层层封装 迭代速度慢 耦合现象一：你改代码，你要上线， 要我配合 可复用性差 耦合现象二：明明有某个功能，却 拿不出来 技术债务 一个功能原来需要开发一下午，现 在需要开发一个月 网易中台体系建设实践 问题 解决 实现 促进 架构腐化问题 架构耦合问题 技术债务问题 业务创新 可理解性 工 程 简 洁 ， 职 责 单 一 ， 易 修 改 ， 易 Re v i e w 可测试性 单元测试覆盖度高，集成测试容易开展 可观测性 成立架构委员会，制定规范，实时监测 快速迭代 开发敢改，同事易review， QA易测试，领导易看到价值 可复用性 中台构建方式一：封装式 传统企业由于采购大量传统服务， 可采用封装式构建中台。 前台APP或者门户一旦需求改变， 后台采购系统或核心稳态系统不 可能随之改变，所以中间封装中 台服务层 传统服务多使用SOAP协议暴露 接口，可通过ESB或者API网关 转换为RESTFul接口对上暴露 服务层采用最新微服务架构进行 开发，适应前台快速迭代 稳态 后台 前 台 敏态 中台 微服务 治理 RESTFul ESB/API网关 SOAP/RESTFul CRM MES ERP HR PLM SCM 用户管理 数据字典 Web应用 消息服务 工单管理 手机App API网关 工业微服务组件 资产管理 组织管理 客户管理 订单管理