Spring内存数据网格应用
Spring in memory data grid application
在基于内存数据网格的应用程序的服务器端使用 Spring 是否明智？
我的直觉告诉我，在低延迟高性能系统中这是无稽之谈。我的一位同事坚持要在其中包含 Spring。这种包含的优缺点是什么？
我的立场是 Spring 可以在客户端使用，但它对服务器来说太重了，它带来了太多的依赖性，并且是另一个需要考虑的漏洞抽象。
首先，我对 "leaky abstraction" 评论感到惊讶。我从未听过有人为此批评 Spring。事实上，恰恰相反。 Spring 从您的应用程序代码中删除数据网格等基础设施的实现细节，并提供一致且熟悉的编程模型，让您专注于业务逻辑。 Spring 在增强配置和对数据网格（尤其是 Gemfire）的访问方面做了很多工作，并且通常本身不会产生任何运行时开销。 Spring 应用程序在初始化过程中，Spring 内部使用了反射和AOP 等工具，这可能会增加应用程序的启动时间，但这对运行时性能没有影响。 Spring 已在许多高吞吐量、低延迟的生产应用程序中得到证明。在极端情况下，Spring 之外的网络延迟和序列化等问题通常是影响性能的最大因素。
"Spring brings in too many dependencies" 是一个常见的抱怨，但却是一个谬论。我会说 Spring 为它需要做的事情带来了恰到好处的依赖关系。此外，Spring Boot starters 和平台 BOM 为简化依赖项管理做了很多工作，因此您无需担心版本不兼容或显式声明公共依赖项。在这件事上，我必须站在你的同事一边。
Data Grid 系统通常是内存和 I/O 密集型的。使用 Spring 不会影响这一点（您可能会争辩说 Spring 会创建很多 bean，但通过适当的垃圾收集调整，这不是问题）。
另一方面，使用 Spring（或任何其他 DI）可以帮助您构建和测试代码。
因此，如果您正在使用实现某种基于数据网格系统的服务器，请注意正确调整 GC、OS 中的套接字（内存缓冲区和套接字内存）。这些会给你带来比减少 DI 更多的好处。
在基于内存数据网格的应用程序的服务器端使用 Spring 是否明智？
我的直觉告诉我，在低延迟高性能系统中这是无稽之谈。我的一位同事坚持要在其中包含 Spring。这种包含的优缺点是什么？
我的立场是 Spring 可以在客户端使用，但它对服务器来说太重了，它带来了太多的依赖性，并且是另一个需要考虑的漏洞抽象。
首先，我对 "leaky abstraction" 评论感到惊讶。我从未听过有人为此批评 Spring。事实上，恰恰相反。 Spring 从您的应用程序代码中删除数据网格等基础设施的实现细节，并提供一致且熟悉的编程模型，让您专注于业务逻辑。 Spring 在增强配置和对数据网格（尤其是 Gemfire）的访问方面做了很多工作，并且通常本身不会产生任何运行时开销。 Spring 应用程序在初始化过程中，Spring 内部使用了反射和AOP 等工具，这可能会增加应用程序的启动时间，但这对运行时性能没有影响。 Spring 已在许多高吞吐量、低延迟的生产应用程序中得到证明。在极端情况下，Spring 之外的网络延迟和序列化等问题通常是影响性能的最大因素。
"Spring brings in too many dependencies" 是一个常见的抱怨，但却是一个谬论。我会说 Spring 为它需要做的事情带来了恰到好处的依赖关系。此外，Spring Boot starters 和平台 BOM 为简化依赖项管理做了很多工作，因此您无需担心版本不兼容或显式声明公共依赖项。在这件事上，我必须站在你的同事一边。
Data Grid 系统通常是内存和 I/O 密集型的。使用 Spring 不会影响这一点（您可能会争辩说 Spring 会创建很多 bean，但通过适当的垃圾收集调整，这不是问题）。
另一方面，使用 Spring（或任何其他 DI）可以帮助您构建和测试代码。
因此，如果您正在使用实现某种基于数据网格系统的服务器，请注意正确调整 GC、OS 中的套接字（内存缓冲区和套接字内存）。这些会给你带来比减少 DI 更多的好处。