开发API时需要关注的十三项指标

开发API时需要关注的十三项指标

首先我们来看看一个典型的软件企业团队都有哪些不同的职能角色。

基础架构与开发运营

通过正确地分配有限的资源,确保服务器能够正常地运转,以供多个工程团队使用。

应用工程与平台

API开发人员负责根据业务逻辑,向API添加新的功能,并解决应用程序中的问题。他们交付的产品包括:API即服务(API as a Service),与合作伙伴的插件和集成,以及其他丰富的API。

产品管理

API产品经理负责通过API功能的路线图,确保构建出正确的API节点;并通过工程的时间和人员条件的约束,来平衡(内部或外部)用户的需求。

业务与增长

这是一个由市场营销和销售人员组成的,面向市场的团队。他们并不会专注API节点,而是会紧跟客户的兴趣点,以确保他们能够使用到已开发出的API,并从中发现新的销售机会。

基础架构API指标

此类指标主要是应用性能监视(Application Performance Monitoring,APM)工具(如:Datadog之类的基础架构监视公司的产品)所获取。它们主要关注如下方面:

1、正常运行时间(uptime)

正常运行时间是衡量服务可用性的一项最基本的指标,我们有时也称为“黄金标准”。许多企业都会在服务水平协议(SLA)中提及,或重点标注出各种与服务相关的“正常运行时间”标准。如下图所示,我们在某些术语表中常见的“三个九”或“四个九”等,就是用来衡量某个服务系统每年的正常运行时间、与宕机时间之间的关系。

开发API时需要关注的十三项指标

当然,从“四个九”提升到“五个九”,远比从“两个九”变成“三个九”要困难得多,这就是为什么除了关键性的(也是最昂贵的)服务之外,您在SLA中鲜少看到“五个九”的原因。话虽如此,我们仍然可以在减少某些服务的正常运行时间的同时,确保其在中断的极端情况下,不会影响到既定的服务处理。例如:Moesif(一个美国人工智能API服务平台)就被设计为即使其网站和仪表板出现完全中断的情况,也能够继续通过各种SDK收集数据。也就是说,SDK能够在本地排队收集的信息,而不会中断现有的应用。

正常运行时间通常是通过诸如PingdomUptimeRobot的ping服务或综合测试来衡量的。您可以将探测的频率配置为每分钟之类的固定时间间隔,来探测特定节点的/health或/status,以获取诸如:数据备份等其他服务的基本连通性状态。您可以通过Statuspage.io之类的工具,将这些收集到的指标发布到目标网站上。例如:Moesif就使用了基于Lambda构建的开源状态页面(请参见:https://github.com/ks888/LambStatus)。

当然,我们还可以设置并使用一些被称为“综合测试”的复杂ping服务。例如:运行特定的一套测试序列,并判定响应负载中是否包含一定的数值。尽管综合测试可能无法代表用户真实的流量,但是这些调试性的API对于获悉系统的正常运行状态还是非常有意义的。值得说明的是:综合监控是由监控服务触发的一组预定义的API调用,能够检查目标API序列是否符合预期运行状态。

2、CPU使用率

CPU使用率也是非常经典的性能指标之一,它可以从某种程度上反应应用程序的响应能力。如果服务器CPU使用率较高,则可能意味着服务器或虚拟机已经过载,而且可能会带来诸如:大量自旋锁(spinlock)等应用程序的性能错误。

基础架构工程师可以使用CPU使用率(包括内存使用百分比),来规划资源,并衡量整体运行状况。某些类型的应用程序(例如高带宽的代理服务和API网关)本身就会比其他进程具有更高的CPU使用率,特别是在涉及到诸如视频编码、以及机器学习等大量浮点运算的工作负载时。

在本地调试API时,您可以通过Windows上的“任务管理器”(https://en.wikipedia.org/wiki/Task_Manager_(Windows) )或MacBook上的“Activity Monitor”,来轻松地查看系统和进程的CPU使用情况。但是在服务器上,如果您不想使用SSH或运行top命令,那么就需要用到各种APM工具了。通过APM提供的代理,您可以将其嵌入应用程序或服务器中,以捕获诸如CPU和内存使用率之类的指标。当然,您也可以通过执行其他特定功能的应用程序监控,例如:线程分析。

我们在查看CPU使用率时,应当主要关注的是每个虚拟CPU(即物理线程)的使用率。如果出现不平衡的情况,则可能意味着应用程序没有正确地执行进程,或者是线程池的大小配置不正确。

许多APM都能够让您使用不同的名称来标记应用程序,以方便实现汇总。例如:您可能希望对诸如:my-api-westus-vm0、my-api-westus-vm1、my-api-eastus-vm0等每一个VM指标进行分组,同时将它们汇总到一个名为my-API的标签之中。

3、内存使用

与CPU使用率类似,内存使用率也是衡量资源利用率的性能指标。较高的内存使用量可能表明服务器处于过载的状态,因此它往往与配置有关。

通常情况下,大数据查询、大流量处理、以及各种生产环境的数据库,都会消耗比CPU更多的内存。因此,为了减少每个VM在批处理查询时所花费的时间,我们应当分配更多的可用内存,以减少检查点(checkpointing),网络同步,以及对磁盘的分页。

我们在查看内存的使用情况时,还应该查看页面的错误数、以及I/O的操作数。常见的配置错误是:只为应用程序分配了一小部分的可用物理内存。这样就很可能会导致高页面的虚拟内存崩溃。

应用程序的API指标

4、每分钟请求数(RPM)

每分钟请求数(Requests per Minute,RPM)是我们在比较HTTP、或数据库服务器时经常使用的性能指标。由于服务器无法准确地计算出诸如:第三方服务在对数据库进行I/O操作时所引起的延迟,因此某些产品虽然会吹嘘自己拥有较高的RPM,但是您的团队仍然需要以效率为目标设法降低RPM。

通常情况下,您需要将具有多个API调用的某些业务功能,合并为更少的API调用,以减少RPM的数量。例如:您可以在单个请求中,批量处理多个请求,以确保自己具有灵活、实用的分页方案。

与RPM相关的术语包括:每秒请求数(Requests per Second,RPS)和每秒查询数(Queries per Second,QPS)。由于软件产品的RPM可能会在每周、甚至是一天中的每一小时都有所不同,因此您需要灵活地调整自己的API,以适应具体的峰谷值。

5、平均与最大延迟

在跟踪客户的体验时,API的延迟时间是一项非常重要的指标。虽然前文提到的CPU使用率之类的基础架构级指标的增加,可能并不会让用户及时感知到响应能力的下降,但是API的延迟肯定会。有时候,单独地跟踪延迟可能无法使您完全理解它为什么会增加。因此,我们需要通过跟踪API的各种变更,包括:新API版本的发布,新节点加入原有架构等方面,来找出导致延迟增加的根本原因。

由于宏观地检查总体延迟,可能会忽略真正有问题的慢速节点,因此我们需要按照路由、地理位置、以及细分字段来进行排查。例如:某个POST/checkout节点随着时间的推移而延迟加剧,这很有可能是由于某个未被正确索引的SQL表在不断增加所导致。但是,由于针对POST/checkout的调用数量非常少,因此该问题很容易被您的GET/items节点所掩盖,毕竟该节点的调用量远远超过了checkout节点。同理,如果您有用到GraphQL API,那么就需要查看每个GraphQL操作的平均延迟。

尽管许多开发与架构人员也会关注延迟问题,但是他们主要是通过检查一组VM的总体延迟,来确保VM不会过载,而不会深入地研究诸如每条路由等,针对应用程序的特定指标。因此,我们认为应用程序与工程人员更需要关注延迟的相关问题。

6、每分钟错误率

与RPM相似,“每分钟错误”(或简称错误率)是指每分钟产生的带有非200系列代码的API调用数量。通过衡量API的错误率、以及易错性,我们可以进一步了解正在发生的错误类型。例如:500系列错误意味着您的代码存在着问题,而400系列错误则意味着不当的API设计和文档。可见,我们在设计API时,使用适当的HTTP状态代码是非常重要的,具体请参见:https://www.restapitutorial.com/httpstatuscodes.html

API产品指标

值得注意的是,我们在此所讨论的API,不仅仅是指与微服务和SOA相关的应用接口,也包括那些独立的产品。此类产品正在变得越来越普遍,尤其在与新的合作伙伴开辟调用通道的时候。

那些以API为产品驱动的团队,既需要检查诸如错误和延迟之类的指标,也需要了解API的使用方式,包括为何无法实现其预定的效果等方面。

7、API使用量的增长

对于许多产品经理来说,API的使用率是一项黄金标准,可以衡量API作为产品的转换效果。一个好的API产品不仅应该没有缺陷,而且有着与日俱增的实际使用量。通常情况下,我们可以月为单位衡量API使用量的增长。

8、API专门使用者

当然,一个月内某个API使用的增加量可能仅来自于某一个用户账号,因此我们需要衡量API的月活用户(Monthly Active Users,MAU)或是API的专门使用者(unique consumers)。此类指标可以让您获悉用户的“拉新”和使用量增长的整体状况。同时,许多API平台团队也会将API的MAU与其网站的MAU相关联,以获取完整的产品态势。

9、使用API的头部用户

对于一些专注于B2B业务的公司而言,了解自己的API产品有哪些头部用户是非常必要的。这些少数头部用户通常会为您的公司带来更多的收入和转发推荐,因此您可以据此来调用对应的节点,并对它们采取进一步的细分,以获悉其使用特定节点的频率,和使用时的体验。

10、API的使用与留存

您也许正在疑惑到底是应该在产品和工程上投入更多,还是在增长上烧钱?光看用户的留存与流失是无法给出清晰的参考依据。毕竟有些用户虽然觉得您的API不够友好,但是迫于已经订阅的年度合同,而无法马上退订,但是他们并不会积极地使用您所提供的API​​。因此,我们需要跟踪的是API作为一种产品,在用户侧的实际使用情况。

11、首次进入时间(TTFHW)

作为一项重要的KPI,首次进入时间(Time to First Hello World,TTFHW),不仅可以跟踪API产品的运行状况,而且可以跟踪开发者的总体体验(developer experience,DX)。

如果您的API是一个吸引第三方开发人员和合作伙伴来使用的开放平台,那么您需要确保他们在首次调用时,就能够顺利流畅运用您提供的API来开发应用。TTFHW主要衡量的是:从首次访问目标网页到通过您的API平台进行首次事务的MVP集成时间。该指标不但适用于API本身,也能考察您的营销效果、以及配套的文档和教程。

12、每种业务交易的API调用

尽管一般而言,各种产品和业务的指标往往是多多益善的,但每一种业务交易的调用次数却是越少越好。该指标直接反映了API的设计水平。如果新的用户需要通过三次不同的调用,才能将数据组合到一起的话,那么这可能意味着该API没有找到正确的节点。因此在设计API时,我们应当考虑到业务交易本身、以及用户想要达到的目标,而不仅仅是能够提供的功能和涉及到的节点。此外,您还可能需要对API采取灵活的过滤和分页操作,具体请参见:https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/?utm_source=dzone&utm_medium=paid&utm_campaign=placed%20article&utm_term=13%20api%20metrics

13、SDK和版本的采用

许多API平台团队还可能需要维护大量的SDK和集成。与仅以iOS和Android为核心的移动端不同,您的平台上可能拥有十来个、甚至上百个SDK。因此,对它们进行持续维护往往既费时又费力。那么,您可以选择性地将一些关键性的功能部署到那些最受欢迎的SDK之中。同时,在弃用某些节点和功能时,您也需要询问那些头部用户的意见,以做出对于API或SDK的取舍,以及版本的权衡。

结论