我们应该将我们的第三方库与我们的组件打包在一起吗?

发布于 2024-08-18 13:16:10 字数 246 浏览 5 评论 0原文

我们正在做一些架构重构。我们是一家 SaaS 公司,因此所有部署都是到我们自己管理的服务器上。当前模型将我们所有的二进制文件以及我们使用的第三方库打包到ears、wars、tars等中。这些包包括它们依赖的所有库。

当它们被部署时,它们被手动爆炸(解压缩)或被它们构建的任何目标容器拾取。

由于这些库没有太大变化,我们想知道作为环境设置的一部分预先部署这些库是否是一个更好的主意,并根据需要更新它们。我们不偏向任何一种方式,我只是在寻找一些反馈。

We are doing some architecture refactoring. We are a SaaS company so all deploys are to our own self managed servers. Current model packs all of our binaries along with 3rd party libraries we use into ears, wars, tars, etc. These packages include all of the libraries they depend on.

When they are deployed they are manually exploded (untar'd) or picked up by whatever target container they were built for.

Since the libraries don't change much we are wondering if it's a better idea to deploy the libraries before hand, as part of environment setup, and update them as needed. We aren't leaning one way or the other, and I am just looking for some feedback.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

盛装女皇 2024-08-25 13:16:10

一般来说,用耳朵、战争等打包库会更好。一些原因是:

  • 配置新服务器时可以节省时间。如果您不将依赖项与可部署项打包在一起,则可能需要很长时间才能在新的目标服务器计算机上获取所有正确的库。
  • 您可以将不同的 .war 文件部署到依赖于同一库的不同版本的应用程序服务器。
  • 如果您将依赖项与可部署项打包在一起(只需重新部署),那么升级库就很简单。如果您的库是独立的,您需要执行额外的步骤来部署新库(以及另一个可能出错的地方)。
  • 如果包含依赖项,您可以确保部署在测试环境中的 .war 在生产环境中的行为相同。测试/生产环境与集中式库和版本的细微差异通常会导致问题。
  • 您的依赖项列表非常明确。例如,您可以进行开源许可证审核。如果你不将依赖项打包到你的包中,你永远不知道......

It is generally better to pack libraries with the ears,wars, etc. Some reasons are:

  • It saves time when you configure a new server machine. If you don't package your dependencies with your deployable it can take a long time to get all the correct libraries on a new target server machine.
  • You can deploy different .war files to an application server that depend on different versions of the same library
  • Upgrading a library is straight forward if you package your dependencies with your deployable (simply redeploy). If your libraries are separate you have additional steps to deploy a new library (and another place where things can go wrong).
  • You can be sure that a .war that is deployed on a test environment will behave the same in a prod environment if you include dependencies. Subtle differences in test/prod environments with centralised libraries and versions often cause problems.
  • Your dependency list is really explicit. You can for example do an open source license audit. If you don't package dependencies with your package, you never know...
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文