微服务架构设计模式 分布式应用程序是什么

分布式云应用程序(又名微服务)已将大量复杂性引入到云软件的设计和运营中 。曾经的单体应用将复杂性隐藏在单个进程或运行时中,现在却分散在数十或数百个松耦合的服务中 。尽管所有这些服务都可以使用不同的编程语言,并且可以彼此独立地进行扩展,但是分布式特性通常会使应用程序整体难以驾驭、难以部署并且很难保证安全 。
【微服务架构设计模式 分布式应用程序是什么】这种新的复杂性使得管理和开发云原生应用程序变得越来越困难,并且引发了有关如何维护健康云软件的问题 。我们如何才能利用面向服务设计的好处,而又不会在其他地方引入冲突和成本呢?
幸运的是,我们之前已经遇到过这个问题 。微服务并不是第一种迫使开发人员弄清楚如何协作,并为无数互连组件操劳的模式 。在过去的几十年中,这类问题的解决方案一直是相同的:依赖管理 。
我们每天都使用依赖管理来重复使用公有和私有软件包,并在他人工作的基础上,将我们自己的应用优雅的封装为可用格式提供给其他人 。依赖管理是释放分布式软件能力的关键,背后的原因有很多;现在是时候向过去学习,为云原生开发的未来提供动力了 。
1. 开发者协作依赖管理工具(如 NPM,Pip,Maven 等)最重要的功能之一是促进开发者之间的协作 。通过提供一致的打包机制以无缝扩展代码,依赖管理工具使原本不相关的团队可以互相使用彼此的成果 。我们可以在企业内部使用这些工具,以使团队能够在工作中协作并发布自己的成果;我们还看到,依赖管理工具得到了更广泛的应用,以在开源社区中促成协作 。依赖管理工具的一致性以及较高的采用率使得社区能够创建功能非常强大且可自由访问的软件库,以供所有人使用并在此基础上继续发展 。
虽然这种协作水平已经在社区中针对单个编程语言实现了(针对 Javascript 的 NPM,针对 Python 的 Pip 等),但尚未在云原生社区中完全实现 。幸运的是,我们使用 Docker 打包云服务可以保证一致性,但是容器没有足够的有关服务之间关系的信息来解析和扩展依赖关系 。如果我们想为微服务实现类似于其他单独编程语言中的依赖管理功能,则非常重要的环节是添加适当的依赖管理工具,以索引并解析与其他应用和服务的关系 。
2. 自服务环境依赖管理工具产生的协作作用并不是凭空产生的 。一致的依赖解析器如此强大的主要原因是,世界各地的开发人员都可以使用相同的命令和流程来重现其效果 。可重复性是依赖管理工具的关键要素 。没有它,开发人员需要使用复杂的传统方式来自行下载和使用其他人创建的库,从而极大阻碍软件库的采用和分发 。
在这方面,面向服务的应用程序与基于特定语言的应用并没有什么不同 。我们扩展他人工作的能力取决于我们运行或访问我们希望调用的服务或应用 。团队能够通过集中式的质量保证或沙箱环境来做出贡献,但无法复现这些环境会带来一系列新问题 。工程师无法运营自己的开发环境,依赖其他应用的服务无法轻松交付,开发人员被迫编写自己的脚本以在本地和远程运行他们的应用,每个团队都需要关心生产级工具、网络的信息,以及网络安全性 。通过一致的依赖管理工具,团队只需声明其服务的依赖,即可为组织中的每个人提供一致的方式来部署其服务栈及其依赖,从而使每个人都可以运营自己的环境 。
3. 自动化一致的依赖管理工具所具有的自服务优势不仅仅意味着开发人员可以运营自己的环境 。这也意味着可以通过自动化的方式来产生和拆除环境 。单个命令或过程(用于解决依赖关系、丰富网络和自动化安全性)的一致性是集成到 CI/CD 流水线的完美秘诀!
如果每个服务都可以一致地运行(例如在容器平台上运行)并且知道其自身的依赖,则可以为每个合并请求提供新的环境,并且在合并到相关分支后可以将更改无缝地升级到预发布和生产环境中 。这意味着每个团队都可以为每个开发人员和添加到应用程序的每个新服务实现可扩展的 GitOps。
4. 安全性微服务架构引入的风险之一是每个服务都需要公开对其功能进行访问的 API 。由于这些服务作为单独的进程存在,因此通过网络进行通信是它们彼此连接并接收处理请求的唯一方式 。这意味着每个新服务都会公开一个可供其他人访问的接口,如果开发人员不注意,他们可能会不小心将其公开给错误的参与者 。

推荐阅读