第一部分认识中台——数字化中台初步认识与建设策略 一、平台是中台吗？ 1.1 业务人员抱怨系统不好用，业务响应慢原因？

问题根源可能出在系统共享、联通和融合能力上。在进行应用建设时，有人可能会站在部门或个人利益角度，特别强调和关注应用的局部“可用”，却忽略了企业级业务和流程的整体“好用”。出现了明显的系统边界和系统重复建设问题，难以支持企业级业务能力的快速融合，不能快速响应企业级业务和商业模式创新，对前台一线业务支持和融合不好，难以在前台形成一致的用户体验，最终影响企业业务发展。

1.2 传统企业大数据战略和阿里中台战略的主要差异？ 二、传统企业中台的建设策略

传统企业的中台建设策略需要从业务中台和数据中台的双中台模式。在中台设计与规划时，要整体考虑企业内前台、中台及后台应用的协同，实现不同渠道应用的前段页面、流程和服务的共享，还有核心业务链路的联通以及前台流程和数据的融合、共享，以支持前台一线业务和商业模式创新。企业中台业务能力建设一般会经历“分”和“合”两个过程。通过将企业可复用的能力沉淀，形成多个不同业务领域职责单一的中台领域模型，然后对不同类型的中台业务能力进行组合和编排，形成企业级业务能力，从而在企业领域模型的“稳”和商业模式与业务流程的“变”中找到最佳平衡。

三、如何实现前中后台的协同 3.1 前台

在前台设计时，可借鉴微前端的设计思想，通过企业级主应用与微前端应用集成，不及可实现前端页面逻辑的解耦和页面级服务的复用，还可根据企业核心业务链路和业务流程，通过对不同业务板块微前端页面的动态组合和编排，实现企业级前台业务的融合。

3.2 中台

传统企业的核心业务大多是基于集中式架构开发的。存在扩展能力弱、弹性伸缩能力差问题，无法适应突发高频访问的互联网业务场景。同时，传统企业数据类应用大多通过ETL工具抽取数据以实现数据建模、统计和报表分析功能。这种传统数仓会存在时效性问题，再加上传统数据类应用主要面向企业管理和决策分析，并不是为前台而生的，因此难以快速响应前台一线业务的数据服务要求。

所以，在企业数字化转型时，需要同时解决传统的业务和数据应用建设问题，采用双中台模式同步建设业务中台和数据中台。

3.2.1业务中台

业务中台的建设可采用DDD方法，通过领域建模数据业务化，将可复用的公共能力哦从各个单体中剥离、沉淀并组合。采用微服务架构，建设成为可共享的通用能力中台。

3.2.2数据中台

数据中台主要完成数据的融合和加工，通过数据智能化，实现智能化的业务和流程创新；通过萃取数据业务价值，提供数据服务，最终实现数字化运营。

数据中台目标如下：

数据中台建设步骤：

3.3 后台

在设计流程审核和管理类功能时，可考虑按照角色或岗位进行功能聚合，将一些复杂的管理需求从通用的核心业务链路中剥离，通过特定程序入口嵌入前台App或应用中，专门供后台管理人员使用。而对于中台与后台数据交互则可采用事件驱动的异步化的数据最终一致性模式实现数据复制，减轻中台业务压力。

第一部分认识中台——企业中台能力框架 一、中台能力总体框架

中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程，最终目标是实现企业级业务能力复用和不同业务板块能力的联通和融合。企业级的综合能力，包括：

二、业务中台

业务中台一般是指支持企业线上核心业务的中台。业务中台承载了企业核心关键业务，是企业的核心业务能力，也是企业数字化转型的重点。

业务中台实现内容：

三、数据中台

数据中台除了拥有传统数据平台的统计分析和决策支持功能外，会更多聚焦于为前台一线交易类业务提供智能化的数据服务，支持企业流程智能化、运营智能化和商业模式创新，实现“业务数据化”和“数据业务化”。数据中台建设模式变化：

数据中台工作包括：

四、技术中台

业务中台落地时需要很多的技术组件支撑，这些不同技术领域的技术组件就组成了技术中台。技术中台有以下几类关键技术领域的组件：

4.1API网管

微服务架构一般采用前后端分离设计，前段页面逻辑和后端微服务业务逻辑独立开发、独立部署，通过网管实现前后端集成。前台应用接入中台微服务的技术组件一般是API网关。API网关主要包括：鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能。API网关可帮助用户，方便地管理微服务API接口，实现安全的前后端分离，实现高效的系统集成和精准的服务监控。

4.2开发框架

开发框架主要包括前段开发框架和后端微服务开发框架。基于前、后端开发框架，分别完成前段页面逻辑和后端业务逻辑的开发。前段开发框架主要是面型PC端或移动端应用，用于构建系统表示层，规范前后端交互，降低前段开发成本。

微服务开发框架用于构建企业级微服务应用。一般具备自动化配置、快速开发、方便调试及部署等特性，提供微服务注册、发现、通信、容错和监控等服务治理基础类库，帮助开发人员快速构建产品级的微服务应用。

4.3微服务治理

微服务治理是在微服务的运行过程中，针对微服务的运行状态采取的动态治理策略，如注册服务、发现、限流、熔断和降级等，以保障微服务能持续稳定运行。微服务治理主要应用于微服务的运行中的状态监控、微服务运行异常时的治理策略配置等场景，保障微服务在常见异常场景下的自恢复能力。

微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。常见的微服务治理有Dobbo、SpringCloud和ServiceMesh等技术体系。

4.4分布式数据库

分布式数据库一般都是有较强的数据线性扩展能力，它们大多采用数据多副本机制实现数据库高可用，具有可扩展和低成本等技术优势。分布式数据库一般包括以下三类：

4.5数据处理组件

为了提高应用性能和业务承载能力，降低微服务的耦合度，实现分布式架构下的分布式业务等需求数据业务化，技术中台还有很多数据处理相关的基础技术组件，包括如下：

五、研发运营

微服务是一种去中心化的架构，去中心化的代价就是运维团队需要由很强的监控和自动化运维能力。企业一方面应尽可能提高自动化研发和运营能力，即加快软件产品交付速度，提高系统稳定性和业务连续性，降低企业的运营成本；另一方面，也需要加强监控告警、限流降级、性能分析诊断等能力，建立精准定位问题、快速分析和解决问题的能力。研发运营的能力主要体现在以下两方面。

5.1研发运营一体化

研发运营一体化是通过组织协同、流程优化和工具平台三者结合，基于整个研发运营团队进行组织协作优化，将软件需求、开发、测试、部署、运维和运营相关流程统一起来，实现项目管理、开发测试、持续交付和应用运营的无缝集成，快速交付高质量的软件和服务。通过将传统的瀑布开发模式优化为敏捷开发模式、实现研发运营团队融合和更快速的产品迭代和软件交付。借助研发运营工具链平台，实现从项目管理、开发管理、测试管理、持续交付和运维管理等全流程自动化管理。

5.2全链路监控

基于应用日志、服务链路和基础资源等多维度监控数据的关联分析，可精确定位和快速解决问题，也可进行事前预测分析，辅助运维人

来源【首席数据官】，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！