因为大部分线上故障都是由变更引起的，所以SRE会非常强调部署流程的小心谨慎。 一旦发现有问题，就会被要求立即回滚。这也就导致了搭车上线是非常讨厌的事情，谁知道你搭车进来的改动会不会翻车。 所以拆分成多进程，各上各的就会变成非常强烈的需求。

多进程当然是有其合理性的，替换进程是最简单最可靠的变更形式。 开源的 kubernetes 等项目也提供了完善的基础设施来支持多进程的部署模式。 特别是没有单元测试情况下的PHP应用，是不是有语法错误都无法在部署之前保证，强烈依赖于上线过程的观察。

但是用拆分进程的方式来解决上线慢的问题也会有一些缺点：

• 反馈不集中：小流量的时候，引起的小规模的故障可能观察不出来
• 灰度数有限：集群规模比较小的时候，总共就几个进程，灰度的刻度就会很大
• 回滚慢：进程替换需要时间
• 灰度时间有限：上线观察一天已经很夸张了，要更长时间的观察是不好用上线的方式来实现的
• 上线顺序：进程之间经常有数据依赖，并不能总是保持向后兼容。当要同时升级多个进程的时候，上线顺序的确定是比较头疼的事情