1.3.3 部署和发布的改变

软件开发过程中的本质问题是不会因为工具、技术、架构的变化而消失的。当我们迁移到微服务架构之后，应用的形态成了一张网，所以部署和发布也会变得复杂。每个服务都需要部署管道、监控系统、自动报警等，通过不同语言实现的服务也没有一个统一的打包方法。另一方面，部署的协调和版本管理也是一个问题。微服务应用中的依赖关系很可能呈现为一张图，每个服务都会有几个依赖服务，你需要保证没有出现循环调用，即保证依赖关系是一个有向无环图，否则你的部署流程会举步维艰。

服务的版本控制也尤为重要，你需要在失败时回滚，或者基于版本实现蓝绿部署、灰度发布这样的功能。因此，更为复杂的运维，或者说更为复杂的应用生命周期管理成了新的挑战。

在运维和管理微服务应用时，最初并没有一套统一的标准去处理异构环境，容器化让这一切变得简单起来。它的一个重要作用就是通过一层标准的封装和运行时环境来标准化微服务的打包和分发过程。从生命周期管理的角度来看，容器这种云原生技术整合了异构系统的运维管理，服务之间的差异会变少，共同点会变多。

一个具有大量服务的应用需要有一个中心化的平台对这些服务进行统一管理，比如Kubernetes。存储、计算、网络这些资源通过Kubernetes进行统一抽象和封装，可让已经被容器统一的微服务直接运行在平台上。我们依然需要构建监控、日志、告警等系统，但通过集中式的方式可以让它们被复用和统一管理。有了这样的平台，运维人员也不用再考虑如何合理地将某个服务分配到某个具体的计算单元上。

容器和编排设施大大简化了微服务本身的生命周期管理，解决了微服务自身的运维管理问题。相对地，我们的关注重点也会转移到了平台层面，即基于平台去学习和使用如何部署和发布微服务应用。