实时API：Mike Amundsen谈关于速度和可观测性的设计

本文要点

• “IDC MaturityScape：数字转型平台1.0”报告指出，有71％的组织预计在未来两年内API的调用量会增加。 有59％的组织期望一个典型API请求的延迟小于20毫秒，而93％的组织期望延迟小于50毫秒。

• 根据同一份报告，正在构建的新应用程序有90%将采用微服务架构，35%的生产应用程序将是“云原生”的

• 为了满足对基于API系统这种日益增长的需求，需要考虑三个方面：性能架构、性能监控和性能管理。

• 良好的架构实践包括避免简单地“平移”到云上，采用异步处理，以及重新设计数据和网络。

• 了解一个系统及由此产生的性能，并能够识别瓶颈，对实现性能目标至关重要。此外，还必须从运维角度（SLIs）和业务角度（KPIs）对服务进行监控。

在最近的 apidays网络研讨会上， Mike Amundsen，培训师兼 O’Reilly 新书 《API流量管理101》的作者，提出了“ 高性能API：基于规模的速度架构设计”。根据 IDC 最近的研究，他认为，企业必须推动系统性变革，以满足未来日益增长地对通过 API 消费业务服务的需求。需求的这种变化既与运维规模的增加有关，也与响应时间的缩短有关。

客户期望本质的不断变化，再加上新的数据驱动产品和前沿（移动、物联网等）消费的增加，意味着这种对低延迟“实时 API”的需求正迅速成为一种常态。

最近，对云技术和基于微服务架构的采用，加快了整个业务领域的创新和开发速度。

然而，这种技术和架构风格对创建高性能的应用程序并不总是有利；在云上，几乎所有的内容都通过虚拟化的网络进行通信，而在面向服务的架构中，通常会调用多个独立的流程来实现每个业务功能。Amundsen 表示，为了满足新的需求，需要对系统的设计、运维和管理方式进行一系列整体性的改革。

性能要求

Amundsen 在演讲开始时描述了他在整个 IT 行业中看到的“性能要求”。他首先关注了生态系统的转型，引用了 2019 年 IDC 的一份研究报告“ IDC MaturityScape：数字化转型平台1.0”。该报告指出，未来 10 年，75％的组织将彻底地实现数字化转型，而那些没有采用现代化工作方式的组织将无法生存。到 2022 年，正在构建的新应用程序有 90％将采用微服务架构，35%的生产应用程序将是“云原生”的。

随着越来越多的组织采用数字化转型，API 调用量也在增加。根据同一份报告，有 71％的组织预计在未来两年内 API 的调用量会增加。大约有 60％的人预测每月 API 的调用量会超过 2.5 亿次（每个工作日约 1000 万次）。人们也越来越关注事务的响应时间，有 59％的组织期望一个典型 API 请求的延迟小于 20 毫秒，而 93％的组织期望延迟小于 50 毫秒。

Amundsen 认为，为了满足组织日益增长的需求，需要考虑三个方面：性能架构、性能监控和性能管理。

性能架构

将应用程序迁移到云供应商的平台可以带来很多好处，比如能够利用数据处理或基于机器学习的服务进行快速创新，或降低组织平台的总体拥有成本（TCO）。然而，就配置和性能而言，云基础设施都与传统硬件有很大的不同。Amundsen 警告说，对现有应用程序进行“平移”（“lift and shift”）不足以确保性能。

云平台中的绝大多数基础设施组件和服务都是通过网络连接的，例如，块存储通常被实现为网络附属存储（NAS）。组件的托管也不能保证，例如，API 网关可能与运行后端应用程序的虚拟机（VM）位于不同的物理数据中心。云平台的全球覆盖为接触新客户提供了机会，也提供了更有效的灾难恢复（DR）选项，但这也意味着客户与服务之间的距离可能会增加。

Amundsen 建议工程团队应遵循与微服务架构风格相关的最佳实践，将组件重新设计为更小的服务。这些服务可以独立发布独立扩展。采用异步通信方法（如消息传递和事件）可以减少等待状态。从最终用户的角度来看，这提供了 API 调用快速返回确认并减少延迟的可能性，即使实际的请求工作已经在后端排队了。工程师还需要建立事务撤销和恢复流程，以减少不可避免的故障影响。这个领域的其他思想领袖，比如 Bernd Ruecker，鼓励工程师构建“ 智能API”，并学习更多关于业务流程建模和 事件源的知识。

为了使系统按要求执行，数据的读写模式经常需要重新设计。Amundsen 建议使用缓存结果是明智的，这可以消除不断查询上游服务的需求。在整个端到端的请求处理过程中，数据可能还需要被适当地“暂存”（“staged”）。例如，通过内容分发网络（CDNs）在本地化的提供点（PoPs）缓存结果和数据，在 API 网关中缓存，以及跨可用性区域（本地数据中心）在全局范围复制数据存储。对于某些事务吞吐量高的用例，可能需要对写入操作进行流处理才能满足需求，例如，数据先写在本地，或者写入 Apache Kafka这样的高吞吐量分布式日志记录系统中，以便在以后的某个时间点再写入到外部数据存储中。

工程师可能需要“重新思考网络”（ 尊重分布式计算的八个谬误），并按照与云供应商和应用程序架构相关的最佳实践来设计他们的云基础设施。为了满足需求，可能还需要减小请求和响应的大小。这可以与增加消息量的能力串联起来一起设计。业界可能会看到“RPC 的回归”，其带有强类型的通信契约和高性能的二进制协议。尽管 JSON 非常方便，但与 HTTP 相比，它在序列化和反序列化中需要大量的计算（和时间），并且通过网络发送基于文本的消息，其有效负载通常会更大。

性能监控

了解一个系统及由此产生的性能，并能够识别瓶颈，对实现性能目标至关重要。可观察性和监控是任何现代应用程序平台的关键方面。从机器到网络堆栈的各个方面，都必须对基础设施进行监控。从高级 API 网关和服务网格实现到云软件定义网络（SDN）组件，再到实际的虚拟化和物理网络硬件，现代的云网络可能包含许多层，并且这些都需要被有效地仪表化。

还必须从运维角度和业务角度对服务进行监控。越来越多的组织采用站点可靠性工程（SRE）方法来定义和收集用于运维度量的 服务等级指标（SLIs），其中包括 利用率、饱和度和错误（USE）或 请求率、错误和持续时间（RED）等顶级指标。业务指标通常与关键绩效指标（KPIs）有关，而关键绩效指标则由组织的目标和关键结果（OKRs）来驱动。

随着基础设施发布了度量标准并且服务生成也要基于 SLI 和 KPI 的度量标准，相应的数据必须能被有效地捕获、处理、并提交给关键利益相关方，以便其对此采取行动。这既是技术挑战，也是 文化挑战。

性能管理

Amundsen 指出，组织应该致力于创建一种“仪表盘文化”（dashboard culture）。监控顶级指标、用户流量和持续交付过程以便“洞察”系统的运行情况，这一点是至关重要的。正如 Nicole Forsgren 博士及其同事在 《Accelerate》一书中所述，与高性能组织相关的四个关键指标是交付周期、部署频率、平均恢复时间（MTTR）和变更失败率。工程师应该能够使用内部工具来有效地解决问题，比如控制对功能的访问、扩展服务和诊断错误。

增加安全缓解措施通常会与性能发生冲突，例如，添加安全验证层会降低响应速度，但这是一种微妙的平衡行为。工程师应该了解系统及系统的 线程模型，以及是否存在任何迹象能指明当前的问题，例如 HTTP 503 错误码生成的越来越多，或者网关的流量过载。

云基础设施的弹性本质通常能够几乎无限的扩展，尽管可能会带来无限的成本。然而，性能管理的文化要求能够轻松了解当前系统是如何使用的。例如，工程师需要知道，在任何给定的时间点，当看到负载增加时，对特定组件进行扩容是否是一种适当的响应。

在基于云的微服务系统中诊断错误，除了需要用工具来收集、处理和显示度量指标、日志和跟踪信息之外，通常还需要有效的用户体验（或开发人员体验）。仪表板和工具应该能显示与客户体验相关的顶层指标，还应该允许工程师通过下钻查看 各个服务到服务的指标来测试假设是否存在问题。能够回答有关可观察性或监控解决方案的特殊问题， 是一个当前相当活跃的研究和产品开发领域。

一旦获得了洞察和解决问题的能力，性能管理的下一个阶段就是提前预测能力。这是一种从故障中自动恢复的能力，即建立 反脆弱（Antifragile）系统的能力，以及对系统进行试验的能力，例如通过使用 混沌工程来检查容错性。

总结

Amundsen 在演讲结束时，再次提到了 IDC 的研究报告。 IT 行业应做好准备，以应对 API 调用量增加和事务处理时间需减少的需求。支持这些新需求需要进行组织和系统范围的变革。

软件开发人员必须要学习如何重新设计服务，重新设计数据，以及如何对服务进行检测，以提高对运维和业务指标的可见性。平台团队也必须重新思考网络、基础设施监控和流量管理。应用程序运维和 SRE 团队需要跨工程组织开展工作，以便能够有效地识别和解决问题，并预测问题及进行实验。

有关本文讨论主题的更详细的探索，可以在 Mike Amundsen 最近出版的 O’Reilly 新书《 API流量管理101》中找到。

作者简介

Daniel Bryant 是 Datawire 的产品架构师，并且担任 InfoQ 的新闻主管和 QCon 伦敦的主席。Daniel 目前专注于“DevOps”工具、云/容器平台和微服务实现。他还是伦敦 Java 社区（LJC）的负责人，为多个开源项目做出过贡献，为 InfoQ、O’Reilly、DZone 等知名技术网站撰写过文章，并定期出席 QCon、JavaOne 和 Devoxx 等国际性会议。

原文链接：

https://www.infoq.com/articles/realtime-api-speed-observability/