两年花费近两亿，构建不出统一 API 系统？

作者 | 赵钰莹

Lawrence Krubner 曾经是三家初创公司的技术联合创始人，其中两家公司在发展到中等规模后就被卖掉了。在过去 20 年，他一直帮助大中型公司做技术咨询，而在最近与一家大公司的合作中发现：这家公司的技术栈实在是太糟糕了，以至于两年时间花了不到两亿人民币也没能构建出统一的 API 系统。

1

两年近两亿，未能构建出一套 API 系统

由于涉及商业隐私等问题，Lawrence Krubner 将这家大型公司称为 SuperRentalCorp，这家公司拥有 11000 名员工，分布在 180 个国家。两年之前，这家公司就在尝试构建一套 API 系统，并决定成为 MuleSoft （一家提供基于云的应用集成服务商）的客户，帮助创建一套新的 API。

到目前为止，Lawrence Krubner 已经在涉及 MuleSoft 的项目上花费了大约2500 万美元（换算成人民币超过 1.7 亿人民币）。MuleSoft 有一些用于构建 API 的工具，但这些工具对读操作的帮助远大于写操作。也就是说，MuleSoft 有助于处理简单的事情，但对复杂的事情帮助不大。

在 Lawrence Krubner 最初被告知这一消息时，他认为非常不可思议。他表示：“现在是 2019 年，有一百万个工具可以轻松设置 API，为什么这是一件非常难的事情呢？一个好的工程师甚至可以在一天时间内完成这项工作，为什么 SuperRentalCorp 如此挣扎呢？”

2

历史原因：沉重的技术包袱

Lawrence Krubner 最初的想法是假设有一个数据库，你只是把 API 放在数据库和外部世界之间，这是他工作过的早期创业公司的常见场景。有一个 greenfield Ruby On Rails 项目，可以在一个小时内构建这种 API。但是，在了解了 SuperRentalCorp 的历史之后，我对这个问题有了更加全面的理解。

SuperRentalCorp 成立于 100 多年前，当时世界上大部分地区由几个欧洲帝国统治，大多数公司在一些西方国家经营全球业务。但在 1948 年至 1980 年间，所有的旧帝国都分崩离析，取而代之的是 100 多个新国家，每个国家都在保护自己获得的独立性。因此，SuperRentalCorp 决定采用去中心化的结构。在大多数国家设立子公司，子公司作为独立公司经营。有时，子公司的部分所有权被出售。这意味着，当上世纪 70 年代末第一批大型数据库出现时，这家公司没有中央数据库、中央 IT 部门，没有 CTO 或 CIO。

不久之后，由于局势比较稳定，合并一些服务的好处显而易见。因此，SuperRentalCorp 合并了一些子公司，成立了区域公司。有一家区域公司负责中东和北非，一家负责欧洲，一家负责北美，一家负责亚洲，一家负责南美。伴随着这种结构调整，公司进入了 90 年代，这时公司开始认真通过网络数据库管理所有服务。

面对上世纪 90 年代激烈的全球竞争，该公司决定通过收购其竞争对手来实现增长，这种收购一直持续到 Web 2.0 时代到来。

最近，新的首席执行官决定：最好是把公司团结起来。几家国际子公司被 100% 收购，目前正在进行重组，以使它们作为公司内部的部门运作，而不是独立的公司。

基于上述背景，SuperRentalCorp 希望创建一套统一的 API ，以使外界认为该公司拥有内部统一的技术架构。也就是说，SuperRentalCorp 希望创造一种幻像，即公司只有一个数据库，并且很容易与该数据库交互。

但现实如何呢？SuperRentalCorp 有 20 个主要数据库，由 20 个不同的团队在至少 10 个不同的国家里运行，这些团队中有许多都曾作为独立的公司运营。每个团队都想保护自己的数据，部分原因是出于安全隐患的担忧，部分来自于当地法律关于用户隐私的担忧，以及国际用户数据转移的规定，而部分只是单单因为脾气倔。

与任何数据库操作一样，这里有两个关注点：读和写。

读其实并不难。我们可以从 20 个不同的数据库中提取（必要的）数据，将数据存储在一个充当缓存的集中式数据库中，并在该数据库和世界其他部分之间放置一套 API。陈旧数据可能会有一些小问题，我们必须进行实验来确定哪些数据是高优先级的，需要在几秒钟内复制。不太重要的数据可以每 5 分钟复制一次，或者在更新时再通过触发器进行复制。

读并没有那么难 (不容易，但也不是不可能)。

而写却是另一回事。如果伦敦的用户想从一间伦敦的子公司租用数据资源，租用请求（数据库写）将发送到中央 API，但这是否意味着中央 API 必须得知道要写到内部哪个特定的数据库？同样的，在尼日利亚、德国和巴西发生的写请求也将进入不同的数据库。这就变成了一场噩梦。二十年前，这种思路导致了企业服务总线体系（ESB）结构的创建，但是 ESB 现在已经不受欢迎了，因为它过于复杂、僵硬和笨拙。

在最佳集成架构方面，在我看来唯一的长期解决方案是类似于 Jay Kreps 在 2013 年所写的统一日志架构。所有进来的写操作都需要放入一个集中的日志中，比如 Kafka，然后各个数据库就可以从中提取需要的东西，每个团队都可以从中心日志中决定需要什么。

然而，SuperRentalCorp 有使用 POS 机（销售终端）系统的零售店，它们与特定的数据库直接对话，并且写路径（直接 POS 机到数据库）是硬编码的方式，这很难改动，所以它需要花费数年来建立单一的 write-point（写操作端点）。

目前，每个数据库团队需要接受来自多个源的写操作。但从长远来看，统一的日志是可行的。这对 20 个团队中的每一个来说都代表着一个巨大的过程变化。这也有助于解释为什么该公司花了两年时间和 2500 万美元试图构建一套 API，但到目前都没有成功。

3

外包靠谱吗？

如上，我只讨论了来自内部数据库和内部流程的问题。从某种意义上说，与依赖外部服务供应商相比，内部问题都很容易，因为外部供应商都不受 SuperRentalCorp 的控制。从上世纪 90 年代开始，出现了一种管理理念，主张公司应该专注于“核心竞争力”，把其他一切都外包出去。这就好像你是一家报社，不需要雇佣门卫来保持办公室的清洁，而是把清洁工作外包给一家专门从事办公室清洁的公司。

如果什么事情都亲力亲为，那么你就犯了“非我发明综合症”（Not Invented Here Syndrome）。尽管我已经看到了这样做的缺点，但在这个论点中有很多我同意的地方。外包限制了灵活性，因为你最终与外部公司建立了长期的、紧密的联系，而这些公司可能不会随着你的需求而发展。尽管解雇一项清洁服务公司并雇佣另一项清洁服务公司似乎很容易，但有一些种类的服务是很难替换的。

早在上世纪 90 年代，SuperRentalCorp 就决定将客户忠诚度计划的管理外包出去，因为这被视为一项财务职能，而 SuperRentalCorp 并不是一家财务公司。他们外包的公司也落后于时代，原始得令人吃惊——该公司没有为他们的服务提供公共 API。现在，当 SuperRentalCorp 想要将忠诚度系统嵌入在各种 CRM（客户关系管理）和 POS 系统时，却做不了，因为它在公司里对管控忠诚度计划的技术决策没有控制权。是的，SuperRentalCorp 可以终止与这家公司的关系，并开发自己的技术来管理忠诚度计划，但他们已经在技术上浴血奋战多年。目前，很难这么做。

4

信任问题

这个问题一部分归咎于技术问题，一部分归咎于信任问题。如果希望构建统一的 API 系统，每个团队都必须放弃一些权力，然后信任一条他们无法控制的流程。当公司有了新的 CEO 之后会发生什么呢？如果决定再次打散公司怎么办？团队能在多大程度上信任当前企业战略的持久性？他们是不是应该给自己留点余地，好让自己能够回到过去做事的方式？

数十亿美元的公司不断地与那些不守信用的内部和外部参与者（外包）打交道。这不是仅存在于理论中，这是现实。关于如何更敏捷的说法并没有多大帮助，因为他们面对的是关于公司结构、所有权和战略的实际问题。

大公司不断面临着被公司内外的贪婪所毁灭的风险。创业公司更容易处理信任问题，因为当整个团队只有 5 个人的时候，互相看着对方的眼睛就可以大致看出他的状态。如果在 180 个国家拥有 11000 名员工，那这就是不可能的了。在很大程度上，“敏捷”几乎等同于“相互信任”。如果想知道为什么大公司在敏捷方面有困难，部分原因是 11000 人不可能像 5 个人那样相互信任。

综上，所有这些都有助于解释为什么在规模更大、历史更久的公司，技术改造很困难，因为需要不断与历史进行斗争。

近年来，随着 jQuery 的落幕，三大框架的割据以及小程序的爆发，大前端的发展也经历了从静态页面到 JavaScript 跨时代的诞生，再从 PC 端到移动端的转向，以及由依赖后端到前后端分离的架构演变。

腾讯在线教育前端团队，近年来在大前端技术架构演进方面也有了不少突破，如 Hybird 方案、离线包方案、PWA 结合 SSR 方案、以及 RN 动态化方案的落地和执行等。

点个在看少个 bug