从 Apigee Edge 到 GCP 中的 Apigee 迁移 - 用 MessageLogging 策略替换 ExtensionCallout 策略以进行日志记录

随着更多公司将其 API 迁移到云端，Google Cloud 上的 Apigee为管理和保护 API 提供了可靠的解决方案。对于Apigee Edge（一种 SaaS 平台）用户，此迁移使他们能够利用 Google Cloud 的云原生功能来提高可扩展性、性能和安全性。

迁移的好处

云原生优势：Google Cloud 上的 Apigee 与 GCP 中托管的应用程序无缝集成，更易于管理 API。
可扩展性和性能：在 Google Cloud 的基础设施上运行，Apigee 受益于其可扩展性、可靠性和强大的性能。
安全功能：Apigee 与 Google Cloud Armor集成，以提供针对威胁和 DDoS 攻击的增强保护。
与 GCP 服务集成：Apigee 与其他 Google Cloud 服务（如IAM、Logging 和 Monitoring）连接。

增强功能

AppGroups用于组织应用程序所有权。
产品内多个代理路径的配额支持。
利用环境组集中管理主机名。
用于访问管理的开箱即用角色。
数据驻留支持。
在代理或环境级别存储键值对的属性集。

缺乏对 Apigee Edge 的支持

随着 Apigee Edge 接近生命周期结束，Apigee Edge 的支持将受到限制，且不会有增强功能。

迁移的关键实体

决定从 Apigee Edge 迁移到 Apigee 并确定架构设计后，需要计划迁移实体/资产，如代理、共享流、产品、应用等。关键实体包括：

组织
环境
API 产品
应用和 API 密钥
开发人员
API 代理
共享流
键值映射
流挂钩
TLS 密钥库

由于两个平台之间的差异，迁移这些实体时需要考虑很多事情。本文将重点关注迁移 API 代理，特别是用 MessageLogging 策略替换ExtensionCallout策略以将日志发送到 Google Cloud 的过程。

API 代理是什么

API 代理是客户端应用和后端 API 之间的中介，它将消费者与后端实现解耦，使后端更改对客户端不敏感。Apigee API 代理还提供各种策略以实现速率限制、配额、日志记录、缓存等附加功能。

共享流是什么

顾名思义，共享流是可在多个代理中共享和重用的策略和资源序列。共享流与 API 代理非常相似，但它没有自己的端点。此外，共享流只能从另一个代理或共享流中调用。像日志记录、令牌验证、缓存等常见功能最好在共享流中完成。

理解 Apigee 中的日志记录：Extensioncallout 与 Messagelogging

ExtensionCallout（也称为 EC）策略用于调用任何扩展 - 将外部资源（如 LDAP、Google PubSub、Google Cloud Storage 等）集成到 API 代理中。它通常用于将 API 流量信息发送到外部日志系统（如 Splunk）。
MessageLogging（也称为 ML）策略是 Apigee 提供的用于与 Google Cloud Logging 直接集成的开箱即用策略。它易于配置，无需外部扩展。
注意：需要为 Google 项目启用 Cloud Logging API 才能将日志推送到 Cloud Logging。

用 Messagelogging 替换 Extensioncallout 以将 API 代理流量信息发送到 Cloud Logging 的步骤

确定 EC 策略的使用位置。
理解使用 EC 策略的现有日志配置。
创建相应的 ML 策略并替换 EC 策略。
进行端到端测试，以确保所有日志都按预期发布。

ExtensionCallout 示例代码

以下是在 Apigee Edge 中使用 EC 策略调用 Google Pub/Sub 的示例代码。
<Connector>元素用于定义使用的扩展。
XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ConnectorCallout async="false" continueOnError="true" enabled="true" name="Extension-Callout-Sample">
    <DisplayName>Extension-Callout-Sample</DisplayName>
    <Connector>GCPPubSub</Connector>
    <Action>publish</Action>
    <Input>
       {
            "message" : {"This is a sample message"}
       }
     </Input>
    <Output>ResponseVariable</Output>
</ConnectorCallout>

MessageLogging 示例代码

以下是使用 ML 策略记录到 Cloud Logging 的示例代码。
<CloudLogging>元素用于记录到 Cloud Logging。
XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MessageLogging continueOnError="false" enabled="true" name="Message-Logging-Sample">
  <DisplayName>Message-Logging-Sample</DisplayName>
  <CloudLogging>
    <LogName>projects/{organization.name}/logs/{log.id}</LogName>
   <Message contentType="application/json">
   {
   "message" : {"This is a sample message"}
   }
   </Message>
    <ResourceType>api</ResourceType>
  </CloudLogging>
</MessageLogging>

与 EC 策略一样，ML 策略也可以在 API 代理的 PostClientFlow 中调用。PostClientFlow 在代理响应发送给客户端后执行，以确保在推送日志之前有日志指标可用。

在 Google Cloud 中记录的最佳实践

设置适当的日志级别：使用适当的日志级别（INFO、WARN、DEBUG、ERROR 等）来识别日志的严重程度。
数据屏蔽：屏蔽敏感数据，如账号号码、访问令牌、信用卡号码等。
监控和日志记录：设置 Cloud Monitoring 警报，以便及时识别和解决任何问题。
配置保留策略：根据需要保留日志的时间（例如 30 天或 60 天）设置日志保留策略。请注意，存储有相关成本。
端到端测试：确保进行性能测试，以确保在代理中更改策略不会引入任何延迟。

迁移到基于云的 API 网关之前的关键考虑因素

迁移到基于云的 API 网关（如 Google Cloud 上的 Apigee）有很多好处，但也带来了一些挑战。一个大问题是成本 - API 调用、数据传输和日志存储的持续费用可能会迅速增加。还有被锁定在一个供应商的风险，这会使以后切换到另一个云或采用多云变得更加困难。
迁移过程本身可能很棘手。可能存在兼容性问题、一些停机时间以及团队的学习曲线。安全也是另一个问题，尤其是在数据隐私、合规性和管理访问控制方面。
性能可能会受到网络延迟、服务中断和冷启动等因素的影响。由于依赖云提供商的服务级别协议（SLA），您可能对自己的设置控制较少。
将云系统连接到当前的本地或混合设置可能很困难，并且随着设置的增长，管理云资源可能会变得复杂。虽然云平台是为扩展而构建的，但配置不当可能会导致问题。
因此，在开始迁移之前仔细考虑这些优缺点非常重要。