写点什么

两年花费近两亿,构建不出统一 API 系统?

  • 2019-10-25
  • 本文字数:3240 字

    阅读完需:约 11 分钟

两年花费近两亿,构建不出统一 API 系统?

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


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

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


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


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

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

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,但到目前都没有成功。

外包靠谱吗?

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


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


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

信任问题

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


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


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


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


参考链接:https://news.ycombinator.com/item?id=20260114


2019-10-25 15:516776
用户头像
赵钰莹 极客邦科技 总编辑

发布了 894 篇内容, 共 679.7 次阅读, 收获喜欢 2694 次。

关注

评论 3 条评论

发布
用户头像
可以猜下这家大公司是哪一家了
2019-10-24 10:27
回复
爱立信?
2019-10-25 16:50
回复
这是目前微信公众号上得票数最高的答案了
2019-10-25 17:58
回复
没有更多了
发现更多内容

中国AI的下一站:从两会高地奔涌向产业河谷

脑极体

实用机器学习笔记二十五:超参数优化

打工人!

学习笔记 超参数调优 机器学习算法 3月月更

hexo+github搭建个人博客前期部署工作

静Yu

Hexo

N个技巧,编写更高效 Dockerfile|云效工程师指北

阿里云云效

阿里云 云原生 Dockerfile 部署与维护 构建工具

TiDB 可观测性方案落地探索 | “我们这么菜评委不会生气吧”团队访谈

PingCAP

web前端培训:react高频面试题分享

@零度

前端开发 React

Gitlab-ci 替代 webhook 触发Jenkins job

网易云信

gitlab

低代码实现探索(三十七)业务的流程,开发的框架

零道云-混合式低代码平台

喜讯!openGauss社区入选2021年 “科创中国”榜单

云计算及国内主流云厂商概述

穿过生命散发芬芳

3月月更

三级等保是最高的吗?有什么用?

行云管家

网络安全 等保 等保2.0

【IT运维】多台海外主机运维用什么工具好?

行云管家

服务器 IT运维 服务器运维 海外主机

数字化时代下,智能运维全栈监控解决方案及案例盘点

云智慧AIOps社区

运维 解决方案 场景应用 自动化运维 运维安全

打造优质的车联网体验,仍需注意数据安全保护

FinClip

JavaScript深入理解之闭包

锋享前端

大数据培训:Hadoop和MPP有什么区别

@零度

hadoop MPP 大数据开发

【51单片机】室友用一把王者时间,学会了去使用数码管

謓泽

3月月更

Jaeger docker部署实操

非晓为骁

Docker Jaeger Go 语言 http client

WebRTC 简单入门

ZEGO即构

WebRTC 动手实践 音视频开发 即构科技

移动域全链路可观测架构和关键技术

阿里巴巴终端技术

架构 App 移动端 体验优化

浏览器工作原理和V8引擎

CRMEB

ICASSP 2022 | 前沿音视频成果分享:基于可变形卷积的压缩视频质量增强网络

阿里云CloudImagine

阿里云 计算机视觉 音视频 视频编码 视频云

如何使用OKR管理团队?

优秀

如何进行数据挖掘?

郑州埃文科技

数据挖掘 数据库

企业知识管理的目标是什么?

小炮

【ELT.ZIP】OpenHarmony啃论文俱乐部——多维探秘通用无损压缩

ELT.ZIP

OpenHarmony 压缩算法

小白入门HarmonyOS Connect设备开发的“芯”路历程

HarmonyOS开发者

芯片 HarmonyOS 设备

Go HTTP Server 基于OpenTelemetry 使用Jaeger - 代码实操

非晓为骁

Go Docker Trace Jaeger OpenTelemetry

向工程腐化开炮 | Java代码治理

阿里巴巴终端技术

Java android JVM 代码治理

【直播回顾】OpenHarmony知识赋能第四期直播——标准系统HDF开发

OpenHarmony开发者

直播 HDF OpenHarmony

java培训:SpringBoot高频面试考点分享

@零度

JAVA开发 springboot

两年花费近两亿,构建不出统一 API 系统?_文化 & 方法_赵钰莹_InfoQ精选文章