为什么分布式应用程序需要依赖管理？ 作者 | David Thor 译者 | Rayden 策划 | 陈思 微服务并不是第一种迫使开发人员弄清楚如何协作，并为无数互连组件操劳的模式。在过去的几十年中，这类问题的解决方案一直是相同的：依赖管理。 分布式云应用程序（又名微服务）已将大量复杂性引入到云软件的设计和运营中。曾经的单体应用将复杂性隐藏在单个进程或运行时中，现在却分散在数十或数百个松耦合的服务中。尽管所有这些服务都可以使用不同的编程语言，并且可以彼此独立地进行扩展，但是分布式特性通常会使应用程序整体难以驾驭、难以部署并且很难保证安全。 这种新的复杂性使得管理和开发云原生应用程序变得越来越困难，并且引发了有关如何维护健康云软件的问题。我们如何才能利用面向服务设计的好处，而又不会在其他地方引入冲突和成本呢？ 幸运的是，我们之前已经遇到过这个问题。微服务并不是第一种迫使开发人员弄清楚如何协作，并为无数互连组件操劳的模式。在过去的几十年中，这类问题的解决方案一直是相同的：依赖管理。 我们每天都使用依赖管理来重复使用公有和私有软件包，并在他人工作的基础上，将我们自己的应用优雅的封装为可用格式提供给其他人。依赖管理是释放分布式软件能力的关键，背后的原因有很多；现在是时候向过去学习，为云原生开发的未来提供动力了。 1. 开发者协作 依赖管理工具（如 NPM，Pip，Maven 等）最重要的功能之一是促进开发者之间的协作。通过提供一致的打包机制以无缝扩展代码，依赖管理工具使原本不相关的团队可以互相使用彼此的成果。我们可以在企业内部使用这些工具，以使团队能够在工作中协作并发布自己的成果；我们还看到，依赖管理工具得到了更广泛的应用，以在开源社区中促成协作。依赖管理工具的一致性以及较高的采用率使得社区能够创建功能非常强大且可自由访问的软件库，以供所有人使用并在此基础上继续发展。 虽然这种协作水平已经在社区中针对单个编程语言实现了（针对 Javascript 的 NPM，针对 Python 的 Pip 等），但尚未在云原生社区中完全实现。幸运的是，我们使用 Docker 打包云服务可以保证一致性，但是容器没有足够的有关服务之间关系的信息来解析和扩展依赖关系。如果我们想为微服务实现类似于其他单独编程语言中的依赖管理功能，则非常重要的环节是添加适当的依赖管理工具，以索引并解析与其他应用和服务的关系。 2. 自服务环境 依赖管理工具产生的协作作用并不是凭空产生的。一致的依赖解析器如此强大的主要原因是，世界各地的开发人员都可以使用相同的命令和流程来重现其效果。可重复性是依赖管理工具的关键要素。没有它，开发人员需要使用复杂的传统方式来自行下载和使用其他人创建的库，从而极大阻碍软件库的采用和分发。 在这方面，面向服务的应用程序与基于特定语言的应用并没有什么不同。我们扩展他人工作的能力取决于我们运行或访问我们希望调用的服务或应用。团队能够通过集中式的质量保证或沙箱环境来做出贡献，但无法复现这些环境会带来一系列新问题。工程师无法运营自己的开发环境，依赖其他应用的服务无法轻松交付，开发人员被迫编写自己的脚本以在本地和远程运行他们的应用，每个团队都需要关心生产级工具、网络的信息，以及网络安全性。通过一致的依赖管理工具，团队只需声明其服务的依赖，即可为组织中的每个人提供一致的方式来部署其服务栈及其依赖，从而使每个人都可以运营自己的环境。 3. 自动化 一致的依赖管理工具所具有的自服务优势不仅仅意味着开发人员可以运营自己的环境。这也意味着可以通过自动化的方式来产生和拆除环境。单个命令或过程（用于解决依赖关系、丰富网络和自动化安全性）的一致性是集成到 CI/CD 流水线的完美秘诀！ 如果每个服务都可以一致地运行（例如在容器平台上运行）并且知道其自身的依赖，则可以为每个合并请求提供新的环境，并且在合并到相关分支后可以将更改无缝地升级到预发布和生产环境中。这意味着每个团队都可以为每个开发人员和添加到应用程序的每个新服务实现可扩展的 GitOps。 4. 安全性 微服务架构引入的风险之一是每个服务都需要公开对其功能进行访问的 API。由于这些服务作为单独的进程存在，因此通过网络进行通信是它们彼此连接并接收处理请求的唯一方式。这意味着每个新服务都会公开一个可供其他人访问的接口，如果开发人员不注意，他们可能会不小心将其公开给错误的参与者。 防止网络接口意外暴露是另一个依赖管理工具可以提供支持的领域。通过开发人员提供其服务的依赖关系的结构化索引，我们不仅可以自动解决这些依赖，而且还可以丰富相应的网络策略来锁定服务调用关系——只有相互依赖的服务才能访问彼此。这种结构化方法极大地减少了开发人员理解网络安全工具的需求，并使他们可以自由的创建更多服务。 5. 灵活性 灵活性是微服务和分布式应用依赖管理工具的另一个好处。开发人员可以捕获依赖项的详细信息并将它们关联到自己的服务，这样解析器本身可以自由地以特定方式在部署环境中检测这些依赖关系。想要尝试不同的 API 网关或服务网格？想要追踪每一个服务的入站和出站的流量来实现分布式追踪？借助依赖管理工具的自动化功能，运营人员可以自由尝试新工具和配置，而不必改动现有服务的代码或干扰开发人员。 为什么它还不存在 依赖关系解析将是一个强大的工具，使开发人员能够进行协作并为云原生应用程序做出贡献，但是我们不能使用已经存在的大量软件包管理器来进行依赖管理吗？虽然使用现有工具会很好，但是解决网络应用程序的依赖关系与解决库与二进制文件之间的关系并不是同样的工作。 对于普通库，满足依赖要求的依赖下载全部在构建时进行，以创建一个主二进制文件 / 库。但是，微服务不是捆绑到单个二进制文件中，而是需要作为独立服务运行，然后通过网络进行连接。这意味着依赖解析策略还有额外的步骤，并且该步骤发生在与常规库完全不同的生命周期阶段。事实证明，在应用程序生命周期中，我们可以正确解决分布式应用程序依赖关系的最早时间是在部署时。此时，我们既了解堆栈中所有服务之间的关系，也了解目标环境的工具和详细信息，而这一目标环境需要正确配置并用以提供服务连接。 综上所述，很难为网络依赖关系创建大规模的解析器，但是这样做将为工程团队和整个云社区带来巨大好处。如果我们要正确地驾驭云原生工具的不断发展的局面，则需要从过去的依赖管理实践中学习经验。 原文链接： https://www.architect.io/blog/why-distributed-apps-need-dependency-management 你也「在看」吗？?? 阅读原文