Java微服务：用Spark替代SpringBoot才是正确的方式 - Christian Lusardi

一个真正的微服务是一个非常轻薄的程序，只有一个函数具有自己的数据库（如果有必要）和非常小的内存占用......在 Java 中可能吗？

问题

我已经使用Spring Framework多年了，现在和我的团队一起开始质疑它，特别是Spring Boot：它是开发微服务的正确选择吗？不，因为根据我们的经验，它太耗费内存了。

我发现在Spring Boot上运行的基本Java应用程序需要至少1GB的RAM才能运行，而且在开发中间件应用程序时也没问题，但在微服务架构中这非常糟糕！

我们注意到部署在CloudFoundry上的Spring Boot应用程序或带有k8s的OpenShift遭遇内存不足错误并且如果它们未设置为最小1GB则会崩溃。

我们正在寻找一种新 工具 来帮助我们使用这个技术规范开发真正的微服务：

• 符合Java标准
• 轻量级
• 没有无用的库
• 内存占用少
• 快速服务请求

正确的框架

下面是pom.xml的一小段摘录

<dependencies>

    <!-- Spark dependencies (the core) -->
    <dependency>
        <groupId>com.sparkjava</groupId>
        <artifactId>spark-core</artifactId>
        <version>2.8.0</version>
    </dependency>

    <!-- Logback version (I hope you want to log!) -->
    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>1.2.3</version>
    </dependency>

那么，现在我们正确定义 Docker 文件......

FROM openjdk:8-jre-alpine

LABEL maintainer=<font>""</font><font> \
      name=</font><font>"my-microservice"</font><font> \
      description=</font><font>"my description"</font><font> \
      myGroupId.myArtifactId=</font><font>"0.0.1-SNAPSHOT"</font><font>

ARG JAR_NAME=</font><font>"service-name-version.jar"</font><font>
ENV HTTP_PORT=4567 #Default Spark port 
EXPOSE ${HTTP_PORT}
WORKDIR /usr/src/app
</font>

我们选择了“ openjdk：8-jre-alpine ”，因为这个起始图像在内存和大小方面都是更小，更轻的。如果你想提高性能，你可以选择Java 11 ...但是目前，不幸的是，这不存在：你可以在将来使用“ openjdk：12-jre-alpine ”当Java12将被发布。（您可以在此处查看完整列表：https://hub.docker.com/_/openjdk/）。

结果

首先，Jar包大小：只有10MB的罐子！太棒了！使用SpringBoot，我们总是达到至少30MB ......不是那么糟糕！

• 启动时间（开发）：使用我们的MCU库（ 这里 查找信息）和Spark的启动时间非常简约。你可以在1分钟内完成“hello-world”GET方法......
• 启动时间：我们习惯等待将近30-40秒......现在我们的等待时间不到1秒。
• 代码行：在微服务架构中，您应该创建一个非常小的程序，具有极简主义配置，依赖性和仅一个功能......在这些前提下，我们假设代码行应该很少。在Spring Boot中，这并不总是正确的，因为框架往往是罗嗦的。使用Spark，LOC数量非常低。
• 内存占用：你可能知道Java是内存贪婪，但通过正确的配置和优化，你可以达到一个很好的目标！在带有Spring Boot的Docker容器中，我们很沮丧，因为很难获得低于500MB的RAM ......现在我们保持大约30~60MB的RAM。
• 可维护性：简单就是更好！微服务的目标之一是在小n问题中划分et impera主要问题。没有困难的配置，没有依赖关系，而且代码很小，可维护性非常简单。
• 可靠性：我们的压力测试没有任何问题......该框架非常强大且具有弹性。

基准测试

们创建了两种类型的基准：

• Hello World - 在JSON响应中序列化的简单“hello world”消息
• 计算任务 - 具有JSON反序列化，ETL作业和对象序列化响应的中等复杂度级别计算任务

我们已经实现了这两种基准类型：

• 使用Undertow Application Server进行Spring Boot
• Spring Boot Webflux
• VertX
• SparkJava

结果如下：

有框架都是差不多的，但随着当代用户数量的增加，Spark开始受到影响。那么，关注点是内存占用而不仅仅是吞吐量。

• 使用此基准测试的Spark内存占用无关紧要：60 MB的堆大小和35 MB的平均使用率，没有任何类型的微调。

对于其他框架，堆大小是非常大，例如使用Spring Boot，我们有大约290-300 MB的堆（受-xmx JVM参数限制）

实际使用率约为100-150MB，比Spark重4-5倍。

结论

如果你必须做一个简单的微服务，正确的选择是Spark，因为：

• 它真的很轻
• 启动时间太快了
• 没有任何无用的类/库
• 最后的罐子重量非常轻

现在，您只关注开发和可扩展性，将其留给Docker和Kubernetes而不考虑内存。

例如：2个Spark容器使用70MB或更少的内存，并且比1个Spring Boot容器提供更多的请求。

​​​​​​​我想强调并感谢我所有团队的合作，特别是Luca Pompei是一位出色的团队领导和开发人员。