原文towardsdatascience.com/real-time-analytics-solution-for-usage-based-api-billing-and-metering-f9e7a350f707https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/bc3fc0794df3b6b24738b3e01f4ab572.png照片由 Doris Morgan 在 Unsplash 上提供免责声明本文作者在 Redpanda 担任开发者倡导者Redpanda 是所讨论解决方案的关键组件。作者还带来了在 API 管理和 Apache Pinot 方面的先前专业知识。因此所提出的解决方案是这些技术的组合旨在解决一个普遍存在的问题。API 业务指的是将服务或功能打包成一组 API应用程序编程接口产品并将其销售给新客户和现有客户的公司。客户可以将这些功能集成到自己的应用程序中。公司可以通过根据客户对 API 的使用情况收费来产生收入。运营 API 业务的公司需要一个数据基础设施组件来跟踪 API 调用量并根据调用量向消费者收费。在这篇文章中我提出了一种使用 Apache APISIX, Redpanda, 和 Apache Pinot 构建实时 API 使用跟踪解决方案的参考架构。本文更侧重于“为什么”而不是“如何”。将其视为一个解决方案设计练习而不是详细教程。我的目标是帮助您提取解决方案模式作为蓝图使其在未来项目中可重用。不再拖延让我们开始吧。API 和 API 管理如果你对 API 和 API 管理概念还不太熟悉让我先快速介绍一下。API 是一种通过网络向消费者提供的企业能力。在数字业务中API 允许以编程方式访问业务操作消除了人工干预。这些业务操作可能包括创建订单、转账资金到更新 CRM 中的客户地址。商业中典型的 API 环境涉及三方后端系统– 这些是运行业务操作的系统。消费者– 希望消费业务操作的甲方和乙方应用程序。API 代理– 位于中间的代理中介。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/b353d89f6bc8a4a98c04755d5a6bd558.png作者提供的图片API 的作用是将内部业务系统与消费者分离从而消除消费者处理后台系统复杂性的需求。这样它充当了一个抽象层。API 跨越各种通信协议其中 HTTP 是最常用的。这就是你看到 RESTful 和 GraphQL API 风格的地方。在生产环境中组织通常使用全生命周期 API 管理平台来管理 API 生命周期的不同阶段例如 API 代理设计、部署、运行时策略参与和监控。API 管理平台为每个阶段捆绑了专门的组件。在本文的上下文中我们将使用 Apache APISIX这是一个在 Apache 许可证下分发的开源 API 管理平台。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/b0b1780598e3f41c026c4a2fb345e825.png图片由作者提供话虽如此我们在这里构建的解决方案并不紧密耦合于 APISIX。它可以与市场上大多数全生命周期 API 管理产品集成前提是它们提供适合集成的接口。利用 API 赚钱接下来让我们看看如何利用 API 赚钱。也就是说制定一种基于消费者使用情况的盈利策略。让我举一个现实生活中的例子来更好地解释。考虑一家为购房者提供即时房产估值的房地产估值公司。这些估值基于简单的因素如邮编、房产类型和区域。目前该公司仅提供基于网络的用户界面。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/e9ede38f330ece181b42fd813456696d.png图片由作者提供为了扩大业务运营吸引更多客户并进入新的市场细分领域这家公司决定成为 API 业务。这意味着他们将估值引擎打包成一系列 API 产品将它们卖给新客户和现有客户并根据他们的 API 调用使用情况向他们收费。这是通过首先隔离估值引擎并将其放置在 API 管理平台之后实现的。这使得消费者可以通过一组 API 访问其功能。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/ce644d2bc6b2a2e58048031656f45175.png将估值引擎隔离出来是成为 API 业务的第一步 – 图片由作者提供估值 API 将吸引来自各个领域的潜在消费者包括但不限于房地产公司– 为购房者提供准确的估值数字。银行– 在批准抵押贷款之前进行房屋估值。保险公司– 为家庭和内容保险提供更准确的报价。政府– 容易计算财产税。API 盈利模式那么这家公司是如何赚钱的呢将估值 API 打包成一系列 API 产品并以订阅层的形式销售它们订阅级别是一个配额允许消费者每月进行固定数量的 API 调用。如果这个配额超过消费者将被限制或将被收取超额使用费。例如估值 API 可以提供以下三个订阅级别。青铜会员每月10k请求黄金会员每月100k请求白金会员每月无限请求https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/7626d679fe67d402d46449c0e7b59af8.pngAPI 货币化模型消费者可以根据预期的使用情况订阅 API从各种级别中选择。月底公司将根据消费者的实际使用情况向他们收费。我们的目标是找到一个高效且可靠的方法来衡量每个消费者的 API 使用情况。规划解决方案现在我们已经了解了我们试图解决的问题让我在深入实施之前带您了解一些设计决策。KPI 指标第一步是确定我们从解决方案中期望的 KPI 或指标。我特别感兴趣的是以下五个。API 使用– 消费者随时间进行的 API 调用API 延迟– 端到端延迟以发现缓慢的 API唯一用户– 每个 API 有多少唯一调用地理使用分布– 大多数 API 用户来自哪里错误计数– 更多的调用故障意味着后端存在问题理想情况下我希望看到所有这些都在这样的仪表板上可视化。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/f3897400c8c1496ef2a898dab753a33d.png利益相关者第二个设计决策是解决方案的利益相关者 – 解决方案应向哪些人提供这些指标。主要有三个方。客户和合作伙伴– 消费者希望在一个实时仪表板上看到他们的配额使用情况以及账单估计。API 运营团队– 这个团队管理 API 管理基础设施特别关注 API 的健康信息如延迟、吞吐量、错误等。API 产品团队– 这个团队拥有 API 产品。他们想进行临时实验看看哪些 API 更受欢迎消费者的统计数据等。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/39ba81d5c3b2394432d105beee672844.png应该向谁提供指标 – 作者图片批量或实时作为最终的设计决策我会在实时和批量指标之间进行 80:20 的划分。数据随时间失去价值。我们越早处理它就越早可以采取适当的行动。因此我们将使 API 流量和健康指标实时化。考虑一种情况消费者 API 密钥被泄露。一个恶意 API 客户端使用被盗的密钥或身份验证令牌代表消费者调用 API。系统可能会检测到 API 密钥的突然流量激增将其识别为异常并阻止密钥同时向消费者发出警报。在收到警报后消费者可以立即重新生成 API 密钥以最小化成本。然而并非每个用例都需要实时处理。一些用例非常适合批量处理例如客户的按月使用量计费报告。为运营团队提供的每周 API 健康报告。为产品团队提供的每日 API 流量报告。实现现在我们已经到达了这篇文章的中间部分这也是我向您展示基于我们迄今为止讨论的以下解决方案架构的地方。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/ca86804634326b7c122d1cf69d817af6.png解决方案架构 – 作者图片我知道这个图很拥挤其中有很多未知的技术。所以让我将其分解为三层并详细讨论每一层。数据收集正如我之前提到的API 管理系统有几个部分在执行 API 生命周期管理操作如设计、运行时方面如流量整形、身份验证和订阅管理。还有更多方面。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/ad497c8a727e2d76584fb9fe880e5916.png典型 API 管理平台的架构组件然而我们最感兴趣的组件是 API 网关。所有 API 流量都通过它流向后端。我们的首要任务是确定 API 网关中的一个接触点。这将使我们能够收集往返的 API 请求和响应。然后我们将构建一个数据管道将此信息实时移动到分析数据存储中便于未来的查询。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/3ad83d94e1432fbbdb2613c55551de46.png分析管道 – 初步设计作者图片然而在实现这个写入路径时直接将数据写入底层数据存储可能会引入几个问题。APIM 系统和分析基础设施之间的紧密耦合– 在未来切换到新的 APIM 供应商时你可能会重写分析基础设施的很大一部分。同步写入– 当系统运行时两个系统都必须可用这使得很难将分析系统关闭进行维护。可扩展的数据摄取– API 网关上的突发流量激增会压垮分析系统迫使两个系统必须同时扩展。这促使我们在 APIM 和分析基础设施之间放置某种类型的缓冲区解耦 APIM。一个流式数据处理平台如 Apache Kafka非常适合这里因为它能够以低延迟从 API 网关摄取高吞吐量数据流。我们将在解决方案中使用Redpanda一个与 Kafka API 兼容的流式数据处理平台因为它在性能和简单性方面优于 Kafka。然而如果你坚持只使用 Kafka那也行。该解决方案对这两种技术都无缝工作。在中间使用 Redpanda 后我们的数据管道看起来是这样的https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/e8ce8f0d6cdb0a37225d8c227afd8468.png中间包含 Redpanda/Kafka 的数据管道作者图片Redpanda 的添加解耦了这两个系统并使写入路径异步。这使得分析系统可以离线进行维护并从上次停止的地方继续。此外Redpanda 可以吸收突然的交通高峰防止分析系统过载并需要扩展以匹配 API 网关。现在的问题是如何将 APISIX 和 Redpanda 连接起来。幸运的是APISIX 提供了一个内置的数据接收器用于 Kafka。每当向网关发出 API 请求并返回响应时这个接收器就会实时地将一条记录发布到 Kafka 主题。我们可以使用这个接收器与 Redpanda 一起使用因为它与 Kafka API 兼容。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/0388d77555f4d628e0b1a8bc0e65ed29.png作者图片APISIX 将单个 API 调用格式化为 JSON 事件并包含关键指标如延迟、HTTP 状态和时间戳。这些将被映射到分析数据存储的相关维度。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/b5988ec62c74cc77cc22654ac52a65a7.pngAPISIX 网关的 API 调用事件示例如果 API 管理平台没有提供 Kafka 接收器怎么办嗯你可以将 API 网关的 HTTP 访问日志作为替代方案流式传输到 Kafka。你可以使用 Filebeat 或类似的工具来做这件事。分析数据库现在我们已经将 API 调用事件落地到 Redpanda下一步是确定合适的分析数据库技术。它可能是一个 OLTP 数据库、键值存储或数据仓库吗让我们根据以下期望来评估它们。流式数据摄取– 必须能够从实时数据源如 Kafka摄取。这里不应该有任何批量数据加载。流式摄取确保了更高的数据新鲜度。低延迟查询– 查询延迟必须在亚秒范围内以满足面向用户的分析仪表板。高查询吞吐量– 必须能够处理来自面向用户的分析仪表板的并发查询而不影响延迟。我们选择 Apache Pinot 作为分析数据库因为它满足所有上述标准。Apache Pinot 是一个实时分布式 OLAP 数据库旨在以极低的延迟和高并发性在流数据上提供 OLAP 工作负载。Pinot 与 Kafka 原生集成允许实时从 Kafka 主题中摄取数据数据生成时即可摄取。摄取的数据被索引并以列式格式存储从而使其上的查询执行效率更高。在架构中加入 Pinot 后我们的端到端数据管道看起来是这样的。请注意由于 API 兼容性Pinot 与 Redpanda 集成得非常紧密。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/57b887717bff49e13938fbd74c6065e1.png端到端数据管道图片由作者提供我们是否需要在管道中使用流处理器实际上不需要。但这取决于预期的用例。与使用流处理器相比您可以使用 Redpanda 的基于 Wasm 的中间代理数据转换来从 API 事件有效负载中删除敏感字段。然而当需要实时连接和丰富– 您需要更多维度传播到 Pinot这可以通过连接多个流来推导出来。例如IP 地理编码。警报– 根据使用中的异常触发警报并启动下游的事件驱动工作流。服务层我们的分析数据管道现在已完成。所有管道组件都位于数据基础设施层。如果需要可以访问 Pinot 查询控制台以运行即席 SQL 查询以生成指标。然而并非每个解决方案的利益相关者/用户都希望这样做。我们需要以用户组认为直观和舒适的方式向每个用户组展示指标。这就是我们实现服务层——分析的最后一步。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/b2e765c1b24fc6e78edae01b5a0d9675.png图片由作者提供我们的优先级是消费者。他们需要实时仪表板来可视化他们的使用情况和计费估计。为此您可以通过利用 Streamlit 等框架来构建基于 Python 的数据应用程序。Pinot Python 驱动程序pinotdb可以将应用程序和 Pinot 查询环境连接起来。需要 BI 和即席探索的用户组特别是 API 产品所有者可以使用 Pinot 的 ODBC 接口连接他们偏好的 BI 工具例如 Tableau 和 Apache Superset。对于批量工作负载Pinot 可以通过相关的 Pinot 连接器连接到查询联邦引擎如 Presto 或 Trino。总结让我们通过列出管道实现步骤的顺序来总结这篇文章。配置 Redpanda 集群创建主题并设置 ACL。在 APISIX 中配置 Kafka 溢出。创建 Pinot 架构和表。根据需要处理数据。创建/连接仪表板。此解决方案假设采用自托管部署模式其中架构中提到的工具由企业自身托管和管理。然而需要注意的是即使您选择这些工具的托管版本同样的设计原则也可以应用。架构中的每个组件都可能会被托管服务所替代这使得解决方案能够高度适应各种部署策略。如前所述本文主要探讨“为什么”而不是“如何做”。目标是理解背后的解决方案模式而不是精确的实现方式。可以将本文视为您下一个实时分析项目的蓝图。根据需要您可以调整它以融入不同的技术。