Edge for Private Cloud 4.54.00 中的更改

变更内容概览

Edge for Private Cloud 4.54.00 引入了多项更改，可增强平台的安全状况，并更新平台组件以使用 Java 21 运行。以下两个部分介绍了这些变更：

除了这些变更之外，您还可以参阅专门的变更检测工具指南。此实用程序可用于识别集群中可能因本次升级而导致中断的代理、共享流或其他工件的更改。

Java Callout 政策变更

在 Edge for Private Cloud 4.54.00 中，核心平台组件（包括消息处理器、管理服务器和路由器）已更新为在 Java 21 LTS 上运行。Java 21 对 Java 平台进行了现代化改造，包括移除旧版 Java EE 和 CORBA 模块 (JEP 320)、移除旧版内部实用程序类，以及强制执行严格的模块化封装 (JEP 403)。

由于这些变更，具有自定义 JavaCallout 政策或自定义资源 JAR（存储在代理、环境或组织级别）的 API 代理在升级到 4.54.00 版后可能会遇到中断。

可能影响 Java Callout 的变更类别

  1. 永久移除 Java EE 和 CORBA 模块 (JEP 320)：之前内置于 Java 8 运行时的模块（包括 JAXB javax.xml.bind.*、JAF javax.activation.*、JAX-WS javax.xml.ws.* 和 CORBA org.omg.*）已从 Java SE 中移除。如果 Callout 引用了这些软件包，但未捆绑独立的替代软件包，则会在运行时失败，并显示 NoClassDefFoundError。
  2. 移除了内部实用程序类：移除了旧版内部辅助程序，例如 sun.misc.BASE64Encoder 和 sun.misc.BASE64Decoder。调用这些类的标注会失败，并显示 NoClassDefFoundError。
  3. 对 Java 内部组件进行强封装 (JEP 403)：无法从自定义标注中反射性地访问 java.base 中的内部软件包（例如 sun.security.*、sun.reflect.* 和 com.sun.*）。反射调用在运行时失败，并显示 InaccessibleObjectException。
  4. 保留的 Java 类中的方法签名更改和移除：在某些 Java 模块中，类在 Java 21 中仍然存在，但特定的构造函数或方法签名已被移除、弃用或更改（例如 org.w3c.dom.Document 和相关 XML 解析类中的特定 DOM 解析方法）。

    工具检测：变更检测工具会将 METHOD_SIGNATURE_MODIFICATION 类别下对这些类的引用标记为 MEDIUM 影响确定性，从而提示开发者检查其调用方的源代码，以了解方法调用是否已修改。

修复策略

在升级之前，请确保您的 Java Callout 政策和自定义 JAR 资源与 Java 21 运行时兼容。使用变更检测工具可帮助您识别整个集群中受影响的 API 代理、共享流以及环境或组织 JAR 资源。

本部分中介绍的补救策略仅为一般性指南，并非互斥。根据您的运营要求，您可以结合使用多种策略，例如，使用策略 2 现代化改造标注源代码，并使用策略 3B 部署更新后的代理修订版本，以便在消息处理器升级期间实现零停机时间。

策略 3A、3B 和 3C 是执行同一操作方法的 3 种方式：在不同时间升级节点和重新部署代理，而不更改代理软件包。您可以根据 API 可用性要求选择其中一种或多种。

请查看以下决策指南，为您的部署选择最合适的方法：

Java Callout 缓解措施决策指南：

需要更新代理软件包并重新部署吗？ 场景或要求 建议的出价策略 解决的问题 主要限制
是（仅限套装更新） 存在双重兼容库；需要零停机时间 策略 1：通过捆绑的 JAR 实现双重兼容的代理 在不停机的情况下恢复各个版本中缺失的库 需要提供双重兼容的独立库，并在 4.54.00 中启用 conf_system_java.21.enable.external.allowed.packages=true
是（源代码修改） 源代码已维护；需要干净的长期修复 策略 2：替代实现（代码和依赖项现代化改造） 永久性地解决了已移除的类和内部 API 依赖项 需要更改源代码并重新部署（搭配策略 3A 或 3B 进行发布）
否（运营方法） 允许的预定维护窗口 策略 3A：计划内维护停机时间（就地重新部署） 允许先升级节点，然后部署更新后的代理 需要为 API 使用方安排停机时间
否（运营方法） 需要零停机时间；无法捆绑双 JAR 策略 3B：创建新环境（零停机时间迁移） 在迁移期间隔离 4.53 和 4.54 节点，实现零流量中断 需要采购临时消息处理器节点
否（操作方法） 升级前无法修改代理软件包 * 策略 3C：节点级外部库放置 在节点范围内提供缺少的库 JAR，而无需修改代理软件包 在节点上的所有代理之间共享；无法解决反射或 java.* 软件包问题
否（闭源第三方库） 第三方供应商库在 Java 内部使用反射 * 策略 4：JVM 标志（--add-opens / --add-exports） 放宽了对内部 Java 软件包的反射限制 无法恢复已移除的类或方法；适用于整个节点

策略 1：通过捆绑的 JAR 实现双重兼容的代理（在升级前进行测试，以实现零停机时间）

适用情形：在以下情况下使用此策略：

  • 有双重兼容的独立替换库：存在一个替换 JAR，它可实现所需的功能，并且可以直接捆绑到 API 代理中，而无需修改源代码。
  • 您希望现有 API 代理和 Java 标注在当前版本（例如 Edge for Private Cloud 4.53.01）和升级后的版本（Edge for Private Cloud 4.54.00）上都能顺畅运行。
  • 您需要在升级 Edge for Private Cloud 集群之前，在暂存环境和生产环境中测试并验证所有更改，确保实时流量不会出现任何意外问题，也不会出现任何停机时间。
  • 您希望避免重写或重构 Java Callout 业务逻辑。

工作原理：在 Java 8 中，某些库（例如 JAXB javax.xml.bind.* 或 Activation javax.activation.*）直接内置到 Java 8 运行时中。因此，开发者无需在其代理软件包中包含额外的 JAR 文件。在 Java 21 中，这些库已从 Java 运行时中移除。

如需使您的代理在 Edge for Private Cloud 4.53.x 和 4.54.00 中“双重兼容”，请执行以下操作：

  1. 确定标注所需的缺失库（例如 JAXB 或 Activation）。
  2. 获取独立的开源替换 JAR（例如 jakarta.xml.bind-api-2.3.3.jar 和 jaxb-runtime-2.3.8.jar）。
  3. 您可以直接将替换 JAR 放入 apiproxy/resources/java/ 下的代理软件包中，也可以使用代理级资源文件 API 将其上传到代理修订版本，或者将其作为资源文件上传到环境级层或组织级层。如需详细了解如何管理资源文件，请参阅 Apigee 资源文件文档。
  4. 在升级之前进行部署和测试：Edge for Private Cloud 4.53.x 和 4.54.00 中的消息处理器都会从这些捆绑的 JAR 中加载类。您现在可以部署此更新后的代理软件包，并在当前的 Edge for Private Cloud 4.53.x 集群中使用合成流量对其进行测试。
  5. 在消息处理器上启用外部允许的软件包加载（4.54.00 必需）：在 Edge for Private Cloud 4.54.00 中，默认情况下，系统会停用从外部或捆绑的资源 JAR 加载已移除的 Java 软件包（例如 javax.xml.bind.* 和 javax.activation.*）(conf_system_java.21.enable.external.allowed.packages=false)，因此默认情况下，仅捆绑 JAR 将不起作用。您必须使用代码配置 (CwC) 在 /opt/apigee/customer/application/message-processor.properties 中启用此属性（您可以在升级消息处理器节点之前配置此属性，也可以在升级后设置此属性并重启消息处理器）：
    conf_system_java.21.enable.external.allowed.packages=true
  6. 升级后实时流量问题为零：当您的集群随后升级到启用了 conf_system_java.21.enable.external.allowed.packages=true 的 Edge for Private Cloud 4.54.00 时，消息处理器已具有所需的 JAR，并会从捆绑的资源文件加载类，而不会发生任何故障 (NoClassDefFoundError)，从而确保顺利升级，实现零停机时间。

代码示例：订单 XML 验证和解析标注

假设有一个典型的 Apigee Java Callout，它使用 JAXB（JAXBContext 和 Unmarshaller）提取并验证传入的 XML 订单。

  • 修复前（在 Edge for Private Cloud 4.54.00 中失败）：在 Edge for Private Cloud 4.53.x 中，代理软件包仅包含标注 JAR，依赖于内置的 Java 8 运行时库来支持 JAXB： 
    apiproxy/
  resources/
    java/
      OrderXmlParserCallout.jar   <-- No JAXB JAR bundled

    Java Callout 实现：

    package com.example.callout;

// other required imports
import java.io.StringReader;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.Unmarshaller;

public class OrderXmlParserCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        try {
            String requestXml = messageContext.getMessage().getContent();
            JAXBContext jaxbContext = JAXBContext.newInstance(Order.class);
            Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
            Order order = (Order) unmarshaller.unmarshal(new StringReader(requestXml));
            messageContext.setVariable("order_id", order.getId());
            return ExecutionResult.SUCCESS;
        } catch (Exception e) { }
    }
}

    故障：在 Edge for Private Cloud 4.53.x 中，此操作会顺利执行。将节点升级到 Edge for Private Cloud 4.54.00 后，此代理会在请求处理期间立即失败：

    java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
        at com.example.callout.OrderXmlParserCallout.execute(OrderXmlParserCallout.java:20)
  • 修复后（在 Edge for Private Cloud 4.53.x 和 4.54.00 之间双重兼容）：您无需重写或重新编译 Java Callout 代码。您可以通过提供独立的 JAR 直接使代理实现双重兼容：
    1. 直接捆绑或上传独立 JAR：获取独立 JAXB 库（jakarta.xml.bind-api-2.3.3.jar 和 jaxb-runtime-2.3.8.jar），并将其放入 apiproxy/resources/java/ 下的代理包中： 
      apiproxy/
  resources/
    java/
      OrderXmlParserCallout.jar
      jakarta.xml.bind-api-2.3.3.jar
      jaxb-runtime-2.3.8.jar

      或者，使用代理级资源文件 API 将 jakarta.xml.bind-api-2.3.3.jar 和 jaxb-runtime-2.3.8.jar 作为资源文件上传，或在环境级或组织级上传，以便同一范围内的所有代理都可以共享这些文件，而无需将它们捆绑到每个单独的代理捆绑包中。

      如果您使用 Maven 从源代码构建代理包，请在 pom.xml 中声明这些依赖项，以便在构建期间自动打包。

    2. 在当前的 4.53.x 集群上部署和测试：将更新后的代理软件包部署到现有的 Edge for Private Cloud 4.53.x 环境，并发送测试调用。由于 Edge for Private Cloud 4.53.x 消息处理器会从这些捆绑的 JAR 中加载类，因此您可以验证标注是否继续以相同的方式运行。
    3. 通过 CwC 启用外部允许的软件包加载：由于 Edge for Private Cloud 4.54.00 (conf_system_java.21.enable.external.allowed.packages=false) 默认停用了加载外部允许的软件包，因此请使用代码与配置 (CwC) 在 /opt/apigee/customer/application/message-processor.properties 中的每个消息处理器节点上启用该功能： 
      conf_system_java.21.enable.external.allowed.packages=true
    4. 升级后实时流量问题为零：在 4.53.x 环境中验证并配置 CwC 属性后，您的代理就已做好充分准备。将集群升级到 Edge for Private Cloud 4.54.00 后，消息处理器会加载捆绑的 JAXB 类，确保零错误和零实时流量中断。

策略 2：替代实现（代码和依赖项现代化改造）

适用场景：建议用于活跃的代码库，其中代理源代码易于维护。这是最简洁的长期 Java 21 合规性方法。发布说明：由于部署现代化代理修订版本需要消息处理器协调，因此请将此策略与策略 3A（在计划的维护窗口期间）或策略 3B（通过并行消息处理器实现零停机时间）搭配使用。

运作方式：将已移除的 Java 内部类替换为官方标准 Java SE API 或开源独立等效项，并直接在代理软件包资源文件或 POM 中打包所需的第三方依赖项。

代码示例：

示例 1：方法和代码现代化改造（替换已移除的内部实用程序）

在 Java 8 中，标注经常使用内部实用程序类，例如 sun.misc.BASE64Encoder。在现代 Java 中，这些类已被移除，但标准 java.util.Base64 API 提供了直接替代方案，无需外部依赖项 JAR：

  • 之前（旧版 Java 8 实现）： 
    // Incompatible in Edge for Private Cloud 4.54.00: sun.misc package removed
import sun.misc.BASE64Encoder;
// other required imports

public class Base64EncodeCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        BASE64Encoder encoder = new BASE64Encoder();
        String encoded = encoder.encode("ApigeePayload".getBytes());
        messageContext.setVariable("encoded_data", encoded);
        return ExecutionResult.SUCCESS;
    }
}
  • 之后（符合 Java 21 的实现）： 
    // Fully compatible with Java 21: uses standard Java SE java.util.Base64 (no external JARs needed)
import java.util.Base64;
// other required imports

public class Base64EncodeCallout implements Execution {
    @Override
    public ExecutionResult execute(MessageContext messageContext, ExecutionContext executionContext) {
        String encoded = Base64.getEncoder().encodeToString("ApigeePayload".getBytes());
        messageContext.setVariable("encoded_data", encoded);
        return ExecutionResult.SUCCESS;
    }
}
示例 2：使用捆绑库进行导入级重构（JAXB 命名空间前缀映射器）

在 Java 8 中，自定义 XML 命名空间前缀的 API 代理通常会扩展 Sun 的内部 JAXB 映射器 com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper。在 Java 21 中，内部 Sun 软件包已被移除且无法访问。

独立开源库 (org.glassfish.jaxb:jaxb-runtime) 在 com.sun.xml.bind.marshaller.NamespacePrefixMapper 下提供相同的类。所有方法签名、参数和返回值类型都相同，代码更改严格来说仅限于 import 语句：

  • 之前（旧版 Java 8 实现）： 
    // In Java 8: Relied on internal Sun class in Java 8 runtime
import com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper;
public class CustomNamespaceMapper extends NamespacePrefixMapper {
    @Override
    public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
        if ("http://schemas.example.com/orders".equals(namespaceUri)) {
            return "ord";
        }
        return suggestion;
    }
}
  • 之后（符合 Java 21 的实现）： 
    // In Java 21: Identical methods and logic; ONLY the import statement changes (".internal." removed)
import com.sun.xml.bind.marshaller.NamespacePrefixMapper;
public class CustomNamespaceMapper extends NamespacePrefixMapper {
    @Override
    public String getPreferredPrefix(String namespaceUri, String suggestion, boolean requirePrefix) {
        if ("http://schemas.example.com/orders".equals(namespaceUri)) {
            return "ord";
        }
        return suggestion;
    }
}
  • 捆绑式依赖项配置 (pom.xml)：如需在运行时提供此类，请将独立的 JAXB 库捆绑在 apiproxy/resources/java/ 中，或在 pom.xml 中声明它们： 
    <dependencies>
    <!-- Standalone JAXB API for Java 21 -->
    <dependency>
        <groupId>jakarta.xml.bind</groupId>
        <artifactId>jakarta.xml.bind-api</artifactId>
        <version>2.3.3</version>
    </dependency>
    <!-- Standalone JAXB Runtime providing com.sun.xml.bind.marshaller.NamespacePrefixMapper -->
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>2.3.8</version>
    </dependency>
</dependencies>

策略 3A：计划内维护停机时间（就地重新部署）

使用场景：建议在具有预定运营维护窗口的环境中使用，在这种情况下，短暂的服务中断是可以接受的。

步骤：

  1. 与 API 使用方协调安排维护窗口。
  2. 按照升级路径指南将 Edge for Private Cloud 组件升级到版本 4.54.00。
  3. 使用新版 Edge 界面或 Apigee Management API（部署）部署 API 代理的预编译、与 4.54.00 兼容的修订版本。
  4. 通过向消息处理器发送合成测试请求并使用跟踪工具检查日志，验证标注执行情况。
  5. 关闭维护窗口，重新开放公共流量。

策略 3B：创建新环境（零停机时间迁移）

何时使用：建议用于需要零停机时间的关键任务生产环境。如果您的 Java Callout 无法同时在 Java 8 和 Java 21 中运行，请使用此方法。

运作方式：此策略涉及采购一个或多个新环境，以便您可以将不同版本的消息处理器节点连接到该环境。随后，将与 Java 8 兼容的代理部署到与 4.53.X 消息处理器关联的环境，并将与 Java 21 兼容的代理部署到与 4.54.00 消息处理器关联的环境。然后，使用负载均衡器或其他路由技术将流量仅路由到与 Java 21 兼容的代理。

对于此策略，了解组织、环境和消息处理器如何交互是实现零停机时间割接的关键（如需了解详情，请参阅 Apigee Edge 组织结构）：

  • Apigee 组织是包含多个环境（例如 prod、test）的顶级管理边界。
  • API 代理修订版本部署到特定环境。只有明确绑定到相应环境的消息处理器才会加载并执行代理修订版本。
+------------------------------------------------------------------------+
|                          Apigee Organization                           |
|                                                                        |
|  Existing Environment (prod)            Temporary Env (prod-migration) |
|  +--------------------------------+     +----------------------------+ |
|  | Current 4.53.01 MP Nodes       |     | New 4.54.00 MP Nodes       | |
|  |               |                |     |              |             | |
|  | Proxy Rev N (4.53.01)          |     | Proxy Rev N+1 (Modernized) | |
|  +--------------------------------+     +----------------------------+ |
+------------------------------------------------------------------------+
                   ^                                    ^
                   | Step 1: Normal Live                | Step 2: Canary
                   |         Traffic (prod)             | Step 3: Complete
          +------------------------------------------------------+
          |       Upstream Load Balancer / Ingress Router        |
          +------------------------------------------------------+

步骤：

  1. 创建临时环境：在您的组织内（按照设置虚拟主机和环境中的说明）创建一个具有专用虚拟主机和端口的新环境（例如 prod-migration）。
  2. 预配 4.54.00 消息处理器节点：在新的或临时虚拟机实例上安装 Edge for Private Cloud 4.54.00，并将这些节点绑定到 prod-migration（请参阅添加消息处理器）。
  3. 确定受影响的代理并创建更新后的修订版本：使用 Java Callout（使用变更检测工具）确定 API 代理，并为每个受影响的代理创建一个新的修订版本，其中包含与 Edge for Private Cloud 4.54.00 兼容的 Java Callout（应用策略 1 或策略 2）。
  4. 将现代化改造后的代理修订版本部署到临时环境：仅将更新后的兼容代理修订版本部署到 prod-migration。
  5. 验证并转移流量：针对新的虚拟主机执行合成验证测试。验证后，配置外部负载均衡器（F5、NGINX），将客户端流量从 prod 重定向到 prod-migration。
  6. 升级原始节点并切换回来：从 prod 中取消部署旧版代理。按照升级路径指南，将原始消息处理器节点升级到 4.54.00。将现代化改造后的代理修订版本部署到 prod，将负载均衡器流量重定向回 prod，并验证操作。
  7. 停用临时环境：从 prod-migration 取消部署代理，移除临时消息处理器节点，并删除临时环境。

策略 3C：节点级外部库放置（共享后备库）

使用场景：如果您有多个 API 代理依赖于 Java 21 中已移除的 Java 类，并且在升级之前重新编译或重新打包每个单独的代理软件包在操作上不可行，建议使用此选项。

运作方式：在 Edge for Private Cloud 4.54.00 中，消息处理器提供了一种机制，可从专用节点目录 $APIGEE_ROOT/data/edge-message-processor/external-lib 加载缺失的 Java 类。

启用此机制后，消息处理器会在回退到默认解析之前检查此目录中是否存在缺失的类。您可以通过以下方式提供缺少的类：从第三方库 JAR 中获取这些类，或者将所需的类捆绑到 JAR 中并将其放置在 external-lib 中。

步骤：

  1. 在每个消息处理器节点上创建外部库目录： 
    mkdir -p /opt/apigee/data/edge-message-processor/external-lib
  2. 将所需的 JAR 文件放入相应目录：将包含所需类的 JAR 文件复制到 /opt/apigee/data/edge-message-processor/external-lib 中。
  3. 设置适当的文件权限：确保 apigee 服务用户具有读取权限： 
    chown -R apigee:apigee /opt/apigee/data/edge-message-processor/external-lib
chmod 755 /opt/apigee/data/edge-message-processor/external-lib
chmod 644 /opt/apigee/data/edge-message-processor/external-lib/*.jar
  4. 在消息处理器配置中启用外部软件包加载：在 Edge for Private Cloud 4.54.00 中，默认情况下，加载外部允许的软件包处于停用状态 (conf_system_java.21.enable.external.allowed.packages=false)。如需启用消息处理器以从 /opt/apigee/data/edge-message-processor/external-lib 解析和加载类，您必须使用含配置的代码 (CwC) 在 /opt/apigee/customer/application/message-processor.properties 中启用此属性： 
    conf_system_java.21.enable.external.allowed.packages=true
  5. 重启消息处理器：
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

策略 4：JVM 标志（--add-opens / --add-exports - 谨慎使用，最后手段）

适用场景：此策略是最后的手段，仅适用于闭源第三方供应商库，这些库无法获取源代码，供应商尚未发布 Java 21 更新，且 JAR 严格依赖于对内部 Java 软件包的反射访问。

步骤：

  1. 确定用于反射的不可访问软件包：确定第三方库通过反射访问的内部 Java 模块和软件包。注意：这些反射错误仅在 Edge for Private Cloud 4.54.00 中的 Java 21 下发生，不会出现在 4.53.x 版本的日志中。升级后，检查消息处理器日志 (/opt/apigee/var/log/edge-message-processor/system.log) 中是否有 InaccessibleObjectException，以确定所需的模块和软件包： 
    java.lang.reflect.InaccessibleObjectException: Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not "opens java.lang" to unnamed module
  2. 使用 Code with Config (CwC) 修改 /opt/apigee/customer/application/message-processor.properties（如果该文件尚不存在，请创建该文件）。
  3. 将目标 --add-opens 或 --add-exports 标志附加到 bin_setenv_ext_jvm_opts。 
    # Configure targeted JVM module access for closed-source legacy callouts (enclosed in double quotes)
bin_setenv_ext_jvm_opts="-XX:+UseG1GC -XX:+AlwaysPreTouch --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.misc=ALL-UNNAMED --add-opens java.base/sun.security.util=ALL-UNNAMED --add-opens java.base/sun.security.x509=ALL-UNNAMED"
  4. 确保文件所有权和权限正确无误： 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
chmod 644 /opt/apigee/customer/application/message-processor.properties
  5. 使用 apigee-service 重启消息处理器：
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

TLS 和加密套件变更

在 Edge for Private Cloud 4.54.00 中，核心平台组件（包括消息处理器、管理服务器和路由器）已更新为在 Java 21 LTS 上运行。此更新通过默认启用 TLS 1.3 (JEP 332) 来实现现代化的加密安全性。消息处理器现在会协商将 TLS 1.3 作为出站后端连接的首选协议，如果后端不支持该协议，则回退到 TLS 1.2。

旧版后端要求和修复

Java 21 加密基准会更新 jdk.tls.disabledAlgorithms 中默认停用的协议和加密套件列表（例如旧版 TLS 协议和非前向保密静态 RSA 密钥交换套件：TLS_RSA_*）。由于您提供自己的 Java 21 运行时，因此停用的协议和加密套件的确切列表取决于您的具体 Java 21 实现。

如果您的现有 API 代理连接到需要停用协议或静态 RSA 加密套件的旧版后端基础设施，请查看以下操作：

  • 实现后端安全现代化（推荐）：升级目标服务器和负载均衡器，以支持 TLS 1.2 或 TLS 1.3 以及现代 ECDHE 加密套件。如需在 API 代理中配置协议和加密套件，请参阅配置从 Edge 到后端的 TLS 和 TLS/SSL TargetEndpoint 配置参考文档（如果使用 TargetServer，请参阅跨后端服务器进行负载均衡）。
  • 使用 CwC 重新启用旧版算法（升级期间的过渡措施）：如果无法在平台升级之前完成后端升级，您可以使用含配置的代码 (CwC) 暂时重新启用所需算法：
    1. 检查 Java 21 安装中的默认 jdk.tls.disabledAlgorithms 值（例如，在 $JAVA_HOME/conf/security/java.security 中）。
    2. 使用相同的已停用算法列表覆盖 /opt/apigee/customer/application/message-processor.properties 中的 conf_jvmsecurity_jdk.tls.disabledAlgorithms，仅移除 TLS_RSA_* 条目（保持所有其他已停用算法不变，以便其余保护措施保持启用状态）。
    3. 使用 apigee-service 重启消息处理器。一旦后端支持 ECDHE 加密套件，就移除此替换项。
  • 更新自定义加密套件许可清单：如果您之前替换过 conf_http_HTTPTransport.ssl.cipher.suites.whitelist，请在升级前进行检查。Java 21 不再支持静态 RSA 套件 (TLS_RSA_*)，因此，如果许可清单仅包含这些套件，消息处理器 将没有可用的密码，并且后端调用会失败，并显示 no cipher suites in common。移除 TLS_RSA_* 条目，并配置 Java 21 实现支持的现代加密套件。如果您尚未替换此属性，则 4.54.00 默认值已包含受支持的套件，无需进行任何更改。
  • 将内部路由器更新为消息处理器加密套件：如果您之前使用静态 RSA 套件替换了 conf_message-processor-communication_local.http.ssl.ciphers，请在升级前使用 Java 21 实现支持的现代加密套件进行更新，否则路由器无法与消息处理器完成 TLS 握手。然后重启消息处理器：
    apigee-service edge-message-processor restart
     请参阅在路由器和消息处理器之间配置 TLS。

如需详细了解如何在 Edge 组件之间配置 TLS，请参阅在路由器和消息处理器之间配置 TLS。

变化检测工具

Apigee 提供了一个变更检测工具，用于扫描集群中可能受 Edge for Private Cloud 4.54.00 升级影响的已部署 API 代理、政策、共享流和资源 JAR。

该工具可识别潜在的升级阻碍因素，包括与 Java 21 不兼容的库、强封装的内部 API、旧版政策弃用和 OpenLDAP RDN 限制，并生成可据以采取行动的报告，帮助您选择合适的补救策略。

如需了解完整的前提条件、下载说明、命令行语法和报告示例，请参阅专门的更改检测工具指南。