中台技术-阿里巴巴中台探索

2015年阿里巴巴集团启动了中台战略，目标是要构建符合互联网大数据时代的，具有创新性、灵活性的“大中台、小前台”的机制，即作为前台的一线业务会更敏捷、更快速的适用瞬息万变的市场，而中台将集合整个集团的运营数据能力，产品技术能力，对各前台业务形成强有力的支撑。

一 阿里启动中台战略缘由

1.1 企业信息中心发展的症结

“烟囱式”系统建设模式

当业务部门提出业务需求，信息中心部门进行系统集成商的招投标，再进入到需求收集、需求分析、开发、测试、上线的项目周期中。某种程度上，每个新系统的上线都预示着一座新的烟囱矗立而成。这种完全基于业务需求建设系统的方式，已经成为过去20多年企业建设IT系统的标准流程，导致IT系统建设早的企业内部系统烟囱林立。这正是今天很多企业面临互联网转型难的根结所在。

项目制的系统建设模式除了带来“烟囱式”建设的一系列弊端，同时使得IT信息化部门一直处于“业务支持”的职能位置，即只为了满足业务部门需求而进行IT系统建设的实施和运维部门。当一个项目顺利上线验收后，这些员工开始投入到下一个项目的工作中。因此，其结果是，员工增长了项目经验，但并不能在某一专业领域得到了知识和经验的沉淀，其最终结果是IT信息中心的员工很多少能在一个业务领域做足够深入的了解和业务沉淀。

模式弊端

• 重复功能建设和维护带来的重复投资。因为大量的功能和业务在多个系统中同时存在，单单从开发和运维两个方面成本投入的角度，对于企业来说就是一种很显性的成本和资源浪费。
• 打通“烟囱式”系统间的集成和协作成本高昂，也牵涉大量的协同和开发成本。
• 不利于业务的沉淀和持续发展。系统业务需求响应的能力和企业本身业务发展对系统建设的要求不成比例。

1.2 构建业务中台的基础—共享服务体系

阿里巴巴电商系统的架构经历了烟囱式架构，到分布式架构，再到共享式架构的转变。

当前的阿里巴巴“厚平台，薄应用”架构形态如下图所示。目前阿里巴巴集团前端超过了25个业务单元，比如淘宝天猫聚划算等，均不是独立地构建在阿里云的云平台之上。在后端阿里云技术平台和前端业务之间有了一个“共享业务事业部”，将阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含额用户中心、商品中心、交易中心、评价等十几个中心。共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。

模式优势

• 服务可重用。通过松耦合的服务带来业务的复用，不必为不同的前端业务开发各自对应的相同或者类似的服务。例如淘宝和天猫不必各自开都开发一个评价服务。
• 服务被滋养。服务不需要“业务稳定”，一个服务如果一味追求不变，那就是固步自封，就会逼着其他系统去建同样的“轮子”。服务需要被滋养，不停的滋养，只有滋养才能最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的 IT 资产，而服务所需的滋养正是来自新的业务不断的接入。
• 共享服务体系是培养创新的土壤。好的创新一定是基于企业现状因地制宜，而这决定了很大程度上企业的创新来自企业内部，而且提出创新的人一定是对行业有过人的认识和理解，才有可能提出创新的想法。在“点”上根本感知不到的问题，在“线”和“面“的平台上，更容易发现这些问题的本质，通过专业的技能解决这些问题，为企业带来实实在在的业务价值，这就是很好的创新。
• 赋予业务快速创新和试错能力。企业试错能力是一个非常重要的能力，只有先人一步，唯快不破，才能帮助企业去抢占商业先机的制高点。如果打造了好的业务中台，可以让少量人员借助于中台提供的核心服务在较短时间内打造系统并推向市场，看看市场的反馈决定是否加大投入。
• 为真正发挥大数据威力做好储备。如今大多数项目在大数据落地实施时却很难，主要有两个问题：一是数据分布广、数据模型和标准不统一。二是缺少能基于数据业务建模能力的专家。而共享服务体系是解决这两个问题的不二法门。
• 改变组织阵型会带来组织效能的提升。改变组织阵型会带来组织效能的提升。彻底改变“烟囱式”系统建设的模式，在项目的建设周期和资源投入上会相比以前带来很大的效率提升。

1.3 中台架构：业务中台、数据中台

一切业务数据化，一切数据业务化！

• 业务中台数据同步到数据中台，结合外部生态数据，面向场景要求选择（或设计）合适的算法，进行数据的计算，实现数据在洞察和预测方面的价值;
• 大数据分析的结果要能反馈到业务生产系统中，实现数据驱动业务运营
• 数据服务中心肩负起业务中台和数据中台的双向交互职能;一是通过数据中台的能力负责业务中台各中心对跨中心或业务场景下数据需求的收集、反馈和实现;另一方面负责将数据中台的数据分析后的价值辐射给业务中台其他中心;

二、 中台是什么？

准确来说，中台是一个技术架构。在我看来，中台是一种快速应答的能力、是内功。中台可以在体系上将能力整合、沉淀、对外开放赋能，将服务能力标准化。

2.1 与前后台关系

前台和后台就像是两个不同转速的⻮轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；⽽后台由于⾯对的是相对稳定的后端资源，⽽且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好， 转速也自然是越慢越好。中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。

• 前台：用于数据的展现，在于灵活，是直接与用户交互的系统。
• 中台：封装变化，快速响应，将后台能力释放出来。
• 后台：掌控着核心资源（数据+计算），提供服务，在于稳定。

企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。

中台存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。

中台（⽆论是技术中台、业务中台还是组织中台）的建设根本上是为了解决企业响应⼒困境，弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾，提供⼀个中间层来适配前台与后台的配速问题，沉淀能⼒，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应⼒。

2.2 建设中台价值

中台建设的过程就是企业发掘沉淀打磨输出自身核心能力的过程，对内共享，对外开放，统一指挥，协同作战。需要我们在内部提高效率，降低成本，创新业务，提升用户体验，苦修内功等风来。

• 协同效率高
• 把握战机敏锐
• 调整方向快
• 一旦发现正确目标和方向，最短时间、最大化扩大战果

三 阿里中台架构一览

3.1 业务中台

主要包括：

• 会员中心：用户共性属性及能力的沉淀
• 商品中心：不同商品模型及能力的沉淀
• 交易中心：交易业务领域的服务中心，如：购物车、交易流程等。
• 订单中心：总订单、子订单，分润，状态等
• 支付中心：各种支付方式的支持，流水记录等
• 评价中心：商品评价等
• 账务中心：面向个人的账户余额，积分等。面向企业的总账户、子账户，对账单等

3.2 数据中台

主要包括：

• 数据仓库：用来存储数据的，结构性数据、非结构性数据等，还有离线数据和实时数据等；
  • 存储数据 - 结构性数据 - 非结构性数据
  • 数据类型
    • 离线数据
    • 实时数据
• 大数据中间件：包含了大数据计算服务、大数据研发套件、数据分析及展现工具
  • 大数据计算服务
  • 大数据研发套件
  • 数据分析
  • 展现工具

3.3 移动中台

移动中台 EMAS 是一个面向企业的移动研发平台，基于阿里巴巴移动技术中台数十年技术积累打造而成，目前已服务于阿里巴巴上百款移动应用和大量的企业客户。面向移动App全生命周期，为开发者提供移动基础设施，方便开发者快速完成App的搭建和上线。

主要包括：

• 研发规范
• 应用框架：跨平台框架
• 功能组件：UI 组件、图表组件、业务组件
• 服务组件：
  • 移动推送：移动推送（Alibaba Cloud Mobile Push) 是基于大数据技术的移动云服务。帮助App快速集成移动推送的功能，在实现高效、精确、实时的移动推送的同时，极大地降低了开发成本。让开发者最有效地与用户保持连接，从而提高用户活跃度、提高应用的留存率。
  • 移动崩溃分析：将Android和iOS平台常见APP的崩溃问题进行归类分析，帮助企业快速发现定位问题
  • 移动用户反馈：移动用户反馈（Mobile Feedback）是App内部的用户反馈系统。无需退出，就可以快速发送文字、图片、语音进行意见反馈和报告Bug
  • 移动热修复：面向移动互联网的APP热修复解决方案
  • 移动测试：帮助客户发现APP中的各类隐患（应用崩溃、各类兼容性问题、功能性问题、性能问题等），减少用户流失，提高APP质量和市场竞争力
  • HTTPDNS：面向移动开发者推出的一款域名解析产品，具有域名防劫持、精准调度的特性。
  • 移动数据分析：App数据统计分析产品，为开发者提供一站式数据化运营服务
  • APM：应用性能管理（Application Performance Management）
    • 内存监控：内存是影响用户直接交互体验的重要因素,它直接影响到App的使用流畅度
      • 内存峰值
      • 内存均值
      • 内存抖动
      • 内存泄露
    • CPU：CPU与内存一样,是APM监控的重点,它直接影响了用户使用APP的发热、卡顿等表现
      • CPU峰值
      • CPU均值
    • 启动时间：启动时间是用户对App的第一直接体验，启动时间的长短，在很大程度上决定着用户保留App的意愿
      • 冷启动时间
      • 热启动时间
      • 页面渲染时间
    • UI性能：UI性能指的是用户在实际使用过程中,对App的页面操作时的直接体验,是用户评价一个App好与不好的一个重要部分
      • 重绘性能
      • 滚动帧率
      • ANR：卡顿（Application Not Responding）
    • 耗电量：耗电量是用户厌烦一个App的重要原因，App可以不好用，但是却不能被用户发现大量损耗电量
      • 耗电量
      • 发热量
    • 网络性能：国内的网络环境错综复杂,而大多数App又是对网络强依赖,所以良好的网络监控和检测,有助于提高App的网络性能
      • 复杂网络环境
      • 请求流量
      • 接口往返时间和首包时间
      • 接口数据异常
      • CDN及服务器异常
    • 用户行为路径：收集用户行为路径,是了解用户App使用习惯以及提高用户所需要信息的重要途径
      • 页面停留时长
      • 操作路径

参考资料

• 《企业IT架构转型之道》
• 《EMAS平台全景介绍.pdf》
• 《企业IT架构转型之道》读书笔记
• 白话中台战略-1开篇：中台是个什么鬼？
• 移动研发平台 EMAS

---

• ← Previous Post
• Next Post →