最近 Google 发了一篇论文：《更有意义的可用性》。

技术管理圈子里有句玩笑话，「只要选对了指标，就没有搞不垮的团队」。

选择正确的指标来考核研发团队的绩效非常关键。

同时也非常困难。

我在两三年前开始使用发布频率、lead time、MTTR、回滚率等四个指标来考核团队绩效，并且把发布频率当成北极星指标。

这四个指标里，发布频率和 lead time 主要表征效率，而 MTTR 和回滚率则主要表征可用性和质量。

在使用过程中一直有点问题的是 MTTR。

可用性是好指标吗？

一提到可用性大家就会想到那几个 9。

可靠性级别	允许的故障时间 （每年）	允许的故障时间 （每季度）	允许的故障时间 （每 28 天）
90%	36 天 12 小时	9 天	2 天 19 小时 12 分
95%	18 天 6 小时	4 天 12 小时	1 天 9 小时 36 分
99%	3 天 15 小时 35 分	21 小时 36 分	6 小时 43 分 12 秒
99.5%	1 天 19 小时 48 分	10 小时 48 分	3 小时 21 分 36 秒
99.9%	8 小时 45 分 36 秒	2h 9 分 36 秒	40 分 19 秒
99.95%	4 小时 22 分 48 秒	1 小时 4 分 48 秒	20 分 10 秒
99.99%	52 分 33.6 秒	12 分 57.6 秒	4 分 1.9 秒
99.999%	5 分 15.4 秒	1 分 17.8 秒	24.2 秒

在国内技术圈你还经常可以看到或者听到「高可用」这个词。

从畅销书的名字就能看出来「可用」是多么重要。

但实际上，「可用性」只是软件系统的核心设计指标「RAMS」里面的一个：

• Reliability
• Availability
• Maintainability
• Safety

甚至在我很喜欢的《Designing Data-Intensive Applications》里，它提到的应用系统主要追求的三个方面就直接没有「可用性」，而是：

• Reliability
• Scalability
• Maintainability

我觉得这里的原因，主要是「可用」更多是用户纬度的一个感受（系统在运行的过程中有多少时间是可以被用户使用的）。它本身是以「可靠性」（系统在出故障的情况十分能够完成工作）和「可维护性」（系统进行定期维护和故障处理十分方便）等其他工程纬度的指标为基础的¹。

按照 Google 那本 SRE 书里面的说法，好的指标应该有三个特性：

• Meaningful
• Proportional
• Actionable

很明显，「可用性」这个指标不太符合第三点：因为你要想让系统更可用，主要是通过提高其他指标表征的工程能力。

但更重要的问题是，「可用性」在「Meaningful」方面也有些问题。

意义不够明确

基于时间计算的问题

考虑可用性很容易想到的首先是基于时间的计算方式：

Availability = Uptime / (Uptime + Downtime)

但是系统怎样算「运行」怎样算「失效」？比如，可以登录添加购物车不能结账算「运行」还是「失效」？

相信每一个奋战过双十一的人都有自己的看法。

所以有了一个看起来更好的计算方式：

Availability = MTTF / (MTTF + MTTR)

北京正常成都打不开算什么？有意的服务降级算哪边？究竟处理什么样的问题算 MTTR？

相信每一个做分布式系统的人都明白，「partial failure」根本避免不了。

而且，系统处于高峰前的不可用和没有流量时不可用，很明显应该有所区分。

为了尝试克服这里面的歧义，一些公司转向了基于次数的计算方式。

基于次数计算的问题

为了克服基于时间计算可用性的问题，最常见的改进是：

Availability = Successful requests / Total requests

这比以时间为基础的指标更加合理，但也存在一些问题:

1. 它主要说明的是高频用户的体验(不同用户的活动水平可以有 3 个数量级的差异)。
2. 它很难对应到最终用户的实际体验。
3. 当用户感知到系统故障时，请求会大量减少，这会带来数据上的巨大偏差。

更有意义的指标

基于时间和基于次数计算都有各自的问题，因此我们实际上没有办法统计类似于下面这样的可用性指标：

• 每小时最高 10 秒的不良可用性
• 每季度最高使用时间 6 小时的不良可用性

Google 的做法从概念上来讲不复杂：就是把 uptime 考察对象从系统切换到用户，一个用户的 uptime 可以是另一个用户的 downtime。然后综合所有用户的统计数据，就可以综合基于时间和基于次数计算的优势，得到一个 user uptime：

\[user \ uptime =\frac{ \sum_{u \in users} uptime(u) }{ \sum_{u \in users} uptime(u) + downtime(u) }\]

难点在于，如何获得每个用户的 uptime 和 downtime：

• 如果是通过探针，那么你很难去对每个用户都做一个不断发送请求的探针。
• 如果是通过统计用户真实请求，那么你会遇上用户请求稀疏造成数据失效。

Google 在论文里面提出的计算方法是：

After a successful (or failing) operation, assume that the system is up (or down) until the user sees evidence to the contrary.

另外，还有一个概念是「截止期」（cutoff time）：用户平均请求时间间隔的 99 分位。如果一个用户发送了一个请求，然后在截止期内没有再发送请求，则既不计入 uptime 也不计入 downtime，而是计入 inactive time：

这个指标显然是 meaningful 并且 proportional 的，那么它是 actionable 的吗？

可操作性

为了增强指标对操作层面的指导意义，Google 的做法是：

To make availability information actionable, we want to be able to distinguish between outages of different durations (e.g. one user outage of 1000 minutes, vs 1000 outages of 1 minute). In general, the bigger the window you examine availability over, the better the availability figure looks. To address this, windowed user-uptime combines information from all timescales (window sizes) simultaneously. For a given window size w, availability is computed by enumerating all windows of size w, computing the availability of each, and then taking the lowest value. Taken together the results are called the minimal cumulative ratio or MCR.

所以，MCR 是枚举固定大小的时间窗口，计算每个窗口的可用性，然后取最小值来计算的。

我们来看论文里面的例子：

和别的可用性指标的图表不同，这里的信息变得非常丰富:

• 本季度的总体可用率约为 4 个 9
• 没有一分钟或更长的时间窗口可用性低于 92%，并且
• 根据曲线的拐点(大约 2 小时的时间窗) ，我们可以推断出有持续两小时左右的故障，使可用性下降到 92%

曲线的拐点还告诉我们应该对什么大小的窗口感兴趣，技术团队应该怎样去解决：

然后，在文章的 5.2 节，提出了一个简化的计算方式：保持窗口大小线性倍增(例如 2 的幂)来采样。

最后，在文章的第 6 节，以实例说明了所有讨论过的基于时间和基于计数的指标的可用性指标的限制，并给出了 计算窗口化的 user uptime 的实际例子：

可以看到 Hangouts 的可用性受到了一个 4 小时事件的影响(曲线拐点) ，而 Drive 没有明显的拐点。这表明 Google 云盘的系统不是单一的宕机引起的可用性差，而是频繁的短故障：这往往意味着如果不解决系统层面的问题，故障时间根本降不下来。

论文的最后一句话是：

…we are confident that windowed user-uptime is broadly applicable: any cloud service provider should be able to implement it.

所以我们也试试吧。

去年在 iTech 做了一次中台的分享，之后就答应右军再整理个说明。

目录

• 概述
• 是什么？
  • 中台的起源
  • 「中台」和「平台」的关系
    • 层次与架构
    • 各层的运行环境
    • 架构的核心难点
  • 业务中台是什么
    • 子系统时期
    • 平台化时期
    • 中台解决的问题
    • 中台建设的前提和难点
• 做什么？
  • 别人做了什么？
  • 我们的总体架构
    • 基础设施
    • 业务中台
    • 数据中台
    • 业务中台与数据中台的关系
• 总结

概述

中台这个词火爆挺久了。但从阿里 2015 年提出并开始实施，发展到目前为止，并没有「标准化」：换句话说，它跟「人工智能」，「大数据」，「微服务」一样，具体的含义在不同公司不同时期的不同上下文里，有着千差万别的含义。

并且和这些词不太一样的是，它是一个在中文技术圈被频繁使用，但在其他语言环境下几乎找不到的词。所以我常跟身边的朋友说，关于它的争议特别多，大家不用感觉奇怪，可以参考中医。

本文的主要目的，是总结一下过去在中台架构和建设的过程中的思路和方法，方便大家对「中台」有一个相对一致的概念和边界，从而在后续的工作中更好地进行思考、讨论和选择。因此内容主要集中在：

1. 中台是什么：我们对中台的理解是怎样的。
2. 中台做什么：我们做出判断和选择的思路是怎样的。

一旦进入具体实现的细节，各个公司的技术栈、上下文和团队发展阶段各不一样，往往没有太大的参考意义，故本文不做过多讨论。

是什么？

中台的起源

中国有个好习惯是「治学先治史」，我们要了解中台究竟是什么，可以看看它发展的历史。

行业里面最早提出并实施「中台战略」的阿里内部，关于它的起源有两种说法：一个是马老师 2015 年年中参观 supercell 之后提出的¹；一个是阿里的工程师们针对业务上的挑战参考美军的发展提出的。

supercell 是一家人数只有不到百人，却连续推出了《部落战争》等多款爆款游戏，先后被软银和腾讯投资数十亿美金的游戏行业的传奇公司。它最大的特色就是内部以小团队（cell）形式作战，每个 cell 最多不超过 7 人。这些小团队依靠公司提供的公共的后端架构、引擎、算法、美术等中台资源，按照几周的时间周期推出大量新游戏，快速试错。

美军则是从一战时的按「军」为单位作战，到越战时按「营」为单位作战，逐步演进为「突击队+航母」的方式进行作战。前线突击队通常 7 到 11 人，有着中后台的强大支持（包括各种资源上的保障支持，卫星和无人机提供的侦查能力，高精度导弹的炮火支持等等），可以灵活选择战术并引领整个进攻高效完成。

可见，无论这两种说法哪种准确，中台战略主要都是指通过「小前台，大中台」的架构方式，降低试错成本，加快响应速度，从而真正做到「降本增效」。

「中台」和「平台」的关系

中台既然是一种架构方式，那么看到「小前台，大中台」的时候，最容易有的困惑就是这跟以前行业里流行过的「厚平台，薄应用」的架构方式有什么区别。

实际上，如果理解了企业级应用的架构难点，以及从服务化到平台化再到中台化的演变过程，就能非常清楚中台架构方式究竟是什么了。

层次与架构

「架构」在软件行业是一个非常微妙的词。

我觉得无论是最初的 C/S 架构、B/S 架构还是如今的微服务架构，架构的内涵主要包括以下两点：

• 是最高层次的系统分解和抽象。
• 是不易改变的设计方案和抉择。

要想对系统进行分解和抽象，找到不易改变的部分，主要的方法是分层。在计算机本身的架构中，到处都有分层的例子：

• 系统：硬件层->HAL 层->OS 层->应用组件或平台->各种应用。
• 网络：不管是五层还是七层的分法，大体上都是硬件->链路->网络->传输->应用。

分层的方式最核心的好处在于：

• 封装细节，解除耦合：不如不用知道硬件细节就可以在 TCP 上构建 FTP 服务，如果硬件层完全换了 FTP 服务也可以正常运行。
• 有利于标准化：因为每层的实现相对自治，就容易形成每一层的标准化协议和运行机制。

和网络这样体系架构已经非常成熟的系统相比，互联网公司构建的「企业级应用」，难度主要在于：

• 复杂的数据层次：需要持久化并经常变更的数据很多，需要打通和集成的外部异构系统很多，数据状态复杂访问量大访问方式异构
• 复杂的业务逻辑：各种商业规则和潜规则形成的业务规则，还会随时变化，软件里没有比业务逻辑更没有逻辑的东西了

因为这两方面的复杂性，对企业级应用分层时最困难的问题就是究竟有哪些层次，每一层的职责和边界是什么。到目前为止，最流行的做法是按照 Brown 的建议²把它分为三层。

• 表现层主要处理用户与系统之间的交互：可以是 App 或网页，也可以是桌面客户端。
• 领域层主要是处理各种业务领域内的逻辑：包括数据抽取，规则计算等等的逻辑。
• 数据层主要是数据库，消息队列等进行数据交互和持久化的工作。

各层的运行环境

进行了层次划分之后，一个需要进行的架构选择就是在哪里运行这部分工作：是在服务器上，还是在用户的机器上。

一个常见的误区是把表现层直接对应到前端应用，领域层直接对应到后端应用。实际上表现层的大量逻辑有可能是在我们的服务器上渲染的。而随着桌面电脑或者手机的处理能力和交互需求的提升，很多领域层的业务逻辑反而是在客户端进行处理的。举个简单的例子就是各种表单填写时的字段校验，在过去是需要提交到后端进行的，现在则有很多是监听用户焦点离开当前输入框就进行了。

因此，在确定各层的运行环境的时候，核心是根据应用本身的特点，考虑不同的运行环境的优劣点安排：运行在客户的机器上，好处是响应性能和不依赖网络；缺点是如何把变更同步到各个客户的机器并且让它有效（想想不同浏览器的兼容性）。

比如数据层，我们当然不希望每个用户有一个自己的数据库，然后我们来做这些数据库之间的读写同步，所以它一般都是运行在服务器上的。但是我们又希望用户有很好的响应和体验，所以我们各级的缓存里有不少是部署在客户端的。

再比如表现层，我们希望给用户很良好的响应速度和用户体验，所以可以在后端根据用户画像进行千人千面的数据组织来给不同用户组合不同的操作界面。同时我们又希望能够对客户端能够有更好的控制力，所以会打造客户端的各种框架和组件。

架构的核心难点

进行了层次划分和运行环境的选择之后，架构的核心难点就在于如何抽象出：

1. 标准的协议和运行机制。
2. 满足标准的分布式执行单元。
3. 去中心化或中心化的控制单元。

正是在这样的抽象过程中，行业里提出了 SOA，微服务，服务网格等服务化到平台化的解决方案（SOA 和微服务的一个很重要的区别是执行单元和控制单元和通信方式，SOA 是有总线的）。而在三层里，如何对控制和处理复杂业务逻辑的领域层进行架构是关键中的关键，它既是公司业务生态的基础，也直接决定了业务探索的速度和业务创新的成本。

所以我们以领域层为例，看看为什么需要业务平台，它又如何演化到业务中台。

业务中台是什么

建设敏捷的前台+强大的中台，绝不是因为阿里或者京东做了，所以货车帮要赶这个时髦。而是货车帮本身的业务不断发展下，技术体系的正确应对策略。

子系统时期

货车帮初期，只有一个主业务，也只有一套主系统。随着 ETC/车油/金融等业务的发展和技术人员的增加，这个系统的交付速度和稳定性都变差了。于是在 2017 年开始做分布式系统：把原来的单体系统拆分成多个中心承担的分布式子系统。

最多的时候我们技术体系有 13 个中心组成，除开包括了用户中心、活动中心等在内的基础服务中心，还有包括平台业务中心（车货匹配业务），车后业务中心等在内的各个业务系统中心，以及大数据中心，运维中心等。

这个阶段的核心工作实际上是把数百人的团队拆分成了功能相对比较集中的小团队。每个独立的系统可以独立设计、独立接需求、独立发布，整个研发交付速度和系统稳定性扛住了业务高速发展的需要。

但随着事业部化的推进，业务决策链路更短，业务发展更快，技术人员的数量也快速增长。而且各个事业部的定位不一样，业务发展阶段、方向和规则都很不一样。为了快速应对每天的业务需求变更，所有的员工都在加班加点，但由于在业务抽象建模，系统架构的开放性等方面考虑不足，导致业务逻辑之间的耦合和相互影响，研发质量和效率大幅下降。

这种见招拆招，垂直发展，未做足够抽象通用的架构行业里称之为「烟囱型架构」，解决这种问题通常就需要平台化了。

平台化时期

从一个个的中心到平台化，核心是业务抽象建模和保持系统架构的开放性：

• 拉通考虑各个业务的逻辑，把基础能力抽象出来，解决共性的 80%问题。
• 系统架构上保持开放性可扩展性，把业务和业务之间不同的逻辑隔离并进行封装，解决 20%的个性化问题。

比如每个业务都需要用户注册和审核的功能，所以我们通过用户平台来提供统一的接口。而不同业务比如车货匹配业务和车油业务对司机审核的力度要求是不同的，前者需要司机提供驾照等证件，后者可能就宽松很多。平台要把不同业务的逻辑隔离开进行封装，对外提供一致的接口。

再比如营销活动，各个业务都要做。我们就可以抽象出一个从设计，上线，到数据收集全生命周期管理的活动平台，提供给各个业务使用。但是各个业务具体的活动逻辑要做到很好的封装，就需要建立元数据中心、规则中心、活动界面自动生成、活动数据自动埋点等等。

图1 子系统到平台化的架构升级

平台化的核心收益其实就是降本增效：

• 抽象共性，减少重复建设投入的人力和时间成本。
• 快速支撑，提高需求到研发上线到效果复盘各环节效率。

平台化的过程一般都会经历从 API 治理和提供，到服务化，到最终形成平台的过程，所以各个平台并不会在同一天完成。实际上，一直到货车帮开始建设中台的时候，仍然有很多平台正在建设中。

那么我们为什么又要推中台战略了呢？

中台解决的问题

我们以一个新业务负责人的视角就很容易想通平台化的问题了。

首先，作为各个业务的负责人，要了解各个平台的功能和职责并且推动合作很困难。做一个新功能的 MVP 究竟需要多少人多少时间甚至都算不出来。

首先，平台是提供抽象出来的共性功能，每个团队专注自己的事情，提升效率。但这样虽然带来了专业，却很容易导致「各家自扫门前雪」，对于创新业务的支持力度不足。

所以，就会出现类似下图的问题：当公司的保险业务负责人想要进行某个新功能的开发时，经过反复沟通，发现自己的团队承担的部分可以在两天之类完成开发，但是依赖的团队对这相关功能的排期可能排到了两三周后面。

图2 业务平台带来的「各家自扫门前雪」

最后也是最大的问题是，领域的平台化解决了领域层内部的问题，但业务的执行都是跨领域的。涉及用户、商品、交易、营销、支付、服务等等环节，横跨多个系统。如何把多个平台的数据集成到一起并加工分析而产生新的支持到业务的价值，变得非常困难。从当时的实际情况看，按照平台化的架构方式，基本上是没有办法做数据驱动运营的。

因此，平台化之后虽然解决了烟囱式架构的很多问题，但是随着公司的发展，整个组织的效率仍然会逐渐降低。这不是一个技术问题，而是一个复杂生态下的协作问题。要解决这样的问题，就要通过打造中台来解决前面说的企业级应用架构的三个核心难点：

1. 标准的协议和运行机制。
2. 满足标准的分布式执行单元。
3. 去中心化或中心化的控制单元。

所以，中台化其实是平台化之后的自然阶段，它主要是带来了：

• 提供完整解决方案而不是暴露 API，给业务带来的快速创新和试错能力的提升。
• 通过数据统一治理和应用，给业务带来数据驱动的运营能力的提升。
• 通过解决信息获取成本高，系统互联互通成本高的问题，给企业带来组织效率的提升。

中台建设的前提和难点

中台建设的前提也是难点有两个。

第一个是要需要有稳健的基础设施：

1. 系统性解决复杂度。
2. 系统性解决高可用，高并发。
3. 系统性解决开发测试环境一致性和便利性。

能够做好具备这三个能力的基础设施，要求公司具备较强的 IaaS/PaaS 层的建设能力。

第二个难点，在于中台本身的建设过程中，如何进行抽象和划分边界。

但从技术架构上来说，常见的抽象方式有两种：

1. 按照信息流、资金流、数据流等等的构成 element 和 process，自上而下进行抽象。
2. 按照对应一个个数据单元的 entity 以及这些 entity 的状态和转移，进行自下而上的抽象。

前者是更加常见也容易入手的方式，但是扩展性较差。后者则更加面向领域内的模型³，具有更好的健壮性，能够支撑更多的业务场景。

但需要注意的是，对系统边界的划分，通常不是一个简单的技术架构的问题，而是牵扯到流程设计、组织架构、业务归属等在内的极其复杂的挑战。

因此，进行中台建设一个隐含的前提，是公司的文化有一定成熟度，并且核心管理团队和骨干成员有一致的目标。摩擦在所难免，解决的办法更多不是靠的技术。

做什么？

理解了中台是什么，我们来看看做什么。

一个很好的做法是，先看看别人做了什么。

别人做了什么？

图3 阿里中台架构图 - 摘自钟华云栖大会分享」

核心三大部分：

• 基础设施：一套支撑分布式服务研发、上线和运营的基础设施⁴。
• 业务中台：包括了用户中心、交易中心、搜索中心、营销中心等在内的业务中台。
• 数据中台：包括了数据技术，数据资产管理，数据服务等各个层次的数据中台。

我们的总体架构

根据我们对中台的理解，并参考其他公司的做法，货车帮的总体架构是：

• 前端和接入层
• 前台业务
• 业务中台和数据中台
• 基础设施
• 企业效能和运维保障体系

图4 整体系统架构：前台/中台/后台

这套架构的核心目的，是在更快更好的支撑公司进行业务创新的同时，赋予业务真正的数据驱动运营的能力，从而在提升组织效率的同时，为发挥大数据的威力奠定基础。

基础设施

图5 货车帮面向云原生的基础设施

包括云原生平台 Newton 在内的基础设施的设计和开发，以及统一规划和提供的企业效能和运维保障能力，过去已经有过不少分享，这里就不再赘述。

但需要再次强调的是，如果没有一套足够好的基础设施，最好先不要开始进行中台的建设。

业务中台

业务中台的核心建设步骤是：

1. 从业务领域的边界是什么，提供的基础服务是什么，领域服务和领域服务之间的流程链接标准是什么等角度，抽象出模型、规则和协议
2. 基于这些模型、规则和协议，建立业务实施标准和管控标准。
3. 根据实施和管控标准，提供权限集中管理、流程灵活可配的工具和引擎。

也就是说，如果还是像平台化阶段，通过一堆 API 来暴露能力，那就不是「中台」。

以中台化之后的用户中心为例，它将不再只是提供用户注册审核相关的 API 或者类库，而是需要站在公司业务特点上建立物流领域的包括用户认证，用户审核，用户评价，用户等级，用户画像等在内的用户标准体系，并且负责所有相关的系统开发、业务协同和评价机制搭建，最终形成完整的能力地图，通过工具和协议开放。

再比如，以订单的创建过程为例，我们传统的做法。需要梳理从能力规范、运行机制到配置管理和执行系统以及运营服务团队构成的整套标准，才能真正为各业务方提供快速、低成本的创新能力。

图6 通过业务中台，为各个前台业务提供统一的订单处理能力

最终，业务中台将通过各种层面的产品和服务来落地：

• 业务能力图谱。
• 业务需求分解和配置的工具。
• 业务流程设计和配置的工具。
• 业务指标度量和跟踪的工具。

基于这些产品，把每个业务它是怎么出来的，出来之后做了哪些业务需求和业务活动，每个业务活动的效果是怎么样的，都沉淀下来。在此基础上，通过统一的运营平台作为中控单元，把整个业务中台串起来，将业务逻辑与具体实现的分离。

数据中台

数据中台的核心在于从数据技术、数据资产、数据服务等各个层次，进行规范和标准化：

• 数据技术：数据如何采集，如何存储，如何进行离线和实时计算。
• 数据资产：全域的数据治理，包括建模，数仓，数据集市等。
• 数据服务：包括对外和对内以产品，接口或者中间件形式提供的各种数据服务。

图7 数据中台实现真正的数据统一、实时、在线

因此，数据中台将通过下面这些产品落地：

• 统一的数据采集、存储、计算平台。
• 统一的数据资产管理平台。
• 统一的数据研发工具平台。
• 丰富的数据服务，完备的数据集市和统一的接口/中间件。

业务中台与数据中台的关系

业务中台和数据中台是相互促进的关系：

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

总结

关于中台的文章已经有很多了，本文主要是讨论之前在负责货车帮时的一些思路。总得来说，我认为：

1. 中台不是目的是手段，需要根据各个公司自己业务和团队的情况来量身打造。
2. 中台建设需要强健的基础设施，还需要组织架构、企业文化、流程制度等各个纬度的支撑。
3. 负责建设中台的团队要有很强的业务抽象能力和很好的服务精神。