# 从服务器到微信云托管

# 背景

提起服务器，现在大部分团队主流的方式是，在云服务厂商购买一些CVM服务器，然后在服务器中安装业务项目需要的服务软件、数据库软件等，并将项目在服务器中启动。然后经过网络层次的相关配置，就能够在客户端或浏览器中访问到业务服务了。

上述云服务器，本质上是通过虚拟化技术，将一个物理服务器分割成多个虚拟机，我们可以将虚拟机当成一个完整的计算机来使用。如此一来，我们可以和其他使用者一起共用一台物理服务器（相当于一群人租了一栋楼）。

既然虚拟机形态下的服务端构建仍然是当前大部分团队的主流，为什么微信云托管是基于容器服务而非虚拟机？

# 对比

虚拟机形态下的服务运维是非常消耗人力的，当服务进行变更或者进行规模扩缩的时候，复杂而专业的运维操作，非常考验运维人员的技术功底和经验学识，这在项目快速扩张的时候最为突出明显。

以致于诞生了很多服务器运维面板和建站工具，帮助开发团队来完成运维操作。这种方式虽然能够在一定程度上节省运维人力，但在业务发展到一定程度，更多的瓶颈弊端仍然会暴露并严重起来：

自动化部署很困难，虽然可以通过各种工具来实现，但仍有很大的水分空间存在。
如果需要运行应用的多个不同的实例，很难让多个实例在同一个服务器上同时存在。
如果服务器停机，由于需要手工流程所以需要较长的时间来恢复。
部署新版本的过程基本是手动的，或者大部分是手动的，难以回滚。
很有可能测试环境与生产环境有较大差异，导致一些生产环境问题不能在测试期间发现。
很难通过增加新的实例来进行横向扩展。

容器技术，规避了传统服务架构模式所带来的问题，作为一种新的架构模式开始在近几年兴起。它通过标准化方式，将业务代码和其所依赖的环境资源一起打包成为镜像，然后在服务器中启动一个实例运行这个镜像，就可以提供服务了。

比如你去网吧工作，使用网吧的纯净系统，需要安装自己所需要的办公软件才能够开始正式工作，这里就类比你在传统模式下需要根据服务设施的不同来进行针对性运维，才能够把自己的业务项目运行起来。
容器服务在上述例子中就是，你带了一块硬盘（或者一个U盘），将你的办公系统存储在其中，到网吧里直接插入你的硬盘，就可以立刻使用熟悉的系统了。并且你的硬盘可以复制多份，就可以非常快速的让多台计算机运行你的系统，且运行的效果完全一致。

相比虚拟器下的传统服务，容器服务的特点主要有如下：

部署容易，可以使用新的容器镜像直接替换整个老版本。
自动化部署也相对容易，可以完全由 CI/CD 来驱动。
部署失败时的回滚只要切换到之前的镜像就行，非常方便。
应用升级不需要去考虑复杂的升级配置流程，不必执行繁琐的步骤。
相同的容器镜像可以在不同的环境中充分测试，再直接部署到生产环境，确保测试环境与生产环境完全一致。
系统更容易从宕机中恢复，因为可以迅速在新硬件资源上启动装有这个应用镜像的新容器，并附加到同一数据源上。
开发人员能在本地以容器的形式，在更逼真的环境里测试新功能。
硬件资源的利用更高效，在单一主机上可以运行多个容器应用。
容器化是支持零停机升级、金丝雀部署、高可用和横向扩展的坚实基础。

# 提升

微信云托管以容器服务为基础，对保障服务的高可用，高稳定的运行有决定性的作用。

多个容器一起构成服务系统并对外提供业务服务，需要容器编排技术的支持，目前主流的容器编排技术是Kubernetes（简称K8S），熟练而合理的配置K8S，也需要一定的技术门槛。

这就像是熟练的驾驶飞机，需要一定的专业学习和经验积累才能够实现0失误

微信云托管将K8S的运维配置完全接手，你不需要关心K8S和容器服务如何配置和相互作用，只需要操作微信云托管提供的简单操作面板，就可以轻松的部署服务。

微信云托管就相当于将飞机复杂的控制面板去掉，取而代之的是易操作的面板，并提供大量自动化的服务，你不需要专业的学习就可以熟练的驾驶飞机。