分布式应用程序需要依赖管理

我们每天都使用依赖管理器来建立他人的工作。 现在是时候我们拥有用于微服务的相同工具了。

前言

这篇文章最初于2020年9月16日在Architect.io博客上发布为《为什么分布式应用程序需要依赖管理》。

分布式云应用程序(也称为微服务)已将大量复杂性引入了云软件的设计和操作中。曾经表现为隐藏在单个进程或运行时中的复杂性的东西现在发现自己分散在数十或数百个松散耦合的服务中。尽管所有这些服务都可以使用不同的语言并且可以彼此独立地进行扩展,但是分布式性质通常会使应用程序整体难以导航,难以部署并且很难保证安全。

这种新的复杂性使管理和开发原生云应用程序变得越来越困难,并引发了有关如何维护健康云软件的问题。我们如何在不引入摩擦和成本的情况下利用面向服务设计的好处?

幸运的是,我们之前已经遇到过这个问题。微服务并不是迫使开发人员弄清楚如何进行协作并为无穷无尽的互连组件网络做出贡献的第一种模式。在过去的几十年中,解决方案一直是相同的:依赖关系管理。

我们每天都使用依赖项管理器来重复使用公共和私有软件包,在其他工作的基础上,并将我们自己工作的细节优雅地封装为可使用的格式。依赖管理是释放分布式软件功能的关键,这有很多原因,现在是时候吸取教训,为云原生开发的未来提供动力了。

1.开发人员协作

依赖管理器(如NPM,Pip,Maven等)的最重要功能之一是促进开发人员之间的协作。通过提供一致的打包机制来无缝地扩展代码,依赖关系管理器使原本不相关的团队可以互相消耗彼此的工作。尽管可以在企业内部使用这些工具以使团队能够在其工作中进行发布和协作,但我们已经看到,依赖项管理器的使用规模更大,可以在开源社区中促成协作。工具的一致性和采用范围的广泛性使得能够创建功能强大且可自由访问的库,以供所有人使用并在此基础上继续发展。

虽然已经在社区中针对单个语言(JavaScript的NPM,Python的Pip等)实现了这种级别的协作,但是在云原生社区中尚未完全实现这种协作。幸运的是,我们让Docker在云服务的打包方式方面建立了一致性,但是容器没有足够的有关服务之间关系的信息来解决和扩展依赖关系。如果我们想为微服务实现其他人已经使用单独语言编写的库所具有的功能,则添加适当的依赖项管理以建立索引并解决与对等应用程序和服务的关系至关重要。

2.自助服务环境

依赖项管理器的协作效果不会神奇地发生。一致性依赖解析器如此强大的主要原因是,全世界的开发人员都可以使用相同的命令和流程来重现其效果。可重复性是依赖管理器的关键要素。没有它,没有复杂的,自定义的引导逻辑,任何人都无法下载和操作其他人创建的库和软件包-创建逻辑和逻辑将是采用和分发的巨大障碍。

在这方面,面向服务的应用程序与特定于语言的库没有什么不同。我们扩展他人工作的能力取决于我们运行或访问我们希望对其打电话的服务和应用程序的能力。团队已经能够通过操作集中的QA或沙盒环境来做到这一点,但是无法重现这些环境会带来一系列新的问题:工程师无法操作自己的开发环境;依赖他人的服务无法轻易交付;开发人员被迫编写自己的脚本以在本地和远程运行其应用程序;每个团队都需要了解生产级工具,网络和网络安全性。通过利用一致的依赖性管理解决方案,团队只需声明其服务的网络依赖性,即可为组织中的每个人提供一致的方式来提升其堆栈中的服务及其依赖性,从而使每个人都可以操作自己的环境。

3.自动化

一致的依赖性管理的自助服务优势不仅意味着开发人员可以运行自己的环境。 这也意味着可以通过自动化来配置和拆除环境。 单个命令或过程的一致性(用于解决依赖关系,丰富网络和自动化安全性)是集成到CI/CD管道的完美秘诀!

如果每个服务都可以一致地运行(例如在容器平台上)并且知道其自身的依赖性,则可以为每个合并请求提供新的环境,并且在合并到相关分支后可以将更改无缝地升级到暂存和生产中。 这意味着每个团队都可以为每个开发人员和添加到应用程序的每个新服务实现可扩展的GitOps。

4.安全

微服务架构引入的风险之一是每个服务都需要公开代理对其功能进行访问的API。由于这些服务作为单独的进程存在,因此通过网络进行通信是它们彼此连接并接收处理请求的唯一方式之一。这意味着每个新服务都公开了一个可供其他人访问的接口,如果开发人员不小心,他们可能会不小心将其公开给错误的参与者。

防止网络接口的意外暴露是依赖管理可以提供支持的另一个领域。通过开发人员提供其服务的网络依存关系的结构化索引,我们不仅可以自动解决这些依存关系,而且还可以通过将其锁定所需的相应网络策略来丰富环境-只有相互依赖的服务才能访问彼此其他。这种结构化的方法极大地减少了开发人员了解网络安全工具的需求,并使他们可以更自由地创建新服务。

5.灵活性

关于微服务和分布式应用程序的依赖管理的另一个好处是灵活性。 随着开发人员捕获其直接依赖项的详细信息并将其与自己的服务相关联,解析程序本身可以自由地在部署的每个环境中以独特的方式检测这些关系。 是否想尝试其他API网关或服务网格? 是否想通过捕获每个服务的入口和出口流量来检测分布式跟踪? 借助可以依赖于依赖解析器的自动化功能,操作员可以自由地尝试新的工具和配置,而无需对现有服务进行任何代码更改或对开发人员造成干扰。

为什么它已经不存在了?

依赖关系解析将是一个功能强大的工具解决方案,它使开发人员能够进行协作并为云原生应用程序做出贡献,但是我们不能使用已经存在的大量程序包管理器来帮助进行检测吗?尽管使用现有工具会很好,但是解决网络应用程序的依赖关系与解决库与二进制文件之间的关系并不相同。

满足库依赖性要求的代码工件的下载全部在构建时进行,以创建一个主二进制文件/库。但是,微服务不会捆绑到单个二进制文件中,而是需要作为独立服务运行,然后通过网络连接到微服务。这意味着解决策略还有其他步骤,并且发生在与常规库完全不同的生命周期阶段。事实证明,在应用程序生命周期中,我们可以正确解决分布式应用程序依赖关系的最早时间是在部署时。至此,我们既了解堆栈中所有服务之间的关系,也了解正确配置和连接服务所需的目标环境的工具和详细信息。

总结

综上所述,很难为网络依赖关系创建大型解析器,但这样做将为工程团队和整个云社区带来巨大利益。如果我们要正确地驾驭云原生工具的不断发展的局面,则需要从过去的依赖管理实践中学习。

SO资源郑重声明:
1. 本站所有资源来源于用户上传和网络,因此不包含技术服务请大家谅解!如有侵权请邮件联系客服!3187589@qq.com
2. 本站不保证所提供下载的资源的准确性、安全性和完整性,资源仅供下载学习之用!如有链接无法下载、失效或广告,请联系客服处理,有奖励!
3. 您必须在下载后的24个小时之内,从您的电脑中彻底删除上述内容资源!如用于商业或者非法用途,与本站无关,一切后果请用户自负!

SO资源 » 分布式应用程序需要依赖管理