转载

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是一位出色的团队领导和开发人员。

原文  https://www.jdon.com/51806
正文到此结束
Loading...