限时领|《AI 百问百答》专栏课+实体书(包邮)! 了解详情
写点什么

在 HubSpot 是如何应对 Fat JAR 困境的

  • 2016-08-28
  • 本文字数:1609 字

    阅读完需:约 5 分钟

在七月底,Spring Boot 和 Dropwizard 分别发布了 1.4 和 1.0 版本,它们都是基于 Fat JAR 的。随着人们更多地采用这些框架和微服务架构,Fat JAR 成为了通用的部署机制。

Fat JAR 技术会将 Java 应用的所有依赖打包到一个 bundle 之中,便于执行,这种方式用到了很多的 Java 微服务框架之中,包括 Spring Boot 和 Dropwizard,甚至还有一个专门的 Fat JAR Eclipse 插件

对于具有少量微服务的组织来说,Fat JAR 所占用的带宽可能并不那么明显。但是,如果你有上千个微服务的话,那么它们所使用的带宽就会成为一个问题了。

在今年夏天的早些时候,HubSpot 曾经提到过借助 maven-shade-plugin进行Fat JAR 部署所遇到的问题,并介绍了他们将100,000 个小文件打包到一个JAR 中所遇到的性能问题。他们还提到,1,000 个以上的应用进行持续不断地构建和部署,会产生大量重复的JAR 依赖。

他们曾经尝试使用maven-dependency-plugin 来减缓这种快速膨胀,但是他们的努力并没有减少所生成的构建工件(artifact)的大小。

为了解决Fat JAR 所带来的痛苦,HubSpot 创建了用于Maven 的SlimFast 插件,它所创建的构建工件只会包含指定项目的类。它会依附到部署阶段上,并将应用的所有依赖分别上传到Amazon Simple Storage Service(S3)之中。通过使用这个插件,HubSpot 的报告显示,构建时间快了60%,并且可用的存储容量增加了99%。

下图展现了使用SlimFast 之后,所带来的构建速度提升:

为了更深入地了解HubSpot 所面临的Fat JAR 问题,InfoQ 采访了他们的软件工程师Jonathan Haber。

InfoQ:你们所遇到的 Fat JAR 问题大部分都是由持续集成和部署引起的吗?

Jonathan Haber:是的,我认为我们所遇到的问题很大程度上都是由我们的开发风格所导致的。我们有很多小团队,他们都在推送代码、构建和部署,这样的活动每天都有上百次。因为我们的构建单元很小,所以创建和上传 Fat JAR 所消耗的时间有时比编译和测试代码的时间还长。话说回来,如果你采用单体结构的话,构建所需的时间可能会超过 20 分钟,那么相对来讲 Fat JAR 的消耗就没有那么明显。但是,我认为有更多的公司在转向这种更快、更轻量级的部署风格,因此可能会面临同样的挑战。

InfoQ:你认为像 SlimFast 这样的替代性打包技术是否应该作为框架的原生方案,比如添加到 Spring Boot 和 Dropwizard 中?

Haber:因为这种方式需要与构建和部署系统集成,我的感觉是如果将其包含在 Spring Boot 或 Dropwizard 中的话,那就太带有倾向性了。但是,有一种处理方式就是将 SlimFast 插件放到一个 Maven profile 之中,通过环境变量来激活。通过这种方式,构建系统能够表明它支持这个特性,否则的话,依然将会采用 Fat JAR 的方式。

InfoQ:如果云提供商(如 Heroku、CloudFoundry 等)采用类似的技术来减少应用之间重复的 JAR,那么他们在带宽方面是不是可以节省很多钱?

Haber:我并不确定能够节省到什么程度,但是我认为采用类似的策略是可行的。不过,我们的优势在于所有的应用都使用了相同版本的第三方库,所使用的库有大量的重叠。对于云提供商来说,他们的用户所依赖的库会广泛得多,会跨所有的不同版本,所以如果你想在应用服务器上缓存依赖的话,会需要大量的空间。但是,如果你不这样的话,速度 / 带宽方面的大量节省就会不复存在。这并不是说,完全没有节省,我只是认为他们的实现会比我们的方式更加复杂。另外一个问题在于,这些云提供商通常只会基于用户的 POM 来运行 Maven,所以他们对于构建生命周期并没有太多的控制权,无法添加这种类型的优化。

InfoQ:在 Fat JAR 应用方面,你希望看到有哪些改善呢?

Haber:如果 Java 能够处理嵌套 JAR 的话,那么构建和运行 Fat JAR 都会容易很多,我并不确定这一点是否会包含在 Java 9 的功能列表中。像 Spring Boot 和 One-JAR 这样的工具都能很好地解决这种局限性,但是他们增加了复杂性并且无法做到完全的透明。

查看英文原文: Solving Fat JAR Woes at HubSpot

2016-08-28 19:002139

评论

发布
暂无评论
发现更多内容

再添新誉!浪潮云斩获年度领先品牌等多项殊荣

云计算

标准物模型:设备无缝对接,IOT界的福音

华为云开发者联盟

物联网 IoT 物模型 标准物模型 IoT Stage

618技术特辑(三)直播带货王,“OMG买它”的背后,为什么是一连串技术挑战?

华为云开发者联盟

CDN 直播 618 低时延 视频直播

HarmonyOS学习路之开发篇——Service Ability

爱吃土豆丝的打工人

Server HarmonyOS 路由 Ability Server

一文读懂云原生 go-zero 微服务框架

晨雨听风

GitHub Web Go 语言

Flink State 和 Fault Tolerance(二)

Alex🐒

flink 翻译 flink1.13

Flink+Hologres助力伊的家电商平台建设新一代实时数仓

Apache Flink

flink

BoCloud博云获评2021云计算PaaS创新领导者

BoCloud博云

容器

恭喜埃文科技入选“2021年中国网安产业潜力之星”!

郑州埃文科技

云图说|数据仓库服务 GaussDB(DWS) 的“千里眼、顺风耳”—数据库智能运维

华为云开发者联盟

数据库 数据仓库 GaussDB(DWS) 云图说 数据仓库服务

bzz节点挖矿分发系统开发案例

薇電13242772558

区块链

好的目标管理:SMART原则

石云升

创业 职场经验 管理经验 6月日更

618技术特辑(四)疯狂剁手的同时,电商隐私安全你注意到了吗?

华为云开发者联盟

电商 数据安全 云安全 618 隐私安全

架构之:数据流架构

程序那些事

架构 系统架构 软件架构 程序那些事

OpenKruise :SidecarSet 助力 Mesh 容器热升级

阿里巴巴云原生

容器 云原生

JAVA语言基础(五)--数组

加百利

Java 后端 6月日更

中年程序员转行第1年的感悟|2021 年中总结

王磊

Java 编程 编程之路 编程故事

【Flutter 专题】101 何为 Flutter Elements ?

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 6月日更

WorkPlus即时通讯-通讯录功能大全

BeeWorks

即时通讯 IM 移动开发 开源安全

GraphQL 初探

wangwei1237

RESTful API graphql

测试开发之网络篇-常用服务协议

禅道项目管理

IP HTTP 协议

Cilium 首次集成国内云服务,阿里云 ENI 被纳入新版本特性

阿里巴巴云原生

容器 云原生

项目管理100问 | 一个完整的缺陷管理流程是什么样的?

万事ONES

项目管理 研发管理 bug ONES

【架构师训练营】电商业务微服务拆分设计

eoeoeo

react源码解析15.scheduler&Lane

全栈潇晨

React

如何有效地管理项目变更?

万事ONES

项目管理 研发管理 ONES

EasyRecovery Pro绿色破解版,免序列号激活

淋雨

数据恢复 EasyRecovery 文件恢复 Easyrecovery破解 恢复软件

2021中国边缘计算企业20强榜单出炉,EMQ强势入围!

EMQ映云科技

开源 边缘计算 计算 emq

物联网发展,行业新领域

anyRTC开发者

音视频 WebRTC 智能硬件 智能安防 实时通讯

推理综艺的正确打开方式!爱奇艺玩转智能技术,“互动+内容”引爆迷综季

爱奇艺技术产品团队

Python——嵌套

在即

6月日更

在HubSpot是如何应对Fat JAR困境的_Java_Matt Raible_InfoQ精选文章