共计 2331 个字符,预计需要花费 6 分钟才能阅读完成。
在整体应用架构中,非生产环境情况下,一般 1GB 或者 2GB 的 RAM 就足够了。如果我们将这个应用程序划分为 20 或 30 个独立的微服务,那么很难期望 RAM 仍将保持在 1GB 或 2GB 左右。特别是如果我们使用 Spring Cloud 的时候。
首先,准备三个服务,Eureka 服务 + 提供 REST API 的两个简单的微服务,并将微服务注册到 Eureka。此处,不以任何方式限制这些应用程序的内存使用。
就像你在下图看到的一样,三个微服务大概占用了电脑 1.5GB 的 RAM 内存。这三个服务是最简单的应用程序,基本没有数据处理量,对于这样的内存消耗量,显然是不理想的。RAM 的最低使用量是用于 Eureka
发现服务,最大的用于初始化声明式客户端以调用其他服务的 API。
关于内存使用量如下图 JProfiler 制作的图表。如图所示,内存使用受堆影响,与非堆相比,它占用了大量空间。
当然,第一个明显的问题是我们是否需要在堆上运行我们的微服务应用程序的空间。答案是否定的,我们没有。现在,我们来简要介绍一下在
Java 8 中如何进行内存管理过程。
我们可以将 JVM 内存分为两个不同的部分:堆(Heap)、非堆(Non-Heap)。如上图所示,我们的微服务器的大小为大小(〜600MB)。反过来,JVM 内存 由 年轻代(Young Generation)、老年代(Old Generation)组成。所有新创建的对象都位于年轻代中。当年轻代被填满时,执行 次要垃圾收集(Minor GC)。更准确的说,这些位于年轻代的一部分对象成为 Eden Space。Minor GC 将所有仍然使用的对象从 Eden Space 移动到 Survivor 0。对于 Survivor 0 和 Survivor 1 空间执行相同的过程。在 GC 的许多循环中幸存的所有对象都被移动到老年代内存空间。从哪里移除对象是由 Major GC 负责的。为了更好地了解下图,在运行 java -jar 命令时,可以使用以下参数设置 Java Heap 的内存限制:
- -Xms – JVM 启动时的初始堆大小
- -Xmx – 最大堆大小
- -Xmn – 年轻代的大小,其余的空间是老年代
JVM 内存的第二部分,从我们的角度来看,上图略显不重要,它是 Non-Heap。Non-Heap 包括以下部分:
- Thread Stacks:所有运行的线程的空间。可以使用 -Xss 参数设置最大线程大小。
- Metaspace:它替代了 PermGem(Java 7 中是 JVM 堆的一部分)。在 Metaspace 中,通过应用程序加载所有类和方法。看看 Spring Cloud 包含的包数量,我们不会在这里节省大量的内存。可以通过设置 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 参数来管理 Metaspace 大小。
- Code Cache:这是由 JIT(即时)编译器编译为本地代码的本机代码(如 JNI)或 Java 方法的空间。最大大小设置 -XX:ReservedCodeCacheSize 参数。
- Compressed Class Space:使用 -XX:CompressedClassSpaceSize 设置为压缩类空间保留的最大内存。
- Direct NIO Buffers
更简单来说,Heap 是用于对象,Non-Heap 是用于类。可以想像,当我们的应用程序 Non-Heap 大于 Heap 时,我们可以结束这种情况。首先,让我们用下面的参数来运行我们的服务发现。在我看来,如果您在 Spring Boot 上启动具有内嵌 Tomcat 的 Eureka,这些配置是最低的值。
-Xms16m \
-Xmx32m \
-XX:MaxMetaspaceSize=48m \
-XX:CompressedClassSpaceSize=8m \
-Xss256k \
-Xmn8m \
-XX:InitialCodeCacheSize=4m \
-XX:ReservedCodeCacheSize=8m \
-XX:MaxDirectMemorySize=16m
如果使用 REST API 的微服务(带有 Feign 或 Ribbon),我们需要增加一些值:
-Xms16m \
-Xmx48m \
-XX:MaxMetaspaceSize=64m \
-XX:CompressedClassSpaceSize=8m \
-Xss256k \
-Xmn8m \
-XX:InitialCodeCacheSize=4m \
-XX:ReservedCodeCacheSize=8m \
-XX:MaxDirectMemorySize=16m
按照如上配置,JProfiler 生成了如下图表。区别在于启动和请求处理时间。与早期的设置相比,该应用程序的运行速度较慢。当然,我不会在生产环境下设置这样的参数。
当前的总内存使用情况如下。微服务仍然是内存占用最大的,而 Eureka 最小。
我也尝试使用不同的 Web 容器运行 Eureka 应用程序。您可以通过在pom.xml
文件中包含以下的依赖关系轻松更改 Web 容器。
使用 Undertow
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
使用 Jetty
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jetty</artifactId>
</dependency>
结果排名:Undertow(116MB)、Tomcat(122MB)、Jetty(128MB)。
此测试仅针对 Eureka 服务执行,而无需注册任何微服务。