变革措施

CDN Pro作为一个Serverless Nginx边缘云平台，不仅仅具备传统内容分发网络 (CDN) 所支持的缓存加速能力，还提供边缘可编程服务，参与者可将复杂的业务逻辑拓展到边缘计算领域。一些个性化的业务逻辑经常需要服务器进行大量的计算，例如加密算法、正则表达式操作和数据压缩等等。在 CDN 边缘云上运行它们不仅可以从源头卸载这些资源密集型活动，还可以显著减少延迟，为最终用户提供令人满意的体验。

然而，这种趋势并不总是反映在行业价格模型中。大多数 CDN 提供商主要根据流量（传送的字节数）或带宽（主要是 95p）收费。这个模型是几十年前创建的，当时大部分 CDN 成本是基于从 ISP 采购的带宽。当 CDN 仅用于交付高度可缓存的大文件 (HCLF) 时，该模型运行良好；然而，今天已不再是这种情况。例如，现代服务器可以轻松提供 40Gbps 的 HCLF；但是，要加速跨越太平洋的相同带宽的动态 API 服务，可能需要 500 台服务器。数据中心成本在很大程度上与服务器数量成正比。不同服务在资源消耗方面的巨大差异给 CDN 提供商及其客户带来了许多定价挑战。

为确保盈利，CDN 提供商必须将所有额外成本合并为每 GB 或每 Mbps 的价格。但在一项服务完全上线之前，准确估计它将产生的额外成本是不可行的。客户通常可以提供流量或带宽的大概数字，但他们无法说出需要多少台服务器。更不用说他们可能随时通过自助服务界面更改业务逻辑。正如我们在CDN Pro混合加速模式中提到过，根据传统CDN分业务加速模式来设定价格需要大量的猜测。因此，几乎不可能创建对所有客户和服务类型都公平的价格手册。

解决方案非常简单：引入对 CPU 消耗的收费。 CPU从云诞生之初就一直是云计算的计费项。因此，它被边缘计算所采用也就不足为奇了，这正是 CDN 正在发展的方向。

它是如何工作的？

由于 CDN 平台的资源是多个客户之间共享的，因此衡量每个客户的使用情况并不容易。即使是流量这个最常用的计费项，也只有应用层的数据才能准确统计。在较底层收集网络开销并将其归因于每个客户是非常棘手的，因此大多数服务提供商决定不去理会这个。衡量每个客户的 CPU 利用率可能更具挑战性。然而，早在 CDN Pro 项目开始时，我们就将此确定为必备功能。当我们决定基于 NGINX 构建边缘服务器时，我们的团队对 NGINX 的开源版本进行了广泛的更改。

NGINX 具有“事件驱动、非阻塞”的架构。每个请求在等待 I/O 时“进入睡眠状态”，在某些数据准备好处理时唤醒，然后在处理完成时再次进入睡眠状态。这在请求的生命周期中可能会发生多次。我们使用函数clock_gettime 在 Linux 上获取 CPU 时间量（以纳秒为单位），统计每个请求在每个活动间隔上花费的时间量并沿途累积。就像我们处理传输的字节数一样，我们在请求的生命周期结束时，会将消耗的总 CPU 时间写入访问日志；同时，也将 CPU 时间记录到流量日志中，以生成低延迟的按域名统计的用量报表。

虽然此方法可以准确测量 NGINX 进程在每个请求上消耗的 CPU 时间，但它不包括以下内容：

• 内核处理来自网络接口卡或其他I/O 设备的中断。
• NGINX 主进程执行的常见任务。
• 运行在同一台服务器上的其他服务，如日志预处理、监控等。

数据

CPU时间消耗指标

如上所述，CDN Pro 平台提供了一个衡量CPU消耗指标的时间序列趋势报表，支持您指定域名和时间粒度来查询CPU消耗量（以秒为单位）。有关此统计指标的详细信息，您可以阅读API文档：查询CPU使用时间 。这个CPU总时间与CPU消耗核数的关系，类似于总流量与带宽消耗之间的关系：

• 带宽消耗是返回每个时间间隔内传送的总流量，然后除以时间间隔，得出平均消耗带宽；
• CPU核数消耗是返回每个时间间隔内消耗的总的CPU运行时间，然后除以时间间隔，得出平均CPU消耗核数。

分发每个请求的CPU时间消耗

一个有趣的指标是处理每个请求的CPU资源量消耗（CPU总时间/请求数）。在 CDN Pro 服务的不同域名中，此比值在几微秒到几秒之间变化。以下是影响此比值的几个主要因素：

• TLS 握手：HTTPS请求比HTTP请求需要更多的CPU时间消耗。 HTTPS比HTTP多了SSL/TLS的过程，下图显示了按TLS连接顺序分组的每个请求的平均 CPU 时间。带有标签“1”的曲线对应于每个TLS连接中的第一个请求，带有标签“2”、“3”和“4”的曲线表示同一个TLS连接中的后续请求。第一个请求与后续请求的差值，反映了 TLS 握手所消耗的 CPU 时间。我们可以看到，使用 RSA-2048 证书的 RSA 连接平均消耗大约 2.0 毫秒（对应下图1：2.5ms-500μm）；相比之下，具有 ECDSA-256 证书的 EC 连接大约使用 0.9 毫秒（对应下图2：1.25ms-250μs）。

RSA连接的平均CPU消耗

EC连接的平均CPU消耗

• TLS 复用率：TLS复用率越高，均摊到每个请求的CPU消耗越少。 如果 TLS 连接被多个请求复用，则握手的成本由所有这些请求分担。

• 缓存命中状态：请求缓存命中率越高，CPU消耗越少。 一次命中通常占用较少的CPU时间，如下图所示的某个域名，HIT请求消耗约500μm，MISS请求消耗约1.5ms~2.5ms之间。

不同缓存状态的平均CPU消耗

• 响应的大小：响应文件越大，分发所需的CPU消耗越高。 更大的响应文件需要更多的 CPU 能力来提供，如下图所示，分发某个小于10MB的文件响应约消耗1ms ~ 1.5ms之间；分发某个大于10MB文件响应约消耗5ms ~ 7.5ms之间。

不同文件响应大小的平均CPU消耗

分发每GB流量的CPU时间消耗

另一个有趣的指标是分发固定数据量所需的CPU资源量消耗（CPU总时间/总流量）。根据业务类型不同，分发1GB流量所消耗的CPU时间存在比较大的差异。通常情况下，HCLF高缓存大文件内容域名每GB流量消耗的CPU可能不到1秒，API纯动态服务相比下可能需要数百倍的CPU时间消耗。

下表是来自具有千兆字节流量的 CDN Pro 客户线上域名的经验测算数据。CPU 时间列表示处理每 GB 数据所需的 CPU 时间（为了保护隐私，我们将具体域名隐藏）。

计费

上面的数据清楚地佐证了本文第一部分提出的观点：仅根据网络流量对 CDN 服务收费是不公平的。这种方法类似于仅根据重量对超市中的所有商品进行收费。

引入按 CPU 时间计费，可确保每个客户就其使用的资源公平地分摊价格。CDN Pro已正式公开此新的计费方式。了解更多CDN Pro的定价模型，您可以阅读：CDN Pro产品计费。