BLOG | NGINX

如同管理四星级餐馆一样管理 API

Karthik Krishnaswamy

Published February 16, 2024

本文转载自 The New Stack。

waiters in a restaurant
特写图片来源：Pixabay

本文是系列博文（共四篇）的第三篇。

旧金山 Benu 或巴黎 Guy Savoy 等知名目的地餐馆确实值得一去。其就餐服务无可挑剔，不仅每盘餐食都精心搭配，让人回味无穷，而且上菜顺序讲究，间隔时间短。一走进厨房，首先映入眼帘的是一片干净整洁的环境，其中主厨和帮厨各司其职，默契配合，犹如共跳锅碗瓢勺之舞。当大批用餐者涌入时，前台员工会把他们带到吧台去品尝小吃并浅酌一盏。最重要的是，整个用餐体验都得到了严格控制、管理和优化。

想必您的 API 团队无需烹饪巧克力蛋奶酥或刷盘子，但高档餐馆运营与 API 生命周期管理有着惊人的相似之处。从试验厨房到厨房烹饪，从供应商管理到确保非预约顾客不会插队或信用卡付款不会被盗刷，在必要的规划、协作、协调以及一套严格的点餐上菜和菜品介绍标准之下，这种多工序、多模式流程让餐馆就像一首精彩绝伦的交响乐一样有序运转。

试验厨房：API 协作与设计

试验厨房是奇幻之源。在此协作环境中，主厨及其团队共同尝试新菜谱，改良现有菜谱，想方设法博得用餐者的交口称赞。

在平行的技术领域，API 主管可能有不同的头衔，例如 API 工程总监或产品、API 和集成副总裁。他们与平台运维或 DevOps 团队展开紧密合作，首先为企业 API 创建一个高级架构，然后制定出更具体的规则和惯例，如同菜谱一样。

这个 API 工作空间是一个协作空间。在 SwaggerHub 或 Postman 等 API 发布套件上，存储着 API 实操指南库，可供团队成员提取业经审查且记录详细的现有 API（例如地理信息系统、块存储或支付处理）用作复杂的复合型应用的一部分。

备餐厨房：应用汇聚之地

在餐馆，经过测试的菜谱需要用到食材和基础配料（高汤、浆汁等）。在某些情况下，食材未经加工，需要备菜，比如水果和蔬菜。有些食材则是半成品，比如鱼贩送来的三文鱼片，或者是成品，比如瓶装葡萄酒。

这些食材好比第一手代码（从零做起）、微服务和内部 API（半成品）以及外部第三方 API（成品）。抛开复合型应用（整顿饭菜）来看，每个小应用只是一道菜。菜肴和饮料搭配食用，带来就餐体验，即用户体验。

厨房员工就像应用开发团队，将认可的菜谱中列出的各种食材组合起来，制作出一盘盘美食。在数字世界中，我们通过消费图像和视频，或使用 CRM（客户关系管理）和视频会议工具来“享用”应用输出。

催菜员和传菜员：API 网关

催菜员站在厨房门口，确保及时将美食送到用餐者桌上。催菜员相当于 API 网关，负责执行策略、监控流量并确保遵守所有规则。在厨房外面，传菜员将菜品送到服务员手中，再由服务员上菜。这些传菜员类似于负载均衡器和 Ingress controller（Ingress 控制器），它们与 API 网关协同运行，确保客户请求按正确的顺序传达，并最终到达正确的位置。

前台和服务员：餐馆负载均衡器

高档餐馆的前台员工在接待顾客和让顾客满意方面都很有一手。前台还负责把关，确保在繁忙的周五晚上所有想要入店就餐的顾客都已提前预约。前台团队还能够识别常客 —— 这些顾客不分时段均可落座就餐，并享受高端服务。

在 API 管理中，前台就是负载均衡器，负责防止系统被流量淹没，确保只有经过验证的流量才能进入。

服务员为顾客提供的体验既代表着餐馆的形象，也彰显着餐馆的个性。他们推荐最新鲜的食材，确保准时上菜，并帮助顾客退菜，同时解释出错的原因。服务员就像 API 可观测层，可帮助后端了解用户的使用情况，同时发现故障点和性能欠佳问题。如果顾客要求换菜，或者出现摆盘杂乱问题，服务员便会做出相应处理。

外卖服务和包装产品：餐馆厨房的外部 API

随着 DoorDash 不断将 Omikase 的寿司或 Papalote 的麦西恩卷饼送到饥肠辘辘的旧金山人手中，餐馆显然正在从外卖中寻求收入来源。鉴于新冠肺炎疫情，餐馆迫切需要赚取外卖收入，并获得在线上线下提供保质期更长的零售产品所带来的诸多优势。

外卖和零售产品是外部 API，打包供合作伙伴或餐馆可能无法控制的其他渠道使用。事实上，近年来增长速度最快的一种餐馆便是只送外卖的幽灵厨房。他们是餐饮界的 Twilio，只提供外卖服务。我们前面提到的催菜员还负责核实这些外部需求是否得以预测、计划和满足。

如果外卖服务平台在未经同意或通知的情况下将餐馆添加到其商家列表中，那么餐馆的外部 API 可能会遭到恶意攻击，导致需求意外激增并影响客户体验 —— 例如，如果送餐时不小心或没有使用正确类型的保温箱。

菜谱和食材的生命周期：API 生命周期管理

正如技术和公司提供应用一样，餐馆也在不断演变，以谋求生存和发展。顾客的口味与时俱进 —— 前一年西班牙白葡萄酒颇受欢迎，后一年奥地利雷司令葡萄酒备受青睐。

API 架构领导者的工作与之大同小异：确保 API 符合现代要求，按需进行升级，有时还要添加全新形式的 API，例如 GraphQL。与此同时，餐馆还必须保留广受常客欢迎的典藏菜谱，因为这些菜谱永远不会过时。最好的厨房能够为常客准备几乎所有的经典菜谱。这就好比 API 的关键向后兼容性。企业必须能够从容地弃用旧版本，而非将其从服务中完全清除。

学会像厨师长一样思考，改善 API 管理

对于大多数复杂的技术来说，很难确定从何处开始使用 API 以及如何打造良好的文化和运维设施来建立出色的 API 驱动型业务。值得借鉴的是，优秀的厨师长在试厨之前，会对品相和口味有一个大致的想法。

首先，他们创建架构，然后为其美食制作建立语法和规则。他们与侍酒师、糕点师和各种美味食材的供应商密切合作，精心挑选出最合适、最可口的食材。厨师长先试验再完善，从试验环境移动到生产 “FoodOps”。他们始终密切关注工作场所中发生的一切，这种可观测性方法反映了现场可靠性工程师、AppDev 团队及其他任何性能负责人员的需求。

厨师长负责制定外部 API 使用规则，并与内部团队保持协商，以确保不会出现任何产能闲置问题。然后，当感觉到客户需要新口味时，厨师长就会查看其业务的 API，并确定有待升级之处 —— 原材料或第一方代码（蔬菜、水果）、微服务和内部 API（高汤、浆汁、糖霜、三文鱼片）或第三方 API（葡萄酒）。他们还将不断设法将餐馆的潜在产品重新包装成可供其他渠道使用的产品，以换取急需的边际收入。

最后，优秀的厨师长会赋能团队，帮助他们接管上述所有职责，而后自己慢慢地优雅抽身，将更多的精力放在菜品创新上。最好的餐馆在厨师长离职后也能照常运转并实现蓬勃发展。同理，API 程序应建立坚实的基础，并将客户需求放在首位。就像高档餐馆必须选用优质食材一样，一家富有弹性、适应性强的企业也必须拥有卓越的应用。如今，这意味着拥有出色的 API。愿您轻松搞定 API 管理！