前几天才看完《中台战略-中台建设与数字商业》一书，就发现书作者参与的项目交付延期严重，对业务方的许多承诺无法兑现而被吐槽--中台，我信了你的邪 | 深氪。对于中台这个蜜汁概念，今天就综合各方说法理一理，摸个概念。
1. 中台起源
1.1 什么是前后台
前台很好理解，指的是面向 C 端的应用，包括前端 (如 App/ 小程序) 和对应的服务端。 至于后台，很多人把它等同于管理后台，比如商品管理后台，负责商品定义/上下架等，提供给内部运营人员使用，这可能不够准确。----深入浅出话中台
前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机 App，微信公众号等都属于前台范畴。 后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据 + 计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。----白话中台战略（一）：中台是个什么鬼？
前台，指的是面向C端的应用，包括前端和提供API接口服务的后端。
后台，指的是面向管理、运营的系统，包括CRM、ERP、OA以及基础设施和计算资源。
1.2 前后台和前后端的关系
前后台都涉及UI与接口调用，所以要建设前后台，必须同时用到前后端。
1.3 为什么要有中台
架构好比生产关系，业务是生产力，架构一定要随着业务发展而演化。0到1阶段，只有一条业务线，比如出租车业务，直接根据需求实现即可。从 1 到 n 阶段，业务线逐渐增加，比如快车 / 顺风车。这时系统有两种做法。
第一种是新业务线还是单独实现，多个业务线之家是相互独立的，系统结构整体上是”川”字型，如下图所示。但如果业务线类似，它们的核心逻辑（地图 / 调度 / 订单支付）也是类似的，子系统之间有大量的代码复制和多地维护，这是非常低效的。
第二种做法是把核心逻辑单独抽取出来，做好通用化，共同服务于所有业务线的需求，此时对于各个业务线系统而言，包括自身的应用层和通用层两部分，定制的东西在应用层解决，共享的东西由通用层提供，再通过编排共享逻辑完成业务流程。系统结构整体上是”山”字型，这个通用层就是山字最底下一横，把各个业务线有机粘合在一起，共享业务逻辑和统一业务规则，实现最大程度的复用。----深入浅出话中台
在简单场景下，前台应用包含这部分功能，在复杂的场景下，就有必要把这部分独立出来，构成独立的中台，为前台减负。
从业务角度看，中台代表通用的基础业务，一个企业基础的业务能力和业务规则是相对稳固和清晰的，各个业务线可以认为具体业务场景，如小程序下单 / 三方外卖等相对复杂和多变，但可以通过组装各个基础业务，快速满足业务场景需求。对于新的业务来说，基础的东西已经差不多有了，只需要少量针对场景的定制开发。总的来说，中台收敛了业务场景，统一了业务规则，比如各个渠道的订单都归到中台的订单服务，遵循类似的订单状态流转和履单过程。
基础业务是有限的，业务场景是无限的，特别是在移动互联网和全面数字化转型的大背景下，传统企业需要开拓大量新渠道，搭建中台，可以很好地通过有限的基础业务满足无限的业务场景。
从系统角度看，中台相当于商业操作系统，提供标准接口给上层应用，对于传统企业来说，中台之下还有明确的后台，中台很好地把前端应用 (面向互联网) 和企业遗留系统 (面向内部管理) 衔接起来，屏蔽底层系统的复杂性和各种适配工作。
从数据角度看，中台收敛业务场景的同时，也收敛了数据 比如自有小程序的订单和外卖订单统一到一个订单库，使用同一套数据模型（具体用到的字段可能略有差异），这为后续的数据中台搭建打下良好基础。----深入浅出话中台
中台强调通用的基础业务，搭建中台可以：
- 抽象前台通用组件，满足多种业务场景；
- 屏蔽后台系统复杂性（前后台存在交互行为，例如计算资源等），快速响应业务需求；
- 解决数据烟囱问题，共享同一套数据模型；
2. 中台架构
整个架构从上到下分 4 层：
渠道 & 应用： 这是整个系统对外部分，包括各个应用的前端，如 APP/ 小程序 / 公众号, 这些是需要定制部分。同时提供 Open API，对外部企业输出业务能力。
应用平台：应用平台是各个实际应用的母体，首先包含各个应用的服务端，比如小程序服务端 /APP 服务端，这些服务端针对具体场景，做流程编排和信息的聚合。 还有各个比较独立的应用模块，如搜索 / 推荐 / 评论 / 拼团，这些模块不强调各个业务线之间共享，只是作为独立模块从服务端剥离出来，方便维护。 还有一些相对简单服务，不属于基础共享业务范畴，比如和具体某个业务相关的配置数据，也通过服务的方式封装。 网关实现前后端隔离，包括外部访问的安全验证和监控，以及内部路由和消息格式转换。
业务中台：由一系列的通用基础服务构成，这些基础服务边界清晰，相互独立，没有调用关系。有些业务场景需要跨服务的数据，比如下单，需要同时涉及商品服务 / 库存服务 / 订单服务，一般在基础服务之上有一层聚合服务，通过组合这些基础服务，形成更大粒度的功能接口，供应用平台调用。 中台最底下是技术中间件，包括消息推送，短信邮件，数据访问等，稳定性主要由这部分保证。
后台：包括两部分，适配插件用于连接商户内部系统和中台基础服务，比如在中台商品服务和后台 ERP 之间同步商品和库存数据，在会员服务和 CRM 之间同步会员信息。一般针对每个内部系统有一个适配插件，适配插件起到类似硬件驱动程序的作用，这个定制化程度比较高。 商户内部系统就不展开，各个企业的情况不同。 架构图最右边是三方 API 对接，典型的如微信 / 支付宝的对接，美团 / 饿了吗三方外卖对接，天猫/京东的电商平台对接。这个对接前端 / 应用平台 / 中台都会涉及。----深入浅出话中台
对于中台类型细分，可以分为业务中台、数据中台、算法中台、AI中台等。
“将企业的核心能力随着业务不断发展以数字化形式沉淀到平 台，形成以服务为中心，由业务中台和数据中台构建起数据闭 环运转的运营体系，供企业更高效的进行业务探索和创新,实现 以数字化资产的形态构建企业核心差异化竞争力。” ——阿里巴巴Aliware团队 ----企业核心业务数字化转型最佳实践
2.1 业务中台
----企业核心业务数字化转型最佳实践
业务中台更多关注的是如何支撑在线业务，典型的业务中台由多个业务服务中心组成。
2.1.1 业务中台与微服务区别
我认为中台是微服务的升级，原来只是一个个离散的服务，只负责提供接口功能，如商品服务 / 订单服务 / 权限服务，在中台里，升级为商品中心 / 订单中心，每个中心更强调体系，包括更好的边界划分和业务抽象，更好地监控和系统运营能力 (稳定性 / 故障定位)，更好的业务运营能力 (比如商品中心自带商品管理后台，支持基础商品定义)。每个服务中心围绕核心业务，自成体系，成为一个微内核，这些微内核既相互独立，又形成一个整体，共同构成基础业务平台，也即中台。松散的微服务 -> 共享服务体系 -> 中台，这是微服务架构和中台的区别和联系。----深入浅出话中台
2.2 数据中台
数据中台是一个用技术连接大数据计算存储能力，用业务连接数据应用场景能力的平台。 中台战略--中台建设与数字商业
2.2.1 数据中台三大能力
- OneData：致力于统一数据标准，让数据成为资产而非成本
- OneEntity：致力于统一实体，让数据融通而非以孤岛存在
- OneService：致力于统一数据服务，让数据复用而非复制。
2.2.2 数据中台技术领域
2.2.3 数据中台产品化服务
2.3 业务中台与数据中台的关系
业务中台抽象、包装和整合后台资源，转化为便于前台使用的可重用、可共享的核心能力，实现里后端业务资源到前台易用能力的专户，为前台应用提供了强大的“炮火支援”能力。 数据中台接入业务中台、后台和其他第三方数据，完成海量数据的存储、清洗、计算、汇总等，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。可以任务，数据中台为前台战场提供了强大的“雷达监测”能力，实时掌控战场情况，料敌先机。----中台战略--中台建设与数字商业
