前⾔
2015年阿⾥巴巴提出“⼤中台，⼩前台”的中台战略，通过实施中台战略到能够快速应对外界变化，整合阿⾥各种基础能⼒，⾼效⽀撑业务创新的机制。阿⾥巴巴中台战略最早从业务中台和数据中台建设开始，采⽤了双中台的建设模式，到后来发展出了移动中台、技术中台和研发中台等，这些中台的能⼒综合在⼀起就构成了阿⾥巴巴企业级数字化能⼒。传统企业在技术能⼒、组织架构和商业模式等⽅⾯与阿⾥巴巴存在⾮常⼤的差异，在实施中台战略时是否可以照搬阿⾥巴巴中台建设模式？传统企业中台数字化转型需要提升哪些⽅⾯的基本能⼒呢？下⾯我们⼀起来分析分析。
00 中台能⼒总体框架
中台建设过程从根本上讲是企业⾃⾝综合能⼒持续优化和提升的过程，最终⽬标是实现企业级业务能⼒复⽤和不同业务板块能⼒的联通和融合。企业级的综合能⼒，⼀般包含以下四种：业务能⼒、数据能⼒、技术能⼒和组织能⼒，如图2-1所⽰。
▲图2-1 企业中台数字化转型基本能⼒框架
业务能⼒主要体现为对中台领域模型的构建能⼒，对领域模型的持续演进能⼒，企业级业务能⼒的复⽤、融合和产品化运营能⼒，以及快速响应市场的商业模式创新能⼒。
数据能⼒主要体现为企业级的数据融合能⼒、数据服务能⼒以及对商业模式创新和企业数字化运营的 ⽀撑能⼒。
技术能⼒主要体现为对设备、⽹络等基础资源的⾃动化运维和管理能⼒，对微服务等分布式技术架构体系化的设计、开发和架构演进能⼒。 组织能⼒主要体现为⼀体化的研发运营能⼒和敏捷的中台产品化运营能⼒，还体现为快速建设⾃适应的组织架构和中台建设⽅法体系等⽅⾯的能⼒。
这些能⼒相辅相成，融合在⼀起为企业中台数字化转型发挥最⼤效能。接下来，我们⼀起来看看在不同的领域应该如何实现这些能⼒。
01 业务中台
企业所有能⼒建设都是服务于前台⼀线业务的。从这个⾓度来讲，所有中台应该都可以称为业务中台。但我们所说的业务中台⼀般是指⽀持企业线上核⼼业务的中台。
业务中台承载了企业核⼼关键业务，是企业的核⼼业务能⼒，也是企业数字化转型的重点。业务中台的建设⽬标是：“将可复⽤的业务能⼒沉淀到
业务中台，实现企业级业务能⼒复⽤和各业务板块之间的联通和协同，确保关键业务链路的稳定⾼效，提升业务创新效能。”
推杆炉
业务中台的主要⽬标是实现企业级业务能⼒的复⽤，所以业务中台建设需优先解决业务能⼒重复建设和复⽤的问题。通过重构业务模型，将分散在不同渠道和业务场景（例如：互联⽹应⽤和传统核⼼应⽤）重复建设的业务能⼒，沉淀到企业级中台业务模型，⾯向企业所有业务场景和领域，实现能⼒复⽤和流程融合。
图2-2是⼀个业务中台⽰例。在业务中台设计时，我们可以将⽤户管理、订单管理、商品管理和⽀付等这些通⽤的能⼒，通过业务领域边界划分和领域建模，沉淀到⽤户中⼼、订单中⼼、商品中⼼和⽀付中⼼等业务中台，然后基于分布式微服务技术体系完成微服务建设，形成企业级解决⽅案，⾯向前台应⽤提供可复⽤的业务能⼒。
▲图2-2 业务中台⽰例
在技术实现上，中台的系统落地可以采⽤微服务架构。微服务是⽬前公认的业务中台技术最佳实现，可以有效提升业务扩展能⼒，实现业务能⼒复⽤。
在业务建模上，中台领域建模可以采⽤领域驱动设计（DDD）⽅法，通过划分业务限界上下⽂边界，构建中台领域模型，根据领域模型完成微服务拆分和设计。
吸音墙
业务中台可以⾯向前台应⽤提供基于API接⼝级的业务服务能⼒，也可以将领域模型所在的微服务和微前端组合为业务单元，以组件的形式⾯向前台应⽤，提供基于微前端的页⾯级服务能⼒。
业务中台建设完成后，前台应⽤就可以联通和组装各个不同中台业务板块，既提供企业级⼀体化业务能⼒⽀撑，⼜可以提供灵活的场景化销售能⼒⽀撑。
蜂鸣器驱动电路02 数据中台
数据中台与业务中台相辅相成，共同⽀持前台⼀线业务。数据中台除了拥有传统数据平台的统计分析和决策⽀持功能外，会更多聚焦于为前台⼀线交易类业务提供智能化的数据服务，⽀持企业流程智能化、运营智能化和商业模式创新，实现“业务数据化和数据业务化”。
最近⼏年，数据应⽤领域出现了很多新的趋势。数据中台建设模式也随着这些趋势在发⽣变化，主要体现在以下⼏点。
申智惠
第⼀，数据应⽤技术发展迅猛。近⼏年涌现出了⼤量新的数据应⽤技术，如NoSQL、NewSQL和分布式数据库等，以及与数据采集、数据存储、数据建模和数据挖掘等⼤数据相关的技术。这些技术解决业务问题的能⼒越来越强，但同时也增加了技术实现的复杂度。
第⼆，数据架构更加灵活。在从单体向微服务架构转型后，企业业务和数据形态也发⽣了很⼤的变化，数据架构已经从集中式架构向分布式架构转变。
第三，数据来源更加多元化，数据格式更加多样化。随着车联⽹、物联⽹、LBS和社交媒体等数据的引⼊，数据来源已从单⼀的业务数据向复杂的多源数据转变，数据格式也已经从以结构化为主向结构化与⾮结构化多种模式混合的⽅向转变。
第四，数据智能化应⽤将会越来越⼴泛。在数字新基建的⼤背景下，未来企业将汇集多种模式下的数据，借助深度学习和⼈⼯智能等智能技术，优化业务流程，实现业务流程的智能化，通过⽤户⾏为分析提升⽤户体验，实现精准营销、反欺诈和风险管控，实现数字化和智能化的产品运营以及
AIOps等，提升企业数字智能化⽔平。
⾯对复杂的数据领域，如何建设数据中台管理并利⽤好这些数据？
这对企业来说是⼀个⾮常重要的课题。
数据中台的⼤部分数据来源于业务中台，经过数据建模和数据分析等操作后，将加⼯后的数据，返回业务中台为前台应⽤提供数据服务，或直接以数据类应⽤的⽅式⾯向前台应⽤提供API数据服务。
数据中台⼀般包括数据采集、数据集成、数据治理、数据应⽤和数据资产管理，另外还有诸如数据标准和指标建设，以及数据仓库或⼤数据等技术应⽤。图2-3是2017年阿⾥云栖⼤会上的⼀个数据中台⽰例。
▲图2-3 数据中台⽰例（图参考：2017年阿⾥云栖⼤会）
喷胶
综上所述，数据中台建设需要做好以下三⽅⾯的⼯作。
⼀是建⽴统⼀的企业级数据标准指标体系，解决数据来源多元化和标准不统⼀的问题。企业在统⼀的数据标准下，规范有序地完成数据采集、数据建模、数据分析、数据集成、数据应⽤和数据资产管理。
高硅氧布
⼆是建⽴与企业能⼒相适应的数据研发、分析、应⽤和资产管理技术体系。结合企业⾃⾝技术能⼒和数据应⽤场景，选择合适的技术体系构建数据中台。
三是构建⽀持前台⼀线业务的数据中台。业务中台微服务化后，虽然提升了应⽤的⾼可⽤能⼒，但是随着数据和应⽤的拆分，会形成更多的数据孤岛，会增加应⽤和数据集成的难度。在业务中台建设的同时，需要同步启动数据中台建设，整合业务中台数据，消除不同业务板块核⼼业务链条之间的数据孤岛，对外提供统⼀的⼀致的数据服务。⽤“业务+数据”双中台模式，⽀持业务、数据和流程的融合。
数据中台投⼊相对较⼤，收益周期较长，但会给企业带来巨⼤的潜在商业价值，也是企业未来数字化运营的重要基础。企业可以根据业务发展需求，制定好阶段性⽬标，分步骤、有计划地整合好现有数据平台，演进式推进数据中台建设。
03 技术中台
业务中台落地时需要有很多的技术组件⽀撑，这些不同技术领域的技术组件就组成了技术中台。业务中台⼤多采⽤微服务架构，以保障系统⾼可⽤性，有效应对⾼频海量业务访问场景，所以技术中台会有⽐较多的微服务相关的技术组件。
⼀般来说，技术中台会有以下⼏类关键技术领域的组件，如API⽹关、前端开发框架、微服务开发框架、微服务治理组件、分布式数据库以及分布式架构下诸如复制、同步等数据处理相关的关键技术组件，如图2-4所⽰。
1. API⽹关
微服务架构⼀般采⽤前后端分离设计，前端页⾯逻辑和后端微服务业务逻辑独⽴开发、独⽴部署，通过⽹关实现前后端集成。
前台应⽤接⼊中台微服务的技术组件⼀般是API⽹关。
API⽹关主要包括：鉴权、降级限流、流量分析、负载均衡、服务路由和访问⽇志等功能。API⽹关可以帮助⽤户，⽅便地管理微服务API接⼝，实现安全的前后端分离，实现⾼效的系统集成和精细的服务监控。
2. 开发框架
开发框架主要包括前端开发框架和后端微服务开发框架。基于前、后端开发框架，分别完成前端页⾯逻辑和后端业务逻辑的开发。
前端开发框架主要是⾯向PC端或者移动端应⽤，⽤于构建系统表⽰层，规范前后端交互，降低前端开发成本。
▲图2-4 技术中台关键技术领域
微服务开发框架⽤于构建企业级微服务应⽤。⼀般具备⾃动化配置、快速开发、⽅便调试及部署等特性，提供微服务注册、发现、通信、容错和监控等服务治理基础类库，帮助开发⼈员快速构建产品级的微服务应⽤。
开发框架⼀般都⽀持代码⾃动⽣成、本地调试和依赖管理等功能。
3. 微服务治理
微服务治理是在微服务的运⾏过程中，针对微服务的运⾏状况采取的动态治理策略，如服务注册、发现、限流、熔断和降级等，以保障微服务能够持续稳定运⾏。
微服务治理主要应⽤于微服务运⾏中的状态监控、微服务运⾏异常时的治理策略配置等场景，保障微服务在常见异常场景下的⾃恢复能⼒。
微服务治理技术组件⼀般包括服务注册、服务发现、服务通信、配置中⼼、服务熔断、容错和微服务监控等组件。
常见的微服务治理有Dubbo、Spring Cloud和Service Mesh等技术体系。
4. 分布式数据库
分布式数据库⼀般都具有较强的数据线性扩展能⼒，它们⼤多采⽤数据多副本机制实现数据库⾼可⽤，具有可扩展和低成本等技术优势。
分布式数据库⼀般包括三类：交易型分布式数据库、分析型分布式数据库和交易分析混合型分布式数据库。
交易型分布式数据库⽤于解决交易型业务的数据库计算能⼒，它⽀持数据分库、分⽚、数据多副本，具有⾼可⽤的特性，提供统⼀的运维界⾯，具备⾼性能的交易型业务数据处理能⼒。主要应⽤于具有跨区域部署和⾼可⽤需求，需⽀持⾼并发和⾼频访问的核⼼交易类业务场景。
分析型分布式数据库通过横向扩展能⼒和并⾏计算能⼒，提升数据整体计算能⼒和吞吐量，⽀持海量数据的分析。主要应⽤于⼤规模结构化数据的统计分析、⾼性能交互式分析等场景，如数据仓库、数据集市等。
交易分析混合型分布式数据库通过资源隔离、分时和数据多副本等技术⼿段，基于不同的数据存储、访问性能和容量等需求，使⽤不同的存储介质和分布式计算引擎，同时满⾜业务交易和分析需求。主要应⽤于数据规模⼤和访问并发量⼤，需要解决交易型数据同步到分析型数据库时成本⾼的问题，需要解决数据库⼊⼝统⼀的问题，需要⽀持⾼可⽤和⾼扩展性等数据处理业务场景。
5. 数据处理组件
为了提⾼应⽤性能和业务承载能⼒，降低微服务的耦合度，实现分布式架构下的分布式事务等要求，技术中台还有很多数据处理相关的基础技术组件。如：分布式缓存、搜索引擎、数据复制、消息中间件和分布式事务等技术组件。
分布式缓存是将⾼频热点数据集分布于多个内存集节点，以复制、分发、分区和失效相结合的⽅式进⾏维护，解决⾼并发热点数据访问性能问题，降低后台数据库访问压⼒，提升系统吞吐能⼒。典型的开源分布式缓存技术组件有Redis。
搜索引擎主要解决⼤数据量的快速搜索和分析等需求。将业务、⽇志类等不同类型的数据，加载到搜索引擎，提供可扩展和近实时的搜索能⼒。
数据复制主要解决数据同步需求，实现同构、异构数据库间以及跨数据中⼼的数据复制，满⾜数据多级存储、交换和整合需求。主要应⽤于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。数据复制技术组件⼤多采⽤数据库⽇志捕获和解析技术，在技术选型时需考虑数据复制技术组件与源端数据库的适配能⼒。
消息中间件主要适⽤于数据最终⼀致性的业务场景，它采⽤异步化的设计，实现数据同步转异步操作，
⽀持海量异步数据调⽤，并通过削峰填⾕设计提⾼业务吞吐量和承载能⼒。它被⼴泛⽤于微服务之间的数据异步传输、⼤数据⽇志采集和流计算等场景。另外，在领域驱动设计的领域事件驱动模型中，消息中间件是实现领域事件数据最终⼀致性的⾮常关键的技术组件，可以实现微服务之间的解耦，满⾜“⾼内聚，松耦合”设计原则。典型的开源消息中间件有Kafka等。
分布式事务主要是解决分布式架构下事务⼀致性的问题。单体应⽤被拆分成微服务后，原来单体应⽤⼤量的内部调⽤会变成跨微服务访问，业务调⽤链路中任意⼀个节点出现问题，都可能造成数据不⼀致。分布式事务是基于分布式事务模型，保证跨数据库或跨微服务调⽤场景下的数据⼀致性。
分布式事务虽然可以实时保证数据的⼀致性，但过多的分布式事务设计会导致系统性能下降。因此微服务设计时应优先采⽤基于消息中间件的最终数据⼀致性机制，尽量避免使⽤分布式事务。
技术中台是业务中台建设的关键技术基础。在中台建设过程中，可以根据业务需要不断更新和吸纳新的技术组件，也可以考虑将⼀些不具有明显业务含义的通⽤组件（如认证等），通过抽象和标准化设计后纳⼊技术中台统⼀管理。为了保证业务中台的⾼性能和稳定性，在技术组件选型时⼀定要记住：尽可能选⽤成熟的技术组件。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议