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