| 这两年中台很火，已经代替微服务成为架构首选，涌现出各类各样的中台名词，业务中台、数据中台、技术中台、算法中台等，让人眼花缭乱，稍微大点的互联网公司都号称在作中台。本人从去年开始，作过相似的事情，这里结合本身的实践，谈谈对中台的理解，但愿可以帮助你们更清晰地了解中台，一家之言，仅供参考。前端 本文的内容包括：算法 1.什么是中台小程序 2.中台和微服务的区别后端 4.为何要作中台安全 4.深刻中台架构微信 1. 什么是中台架构 既然讲中台，必然还有前台和后台。前台很好理解，指的是面向 C 端的应用，包括前端 (如 App/ 小程序) 和对应的服务端。至于后台，不少人把它等同于管理后台，好比商品管理后台，负责商品定义 / 上下架等，提供给内部运营人员使用，这可能不够准确。分布式 简单来讲，对于一个交易系统，前台对应用户能看到的部分，如商品浏览和下单，属于接单的部分；后台对应履单部分，如仓库拣货 / 配送 / 财务结算 / 采购补货等，属于实际干活的，由企业内部人员负责，处于一个交易处理流程的后端。微服务 在传统企业，没有在线的前台，基本是线下手工接单，内部信息管理系统基本都属于履单范畴，例如 ERP、CRM、采购系统、仓库管理系统，财务系统等，这些系统属于通常意义上的后台概念。spa 在互联网企业，由于系统通常是本身开发，管理后台既包含面向前台销售的功能，如商品上下架和促销管理，也包含面向履单部分，好比配送、采购、财务结算，因此互联网企业的管理后台并不简单等同于履单后台。 接单和履单之间还有一系列事情要作，包括生成订单时的优惠计算 / 建立实际的订单 / 支付 / 库存扣减等, 这部分功能属于交易逻辑的核心。在简单场景下，前台应用包含这部分功能，在复杂的场景下，就有必要把这部分独立出来，构成独立的中台，为前台减负。 一些文章笼统地介绍中台是用来链接前台和后台的，这个值得商榷。若是管理后台就是后台，那没有链接的必要，由于管理后台自己就是系统的附属部分，和前台属于一体两面。至于履单后台，前台接单系统和后台履单系统设计时就是打通的，也不须要额外定义一个中台来链接二者。互联网企业的中台更多的是基础业务下沉，实现多业务场景共享，但在传统企业，后台系统清晰地存在，中台确实起到链接后台 (内部老系统) 和前台 (新的 C 端应用) 的做用，因此互联网企业的中台和传统企业的中台定位和侧重点是有差别的，这个下文会展开介绍。 为了更好地理解中台，这里举个形象的例子： 
最上面是各类具体的桌面应用，好比 office 套件，最底下是各类硬件设备，磁盘 / 内存 /CPU 等。 桌面应用能不能直接操纵底层硬件设备完成功能？理论上是能够的，好比在应用里嵌入汇编语言直接操做硬件，但显然开发效率低，可维护性不好。若是中间加一层操做系统进行转换，向下管理硬件，向上提供简洁的 API，应用开发就很是方便，这里操做系统相似中台的定位。 对于大型传统零售企业 (上图右边部分)，企业通过多年信息化建设，购买了大量的商业套装软件，造成内部 IT 基础设施，如今要往新零售转型，理论上 C 端的应用能够直接调用老系统的 API(如 SAP 产品提供必定的开放能力) 来实现功能打通。但和桌面应用直接控制电脑硬件设备相似，这二者直接对接是低效的，二者的服务对象 (2C 和 2B)/ 数据模型 / 技术栈 / 实时性要求差别很大，并且新的应用进来，又要从头至尾对接一遍，新业务上线，至少须要大半年的时间。 这时若是有个中间层负责桥接和转换，就很是方便。C 端应用能够快速基于这个中间层构建，不用关心底层遗留系统的实现细节。这个中间层就是中台，起到相似操做系统的做用，把旧的基础设施转换成面向互联网的基础平台，并且这个平台很是通用，新业务能够快速对接，短期搞定上线。传统企业在作全面数字化转型时，这样的一个中台必不可少。 2. 中台和微服务的区别 中台源于大型互联网企业，这些系统通常是分布式的微服务架构，那么中台和微服务架构有什么区别呢？ 简单地说，我认为中台是微服务的升级，原来只是一个个离散的服务，只负责提供接口功能，如商品服务 / 订单服务 / 权限服务，在中台里，升级为商品中心 / 订单中心，每一个中心更强调体系，包括更好的边界划分和业务抽象，更好地监控和系统运营能力 (稳定性 / 故障定位)，更好的业务运营能力 (好比商品中心自带商品管理后台，支持基础商品定义)。每一个服务中心围绕核心业务，自成体系，成为一个微内核，这些微内核既相互独立，又造成一个总体，共同构成基础业务平台，也即中台。松散的微服务 -> 共享服务体系 -> 中台，这是微服务架构和中台的区别和联系。 如今你们谈的最多的是业务中台，我认为一个典型的业务中台包含 3 层：
对于中台来讲，完善的基础业务功能由通用基础业务平台实现；通用聚合服务进一步提高易用性 ; 通用中间件平台保证系统的稳定性。 除了业务中台，提的比较多的是数据中台，数据中台也是整合数据能力，能够高效地给业务赋能，好比智能推荐，千人千面，精准营销等。 补充说明下，这里通用中间件平台和技术中台一个概念，我以为没有必要单独叫技术中台，不带业务的中台是没有灵魂的，不能叫中台。同理内容中台的说法是合适的，但算法中台就不合适，你们能够用这个原则区分各类中台的真伪。 3. 为何要作中台 软件架构从单体架构，到分布式 SOA，到微服务，到中台架构，这都是业务复杂化的结果，架构比如生产关系，业务是生产力，架构必定要随着业务发展而演化。 0 到 1 阶段，只有一条业务线，好比出租车业务，直接根据需求实现便可。从 1 到 n 阶段，业务线逐渐增长，好比快车 / 顺风车。 这时系统有两种作法，第一种是新业务线仍是单独实现，多个业务线之家是相互独立的，系统结构总体上是”川”字型，以下图所示。但若是业务线相似，它们的核心逻辑（地图 / 调度 / 订单支付）也是相似的，子系统之间有大量的代码复制和多地维护，这是很是低效的。 第二种作法是把核心逻辑单独抽取出来，作好通用化，共同服务于全部业务线的需求，此时对于各个业务线系统而言，包括自身的应用层和通用层两部分，定制的东西在应用层解决，共享的东西由通用层提供，再经过编排共享逻辑完成业务流程。系统结构总体上是”山”字型，这个通用层就是山字最底下一横，把各个业务线有机粘合在一块儿，共享业务逻辑和统一业务规则，实现最大程度的复用。 固然搭建山字形是有难度的，何时转型为“山”字形？ 一方面和 n 值有关，好比 n>=3 时，应该要考虑转到山字形，另外一个因素和各个业务线的类似度有关，类似度高更适合”山”字形，好比电商的 C2C 和 B2C 业务；差别比较大，适合”川”字形，好比电商业务和互联网金融业务，不必强行扭在一块儿。
从业务角度看，中台表明通用的基础业务，一个企业基础的业务能力和业务规则是相对稳固和清晰的，各个业务线能够认为具体业务场景，如小程序下单 / 三方外卖等相对复杂和多变，但能够经过组装各个基础业务，快速知足业务场景需求。对于新的业务来讲，基础的东西已经差很少有了，只须要少许针对场景的定制开发。总的来讲，中台收敛了业务场景，统一了业务规则，好比各个渠道的订单都归到中台的订单服务，遵循相似的订单状态流转和履单过程。 基础业务是有限的，业务场景是无限的，特别是在移动互联网和全面数字化转型的大背景下，传统企业须要开拓大量新渠道，搭建中台，能够很好地经过有限的基础业务知足无限的业务场景。 从系统角度看，中台至关于商业操做系统，提供标准接口给上层应用，对于传统企业来讲，中台之下还有明确的后台，中台很好地把前端应用 (面向互联网) 和企业遗留系统 (面向内部管理) 衔接起来，屏蔽底层系统的复杂性和各类适配工做。 从数据角度看，中台收敛业务场景的同时，也收敛了数据 好比自有小程序的订单和外卖订单统一到一个订单库，使用同一套数据模型（具体用到的字段可能略有差别），这为后续的数据中台搭建打下良好基础。 4. 深刻中台架构 大一点的互联网企业，系统已是类中台的“山”字型架构，更多的是局部强化和整合。对于传统企业来讲，系统基本是”川”字型，大量相互独立的商业套件组成遗留系统。如何基于这些系统搭建中台挑战很大，因此这里更多剖析传统企业的中台架构。 下图是比较典型的传统企业中台架构：
整个架构从上到下分 4 层： 渠道 & 应用 这是整个系统对外部分，包括各个应用的前端，如 APP/ 小程序 / 公众号, 这些是须要定制部分。同时提供 Open API，对外部企业输出业务能力。 应用平台 应用平台是各个实际应用的母体，首先包含各个应用的服务端，好比小程序服务端 /APP 服务端，这些服务端针对具体场景，作流程编排和信息的聚合。 还有各个比较独立的应用模块，如搜索 / 推荐 / 评论 / 拼团，这些模块不强调各个业务线之间共享，只是做为独立模块从服务端剥离出来，方便维护。 还有一些相对简单服务，不属于基础共享业务范畴，好比和具体某个业务相关的配置数据，也经过服务的方式封装。 网关实现先后端隔离，包括外部访问的安全验证和监控，以及内部路由和消息格式转换。 业务中台 由一系列的通用基础服务构成，这些基础服务边界清晰，相互独立，没有调用关系。有些业务场景须要跨服务的数据，好比下单，须要同时涉及商品服务 / 库存服务 / 订单服务，通常在基础服务之上有一层聚合服务，经过组合这些基础服务，造成更大粒度的功能接口，供应用平台调用。 中台最底下是技术中间件，包括消息推送，短信邮件，数据访问等，稳定性主要由这部分保证。 后台 包括两部分，适配插件用于链接商户内部系统和中台基础服务，好比在中台商品服务和后台 ERP 之间同步商品和库存数据，在会员服务和 CRM 之间同步会员信息。通常针对每一个内部系统有一个适配插件，适配插件起到相似硬件驱动程序的做用，这个定制化程度比较高。 商户内部系统就不展开，各个企业的状况不一样。 架构图最右边是三方 API 对接，典型的如微信 / 支付宝的对接，美团 / 饿了吗三方外卖对接，天猫 / 京东的电商平台对接。这个对接前端 / 应用平台 / 中台都会涉及。 5. 总结 架构向中台转型是业务复杂化发展的必然结果，中台提供了多方面的价值，无论互联网企业仍是传统企业，中台的大方向都是没错的。 对于互联网企业，有基础，往中台靠是改良，须要注意的是，根据当前的业务发展阶段，平衡投入和产生比，适时启动中台改造。 对于传统企业，内部 IT 基础设施和面向互联网的应用差别很大，往中台转是革命性动做。如何落地中台战略既须要顶层思考，又须要结合实际，作各类平衡和妥协。作的很差，效果拔苗助长，所谓不作中台等死，作中台立刻死，从这个意义上说，是否上中台，有点相似十几年前上大型 ERP，须要务实的评估，拒绝形式主义。 |