QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

在 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:001989

评论

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

小白学深度学习:知识蒸馏研究综述

阿里云天池

淘宝店铺所有商品数据接口怎么获取

tbapi

淘宝API接口 淘宝店铺所有商品数据接口

私有云服务器虚拟化超分比及资源扩容管理

天翼云开发者社区

云计算 服务器 虚拟化

与客户建立联系,成为企业战略决策的引领者

智达方通

全面预算管理 财务管理 客户关系

HBlock应用实践与性能测试:解锁老旧服务器存储潜力,打造高效稳定的存储集群

Geek_2dc40b

HBlock 老旧服务器盘活

通义灵码使用安装教程,3分钟快速上手体验

阿里巴巴云原生

阿里云 云原生 通义灵码

TikTok直播限流与网络有关系吗?怎么解决?

Ogcloud

海外直播专线 海外直播 tiktok直播专线 海外直播网络 tiktok直播网络

ps2224最新版,Photoshop 2024(Win&Mac) 软件下载

你的猪会飞吗

PS2024破解 mac破解软件下载 ps2024中文

河南大学OpenHarmony技术俱乐部正式揭牌成立

科技热闻

海外直播带货,怎样确保网络稳定流畅

Ogcloud

海外直播专线 海外直播 直播专线 海外直播网络 tk直播专线

云原生主键模型:高效、弹性,省钱又省心

StarRocks

数据库 大数据 存算分离 存算分离架构 湖仓一体

万界星空科技MES系统如何帮助企业降低成本

万界星空科技

工业互联网 制造业 生产管理系统 mes 智能制造业

《有恃无恐》

充实的orzi

#小说 #艺术来源于现实

人工智能 | MetaLlama大模型

测试人

人工智能 软件测试

无需推翻既有的建设,这个可观测性产品思路清奇

巴辉特

监控 可观测性 Prometheus 故障定位

GPU虚拟化技术简介:实现高性能图形处理的灵活部署

天翼云开发者社区

云计算 gpu 虚拟化技术

新手使用住宅代理有哪些常见误区?

IPIDEA全球HTTP

NFTScan | 08.26~09.02 NFT 市场热点汇总

NFT Research

NFT\ NFTScan

【论文速读】| 基于大语言模型智能体对文本到图像模型进行越狱

云起无垠

算网资源调度关键技术

天翼云开发者社区

云计算 云服务

CRISP-DM的应用与理解

天翼云开发者社区

数据挖掘 CRISP-DM

金九银十来了,你的简历写好了么?

不在线第一只蜗牛

程序员 前端

智能体进化发展了一年,现在的RPA Agent迭代到什么程度了?

王吉伟频道

RPA 智能体 大语言模型 AI Agent RPA Agent

解析淘宝商品详情API返回值中的关键属性

代码忍者

观测云核心技术揭秘:基于时间的半结构化数据模型

观测云

数据结构

NocoBase 与百事通:为法律行业带来全新变革

NocoBase

低代码 无代码 客户案例

俄罗斯即将启动跨境加密支付试行计划:规避制裁与加密货币的未来

区块链软件开发推广运营

交易所开发 dapp开发 区块链开发 链游开发 NFT开发

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