2天时间,聊今年最热的 Agent、上下文工程、AI 产品创新等话题。2025 年最后一场~ 了解详情
写点什么

构建弹性平台:来自关键任务基础设施领域逾二十年经验的见解

作者:Matthew Liste

  • 2025-11-18
    北京
  • 本文字数:5790 字

    阅读完需:约 19 分钟

大小:2.86M时长:16:40
构建弹性平台:来自关键任务基础设施领域逾二十年经验的见解

本文要点

  • 伟大的平台通过隐藏复杂性和魔法般的界面来提供直观的体验;它们运行如此无缝,以至于用户认为它们是理所当然的,永远不需要考虑底层基础设施。

  • 平台建设者必须平衡“三个 S”(稳定性、安全性、可扩展性),将它们作为不可让步的要求,同时维持一种持续更新和修补的常青方法。

  • 取得成功的前提是对该构造什么有自己的主见,并经常说“不”;少做但做得特别好,比做很多但做得不好更佳。

  • 开源在大规模构建现代平台、提供社区创新、跨环境的可移植性以及读取和扩展底层代码的能力方面发挥了重要作用。

  • 以赋权的团队和思想的多样性建立正确的文化是基础;伟大的文化驱动着伟大的团队,而伟大的团队反过来又构建了伟大的产品。

引言

构建弹性平台需要理解创造“被他人依赖的关键应用基础设施”的艺术和科学。基于二十多年各种支持关键应用平台的构建经验来看,这种观点适用于所有大规模构建软件的人们,无论它们是开发基础设施平台、软件开发平台、消息系统还是银行平台。

 

我的金融服务之旅的启程是出乎意料的。我的职业生涯始于石油和天然气行业,从事海上船舶的数据采集和通信工作,然后转向网络和电信。搬到纽约后,我进入了金融领域,当时金融领域为底层基础设施专业人员提供了最好的机遇。这被证明是我的幸运,因为银行非常关心正常运行时间和弹性,并在底层基础设施上投入巨资。这个领域提供了持续的投资机会,用于大规模的平台工作上,停机时间是不可接受的,风险始终保持在高位。

 

在包括美国运通、摩根大通和高盛在内的主要金融机构工作,意味着构建支持交易系统、银行系统和信用卡处理等平台。所有这些系统都不能容忍停机时间、安全漏洞或无法随着业务需求扩展的问题。

什么是平台?

字典将平台这个词描述为一个平坦的、水平的表面,人们或物体可以站在上面。这个隐喻在技术领域得到了很好的延伸。想想火车站台或下水道系统这样的城市基础设施。这些平台在后台静静地存在,隐藏了用户永远不需要考虑的复杂性。它们变得如此不可或缺,以至于被视为理所当然。

 

在技术术语中,平台代表了一组集成技术,用作开发其他应用程序或流程的基础。最好的平台构建者在平台被认为理所当然时就大功告成了,他们看到的成功不是掌声,而是沉默。

 

用户可以在从未考虑底层基础设施的情况下照常工作,因为平台简单地运行在那里,始终如一且可靠,使它们变得悄然无形。就像为我们的设备提供能量的电力基础设施一样,这些系统背后的复杂性都隐藏了起来,同时使用户能够专注于他们的主要任务。

 

当今平台的最佳体现是云平台,无论是公共云还是私有云,它们支撑着绝大多数现代软件应用程序,从我们熟悉的品牌(例如,优步、网飞)到复杂的企业系统。复杂性被隐藏起来,消费者永远不需要考虑它。

基础设施平台的原则

构建一个如此顺畅运行的平台并非偶然,它是精心工程实施的产物。它需要经验、纪律和一套指导人们如何思考大规模构建的原则。多年来,我将这些原则写下来,形成了一份白皮书,供我的团队更广泛地使用,以捕捉在构建平台的过程中帮助我的东西。

提供直观的体验

优秀的平台优先考虑直观的体验。十五年前,使用公共云基础设施是痛苦的:复杂性、困难和晦涩使得消费变得具有挑战性。今天的公共云平台提供了直观的体验,因为它们在隐藏复杂性的同时做到了无缝集成。它们看起来像魔法。

 

亚瑟·C·克拉克的见解,即足够先进的技术会变得与魔法无法区分,完全适用于基础设施平台。这里的魔法来自于无缝集成,无形地处理复杂性。例如,史蒂夫·乔布斯倡导简单是终极的复杂性:使某物看起来简单需要巨大的努力。暴露复杂性是容易的;创建一个直观地工作的东西是困难的。

 

成功地隐藏复杂性的同时提供强大的功能定义了平台的卓越水平。水下的复杂工程应该对用户保持不可见,用户只想无摩擦地完成他们的任务。

构建通用和可互换的组件

平台通过集成来取得成功,确保组件无缝协作。典型系统涉及许多不同的构建块(例如,消息传递、数据库、Web 层)并且必须完美地相互锁定。共同的可观察性就是这个原则的体现,虽然可观察性曾经是分散的,跨组件的故障排除被证明是不可能的,但现代云平台现在提供了统一的日志记录、遥测和仪表板。

 

乐高玩具的隐喻完美地说明了这一点:有限的一组相互锁定的块提供了无限的创造可能性。平台必须为互操作性制定标准,如可观察性系统或身份管理方法。这种对共同性的坚持为消费者提供了无缝的集成。一方面,共通性让支撑平台的内部组件得以“免于选择”;另一方面,它也通过简约为用户创造了自由。

 

以在三层应用程序中的身份管理功能为例:当身份管理在所有层中一致工作时,部署变得无缝。可互换组件的美妙之处在于这种可预测、可靠的交互模式,让用户可以信赖它们。

使用三个 S:稳定性、安全性和可扩展性

金融服务平台需要支持很多关键任务操作,如交易系统和信用卡处理。这些系统对停机时间、安全漏洞或扩展失败的容忍度为零。三个 S 代表了三种不可让步的要求。与房地产行业不同,你可能在三个因素中优化两个(例如,位置、价格、大小),但金融平台必须在不妥协的情况下提供全部三个要素。

 

稳定性意味着始终一致、可靠的操作。然而,通过停滞不前来实现的稳定性会在未修补的系统中产生安全漏洞。修补引入了可能影响稳定性的变化,同时实现安全性。可扩展性要求为 10 倍增长做准备:成功的平台会像一股不可阻挡的力量一样吸引用户,许多平台之所以失败,是因为它们无法随着客户需求的增长而扩展。

 

平衡这三个要求需要持续的关注和投资。虽然成本可能会根据业务需求和优先级波动,但这三个基本要素建立了一个不可侵犯的基础。有时扩展优先,需要临时调整修补周期。关键在于在所有三个维度上保持最低可接受水平,同时根据即时需求进行优化。

保持常绿

维护安全性需要持续的环境维护:也就是保持常绿。在大规模层面上这变得非常具有挑战性。管理成千上万的服务器、数十万或数百万的虚拟机、容器、数据库和消息代理意味着维护数百万有各自生命周期的组件。有些需要季度更新,有些需要半年更新,有些需要月度更新,而且越来越多的组件甚至需要每日补丁。

 

在不干扰客户的情况下管理这种维护工作被证明是非常困难的。许多金融服务应用程序并未设计为支持滚动升级。修补不能容忍停机时间的数据库,协调变更窗口,管理 API 合同变更,所有这些工作会让复杂性迅速增加。

 

推迟维护的诱惑总是存在的,但落后会产生无法克服的技术债务。从安全角度来看,坏人利用零日漏洞的情况与日俱增,表明推迟维护很容易演变成危机管理。保持常绿需要永恒的警惕和承诺。一旦你落后,再次赶上几乎变得不可能。这一原则要求提前规划和坚定不移的执行。

避免无差异化的重体力劳动

工程团队自然倾向于从零开始构建一切。聪明的基础设施工程师可能会提议构建定制数据库、消息代理甚至操作系统。然而,当已经存在优秀的选项时,金融机构不需要定制数据库引擎。

 

重点必须保持在客户实际需要的东西上。例如,使数据库企业就绪可能意味着用自动故障转移、备份和合规控制包装 Postgres,而不是重写数据库引擎本身。在现有基础上只添加必要的控制,并严格应用奥卡姆剃刀原则(最简单的方法通常是最佳):只做必要的。

 

在现有基础上构建会将重心缩回到业务价值上,而不是重新发明轮子。抵制过度工程的诱惑,无论这类挑战可能多么令人兴奋。

要有主见

平台所有者必须对范围做出决定性的选择。客户会要求一切可以想象的东西,但说“不”保护了平台的完整性。不受欢迎通常意味着良好的决策,因为用卓越的表现做好更少的事情比做很多糟糕的事情要好。

 

考虑关系数据库引擎:你真的需要 MySQL、Postgres、Oracle、CockroachDB 和 MS SQL 吗?专注于主流的 80%用例。接受你不能取悦每个人的现实,有时客户必须适应你的平台,而不是要求无尽的定制。

 

经验表明,太频繁地说“是”会导致不可持续的扩张。资源在太多倡议中过于分散,导致维护不善、不稳定和客户不满的结局。一开始就让一些用户失望比最终让每个人都失败要好。

 

退役技术债务需要类似的决心。尽管用户会抗议,但必须停用他们心爱的但过时的系统。没有客户想要移植他们的应用程序,但平台的可持续性一定需要这些艰难的决策。魔法在于在保持决心的同时,以同情心管理这些过渡。

一直“贪婪”下去

平台决策需要长期思考。就像带一只小狗回家,你不仅仅是承诺一个温馨的开始,更是承诺多年的照顾和喂养。那只可爱的小狗变成了需要散步、食物和兽医护理的狗,持续十年甚至更长时间。平台需要类似的长期承诺。

 

一旦客户部署在了你的平台上,你就隐含地承诺了对他们多年的支持。在接受新责任之前,请考虑你是否愿意在未来十年内资助功能团队,处理维护工作,并在任何情况下提供支持。

 

从错误中学习有助于完善决策。例如,首先使用 Tomcat,然后是 Docker,接着是 Mesosphere,最后采用 Kubernetes 构建多个容器平台,这些举动造成了迁移噩梦。每个平台都积累了大量抵制迁移的客户。有时等待行业共识比早期采用更明智。

 

让社区创新提供宝贵的信号。六个不同的团队各自独立构建了 Kafka 实现,表明了一种对共同平台的真实需求。创新的艺术在于时机,不要太早,当共识仍然不稳定时不要行动;也不要太迟,当碎片化已经发生时就为时已晚。

共享责任

平台提供商和消费者之间有一个隐含的共识,那就是明确的文档对双方都有好处。除了 API 合同和 SDK 之外,还要澄清控制边界、正常运行时间预期、服务水平目标(SLO)和维护窗口。

 

明确预留每季度用于有状态数据库的补丁窗口,以防止未来的冲突。没有事先沟通,客户将抵制任何停机时间。记录 SLO,持续测量它们,并公开讨论它们。

 

明确责任分工。平台可以提供许多服务,但不是料理一切。可以将问题视为冰块与雪花:平台可以高效地生产各种冰块形状,但每个独特的雪花都需要定制工艺。明确能力和限制,使合作伙伴关系富有成效。

抽象,不要混淆

客户有不同的需求和舒适度。有些人更喜欢 UI 交互而不了解底层机制,例如大多数汽车驾驶员,他们只想要可靠的交通工具而不了解引擎。其他人更喜欢 Terraform 配置或直接 API 访问。

 

构建多个抽象层次,同时保持对它们的可访问性。当出现问题时,用户需要看到底层系统。如果平台完全混淆内部组件,故障排除会变得不可能。

 

从汇编语言到编译器再到 AI 辅助编码的演变展示了连续抽象层的发展。每个新层在需要时提供价值,同时保持对较低层的访问。现代开发人员可以通过 AI 生成整个应用程序,同时在必要时仍然能够检查和修改生成的代码。

 

关键是不要为所有人简化平台交互,而是提供多个抽象层次,并允许客户在他们认为合适的地方进入。

站在巨人的肩膀上

开源已经改变了平台建设,特别是在金融服务领域。艾萨克·牛顿关于科学发展建立在先前研究和洞察之上的著名见解(“如果我看得更远,那是因为我站在巨人的肩膀上。”)完美地预见了开源的价值主张。社区提供了巨大的心智份额、共享的工程资源、持续的创新、由于共同组件而产生的可移植性,以及通过可见代码实现的前所未有的透明度。

 

例如,Linux 现在为大型金融机构的一众关键交易和银行系统提供动力。Kafka、Cassandra、Kubernetes、Postgres、MySQL 和 Terraform,这些开源基础允许平台构建者专注于差异化而不是商品基础设施。

 

开源不是免费软件:没有免费的午餐,无论许可模式如何,开发人员都需要补偿。开源的价值来自社区协作、可移植性和标准化。例如,Postgres 在 AWS Aurora、Azure 和 GCP 上运行,几乎不需要修改,提供了真正的可移植性。

 

开源并没有减少专有软件的价值,相反,它为平台建设提供了独特的优势。开源基础与专有差异化的结合创造了强大、可持续的平台。

建立文化,其余的自然而来

大规模的平台建设需要多个团队构建不同的组件,这些组件必须一致地集成。实现这种一致性需要正确的文化。伟大的文化创造伟大的团队,伟大的团队构建伟大的产品。不要将临时成功与可持续的卓越混淆;可重复性需要文化基础。

 

三个文化维度至关重要。首先,授权团队在不寻求许可的情况下做出决策,但要在预先定义的边界内。团队需要自由地在他们的核心职责上创新,同时遵守平台标准。

 

其次,思想多样性防止了群体思维并推动了创新。同质化团队缺乏卓越所需的创造性张力。当你的朋友雇佣有类似背景和经验的朋友时,你最终会得到十个相同思维方式的人。建立多样化的团队需要有意识的招聘、晋升和管理实践。

 

第三,以团队为导向的领导有时需要为了团队的动态牺牲个人偏好。优秀的团队需要平衡的组成,这意味着有才华的个体可能需要移动到他们能最有效地贡献的地方。

 

文化转型需要数月到数年的时间,而不是几天到几周。这种对文化的长期投资代表了最重要的平台建设活动。每天都关注文化将为其他一切奠定基础。

总结

平台渗透到现代生活的方方面面,层层叠加。就像地质层一样,每个平台层为下一个平台层提供基础。伟大的平台实现了如此强大的稳定性,以至于用户认为它们是理所当然的。它们拥有永久性,而不需要思考。

 

平台建设依旧是无名英雄的工作。当平台完美运行时,没有人会打电话庆祝,只有在出现问题时才会打电话。最高的赞美是沉默。成功意味着保持透明、未知和无名。当用户开始直接打电话给你时,说明平台出了问题。

 

这些原则为构建他人可以依赖的平台提供了一个框架,这些平台隐藏了复杂性,同时提供价值,是为持久而建的平台。无论是构建基础设施、创建内部工具还是开发任何其他人将使用的软件,这些原则都指导着通向真正可扩展的弹性平台的路径。

 

这段旅程需要耐心、纪律和对卓越的承诺,而结果将使其他人能够构建他们自己无法独立创造的惊人事物。

作者介绍

Matthew Liste 是美国运通的执行副总裁兼全球基础设施主管。在这个职位上,他负责监督公司的全球技术基础设施服务和资源,包括工程和运维,以及所有业务线的现场可靠性工程和应用支持。他之前在摩根大通,最近担任全球技术基础设施平台服务主管,监督银行平台基础设施的设计、建设和管理。他的成就包括领导银行私有云平台的孵化和构建以及对公共云的采用,结果让该银行很大一部分应用程序组合现在运行在混合云平台上。Matthew 因建立了强大的创新和工程学科文化而受到广泛认可。在加入摩根大通之前,他在高盛工作了近十年,并于 2011 年被任命为董事总经理和技术研究员。在他任职期间,他担任过几个工程职务,包括网络工程、全球网络/语音运营以及计算和存储工程。

 

原文链接:Building Resilient Platforms: Insights from Over Twenty Years in Mission-Critical Infrastructure

2025-11-18 11:1814

评论

发布
暂无评论

什么是中国企业信息化

秋去冬来春未远

数字化信息化中国文化

SeekTiger迎来新征程,STI即将登录Gate.io

BlockChain先知

2022观测云产品发布会前瞻:这是一份给IT工程师们的礼物

观测云

【直播预告】优化器及 Flink CDC + OceanBase 全增量一体化数据集成方案

OceanBase 数据库

OceanBase 社区版

架构训练营-作业八

默光

消息队列 训练营

压力如同下雨一样具有存在的必要性,我和你交个朋友吧。

叶小鍵

react源码解析10.commit阶段

buchila11

React

jackson学习之八:常用方法注解

程序员欣宸

4月月更

论语音社交视频直播平台与 Apache DolphinScheduler 的适配度有多高

白鲸开源

逐向双碳:绿色计算的误区与正确打开方式

脑极体

多模块项目 mybatis mapper bean 找不到问题

Z冰红茶

[Day13]-[动态规划]爬楼梯

方勇(gopher)

LeetCode 数据结构和算法

渗透测试系列之靶机渗透

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 漏洞挖掘

宜搭小技巧|自动计算日期时长,3个公式帮你搞定!

一只大光圈

低代码 数字化 钉钉宜搭 宜搭

阿里云PolarDB开源数据库社区与 Tapdata 联合共建开放数据技术生态

阿里云数据库开源

数据库 阿里云 polarDB PolarDB-X

分布式shiro权限验证

Rubble

4月日更

开启 JSON 和多模,让生态更多可能 | OceanBase 社区版 3.1.3 发版

OceanBase 数据库

OceanBase 社区版

cdr2022订阅版本安装包

茶色酒

cdr2022

从架构上详解技术(SLB,Redis,Mysql,Kafka,Clickhouse)的各类热点问题

利志分享

架构 #热点问题

P5直升P7!“阿里爸爸”最新出品年薪30W~120WJava架构师学习路线

Java全栈架构师

程序人生 IT java程序员 java面试 java架构

Web3 和区块链技术:数字资产所有权如何颠覆当前的商业模式

CECBC

在线标准程序员计算器

入门小站

工具

领导看了我写的关闭超时订单,让我出门左转!

阿Q说代码

RabbitMQ 延时队列 4月月更 关闭订单

linux之chsh命令

入门小站

Linux

动态压测模型让工作更轻松

FunTester

详解动静态缓存各种方式

穿过生命散发芬芳

4月月更

智能风控中台设计与落地

第四范式开发者社区

人工智能 自动化 金融 中台架构 风险控制

在线CSV转TSV工具

入门小站

工具

redis中报too many connections错误的解决

杨彦星

redis

带你了解什么是DHCP,为什么要用DHCP?

乌龟哥哥

DHCP 4月月更

Android C++系列:JNI开发准则

轻口味

c++ android 4月月更

构建弹性平台:来自关键任务基础设施领域逾二十年经验的见解_管理/文化_InfoQ精选文章