终于有人把业务中台、数据中台、技术中台说清楚了。实现企业级业务能力的复用和不同业务部门能力的互联互通。企业级综合能力一般包括以下四类：业务能力、数据能力、技术能力和组织能力，如图2-1所示。▲图2-1台湾企业数字化转型基本能力架构。业务能力主要体现在中台领域模型构建能力，领域模型持续演进能力，以及业务能力在企业层面的复用、集成和产品化能力。以及对市场快速反应的商业模式创新能力。数据能力主要体现在企业级数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力。技术能力主要体现在设备、网络等基础资源的自动化运维和管理能力，以及微服务等分布式技术架构的系统化设计、开发和架构演进能力。组织能力主要体现在一体化的研发运营能力和敏捷的中台产品化运营能力，以及快速构建适应性组织架构和中台建设方法体系的能力。这些能力相互补充，相互融合，最大限度地发挥企业中台数字化转型的成效。接下来我们就来看看这些能力在不同领域是如何实现的。01中台台资企业能力建设全部服务于一线业务。从这个角度来说，所有的中台都应该叫做业务中台。但我们所说的业务中台，一般是指支撑企业线上核心业务的中台。业务中台承载着企业的核心关键业务，是企业的核心业务能力，也是企业数字化转型的重点。业务中心的建设目标是：“将可复用的业务能力沉淀到业务中心，实现企业级业务能力的复用和业务板块之间的连通协同，保障关键业务环节的稳定和高效，提升业务创新效率。”业务中心的主要目标是实现企业级业务能力的复用，因此业务中心的建设需要优先解决业务能力的重复建设和复用问题。通过重构业务模型，将分散在不同渠道和业务场景（如：互联网应用和传统核心应用）的业务能力沉淀到企业级中台业务模型中，面向全业务场景和领域企业，实现能力综合体。使用与流程一体化。图2-2是一个服务中心的例子。在设计业务平台时，我们可以通过业务领域边界划分和领域建模，将用户管理、订单管理、商品管理、支付等通用能力集成到用户中心、订单中心、商品中心、支付中心。业务中台，进而基于分布式微服务技术体系完成微服务构建，形成企业级解决方案，为前端应用提供可复用的业务能力。▲图2-2业务中台示例在技术实现上，中台的系统实现可以采用微服务架构。微服务是目前公认的业务中台技术的最佳实现，可以有效提升业务扩展能力，实现业务能力复用。在业务建模方面，中台的领域建模可以采用领域驱动设计（DDD）的方法。通过划分业务边界和上下文边界，构建中台领域模型，根据领域模型完成微服务的拆分和设计。业务中心可以为前端应用提供基于API接口层的业务服务能力，也可以将领域模型所在的微服务和微前端组合成业务单元，提供基于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技术中心重点技术领域的微服务开发框架，用于构建企业级微服务应用。一般具有自动配置、快速开发、调试部署方便等特点，提供微服务注册、发现、通信、容错和监控等服务治理基础类库，帮助开发者快速构建产品级微服务应用程序。开发框架一般都支持代码自动生成、本地调试、依赖管理等功能。、限流、断路降级等，保证微服务持续稳定运行。微服务治理主要应用于微服务运行过程中的状态监控、微服务运行异常时的治理策略配置等场景，保障微服务在常见异常场景下的自恢复能力。微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错、微服务监控等。常见的微服务治理包括Dubbo、SpringCloud、ServiceMesh等技术体系。4、分布式数据库分布式数据库一般都具有很强的数据线性扩展能力。它们大多采用多种数据副本机制来实现数据库的高可用性，具有可扩展性、低成本等技术优势。分布式数据库一般包括三种类型：事务型分布式数据库、分析型分布式数据库和事务分析型混合分布式数据库。事务型分布式数据库用于解决事务型业务的数据库计算能力。支持数据分库、分片、数据多副本。具有高可用特性，提供统一的运维接口，拥有高性能的事务性业务数据。处理能力。主要用于有跨地域部署和高可用需求，需要支持高并发和高频访问的核心交易业务场景。分析型分布式数据库通过水平扩展能力和并行计算能力，提高数据的整体计算能力和吞吐量，支持海量数据的分析。主要应用于数据仓库、数据集市等大规模结构化数据统计分析、高性能交互分析等场景。事务分析混合分布式数据库采用资源隔离、分时、数据多副本等技术手段，根据不同的数据存储、访问性能、容量需求，采用不同的存储介质和分布式计算引擎，满足业务事务和分析需求。主要用于大规模数据和大访问并发。需要解决事务数据同步到分析型数据库成本高的问题，需要解决数据库统一录入的问题，需要支持高可用、高扩展等数据处理业务场景。5、数据处理组件为了提高应用性能和业务承载能力，降低微服务的耦合度，实现分布式架构下的分布式事务，技术中心也有很多与数据处理相关的基础技术组件。如：分布式缓存、搜索引擎、数据复制、消息中间件和分布式事务等技术组件。分布式缓存是将高频热点数据集分布在多个内存集群节点中，并以复制、分布、分区、故障相结合的方式进行维护，解决高并发热点数据访问性能问题，降低后台数据库访问压力，以及提高系统的吞吐能力。典型的开源分布式缓存技术组件包括Redis。搜索引擎主要解决快速搜索和分析大量数据的需求。将业务、日志等不同类型的数据加载到搜索引擎中，提供可扩展和近实时的搜索能力。数据复制主要解决数据同步需求，实现同构和异构数据库之间、跨数据中心的数据复制，满足数据多级存储、交换和集成需求。主要应用于基于表或库的业务数据迁移、业务数据复制到数据仓库等数据迁移场景。大多数数据复制技术组件采用数据库日志捕获和解析技术，在选择技术时必须考虑数据复制技术组件与源数据库的适配性。消息中间件主要适用于数据最终一致性的业务场景。采用异步设计，实现数据同步到异步操作，支持海量异步数据调用，通过削峰填谷设计提高业务吞吐量和承载能力。广泛应用于微服务间异步数据传输、大数据日志采集、流计算等场景。另外，在领域驱动设计的领域事件驱动模型中，消息中间件是实现领域事件数据最终一致性的一个非常关键的技术组件，可以实现微服务之间的解耦，满足“高内聚和多线程”的要求。松耦合”。设计原则。典型的开源消息中间件有Kafka等。分布式事务主要解决分布式架构下的事务一致性问题。单体应用拆分成微服务后，原有单体应用的大量内部调用将变为跨微服务访问。如果业务调用链路中的任何一个节点出现问题，都可能导致数据不一致。分布式事务基于分布式事务模型，保证跨数据库或跨微服务调用场景的数据一致性。分布式事务虽然可以保证数据的实时一致性，但是过多的分布式事务设计会导致系统性能下降。因此，在设计微服务时，首先应该使用基于消息中间件的最终数据一致性机制，尽量避免分布式事务。技术中台是业务中台建设的关键技术基础。在中台建设过程中，可以根据业务需要不断更新吸收新的技术组件，一些没有明显业务意义的通用组件（如认证等）也可以考虑集成到中台。经过抽象和标准化设计管理的技术中台。为了保证业务平台的高性能和稳定性，我们在选择技术组件时一定要记住：尽可能选择成熟的技术组件。作者简介：欧创新，大型保险公司架构师，拥有十余年软件架构设计经验。热衷于DDD、中台和分布式微服务架构设计。在DDD、中台、分布式微服务架构设计方面有深厚积累，擅长分布式微服务架构设计。邓迪，某大型保险公司高级工程师，国家青年岗位能手。致力于基于DDD的企业级微服务架构改造实践，精通前端开发相关技术栈，具有丰富的企业级微前端实战经验。本文节选自《中台架构与实现：基于DDD和微服务》，经发布者授权发布。
