微服务部署演进

最新推荐文章于 2022-06-01 19:27:25 发布

danpu0978

最新推荐文章于 2022-06-01 19:27:25 发布

阅读量149

点赞数

文章标签：大数据 python 人工智能 java 数据库

微服务在这里留下来

几年前，大多数软件系统都具有整体架构和缓慢的发布周期。近年来，向微服务架构迈出了明显的一步，该架构针对可伸缩性，弹性，故障和变更速度进行了优化。通过采用云和容器，这种趋势得到了进一步加强，这也使诸如DevOps之类的实践成为可能。

IT行业的趋势

所有这些更改导致开发的服务数量不断增加，部署的数量也越来越多。很快变得很清楚，无法使用微服务前工具和技术来控制部署数量的爆炸式增长，并且催生了新的方式。在本文中，我们将看到诸如Kubernetes之类的Cloud Native平台如何在最少的人工干预下就可以大规模部署微服务。

在这里，我以Kubernetes为例，但是其他基于容器的Cloud Native平台（Amazon ECS ，Apache Mesos ，Docker Swarm ）确实提供了相似的原语和功能。在不久的将来，此处描述的实践将成为大规模管理和部署微服务的常用方法。

云原生部署特征

自助服务环境

本地，开发，测试，内部，性能，阶段，产品…。是所有环境，但实际上是什么环境？通常，它是一个VM或代表环境的一组VM。例如：

本地是开发人员笔记本电脑，用户可以完全自由地进行实验和破坏东西。它仍然必须与其他环境类似，以避免“在我的机器上工作”综合症。

开发是第一个将所有开发人员的更改都集成到一个工作应用程序中的环境。它运行SNAPSHOT版本的服务，模拟了外部依赖关系，并且在大多数情况下，它不受不断变化的影响。

发布服务后，会将其移至更稳定的环境（例如Test） 。该环境可能稍微强大一些（也许有多个VM），可能有更多可用的外部服务而不是模拟，并且测试人员也可以访问它。

当环境越来越接近Int / Stage / Perf等生产环境时，它们会变得更大，具有更多的VM和更多的外部依赖项。在某个时候，我们可能需要一个环境，该环境应具有与生产环境可量化的资源，因此我们可以进行性能测试，这意味着与生产环境有关。

此模型的主要困难在于，环境的概念已映射到物理或虚拟VM，因此更改起来很慢。您无法轻松地更改现有环境的资源配置文件，创建新环境或为每个开发人员动态分配环境。

Kubernetes管理的环境

动态放置的应用程序

在Cloud Native世界中，环境只是一个隔离，受控和命名的资源集合。例如，给定一个由8个VM组成的池，您可以根据各个团队的需求将资源池分块并将其用于不同的环境实例。而且这些块不会映射到VM，这意味着可能是多个环境并置并且共享很少的VM。使用一条命令即可立即创建，编辑，销毁环境，而无需虚拟机请求，并且可以等待数天甚至数周。这使团队可以根据自己不断变化的需求以自助服务的方式更轻松，更快速地更改环境配置文件。

我们可以看到用于管理环境的自助服务平台如何简化新开发人员，服务，项目的入职流程，甚至启用可能需要临时环境的自定义发布策略。准备好环境后，下一个任务是选择一种将微服务放置在环境中的策略。

我最喜欢的与微服务相关的书之一是Sam Newman的 Building Microservices 。 在本书中，Sam从所有可能的角度研究了微服务，其中之一就是部署。在“部署”一章中，作者描述了一些将服务映射到主机及其利弊的策略。

服务到主机的映射策略

声明式服务部署

我还在Camel Design Patterns一书中针对基于Apache Camel的应用程序详细介绍了这种方法。基本上，归结为选择一种打包服务的方法，并考虑所有类型的服务和主机依赖性，将它们分组到可用主机上。对我们来说幸运的是，该行业发展Swift，容器已被接受为包装微服务的标准。除非您是Netflix并且拥有超过10万个Amazon EC2实例，否则您不应该寻找为每种服务刻录EC2图像的快速方法，而应该使用容器。

甚至Netflix都在前进，他们正在尝试容器，甚至开发开源容器调度软件。因此，每个服务不再需要VM，也不再需要服务来托管映射策略。相反，根据您的服务要求/依赖性和可用的主机资源，您的Cloud Native平台应以策略定义的可预测方式为每个服务找到一个主机。这需要了解每个服务并描述其需求，例如存储，CPU，内存等，但后来带来的好处是巨大的。

Kubernetes 调度程序不会预先手动编排每个服务并将其分配给主机，而是对服务进行编排，并在请求时动态地将其放置在主机上。

如您所见，VM / Host的概念随着环境跨越多个主机而消失，并且服务被动态放置在主机上。我们不在乎，我们也不想知道实际主机所在的环境以及微服务的放置位置（除非在可预测的性能至关重要且应避免共享主机资源和平台资源的情况下）。

我们可以自助服务方式配置环境，并以最小的努力将服务放置在环境中。但是，当我们有一个服务的多个实例时，如何部署新实例？我们是否必须首先停止实例，然后升级，并且在出现问题时进行回滚？ Cloud Native平台（特别是Kubernetes）也考虑过这一点。使用部署的概念，Kubernestes可以描述如何执行服务升级。