微服务部署演进
微服务在这里留下来
几年前，大多数软件系统都具有整体架构和缓慢的发布周期。 近年来，向微服务架构迈出了明显的一步，该架构针对可伸缩性，弹性，故障和变更速度进行了优化。 通过采用云和容器，这种趋势得到了进一步加强，这也使诸如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可以描述如何执行服务升级。
滚动和固定部署
部署的滚动更新策略一次更新一个Pod，而不是同时关闭整个服务并确保零停机时间。 另一方面，此固定（或称为Recreate）策略将关闭所有服务实例，然后逐渐启动新版本。
在这两种情况下，Deployment都会在后台声明性地逐步更新已部署的应用程序。
额外的好处
具有能够管理服务的整个生命周期的平台还可以提供与部署相关的其他好处。
蓝绿色和金丝雀版本
蓝绿色版本是一种用于快速回滚的方法，以防新版本出现任何问题。
Canary版本是一种技术，可通过在仅向一小部分用户进行更改之前向所有人推出更改来降低在生产中引入新软件版本的风险。
蓝绿色和金丝雀版本
自我修复
使用Kubernetes可以以最少的人工干预轻松实现这两种技术。
Cloud Native平台不仅能够检测故障，而且可以采取措施并进行修复。 Kubernetes将定期对您的应用程序进行运行状况检查 ，如果它检测到错误，它将重新启动您的服务，甚至走得更远，并在需要时将其移至其他更健康的主机。
自动缩放
除了自我修复外，该平台还能够自动扩展服务甚至基础架构。 这是一项非常强大的功能，为平台提供了一些抗脆弱特性 。
DevOps和抗脆弱性
如果我们看一下Kubernetes提供的所有好处，我认为可以说它提供了更适合大规模管理微服务的原语和抽象。 有了这样的工具，团队和组织就可以更轻松地使用DevOps之类的实践，并专注于改进业务流程以实现抗脆弱性。
总结思想
没有免费的午餐
我们已经看到了Cloud Native平台在微服务部署方面的许多好处，但没有在本文中有意讨论其任何缺点。 如您所料，Kubernetes的学习曲线非常陡峭，在开发此类应用程序时也需要改变模式，原理，实践和流程。 基本上，这就是向Cloud Native应用程序的迁移。
改变是不可避免的
这听起来可能太强大了，但是如果您正在执行微服务，那就是大规模的微服务，则必须使用Cloud Native平台（例如Kubernetes）。
图片来自*。 WE Deming的智慧
如果您使用微服务之前的工具，技术和实践来开发微服务，它将使您反感，微服务可能对您不起作用。
翻译自: https://www.javacodegeeks.com/2017/01/microservices-deployments-evolution.html