问候 Spring 社区以及 Pivotal GemFire/Apache Geode 的用户们-

我经常被问到的一个问题是：“Spring Data GemFire 和 Spring Data Geode 有什么区别？”

现在，Spring Data Geode 已成为 Spring Data 发行系列 (Release Train) 的一部分，从 Kay 开始（详情请参阅 官方发布公告），现在终于是在一个开放论坛中回答这个问题的时候了。

为了帮助回答这个问题，我为 Spring Data GemFire 和 Spring Data Geode（现在统称为 SDG^2）设定了 2 个简单目标：

1. 首先，也是最重要的一点是，允许用户无缝地互换使用 Spring Data Geode 和 Spring Data GemFire。

2. 其次，帮助用户将其基于 Spring Boot、Pivotal GemFire 或 Apache Geode 的应用程序，从本地开发环境迁移到托管环境，例如 Pivotal CloudFoundry，只需很少或无需修改代码。

让我们仔细看看每个目标及其含义。

可互换的依赖

第一个目标是关于选择。

这意味着用户可以从 spring-data-geode 切换到 spring-data-gemfire，并且可以期待无需更改其使用 Pivotal GemFire 或 Apache Geode 的 Spring Boot 应用程序中的任何一行代码。

只需将 依赖声明 从这样…​

Maven

<dependency>
  <groupId>org.springframework.data</groupId>
   <artifactId>spring-data-geode</artifactId>
   <version>2.0.0.RELEASE</version>
</dependency>

Gradle

compile 'org.springframework.data:spring-data-geode:2.0.0.RELEASE'

变成这样…​

Maven

<dependency>
  <groupId>org.springframework.data</groupId>
   <artifactId>spring-data-gemfire</artifactId>
   <version>2.0.0.RELEASE</version>
</dependency>

Gradle

compile 'org.springframework.data:spring-data-gemfire:2.0.0.RELEASE'

然后就完成了！

甚至可以再次从 spring-data-gemfire 切换回 spring-data-geode，一切都能正常工作。整个 Pivotal GemFire 代码库及其所有功能都包含在开源版本 Apache Geode 中。

从功能和行为上讲，它们是一样的。唯一可辨别的区别在于，你将获得一组不同的传递依赖，即 GemFire vs. Geode。试试用其他任何 IMDG（特别是 OS 版本和企业级解决方案之间）来说这句话。

包名和类名

等等！包名和类名呢？ 它们在 Pivotal GemFire 和 Apache Geode 中难道不是不同的吗？ 你们难道不会更改包名和类名吗，例如将 Spring Data GemFire 中的 org.springframework.data.gemfire.GemfireTemplate 更改为 Spring Data Geode 中的 org.springframework.data.geode.GeodeTemplate？

不；绝对不会！

例如，考虑以下 GemFire/Geode 接口：org.apache.geode.cache.GemFireCache。

在 Pivotal GemFire 9.0 及更高版本中，该接口是 org.apache.geode.cache.GemFireCache，使用了 org.apache.geode 包命名空间。在 Apache Geode 中，相同的接口是 org.apache.geode.cache.GemFireCache，其中仍然使用了“GemFire”这个名称。其他类和接口也是如此。

这对于互操作性以及迁移原因来说实际上非常重要，尤其是在 GemFire/Geode 的分发层，其中客户端和服务器之间以及集群中对等成员之间会发送专有消息。

版本

Spring Data GemFire 2.0 (Kay) 基于 Pivotal GemFire 9.1.1，而 Pivotal GemFire 9.1.1 本身基于 Apache Geode 1.2.0。

Spring Data Geode 2.0 (Kay) 基于 Apache Geode 1.2.1。

因此，SDG^2 库实际上可以互换使用，无需更改应用程序代码。

既然 Spring Data Geode 正式成为 Spring Data 发行系列 的一部分，Spring Data Geode 和 Spring Data GemFire 的版本号将保持一致，并从现在开始保持相同。

提示

我们建议您要么使用 Spring Data BOM 文件，即 org.springframework.data:spring-data-releasetrain:Kay-RELEASE（如 Spring Boot 在其 依赖声明 和 版本 中所做的那样），要么继承 Spring Boot starter parent POM。此外，您还可以使用 Spring IO Platform，它提供了一组经过精心挑选和协调的依赖项，这些依赖项都经过测试可以协同工作。

从本地到托管环境

第二个目标旨在帮助用户踏上云端之旅，通过利用 云原生 (Cloud Native) 软件设计模式，并以 Spring 的方式运用 Pivotal GemFire 等云就绪解决方案。

回顾 2003 年，我的一个同事曾对我说：“考虑全球，构建本地”。他当时是在讽刺，但我刚刚加入公司，正在询问如何在本地、从我的 IDE 中构建、运行和测试我们的企业级 Java 应用程序。

当时，我们的团队正忙于尝试集中所有开发活动。部分原因在于，由于我们的应用程序必须在 WebSphere 上运行，设置开发人员的本地开发环境、在本地安装 IBM WebSphere 变得异常复杂。

结果证明，他的评论其实是对的！

确保运营合同不会妨碍开发至关重要，尤其是在开发阶段，因为它们反正很可能会随着时间推移而改变。实施 CI/CD 的主要原因之一就是弥合这一差距。

在开发过程中，开发人员需要完全控制其环境以满足应用程序的需求。能够使用轻量级进程构建、启动、测试、调试和分析应用程序，对于保持敏捷至关重要。随着项目从概念到生产的推进，CI/CD 在及时响应变化方面变得必不可少。然而，没有什么应该阻碍开发人员交付可工作的代码的能力，而这始于 IDE 内部。

从一开始，Spring 就专注于提升开发人员的生产力，为开发人员提供正确的框架和工具，以快速、可靠、高质量地解决任何企业应用程序问题。现在，有了 Spring Boot 和 Spring Cloud 等技术，发展道路变得非常清晰，这一切都围绕着“云原生 (Cloud Native)”。这不仅仅是常识性的开发，更是智能的开发。

因此，目标 #2 的主要意图是将这些相同的概念应用于数据，分别通过 Spring Data GemFire 或 Spring Data Geode 来针对 Pivotal GemFire 或 Apache Geode。通过在用户的 Spring Boot 应用程序中使用 SDG 新的基于注解的配置方法 (Annotation-based configuration approach)，以及针对 Pivotal GemFire/Apache Geode 的自动配置支持 (auto-configuration support)，无论是用户在本地使用 Apache Geode，还是在全球 PCF 中使用 PCC / SSC（由 Pivotal GemFire 提供支持），都将获得一致的体验，只需很少或无需更改代码。

这意味着减少意外，更多地专注于真正重要的事情——为最终用户交付价值。毕竟，这就是框架或工具的全部意义所在：简化流程，并处理那些虽然必要但对最终用户来说非本质性的样板代码。

总结

那么，区别是什么呢？

绝对没有区别！至少在实践中，即使在不同的环境中，也不应该有明显的差异。

我希望这篇文章能帮助人们从根本上理解和认识到这里试图实现的目标范围，它远远超出了 Spring Data GemFire 和 Spring Data Geode 在功能、行为和表面上的差异。它还包括在最简单、最容易的方式下，从概念到生产交付的始终如一的体验。

一如既往，非常欢迎您的反馈，无论是通过在 JIRA 中提交工单，提交 PR，还是仅仅在 StackOverflow 中提问。

重要提示

今年一定要参加 SpringOne Platform 大会。大会计划了许多精彩的内容，还有很多新东西可以学习，特别是关于新的 Reactive Spring。这将是一场具有划时代意义的盛会。