Java平台模块系统（JPMS）随Java 9引入，代表了该平台最重大的变革之一。对于运行遗留单体应用的组织而言，JPMS通过显式的模块边界和强封装，提供了一条通往更好可维护性、安全性和可扩展性的道路。然而，迁移需要周密的规划和策略。本文为成功将遗留Java应用迁移至模块化架构提供了实用指南。

理解JPMS解决的问题

遗留Java单体应用通常存在紧耦合（组件深度交织，导致更改风险高）和弱封装（所有内容全局可访问，增加错误）的问题。其他挑战还包括构建速度慢（微小更改需要完全重建）以及有限的可扩展性（难以独立部署部分功能）。

JPMS通过引入显式的模块边界、强封装和更好的依赖管理来解决这些问题。该模块系统允许您分组包，并严格控制哪些属于公共API，模块会显式声明其依赖项，而不是仅仅依赖类路径。

什么是模块？

模块用于分组包，并严格控制哪些包属于公共API。与Jar文件不同，模块显式声明它们依赖哪些模块，以及它们导出哪些包。模块声明存在于源层次结构根目录下名为 module-info.java 的文件中。

以下是一个基本的模块声明：

module com.company.data {
    requires java.sql;
    requires java.logging;

    exports com.company.data.api;
    // 内部包不会被导出
}

导出包的公共成员将被依赖模块访问，而私有成员则无法访问（即使通过反射，具体取决于Java版本设置）。

迁移准备

在着手模块化之前，您需要了解应用程序的结构和依赖关系。

步骤1：分析依赖关系

JDeps（Java依赖分析工具）是一个命令行工具，用于处理Java字节码并分析类之间静态声明的依赖关系。该工具对于迁移规划至关重要。

在您的应用程序上运行 jdeps 以获取依赖关系概览：

jdeps -s myapp.jar

这将提供一个摘要，显示您的应用程序依赖哪些JDK模块。要进行更详细的分析：

jdeps --class-path 'libs/*' -summary -recursive myapp.jar

步骤2：识别JDK内部API使用情况

最关键的迁移挑战之一是识别对JDK内部API的依赖，这些API在Java 9+中不再可访问。使用 jdeps 查找这些有问题的依赖：

jdeps -jdkinternals myapp.jar

如果您使用了内部API，jdeps 可能会建议替换方案以帮助您更新代码。例如，如果您的代码使用了 sun.misc.BASE64Encoder，jdeps 将建议改用 java.util.Base64。

步骤3：创建依赖关系图

理解应用程序的一个有效方法是使用分层图，以分层方式表示依赖关系。这有助于识别哪些组件可以迁移以及迁移顺序。

您可以生成DOT文件用于可视化：

jdeps --dot-output . myapp.jar

然后使用像Graphviz这样的工具或像 webgraphviz.com 这样的在线服务来可视化生成的 .dot 文件。

步骤4：识别循环依赖

JPMS禁止模块之间存在循环依赖。解决此问题的常用方法是创建一个包含共享代码的中间模块，从而打破循环。

例如，如果模块A依赖于B，而模块B又依赖于A，您需要将共享功能提取到一个新的模块C中，让A和B都依赖于C。

迁移策略：自顶向下 vs 自底向上

JPMS支持两种主要的迁移策略，每种策略适用于不同的场景。

自底向上迁移

在此策略中，最初所有JAR文件都位于类路径上。然后，通过一个逐步的过程，所有JAR都可以逐个迁移到模块路径上。

过程：

1. 选择最低层级的模块：从对您的其他JAR没有依赖关系的模块开始。
2. 添加 module-info.java：创建一个模块描述符，定义其依赖项和导出项。
3. 移动到模块路径：此JAR成为命名模块。
4. 向上重复：继续处理下一层级的模块。

一个三层应用程序（Utils → Services → Application）的示例进展：

# 步骤1：模块化Utils（无内部依赖）
jdeps --generate-module-info . utils.jar

# 步骤2：模块化Services（依赖于Utils）
jdeps --generate-module-info . services.jar

# 步骤3：模块化Application（依赖于两者）
jdeps --generate-module-info . application.jar

自底向上迁移允许底层模块强制执行强封装，而上层模块在过渡期间仍可以访问模块化和非模块化的依赖项。

自顶向下迁移

在此策略中，最初所有JAR文件都位于模块路径上，因此所有未迁移的项目都被视为自动模块。然后，您选择依赖层次结构中尚未迁移的最高层级的项目。

过程：

1. 将所有JAR放在模块路径上：非模块化JAR成为自动模块。
2. 从顶部开始：首先模块化您的主应用程序模块。
3. 添加 module-info.java：使用自动模块名称定义依赖项。
4. 向下工作：逐渐用适当的命名模块替换自动模块。

自顶向下迁移鼓励在更高层级进行仔细的API设计，并允许您的主应用程序代码立即从模块化中受益。

理解模块类型

在迁移过程中，您将处理三种类型的模块：

命名模块（显式模块）

显式模块遵循其模块声明（module-info.java）中定义的依赖项和API规则。这些是具有完整模块描述符的完全模块化JAR。

自动模块

自动模块是位于模块路径上的普通JAR（无模块描述符）。模块名称源自JAR文件名或 MANIFEST.MF 文件中的 Automatic-Module-Name 条目。

自动模块在迁移期间提供了一个桥梁：

• 它们可以读取所有其他模块
• 它们导出其所有包
• 其他命名模块可以依赖它们

未命名模块

类路径上的所有内容都成为未命名模块的一部分。未命名模块可以读取所有其他模块，但不能被命名模块所需。这提供了向后兼容性。

使用 jdeps 生成模块描述符

jdeps 命令可以为指定的JAR文件生成 module-info.java 文件：

# 生成模块描述符
jdeps --generate-module-info output-dir myapp.jar dependency.jar

# 生成开放模块（用于反射密集型代码）
jdeps --generate-open-module output-dir myapp.jar

生成的 module-info.java 文件提供了一个起点，但您应该审查并完善它们，以正确封装内部包。

处理常见的迁移挑战

拆分包

一个包不能存在于多个模块中。如果您有拆分包，您需要进行重构或合并，以避免同一个包分布在多个模块中。

反射密集型框架

如果框架使用反射（例如 Spring, Hibernate），请声明 opens 以允许访问：

module com.company.data {
    requires java.sql;

    exports com.company.data.api;
    opens com.company.data.entities to org.hibernate.core;
}

opens 指令允许对包进行反射访问，而无需将其导出到公共API。

第三方库

某些第三方库可能尚未模块化；在这些情况下，请使用自动模块或模块修补。随着生态系统的成熟，越来越多的库正在添加模块支持。

对于没有模块的库，请确保它们的 MANIFEST.MF 中有一个 Automatic-Module-Name，或者向上游贡献一个。

更新构建工具

Maven 配置
使用 maven-compiler-plugin 并配置 --module-path 和 --patch-module 选项：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.11.0</version>
    <configuration>
        <release>17</release>
    </configuration>
</plugin>

Gradle 配置
使用支持模块化的 java-library 插件：

plugins {
    id 'java-library'
}

java {
    modularity.inferModulePath = true
}

实践示例：模块化一个三层应用程序

让我们逐步完成一个典型的分层应用程序（包含数据层、服务层和API层）的模块化过程。

步骤1：数据层模块

// 数据层的 module-info.java
module com.company.app.data {
    requires java.sql;
    requires java.logging;

    exports com.company.app.data.api;
    // 内部包不导出
}

编译和打包：

javac -d mods/com.company.app.data src/com/company/app/data/**/*.java
jar --create --file mods/com.company.app.data.jar -C mods/com.company.app.data .

步骤2：服务层模块

// 服务层的 module-info.java
module com.company.app.service {
    requires com.company.app.data;
    requires java.logging;

    exports com.company.app.service.api;
}

使用模块路径编译：

javac --module-path mods -d mods/com.company.app.service \
    src/com/company/app/service/**/*.java

步骤3：应用程序模块

// 应用程序的 module-info.java
module com.company.app {
    requires com.company.app.service;
    requires com.company.app.data;
    requires java.logging;
}

运行模块化应用程序：

java --module-path mods -m com.company.app/com.company.app.Main

测试您的模块化应用程序

运行完整的单元测试和集成测试，以验证模块边界。测试确保：

• 所有必需的模块都已正确声明
• 导出的包对于依赖模块是足够的
• 没有发生非法访问尝试
• 基于反射的框架能通过 opens 指令正常工作

用于兼容性的命令行选项

在迁移期间，您可能需要临时的变通方案。Java提供了几个命令行选项：

• --add-exports：将一个模块的包导出给另一个模块
• --add-opens：为一个包开放深度反射权限
• --add-reads：使一个模块读取另一个模块
• --patch-module：覆盖或扩充模块的内容

这些选项应作为临时解决方案，同时您需要适当地重构代码。

迁移后的好处

成功迁移后，您将获得：强封装（模块显式控制API）、更好的依赖管理（具有清晰的模块边界）、更高的安全性（通过减少攻击面）以及更快的启动时间（通过优化的模块图）。

模块化的JDK本身展示了这些好处——您可以使用 jlink 创建仅包含应用程序所需模块的自定义运行时映像，从而显著减小部署大小。

最佳实践

成功迁移到JPMS需要遵循成熟的模式并避免常见的陷阱。以下最佳实践源自现实世界的迁移经验，代表了已成功模块化大型Java应用程序的团队的集体智慧。遵循这些指南将帮助您避免代价高昂的错误，并确保顺利过渡到模块化架构。

最佳实践	描述	重要性
从 Java 9+ 兼容性开始	在尝试模块化之前，确保您的应用程序可以在 Java 9+ 上运行	将运行时问题与模块相关问题分开，使调试更容易
增量迁移	不要试图一次性模块化所有内容；选择自底向上或自顶向下策略并系统地进行	降低风险，允许从早期模块中学习，并保持应用程序稳定性
策略性使用自动模块	将自动模块视为迁移期间的临时桥梁，而不是最终目标	自动模块缺乏适当的封装，应替换为显式模块
审查生成的描述符	始终审查和完善由 jdeps 生成的 module-info.java 文件	生成的描述符是起点，可能会过度导出或错过重要的封装机会
积极封装	仅导出真正属于公共API的包；隐藏内部包	强封装防止紧耦合，使重构更安全
文档化模块依赖关系	维护关于模块边界、职责和依赖关系的清晰文档	帮助团队理解模块图并在开发过程中做出明智决策
彻底测试	在每次模块迁移后运行全面的单元测试和集成测试	模块化改变了可见性和访问模式，可能会破坏基于反射的代码
监控非法访问	在测试期间使用 --illegal-access=warn 或 --illegal-access=deny	在内部API导致生产问题之前识别依赖它们的代码
规划循环依赖	通过将共享功能提取到单独的模块中，及早识别并解决循环依赖	JPMS禁止模块间的循环依赖，因此必须对它们进行重构
一致的模块版本管理	在模块生态系统中使用一致的版本控制方案	简化依赖管理并使故障排除更容易

结论

将遗留Java单体应用迁移到使用JPMS的模块化Java是一项重大但有益的工作。通过周密的规划、重构和测试，您可以获得更好的可维护性、性能和安全性等好处。

关键是为您的应用程序选择正确的策略——对于依赖关系较少的库和组件使用自底向上，对于希望在应用程序级别立即受益的应用使用自顶向下。广泛使用 jdeps 来了解您当前的状态并指导您的迁移决策。

虽然模块化可以说是Java有史以来最令人望而生畏的特性之一，并且适当的模块在Java世界中仍然很少见，但对于大规模应用程序而言，强封装、显式依赖关系和更高的安全性所带来的好处使得迁移工作是值得的。

---

【注】本文译自：Java Platform Module System: Migration Strategies for Legacy Applications

Java 缓存精要

实现更低延迟、降低成本并赋能智能体架构

作者：GRANVILLE BARNETT
架构师，HAZELCAST

缓存技术在系统中的作用日益重要，对于大规模解锁众多用例至关重要。几十年来，缓存已实现低成本、可扩展地访问会话状态和数据存储等信息。更现代的缓存用例正在实现低成本、可扩展的工具链，并在智能体架构中实现嵌入生成，这正在解锁下一代系统创新。

本参考资料卡介绍了使用 Java 的 JCache（Java 临时缓存 API）将缓存融入系统的方法。文中首先讨论了缓存的基础知识，然后通过代码示例简要介绍了 JCache API，最后总结了缓存部署架构。

缓存概述

缓存是先前计算结果的一个存储，以便可以省略后续计算。理解缓存最简单的方式是将其视为键值存储：对于给定的输入（键），输出（值）代表先前基于该输入计算出的结果。

缓存命中表示特定数据存在于缓存中，这种情况下可以使用其值。否则，就会发生缓存未命中，此时需要执行相关计算并将其输出放入缓存。缓存未命中的代价可能除了昂贵的计算操作外，还涉及网络通信。

图 1：简化的缓存命中/未命中流程

采用缓存是为了减少延迟并降低运营成本，几十年来对于实现众多类别的应用程序至关重要。缓存数据的例子包括 Web 应用程序的会话状态、数据库查询结果、网页渲染结果，以及来自通用网络和计算成本高昂的操作的结果。

缓存的一个更现代的用途是在 AI 领域。在这里，缓存的使用减少了昂贵的 API 调用（例如，嵌入生成），并最大限度地减少了智能体架构中智能体之间的对话断续（例如，由于工具调用和网络通信所致），从而解锁了新一波的解决方案和用户体验。

缓存可以驻留在进程内，作为客户端-服务器架构的一部分存在于服务中，或者是两者的结合。此外，缓存的部署通常可以组合。例如，应用程序可能与位于同一数据中心的缓存服务通信，而数据中心的本地缓存又是跨越多个数据中心的缓存的缓存。这种灵活性，加上缓存所支持的应用类别，使得缓存在过去几十年中成为一种主导的抽象概念。

本参考资料卡的剩余部分将讨论 JCache——Java 用于将缓存融入应用程序的抽象——首先简要概述您将经常使用的类，然后深入探讨 JCache 更广泛功能所提供的特性。最后，我们将总结缓存部署策略。

JCACHE 精要

JCache 在 Java 规范请求（JSR）107 中引入，并提供了一套关于缓存的抽象。JCache 有两个突出的特性：

• JCache 是一个规范。 JSR 是由专家组设计和提交，并最终由 Java 社区过程执行委员会批准的规范。因为 JCache 是一个规范，所以它与那些 API 频繁变化的实现隔离开来。
• JCache 是提供商独立的。 JCache 作为规范的一个副作用是，缓存解决方案提供商可以通过实现其暴露的服务提供程序接口（SPI）来与 JCache 集成。这为系统设计者提供了灵活性并避免了供应商锁定。

以下是一个简单的 JCache 示例，以便理解其使用方式。javax.cache 依赖项的获取方式可以在此处找到。

import java.util.Map;
import javax.cache.Cache;
import javax.cache.CacheManager;
import javax.cache.Caching;
import javax.cache.configuration.MutableConfiguration;
import javax.cache.spi.CachingProvider;

public class App {
    public static void main(String[] args) {
        CachingProvider cachingProvider = Caching.getCachingProvider(); // (1)
        CacheManager cacheManager = cachingProvider.getCacheManager(); // (2)
        MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>(); // (3)
        Cache<String, String> cache = cacheManager.createCache("dzone-cache", cacheConfig); // (4)
        cache.put("England", "London"); // (5)
        cache.putAll(Map.of("France", "Paris", "Ireland", "Dublin")); // (6)
        assert cache.get("England").equals("London"); // (7)
        assert cache.get("Italy") == null; // (8)
    }
}

对上述示例的简要说明：
(1) 获取底层缓存提供程序的句柄
(2) 管理缓存的生命周期（例如，创建和销毁缓存）
(3) 允许启用/禁用缓存的特定功能（例如，统计信息、条目监听器）
(4) 创建由缓存提供程序支持的缓存
(5) 在缓存中放入单个键值条目
(6) 将键值条目放入缓存
(7) 断言缓存条目的存在
(8) 断言某个条目不在缓存中

本节的剩余部分将更详细地讨论上述示例中引入的抽象，以及您将经常遇到的相关类的其他方法。

javax.cache.spi.CachingProvider 构成了 JCache SPI，缓存提供者可以与之集成。您将使用的最常见功能是获取对 CacheManager 的引用。我们稍后将讨论 Caching。

getCacheManager 是 getCacheManager 变体中最简单的一个。这将根据提供者的默认设置获取一个 CacheManager。可以使用 javax.cache.CacheManager 创建和销毁缓存：

• createCache 创建一个具有给定名称和配置的缓存。
• destroyCache 销毁具有给定名称的缓存。

javax.cache.Cache 是对提供者缓存的抽象，并暴露了少量用于查询和变更缓存项的操作：

• put 和 putAll 将条目放入缓存。请注意，这些方法不返回与正在放入的键先前关联的任何值。
• containsKey 测试键是否存在于缓存中。
• get 和 getAll 返回与指定键关联的值。
• remove 和 removeAll 从缓存中移除项。

JCACHE 包

在本节中，我们将快速概述 javax.cache 更广泛包结构中的一些重要接口，并提供常用功能的示例。我们可以参考文档来浏览其内容的详尽列表。

图 2：javax.cache 的组成包

JAVAX.CACHE

通用管理（CacheManager）和与缓存交互（Cache）的设施位于 javax.cache 包内。除了初始配置之外，除非您想为缓存添加额外功能，否则仅使用此包中的类型就可以完成很多工作。例如，"JCache 精要"部分介绍中的示例用法主要使用了 javax.cache 中定义的接口。

JAVAX.CACHE.CONFIGURATION

在创建缓存期间，您可能希望添加功能，例如启用统计信息或通读缓存。此包提供了一个 Configuration 接口和一个实现 MutableConfiguration，可用于此类目的。

// ...
MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>();
cacheConfig.setManagementEnabled(true).setStatisticsEnabled(true);
Cache<String, String> cache = cacheManager.createCache("dzone-cache", cacheConfig);

JAVAX.CACHE.EXPIRY

有时您希望驻留在缓存中的项过期。例如，我们可能有一个家庭保险报价的缓存，有效期为 24 小时。在这种情况下，我们可以使用过期策略如下：

// ...
MutableConfiguration<String, Double> cacheConfig = new MutableConfiguration<String, Double>();
cacheConfig.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(Duration.ONE_DAY));
Cache<String, Double> cache = cacheManager.createCache("insurance-home-quotes", cacheConfig);
cache.put(quote.getId(), quote.getValue());

javax.cache.expiry 包提供了额外的过期策略，可能对其他场景有用。例如，AccessedExpiryPolicy 允许基于缓存条目的最后访问时间附加过期设置。

JAVAX.CACHE.EVENT

JCache 的一个强大功能是能够订阅缓存事件。例如，我们可能希望在创建或删除缓存条目后运行某些领域逻辑。javax.cache.event 包提供了实现此功能的抽象，特别是订阅缓存创建、更新、过期和移除的能力。以下基本示例在缓存条目创建后运行某些领域逻辑：

// ...
CacheEntryCreatedListener<String, String> createdListener = new CacheEntryCreatedListener<String, String>() {
  @Override
  public void onCreated(Iterable<CacheEntryEvent<? extends String, ? extends String>> events) throws CacheEntryListenerException {
    for (var c : events) {
      performDomainLogic(c);
    }
  }
};
MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>();
MutableCacheEntryListenerConfiguration<String, String> listenerConfig = new MutableCacheEntryListenerConfiguration<>(() -> createdListener, null, false, true); // 请参阅文档
cacheConfig.addCacheEntryListenerConfiguration(listenerConfig);
Cache<String, String> cache = cacheManager.createCache("events", cacheConfig);
cache.put("key", "value"); // 调用创建监听器

JAVAX.CACHE.PROCESSOR

JCache 的一个强大组件是能够使用 EntryProcessor 将计算移至数据所在处，然后以编程方式调用该计算。当使用在分布式系统（例如，Hazelcast）内托管其缓存的提供者时，这尤其强大，因为它以很少的投入为分布式计算提供了一个简单的入口点。以下是一个 EntryProcessor 的简单示例，它将 UUID 附加到缓存条目：

// ...
class AppendUuidEntryProcessor implements EntryProcessor<String, String, String> {
  @Override
  public String process(MutableEntry<String, String> entry, Object... arguments) throws EntryProcessorException {
    if (entry.exists()) {
      String newValue = entry.getValue() + "-" + UUID.randomUUID();
      entry.setValue(newValue);
      return newValue;
    }
    return null;
  }
}
// ...
cache.invoke(key, new AppendUuidEntryProcessor())

JAVAX.CACHE.MANAGEMENT

JCache 提供的管理钩子非常强大且易于启用。例如，下面的小代码片段暴露了由 Java 管理扩展（JMX）规范定义的托管 Bean。这使得诸如 jconsole 和 JDK Mission Control 之类的 JMX 客户端能够查看缓存配置和统计信息（例如，命中和未命中百分比、平均获取和放置时间）。

// ...
MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>();
cacheConfig.setManagementEnabled(true).setStatisticsEnabled(true);
Cache<String, String> cache = cacheManager.createCache("management", cacheConfig);
// ...

JAVAX.CACHE.SPI

"JCache 精要"部分提供的示例省略了我们如何注册缓存提供者，即使用 JCache API 与我们的应用程序交互的缓存宿主服务。这就是 JCache 的 SPI 组件发挥作用的地方。

实现这一点有两个组成部分：

1. 将我们的缓存提供者添加到类路径中
2. 告诉 JCache 使用该提供者

第一步很简单：只需添加对任何符合 JSR 107 标准的提供者的依赖。

第二步有几种通用的方法：

• 我们可以通过调用 Caching#getCachingProvider(...) 的某个变体（以及其他方法）来告诉 JCache。
• 我们可以提供一个 META-INF/services/javax.cache.spi.CachingProvider 文件，并让其指定提供者实现。指定的提供者是您的提供者的缓存提供者实现的完全限定名称。
• 我们可以使用 Caching#getCachingProvider()；但是，最好明确限定要使用的提供者，因为您的类路径上可能有多个提供者，这会抛出 javax.cache.CacheException。

例如，以下代码使用 CachingProvider Caching.getCachingProvider(String) 指定 Hazelcast 为提供者：

CachingProvider cachingProvider = Caching.getCachingProvider("com.hazelcast.cache.HazelcastCachingProvider");
CacheManager cacheManager = cachingProvider.getCacheManager();
MutableConfiguration<String, String> cacheConfig = new MutableConfiguration<String, String>();
Cache<String, String> cache = cacheManager.createCache("spi-example", cacheConfig);
cache.put("k", "v");

JAVAX.CACHE.ANNOTATION

JCache 定义了许多注解，用于集成到上下文和依赖注入环境中。Spring Framework 原生支持 JCache 注解。我们可以参考 JCache 文档以获取更多信息。

JAVAX.CACHE.INTEGRATION

javax.cache.integration 包提供了 CacheLoader（需要通读）和 CacheWriter（需要通写）。CacheLoader 在将数据读入缓存时使用——例如 Cache#loadAll(...)。CacheWriter 可以作为一个集成点，将缓存变更（例如，写入、删除）传播到外部存储服务。

缓存部署

JCache 没有缓存部署策略的概念；它仅仅是缓存提供者之上的一个 API。然而，不同的提供者支持不同类型的缓存部署。请考虑哪种缓存部署对您的应用程序有意义，并由此反向确定合适的缓存提供者。

图 3： 缓存部署示例

请注意，一些缓存提供者可能支持所有这三种缓存部署，而其他提供者可能不支持。

本节的剩余部分讨论图 2 中所示的常见缓存部署：

• 嵌入式 – 缓存与应用程序位于同一进程中。
• 客户端-服务器 – 缓存托管在独立的服务中，客户端与该服务通信以确定缓存驻留。
• 嵌入式/客户端-服务器 – 这是一种混合模式，整个缓存托管在不同的服务上，但客户端在同一进程中拥有一个较小的本地缓存。

重要的是要注意，上述缓存部署并非互斥的；它们可以通过多种方式组合以满足应用程序需求。

最简单的缓存部署是让缓存与应用程序驻留在同一进程中，这样做的好处是提供低延迟的缓存访问。嵌入式缓存不能在应用程序之间共享，并且在应用程序重启或故障时，其托管（它们所需的资源）和重建成本可能很高。

客户端-服务器缓存部署将缓存托管在与客户端不同的服务中。缓存服务允许通过跨服务复制来满足容错需求，提供更大的容量、更多的可扩展性选项，以及跨应用程序共享缓存的能力。客户端-服务器模型的主要缺点在于客户端缓存查询期间网络通信的成本。

混合嵌入式/客户端-服务器部署是指我们拥有一个嵌入式缓存，它包含来自服务缓存条目的一个子集，作为应用程序缓存请求的副作用被填充。在这里，客户端可以对频繁访问的数据（或表现出特定访问模式的数据）实现低延迟的缓存命中，并省去与缓存服务通信所带来的网络通信开销。如果嵌入式缓存过期，一些提供者会负责使用服务托管的缓存来更新它们。

结论

本参考资料卡介绍了缓存以及如何将其与 Java 的 JCache API 一起使用。JCache API 直观、强大，并且由于其是一个规范而避免了供应商锁定，为架构师和系统设计者提供了他们所需的灵活性。这种灵活性在我们进入基于智能体架构的新一代创新时尤为重要，其中缓存对于工具链和嵌入生成至关重要。

作者：GRANVILLE BARNETT,
架构师，HAZELCAST
Granville Barnett 拥有计算机科学博士学位，是拥有超过 15 年经验的分布式系统专家。他目前是 Hazelcast 的架构师，此前曾在 HP Labs 和 Microsoft 任职。Granville 拥有多项美国专利，并发表了关于程序验证主题的研究。

附加资源：

• 《Java 应用程序容器化与部署》，作者 Mark Heckler，DZone 参考资料卡
• Java 社区进程

---

【注】本文译自：Java Caching Essentials