从服务器到微信云托管，到底经历了什么丨直播回顾

“服务上云”一直是一个进行时，在2010年-2017年期间，发力点重心都在「自有物理建设」到「IaaS基础设施即服务」，各个云厂商都在此基础上推出网络产品、数据库产品、存储产品，提供「PaaS」层面的产品来促进上云的过程，我们称为“服务上云1.0”。

“服务上云1.0”本质上就是将自建的物理服务设施迁移到云厂商提供的服务设施，并配备了一大批专业的工具。但在这一过程中，内在的关于开发者所选的服务技术架构，却很少干预触及；目前大部分流通的都是传统服务架构模式。

传统服务架构模式是什么？有什么特点？以下我列举几个大家对照感受一下

1. 使用本地文件系统来持久化存储，数据文件和应用的文件混合在一起。
2. 在同一个服务器上运行很多服务，比如 Mysql、Redis 、Nginx 以及一大堆定时任务。
3. 使用大杂烩式的脚本和手工流程进行安装和升级。
4. 配置是存储在文件里的，通常散落在多个位置，并与应用的文件混在一起。
5. 进程间的通信是借助本地文件系统进行的（比如在磁盘上放一个文件，另一个进程来读取），而不是TCP/IP。
6. 按照单个服务器上只运行一个应用的实例的方式来设计的。

这些特点会在执行维护的过程中暴露出很多问题，比如：

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