标签：来源 nbsp 离线 锁定 连接 二层 用户命令 搜索结果 标准化
目录：
1.关于中台的名言
2.中台起源
3.中台定义
4.中台类型
5.中台能力
6.中台本质
7.中台优势
8.中台动态
9.排头兵的中台案例
10.建设中台的两大原因
11.中台究竟能解决的问题
12.中台解决的痛点
13.中台对中小型公司的意义
14.做中台两个关键点
15.中台落地
16.中台完整的体系
17.中台技术本质
18.中台技术架构
19.遥望未来10年—AI中台
20.业务中台
21.业务中台&数据中台
22.业务中台&大数据
23.彩蛋
关键词： 业务中台/ 共享 / 公共通用 / 复用
书籍推荐：
《淘宝技术十年》
《企业 IT 架构转型之道：阿里巴巴中台战略思想和架构实战》
名言：
2014年马云也曾在阿里内部说过：一切业务数据化和一切数据业务化。
解释：“一切业务数据化”，即业务中台能够将企业相关业务领域的原生数据，做好统一、规范及标准，让企业业务数据实时、统一、在线。这是业务中台干的事情。但此后，这些原生数据其实不能给企业产生大数据的价值。数据要有价值，要发挥洞察和预测的能力，便得“一切数据业务化”。“数据的回馈能力很重要，所有业务场景中收集和采集的数据，围绕业务场景，根据调度算法或预测算法反作用到业务，这才是一切数据业务化的本质和核心”，
起源：
中台这个概念早期是由美军的作战体系演化而来的，技术上所说的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系。国内知名的有阿?的“?中台，?前台”战略。并且华为在几年前就提出了“?平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台?撑下小前台的作战策略。这种极度灵活又威力巨?的战法，使之可以迅速响应瞬息万变的战场，一旦锁定目标，通过大平台的炮火群，迅速精准对于战场进行强大的火?支援。
中台定义：
1. 中台是一种企业级能力复用平台，是一种共性能力，支持了多个业务。核心是“功能复用”，构建“大中台，小前台”来满足业务快速扩展的需求；
2.主要职责是汇总所有业务数据，协同各个业务单元，提炼业务的共性需求，支撑前、后台业务的快速发展
3.沉淀了大量的用户行为数据（包含非体系内用户），为大数据智能算法的新的商业模式奠定了基础
5.作为业务服务的提供方，不需要依赖业务的稳定性，而是需要不断为新业务提供能力支持。
中台类型：
中台—> 业务、数据、用户、搜索、推荐、内容、技术、算法、移动、研发等一系列中台
中台的几方面能力：
前台/中台/后台
前台：
由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。
中台：
因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。中台战略的构建，从功能上说，包括构建数据中台、构建技术中台、以及构建业务中台。其中数据中台的本质是将数据资产化，技术中台的本质是将流程自动化，业务中台的本质是将应用场景化。
后台：
由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
结论：
中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。
中台本质：
中台的本质是提炼各个业务线的共性需求，并将这些功能打造成组件化的产品。前台要做什么业务，需要什么资源可以直接找中台，不需要每次去改动自己的底层，而是在更丰富、灵活的“大中台”基础上获取业务能力支持，让“小前台”更加灵活敏捷，中台架构被认为是未来企业级架构的方向。中台类似一个变速齿轮，将前台的快速响应和后台的复杂，稳定可靠，变化周期相对较慢的矛盾适配起来，快速驱动业务创新的同时，又保持了IT架构的稳定
中台系统的优势：
排头兵的中台动态：
2017 年 12 月，滴滴出行执行总监赖春波透露了滴滴如何搭建出行业务中台的过程：滴滴从专业深度、人力资源、用户体验、全局打通四个维度，将快车、出租车、专车、顺风车、代驾等多个业务的垂直化架构整合到了同一套架构体系中。由于滴滴的业务和用户命令输送相对具备一致性，滴滴的中台建设也主要基于数据的维度。进一步地，在业务更为复杂、服务更为多元的企业中，需要建构的中台模式也将更为复杂。
2018 年 11 月 26 日，据报道，美团正在尝试打通美团 APP 全平台、大众点评、摩拜各个业务之间的数据，构建数据中台。
2019 年 3 月 19 日，字节跳动也被曝出正在搭建「直播大中台」，抖音、西瓜视频、火山小视频这 3 款 APP 的直播技术和运营团队将被抽出、合并，支撑旗下所有的直播产品。
阿里巴巴的数据业务双中台。毕竟阿里的“大中台小前台”战略人尽皆知，其威力也是显而易见的。业务中台将后台资源进行抽象包装整合，转化为前台友好的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化。数据中台从后台及业务中台将数据流入，完成海量数据的存储、计算、产品化包装过程，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。
排头兵的中台案例：
阿里云——业务数据双中台
阿里巴巴——移动中台
阿里巴巴——技术中台
腾讯——数据中台和技术中台
百度——搜索中台
京东——数据中台
广发银行——业务中台
海通证券—— 数据中台、技术中台、业务中台三元统一
恒生电子 —— 数据中台+技术中台+业务中台+行业级业务中台
举例：
讲到中台，一定会提到两个例子，一个是13年马云参观supercell，然后在15年确定了阿里的中台战略；另一个是华为的中台战略转型，也就是那句著名的“让听得见炮火的人指挥战斗”；
举例：
阿里的共享服务部发展历程，即供应链中台。公司刚开始只有淘宝，后来意识到B2C模式的业务也会是电商领域重要的组成部门，所以出现了天猫，随着天猫的不断发展，逐渐独立成一个部门，但是这两套都包含订单、商品、库存、价格、仓储、物流等基本业务系统。这两个系统互相独立，各自运行。等到10年左右，阿里开始上线1688、聚划算等业务的时候发现，这些业务针对的领域虽然各不相同，但是他需要用到的系统功能也高度类似，主要也是订单、商品、库存、价格、仓储、物流等系统。如果这些新业务的系统也都要全部重新开发一遍，这无疑是很大的资源浪费。明明既有的系统调整一下就可以满足新业务的需求，为什么还要继续开发新系统呐？在这个大的背景之下，阿里内部将共享服务部的职权不断提升，统一将各个业务业务部门重复使用，反复建设的功能和系统统一规划和管理。
举例：
滴滴在15年末开始启动自己的中台战略，这与滴滴当时的业务发展阶段也是相关的。2015 年末，滴滴在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。这些业务虽然会有一些差别，但是核心系统和流程都是类似的。如果各自独立开发，也会出现各种各样的问题。比如说，开发成本过高，滴滴旗下的每个业务，其实都是可以单独支撑起一家公司的，如果每个业务都独立做到极致，那么开发成本和人力成本就会非常巨大，而如果为了控制成本，就把系统的建设放缓，则意味着，无论是核心系统本身的质量，还是对外的用户体验都不太好。在这样的背景下，滴滴也开始考虑将诸多业务，以及各个城市的系统统一规划，统一建设，提升服务前台的能力。
建设中台的两大原因：
一类是，许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设，导致复用性低、效率低、产研资源浪费、用户体验不统一；另一类是，早期业务发展过程中，为了解决一些当下的业务问题，垂直的、个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑也非常多，这样导致在新业务、新市场的拓展过程中，系统没法直接复用，甚至没法快速迭代。
中台究竟能解决的问题：
中台作为一种产品设计思路，或者系统架构思路，并不受限于公司的规模，理论上讲，任何一家即将或者正在面临业务高速增长的状态时，都很值得利用和借鉴中台的思路，将目前业务当中大量可复用的功能和场景进行梳理，为业务的高速增长做好准备
举例：
1、多业务来源数据统一
数据来自于高德、美团...等等，通过中台系统，可以把这些数据统一接入订单库
2、数据聚合
通过中台聚合订单，对外提供「订单API」。运能系统通过订单API扣减运能，财务系统通过订单API结算。
3、快速扩展
企业如果后续要上新系统，比如会员、积分子系统等都可以直接和中台接口对接，获取到全渠道的业务数据，快速完成系统搭建，响应业务需求。
中台解决的痛点：
痛点一：企业前方市场与企业内部支撑的冲突，即用户和用户的需求永远是善变的。企业前方市场总是会趋于变化无序，而企业内部支撑总归要趋于稳定有序
痛点二：前台与后台的冲突
前台是对接用户的，所以系统需要快速响应前端用户的需求，快速创新、快速迭代。简而言之，快速建设、错了就推翻重来、不能耗费太大成本。
后台是企业对内的，为了支撑前台越来越多的业务，后台系统不断地建设，系统不断庞大起来。所以后台系统需要扎实稳定，建成之后往往不能随意改动。
痛点三：大企业的通病（各占山头、重复建设）大企业内部各处都是墙——部门墙、业务墙、数据墙
中台对中小型公司的意义：
对于很多中小公司，当他们走出生存困境，进入到高速发展阶段时，会遇到很多的问题，但大概率会遇到的一个问题是，过往的业务模型，产品能力很有可能没法完全承接住大规模用户增长带来的压力。而当你具体到每个用户的时候，你又能发现，他们遇到的问题你之前都遇到过，只不过，因为一下来的太多，你没法像过去一样提供达预期，甚至超预期的服务时，对方就会产生不满。这也是为什么许多公司会生于拉新，死于留存的一个原因。所以，在有可能的情况下，公司将一些大概率长期有价值的功能，专门模块化，进行开发和优化，确保即使业务规模进一步扩大，也能够满足业务需求。甚至，随着能力或方法论的不断优化，甚至有可能某一天成为整个行业的方法论。对于中小公司而言，中台的理念不见得是单独拉几十人搭建一个中台产研团队，可以将一些关键流程先行标准化，把一些反复出现的场景当中的解决方案进行沉淀，部分需要产品化的功能先行产品化，可能对于一家业务刚刚开始起步的公司来说，就已经很重要了。
做中台两个关键点：
思维：
必须思考的问题是，这个功能在现在或者将来能满足多少业务场景？如果将来有新的业务出现，是不是能够复用？或者说，需要做多大的调整才可以复用？甚至于，这个功能有没有可能对外输出，提供SaaS化的服务。
环境：
响应多个业务部门，大量的精力耗散于不同部门之间的沟通协调。因为接下来的解决方案，是要服务于多个业务。需要看到不同需求之间的共性需求，并提炼出一个产品化的解决方案
中台落地：
1、通用
标准统一，实现数据打通、可通用性。数据打通是需要整合企业内部被“部门墙”割裂的数据。
2、组件化
中台提供的服务最好以组件化的方式让业务端可以即取即用。组件化设计可以避免系统间耦合性大，牵一发而动全身。这需要针对共用服务进行抽象设计。通过抽象出的组件化服务提供，前台业务端可以以组合挑选的方式“按需取件”，减少重复建设得以实现。
3、可复用
中台提供的服务是应该可以即取即用的。不仅如此，这次用完，下次还来。业务A用了，业务B也来用。一个中台提供出的公用服务的价值高低，是“可用”和“可复用”的区别。
4、可共用
基础服务有了，那通过中台向前台提供“相应的服务”还是提供“一揽子的服务”？取决于服务提供的可开放共用的程度。就像我们看到，各大互联网决定中台建设的开始，总是要伴随企业层级的组织架构的调整。虽然各部门权限、各业务属权，恐怕不是一句“开放共享”的愿景就能完全解决和无差别共用的，但是通过开放共享实现“可共用”的目标终究是中台建设的原则。
5、灵活扩展
在一揽子的服务都可输出后，业务量可能会短时间大大激增。能扛得住大流量高峰时期的高并发、高可用将成为一个大挑战。底层的可灵活扩展能力将非常重要。企业应当应用DevOps、Docker等先进的开发技术理念，在中台建设前就开启数字化的技术转型。
中台完整的体系：
第一层：无数碎片化的、场景化的前台业务应用，如零售、采购、招聘、报销...
第二层：业务中台，如零售中台、人力中台、财务中台....
第三层：数据中台：主数据（画像标签/关系图谱）、数据模型、人工智能业务算法
第四层：后台应用：如被分解后剩下的单一企业内部超稳定的收敛的应用
第五层：应用平台：协同平台（工作流引擎/消息引擎等）、应用组件（聚合支付/电子发票/电子合同/自动报税等等）、集成开发平台/定制开发平台/实施平台/运维平台
第六层：技术平台：微服务中间件、SQL/NOSQL数据库、大数据技术平台（如Hadoop和Spark）、AI技术引擎、云IaaS平台
中台技术本质：
在软件开发领域，有专门的名称，叫做“重复造轮子”和“烟囱式架构”。企业在发展过程当中，为了解决当下的业务问题，快速上线了很多功能，而欠下了许多技术债，当企业进入成熟期之后，发现这些问题的存在，严重影响了企业的运行效率和运营成本。
中台技术架构：
1、UI交互层：Windows UI、PC Web UI、移动App UI、微信小程序UI、摄像头视觉识别人机界面、语音交互人机界面
2、逻辑层：面向对象技术/组件技术/SOA服务中间件/微服务中间件技术、人工智能NLP/机器学习
3、数据层：SQL数据库/NOSQL数据库、大数据计算平台/数据仓库数据湖/可视化
4、基础设施层：云计算IaaS（服务器、存储、网络、文件系统）
PS:虽然业务中台，根本不是在这个分层视角维度体系来看事的。不过话说回来，中台应用要具体代码实现，还得依赖这些具体的技术。这就是他们俩之间的关系。
遥望未来10年—AI中台：
未来的应用是：产业互联网、社会化商业，到处连接；我们讲了未来的技术是：人工智能最佳算法调度，而非写死的业务逻辑规则代码，阿里云都成立十周年了，应用了10年的云计算。
云技术上半场是：
1、UI层：移动App、微信小程序
2、逻辑层：分布式微服务、分布式消息中间件
3、数据层：分布式关系数据库、分布式NOSQL数据库
4、数据层：实时大数据计算平台
5、基础设施层：虚拟化、容器
云技术下半场应该是：
1、UI层：IoT智能硬件传感器、麦克风语音交互、摄像头视觉识别
2、逻辑层：人工智能关联推荐&最佳资源调度
3、数据层：跨链区块链
4、基础设施层：量子计算
数据输入：
采集数据：
智能硬件传感器收集
摄像头视觉识别收集
麦克风语音交互收集
互联网爬虫收集
互联网OpenAPI来收集
PS:未来也不是在逻辑技术层写死业务规则逻辑代码，而是设计好模型、触发消息，通过人工智能最佳调度算法自动调整模型、自动设置阈值来触发逻辑规则条件发生。所以，中台应用逻辑是活的，是大数据训练的人工智能智能执行的。
AI 中台主要成分：
中台与平台的区别：
中台和平台都是某种共性能力，区分两者的重点一是看是否具备业务属性，二是看是否是一种组织。中台是支持多个前台业务且具备业务属性的共性能力组织，平台是支持多个前台或中台业务且不具备业务属性的共性能力。
中台是动态变化的，是数据驱动不断训练调整人工智能业务算法和业务模型的。平台是静态的，一旦版本发布，不管你是今年调用这个功能，还是明年调用这个功能，出来的效果是一样的
业务中台
背景：
企业级业务架构设计来实现组件化开发也是企业数字化转型的优选路径，是弥合业务与技术之间“数字鸿沟”的有效手段。
举例：
阿里从 2009 年建立共享事业部开始，几经曲折，但是一直在积累，直到 2015 年正式发展成中台战略。大型架构、好的架构都不是一蹴而就的设计，是根据实践不断磨合调整得来的。阿里的中台大约有十几个共享业务单元，包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的，共享业务单元则由阿里云平台支持。共享业务单元的划分原则其实不是可以简单掌握的，要综合考量设计、运营和工程因素，尽可能遵循“高内聚、低耦合”、“数据完整”、“业务可运营”和“渐进”的原则。阿里在划分中台时非常重视其业务价值和基于业务的设计，而且有业务架构岗位，每个共享单元都有业务架构师。但总体来讲，其业务架构仍然是领域性的
阿里系统要解决的核心问题是高并发、可扩展，也就是说，规模带来的复杂度对阿里而言更具挑战性。因此，业务通过中台进行共享支持后，基础设施必须能够消解这种压力。阿里采用去中心（也就是去 ESB）的 HSF 分布式服务框架，以支持服务的点对点调用，解决 ESB 可能产生的瓶颈问题；采用微服务设计方式，提高变化响应，并通过大力推行 DDD（领域驱动开发）设计模式，提升设计效率；自研设计了分布式数据层框架 TDDL（Taobao Distributed Data Layer，又称“头都大了”）以及分布式数据库 DRDS；研发了支持分布式事务处理的 AliWare TXC；支持高效故障定位和运维监控的鹰眼平台；实现了限流和优雅降级设计，以及做保障的全链路压测平台、业务一致性平台等。这是一套完整的基础设施，提供针对电商业务特点的支持。
总结：
阿里中台是其自身在业务不断发展的过程中演进和磨合出的架构，其架构即体现了电商的业务特色，也包含了完整的技术支持体系。由于其灵活支持和快速响应能力，成为了互联网架构的优秀实践案例和设计标杆。也正因如此，目前很多人提到“中台战略”基本上就会想到阿里，毕竟他们是主打这张“牌”的。
业务中台&数据中台：
1 职能上
业务中台，更多是业务支持，比如客户中心，平台、身份、验证，这些统一的东西来自一个地方，分别支持多个系统对业务的管理要求，不同系统开发的时候，可以直接从这里获取这个功能，而不需要再开发，从而把更多的系统连接在一起。
数据中台，利用获取的各类信息、行为习惯信息和算法，获取分析结果，比如业务中台参照的客户标准和分类方法就是基于数据中台运算的分析结果，例如需求偏好（客户标签）。
数据中台的数据来自业务系统，有原始数据（不同频次的历史快照+实时数据）、共享数据（拉到一起）、萃取数据（已经整理的标准化数据、标签、模型），再反哺给业务中台用起来。以精准营销为例，数据中台支持算法，业务中台基于算法的结果，支撑实时推荐。
2 内容上
业务中心只能知道当前状态，数据中心包含当前、历史、处理数据。比如淘宝、天猫和支付宝，统一的用户中心数据库放在业务中台，登录、查询、修改都在此。
而业务的数据，会同步到数据中心，数据中心会保留所有变更记录，类似于数仓的历史快照再往上还会有算法模型和统计数据。
3 目的上
业务中台更像一个功能模块，而不是数据库，目的是让业务更专注业务，业务中台的数据服务中心和业务联系紧密，实时做支持，更极致一些。
数据中台的初衷是为了让数据沉淀下来，产生价值，所有业务系统的数据，各业务触点的信息，会流向数据中台，解决企业数据孤岛的现象，达成信息共享。
4 业务系统和两个中台的关系
业务中台使得任何一条业务线都具备整个公司的核心能力。
中台不影响原业务的管理流程和管理办法，业务系统生产数据库还保持在用，只是根据情况，把业务数据同步到两个中台，共性的放到数据中台。
对于有一定信息化基础的传统企业来说，各个系统，只要把共性和个性的部分做个拆分，把共性的汇聚到一起，打通起来，就相当于业务中台完成大半了，实现难度反而比数据中台重新搭建来得比较小。
5 对中台意义的理解
从技术角度，做中台是为了搭建一个灵活快速应对变化的架构，更快实现前端提的需求，避免高度复用的功能重复建设，这是敏捷开发、提高效率的地方。
从业务角度，借助中台沉淀能力，可以支持快速创新，让研发更灵活，业务更敏捷，以应对未来不可预知的市场变化。退一万步讲，有些功能其他业务板块已经做好了，那么底层只要组合一下即可，更加灵活和快速。
业务中台&大数据：
大数据的下半场争夺核心是场景。基于业务中台，实现场景内数据闭环，成为竞争的关键。新业务方式，数据为业务系统核心，基于技术中台的能力，将企业内外部数据打通形成数据中台，由数据中台驱动业务中台，并利用业务中台的组件重构业务系统。由于有中台的支撑，各类开放服务可以对前端应用的快速变化做出响应，因此商业价值会更高。
基于场景的数据闭环会越来越重要
单一场景的数据中台驱动形成业务中台，由业务中台支持业务场景落地，而业务场景又会不断反馈数据给到数据中台，整个流程会实现数据闭环，循环往复，最终会使得业务更加智能化。场景本身会产生数据，这些数据应用在场景内不会受到限制。例如微信生态内的用户个人数据非常敏感，但基于微信数据，提供微信生态内的个性化广告、个性化服务的业务，数据本身不出场景，不受到太大限制。场景内产生的数据价值未来一定会超过外部数据。场景中产生的是正在发生的“热数据”、“活数据”，用户在使用Google、百度等搜索引擎时，在搜索结果页上的每一次点击（或者翻页）都会作为行为数据被记录下来，这些数据才能真实反映用户当前在这个场景的偏好。场景内产生的数据，一定会是最适合场景本身需求，场景内形成的反馈闭环，能够帮助算法持续迭代和产品的关键突破，使用户体验不断突破边界。场景的价值度在逐步提升，这一过程中，能够将场景理解沉淀，同时形成反馈闭环的，一定是业务中台，因此，业务中台是构建场景壁垒的第一个核心因素。数据智能公司能够不断沉淀对场景的理解能力，建立自身的护城河。
举例：
美团为例，美团的超级大脑指挥调度着60万送外卖小哥的行动，高峰期一个小时要处理29亿次订单派遣，每天要处理2000万个订单，整个流程完全是基于数据驱动，由系统自动去运转
京东超过70%的商品采购都是机器推荐的，京东自营商品已超过2600万种，只有通过数据形成业务中台才能够实现商品采购，不可能依靠业务人员去完成。
从价值度的角度来看，业务中台能够覆盖场景的全流程，解决全场景问题，实现技术赋能，按照效果进行收费，价值度最高。
【尝试三句话说清楚】
1、业务中台的核心是通过“服务复用”，构建“大中台，小前端”来满足快速发放业务的市场需求，比如“聚划算”团购平台在投入10多个人开发1个半月就上线，速度远超过其他电商平台从零开始的模式。
2、业务中台沉淀了信息数据，为基于大数据挖掘新的商业模式奠定了基础，比如蚂蚁金服基于普通人消费行为为金融机构做的征信系统。
3、业务中台作为服务提供者，不需要“业务稳定”，需要不停地提供新的业务支持。
彩蛋：
滴滴出行构建业务中台的原因及在过程中遇到的问题和应对的策略
构建业务中台的原因
2015年末，滴滴出行在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。滴滴启动了中台战略整合业务系统。决定构建业务中台主要出于四方面考虑：专业深度、人力资源、用户体验、全局打通
专业深度。由于是多业务垂直化的架构，会有多个团队开发同样的架构，这就需要很多的工程师。每个团队都是用最快速的方式构建流程，所以技术很难做深。这样一来，导致客户端的流畅度不高，后端不稳定，影响可扩展性。
人力资源。原则上来说把每个团队加到足够的人，每个架构都能有很好的发展。但工程师的薪资都非常高，招聘大量工程师来做同样的架构，研发成本高昂。很还有些时候，愿意花钱，却招聘不到合适的人。
用户体验。流畅度、稳定性、扩展性、界面、交易流程等都是影响用户体验的重要因素。在当时的组织结构和研发情况下，会出现业务的颜色各异，交易流程却相同的问题，很影响用户的体验。
全局打通。所有业务本质都是出行，出行本质有协同效应。但在各自独立发展情况下，协同性就完全没有，在构建中台过程中，可以逐步把协同性加起来。
构建出行业务中台在软件复杂度上的挑战
构建出行业务中台并不是只有好处，也一定会带来很多问题，最大的问题是软件复杂度。
从业务角度来说，把所有业务合并到一个体系下，本身就是很难的事，再加上滴滴出行是实时性O2O业务，场景差异很大，而且作为互联网公司，不仅很多需求不明确，还会持续变化。这种情况下，想要用一套相对稳定、相对固定的架构去支持所有业务，十分困难。
从组织角度来说，滴滴出行有多个事业部，业务涉及400多个城市，组织和个人的变化更快。
针对软件复杂度的挑战，中台的目标是：在业务多元化发展的组织中，去构建一套工程架构，构建一套组织结构及对应的管理机制，以保证业务可持续的又快又好的发”。
攻破软件复杂度问题的具体对策与实践
在谈具体对策与实践之前，先来看看整个业务中台的架构设计，如下图。
整个的架构设计分几个边界的上下文，好处在于把相关性不强的逻辑拆开，同时在一个相关性下面，通过分层可以去把业务进行更好的建模。调度层做为入口去牵引多个业务线，业务流程层为调度层做服务，状态智能层用来支持上面两层。
在对业务和产品进行更好建模的基础上，进行“五化”：服务化、异步化、配置化、插件化、数据化。
服务化。服务化很常见，以下单为例，如下图：
下单流程能够调用很多服务，在多个层次，以接口层次结果拆解。这里需要提醒的是服务化要注意如下三点：
? 服务之间的协议和规范要建立好。
? 注意控制力度，力度太小、太大都会有问题。
? 随着时间的发展，服务化本身要不断的演进。
异步化。对每个事件的非核心或不需要实时反馈给客户端的逻辑进行拆解，核心的主流程会变简洁。对非核心的逻辑在事件上做订阅之后，进行二级处理。以结束订单为例，如下图
结束订单的时候有很多逻辑要做，但是都是通过MysqlBinlog处理或MQ处理。
配置化。服务化和异步化能解决很多迭代效率的问题，但由于系统、业务的复杂性，各个业务都有些差异，体现在不同的产品线、城市、区域、时间等等，配置化核心是对这些进行建模，把每个对象模型化，抽象成ID，在不同的服务化里把这些可配置的能力进行抽象。具体抽象过程，如下图。
第一级抽象采用是类 iptables 的规则引擎判定产品分类，第二级的规则引擎，由模块自定义。所有配置化都是用自生成平台，要配置什么，自定义配置即可，这个过程是动态进行的。当前业务中台已经可以支持上千个配置点，比如不同层次的计价规则不一样、不同产品线的车样子不同、不同的场景，如拼车和接送机，管控规则也不一样等等。
插件化。配置化解决的是业务线差异问题，但遇到逻辑差异较大的情况，就要做插件，统称为FPI。
在FPI的能力上，不同的团队可以开发很多插件，在特定的配置点下，把它的逻辑去进行加载。真正业务流程到这儿，可以调起它对应的插件做出来。对于一些没有差异化需求的业务，可以用开发的default逻辑，这是更极端的灵活性的体现。
有灵活性的体现后，团队还可以做一些组织上的调整，原来看起来，每个服务或者平台是一个垂直化的架构，有些团队是横向，是FT，有些FT是接送机FT，专门做接送机的事情。
通过插件的形式在每个系统加载它的插件，它就可以跟着业务思考、跟着产品思考这个业务怎么走、这个产品怎么演化。相对的逻辑是更加专注的，这也带来很好的组织结构对中台的适应性。
数据化。在大数据时代，数据是不得不考虑的问题，所以在业务中台，要实现全局打通，本质是要把数据打通。所以制定了离线分析与在线决策的方案，如下图。
第一个是离线做分析，可以做数据血缘、模型训练，同时可以把它放到在线决策层面，构建很好的智能客户引擎和交易引擎，这个可以干预，因为干预可以让升舱或者多业务线的清单成为可能。因为有这样的决策，使在线服务的管控和判决做得更加智能。
数据化方面，需要注意三方面：
? 让数据更加规范和标准化。
? 构建完整的数据流，从在线到离线，从日志到模型的在线使用。
? 引入机器学习的算法、人工智能的算法去构建在线数据智能的决策。
这是业务中台的五个对策，主要解决传统的系统架构问题，怎么做到高耦合和内聚，怎么提高迭代。配置化和插件化解决灵活性问题，把灵活性开放给不同团队。数据化实际上是中台赋能业务，有中台的赋能才能变得更好。
经验总结
第一点：从最大的业务孵化中台是滴滴出行构建业务中台最大经验，因为最大的业务最复杂，把最复杂的业务搞定，用最复杂的业务落地别的业务会容易。从快车开始做，逐步整合专车、出租车、代驾等。
第二点：稳定，中台对业务有收益，最根本的是保证稳定，稳定是发展的前提和基础。在整个构建中台的过程中非常重视稳定性，有各种机制，包括灰度发布、分层次发布、流量回放、全链路压测等等，保证代码的质量和系统的稳定。
第三点：加强沟通，平衡多业务的优先级。滴滴出行有多个业务，有很多大区和城市，每个地方都有很多需求，要有一套机制和资源池，如何保证相应每个业务都能按照所对应的在公司的重要性的部分资源，要保障它的灵活性和效率，所以要有很多沟通工作，有很多平衡的工作。
第四点：中台系统要不断演进，不能一层不变，要发现问题、解决问题。业务中台不是一蹴而就，而是要在发展过程中不断的变化，持续迭代。
第五点： “没有最好，只有最合适”！所有中台都一定是适合某个公司特点，最合适的中台是当你深入了解业务、产品、系统、组织，而且不仅了解今天在哪里，还要了解过去是怎么演变而来，未来又会怎么演化。只有当了解所有的东西之后，才能做出最好的中台架构的设计。
标签：来源 nbsp 离线 锁定 连接 二层 用户命令 搜索结果 标准化
原文地址：https://www.cnblogs.com/Jenaral/p/11403407.html
