Spring in memory 数据网格应用答案

【问题标题】：Spring in memory data grid applicationSpring in memory 数据网格应用
【发布时间】：2016-08-19 19:36:54
【问题描述】：

在基于内存数据网格的应用程序的服务器端使用 Spring 是否明智？

我的直觉告诉我，在低延迟高性能系统中这是无稽之谈。我的一位同事坚持要在其中包含 Spring。这种包容的利弊是什么？

我的立场是，Spring 可以在客户端使用，但它对服务器来说太重了，它带来了太多的依赖关系，并且是一种更容易考虑的泄漏抽象。

【问题讨论】：

标签： spring hazelcast infinispan gemfire geode

【解决方案1】：

数据网格系统通常是内存和 I/O 密集型的。使用 Spring 不会影响这一点（您可能会争辩说 Spring 创建了很多 bean，但是通过适当的垃圾收集调整这不是问题）。

另一方面，使用 Spring（或任何其他 DI）可以帮助您构建和测试代码。

因此，如果您正在使用基于 Data Grid 系统实现某种服务器，请注意正确调整 GC、操作系统中的套接字（内存缓冲区和套接字内存）。与减少 DI 相比，这些会给您带来更多好处。

【讨论】：

【解决方案2】：

首先，我对“泄漏抽象”的评论感到惊讶。我从未听过有人为此批评 Spring。事实上，恰恰相反。 Spring 从您的应用程序代码中移除了数据网格等基础设施的实现细节，并提供了一致且熟悉的编程模型，让您可以专注于业务逻辑。 Spring 在增强配置和对数据网格的访问方面做了很多工作，尤其是 Gemfire，并且通常不会产生任何运行时开销本身。在 Spring 应用程序的初始化过程中，Spring 内部使用了反射和 AOP 等工具，这可能会增加应用程序的启动时间，但这对运行时性能没有影响。 Spring 已在许多高吞吐量、低延迟的生产应用程序中得到证明。在极端情况下，诸如网络延迟和序列化之类的 Spring 外部问题通常是影响性能的最大因素。

“Spring 带来了太多的依赖”是一个常见的抱怨，但却是一个谬论。我会说 Spring 为它需要做的事情带来了正确数量的依赖项。此外，Spring Boot 启动器和平台 BOM 为简化依赖项管理做了很多工作，因此您无需担心版本不兼容或显式声明常见依赖项。在这个问题上，我必须支持你的同事。

【讨论】：