TPG Telecom 利用 Apigee 将 API 交付时间缩短了 50%

TPG Telecom是澳大利亚电信业的一颗新星，其战略以广泛的并购和有机增长为基础。我们的品牌包括 Vodafone、TPG、iiNet 和 AAPT，通过广泛的移动和光纤网络为 500 万移动客户和 220 万固定宽带客户提供服务。

API 在三个层面上对我们的业务至关重要。在客户体验层面，基于集成的 API 专注于与客户相关的旅程，而我们也将 API 用于与网络和支付相关的活动。然而，我们基于并购的增长战略意味着我们正在使用具有 API 功能的多个技术堆栈和系统。我们需要转向现代 API 管理平台，原因有很多，包括通过交叉销售实现现有和收购业务的好处。当前的客户关系管理 (CRM) 和计费系统提供不同格式和协议的 API。因此，对各种 API 交付平台的支持和跨 API 的可见性对业务至关重要。使用 Apigee 作为 API 网关允许 TPG 以一致的格式向数字消费者系统公开 API，以便这些数字系统可以专注于数字体验，而不是专注于实现支持多种 API 协议的复杂性。这有助于简化与各种后端系统的集成。

API 治理对 TPG 来说非常重要，因为我们需要了解 API 的使用方式和性能，以便我们能够根据所使用 API 的反馈不断改进我们的 API 体验。我们使用 API 指标来触发警报，帮助我们主动识别和解决下游系统中的问题。

我们希望用去中心化的云原生平台取代主要采用本地部署的 API 管理解决方案，以符合我们更广泛的业务方向。我们还寻求从外包的多元化开发模式转变为敏捷的集中式 DevSecOps，以便我们能够以无缝、一致的方式交付 API。

在与另一家云提供商合作时，我们需要一种解决方案，使我们能够使用多种语言或框架构建 API，并一致地公开功能以供使用。它必须支持集成各种后端并在我们的首选合作伙伴中启用运行时，同时确保帐户与我们的内部部署和合作伙伴云产品之间的无缝集成。此外，我们必须将所有 API 置于一个通用治理平台下，以实现可见性。

我们为什么选择 Apigee

我们评估了多个 API 管理平台，最终选择了Apigee。它最适合我们，原因有很多，包括它凭借直观的设计和全面的功能集成为市场领导者。Apigee 许可模式还使我们能够更好地预测在许可上需要花费多少钱。

此外，我们花费了更少的精力来公开和保护 API，并启用自动化 CI/CD 管道，从而实现更快、更高效的部署。最后，Google Cloud 在 AI、Kubernetes 和服务网格等技术方面的投资和熟练程度（这些技术对我们的业务都有丰富的应用）促使我们做出选择。

此外，Apigee 提供了灵活的部署选项，我们选择了 Apigee Hybrid 来实现跨多云和本地环境的运行时和集成。Apigee 还使我们能够为整个业务中的所有 API 建立一个通用的治理平台。

我们于 2022 年底在 Apigee 上推出了第一组 API，TPG Telecom 目前正在进行为期数年的旅程，以连接六个平台和多达 300 个底层系统。我们在使用 TPG 向内部和外部消费者公开的 API 方面拥有一致的体验。此外，Apigee 平台内置的安全性可确保所使用的 API 不存在漏洞，并受到实时监控以发现任何性能或可用性问题。因此，我们看到了更快的集成速度。

我们并不是强制集中使用它，而是在内部展示价值的基础上在 TPG 范围内扩大其采用率，这意味着寻找机会与团队合作将 API 引入 Apigee。

下面是我们当前的 Apigee 架构图，以及我们如何将 API 与外部服务提供商集成：

当前状态架构 – Apigee

克服 API 可见性和重复性挑战

Apigee 通过在业务中利用 API 帮助我们克服了一系列挑战。例如，我们对 API 及其使用的可见性有限，这使得制定政策变得困难，延迟了漏洞修复，并减慢了 API 的测试和发布，从而大大降低了上市速度。此外，由于缺乏跨业务部门的可见性，我们各个业务和品牌之间基于 API 的产品和服务存在大量重复。由于没有一个单一的平台来公开 API，利用我们服务的外部消费者会导致 API 请求穿越多个集成点并延迟响应时间。我们还需要改进我们的文档方法，以标准化和澄清我们的流程和实施规则，并提供一个统一的存储库来存储与规则、模式和集成样式相关的 API 工件。

借助 Apigee 和API Hub，我们现在拥有一个可以设计和发布 API 的中心位置，这些 API 有详尽的文档和明确的规范，并且我们正在转向单一 API 格式，以降低复杂性和创建时间。

在使用 Apigee 之前，重复也延伸到了安全控制。由于我们没有统一的 API 管理和 API 解决方案来为 API 使用者提供抽象层，因此我们不得不聘请不同的渗透测试和安全团队来独立测试我们的后端系统、网络和客户体验应用程序。由于渗透测试周期持续两个冲刺，因此减少在不同平台上实施相同控制所需的时间是当务之急。第一个冲刺涉及为应用程序推荐安全措施，第二个冲刺是验证这些措施是否已实施。

我们现在使用 Apigee 的高级 API 安全作为单一控制平面来管理数百个已发布 API 的安全性。Apigee 的高级 API 安全解决方案提供的安全控制建议和补救措施还简化了一致执行关键安全控制的流程。

在实施 Apigee 之前，我们的 API 管理环境支离破碎且复杂。由于存在多种解决方案，很难投资于平台工程最佳实践，包括 CI/CD、可观察性和治理。我们无法通过 New Relic、Splunk 或其他产品实现可观察性，也没有主动监控来发现任何问题并通知合适的人员做出响应。如果没有自动化的 CI/CD，许多这些平台都需要高度手动的构建部署流程，这使得维护和管理代码版本变得困难，并且解决方案的部署到生产中通常会延迟数周。

此外，Apigee 还使我们能够标准化日志记录和监控，因此我们所有的 API 都遵循通用模式，并且我们的 Apigee 日志会进入 Splunk，以便在整个平台上进行观察。我们现在还配置了一些警报和监控系统，以确定我们的系统是否遇到超时或延迟等问题，这使我们能够及时与相关团队合作解决这些问题。

在我们之前的平台下，API 开发和部署之间的执行逻辑是紧密耦合的，这意味着我们的开发人员必须了解大量的业务逻辑，然后才能向外部客户提供 API 服务。让这些开发人员快速上手会不必要地增加我们的开销。现在有了 Apigee，我们实现了松散耦合的架构，并成立了一个集中的 API 团队，专注于部署、标准和运行时操作，从而减少了开发开销并加快了发布节奏。

借助 Apigee，我们能够为我们的 API 实现标准化、安全性和一致的集成流程。在规划特殊活动和促销活动（例如新手机发布）时，我们会捕获请求量和预期发布流量，并记录其他业务指标以确定 EKS 集群的自动扩展特性。Apigee Hybrid 的扩展性极佳，不会对性能或可用性产生任何影响。

将 API 投入生产的速度提高两倍

我们现在只需两周时间就能将 API 投入生产，包括集成、可观察性和相关自动化。使用我们之前的 API 管理平台，这通常需要长达四周的时间。Apigee Advanced API Security 使我们能够评估每个 API 的安全分数，并在运行渗透测试之前识别和修复大量问题，从而让我们确信基础安全控制措施正在保护我们的生产 API。

文章来源：TPG Telecom reduces API delivery time by 50% with Apigee