代码同步部署解决方案介绍

在上一篇中我们介绍了一下pull、push模型，除了在网页获取数据时用得上以外，其实还有很多应用场景（甚至可以说处处都见得到），在这次第一个正式工作，是写一个同步发布脚本，因此也了解了一些常见的同步方案，其中包括了运用这两种不同模型的几种选择。

Git + Rsync

这是目前在使用的解决方案，Rsync的介绍与配置留在下一篇博客，Git只是负责从远程获取到最新的代码到源机器（把上一篇文章的服务器看做源机器，客户端看做目标机器即可），Rsync负责差异同步到目标机器。这套方案比较简单，缺点是太简单，没有后续方案的话失败需要手动回滚到上一版，后续搭配SSH自动或人工食用。（除了我们以外Teambiton似乎也有开源的解决方案sneaky）。

SSH + wget/Docker

上一个解决方案很明显就是主动推送，关于主动推送的缺点，上一篇文章已经有了说明，既然后续操作还要有SSH，我们就想，为什么不直接用SSH呢，在远程进行代码获取。（这个方案杨叔叔告诉我的OTZ）

使用的模型是上一篇文章略微提及的观察者模式中的被动获取：源机器SSH到目标机器（源机器通知目标机器），在目标机器中执行相应操作，据说实际上发布时很少同步零散的代码，通常是整包上传，所以首先先停止其中几台机器的Nginx，从均衡负载中剔除他们，拉下来到临时文件夹，解压缩之后（想用Git也是可以的），备份一下原来的用于回滚，复制过去。尝试重新启动机器，成功，再操作剩下几台，如果没有成功，也没有危害（反正此时已经被剔除了，目前是掉线中），之后根据操作成功与否来进行判断。

Docker是更加现代化的解决方案，这里就不多做介绍了。

更安全的方法——使用中间件

看到这里，我们已经想到了这种方法的缺点了，比较简陋的话如果同步失败，是不是可以加入一个自动重试的机制？虽然在上面我们从均衡负载服务器中剔除了他们，似乎已经没什么太大问题了，但是毕竟似乎还没有让懒癌晚期完全省心省力的样子——当然这个方案成本略高也不一定值得推崇。

事实上，也真的有人这么做——用中间件。

我们都知道中间件就是现成的消息模型，即使目前服务器正忙，也可以在服务器闲时推送给客户端，直到客户端ACK之后。

这种现成的东西肯定比起自己造轮子可靠度高了不少，似乎确实能实现自动部署，缺点是好的中间件如RabbitMQ略肿，甚至最轻巧的中间件，都需要在两端进行一定的配置（比如你需要一个接收程序），如果你没有办法维持接收程序的稳定性，那么可能比本来的同步方案更加糟糕——毕竟是个发布订阅模型，如果订阅者直接从模型中被剔除了，就没有同步可言。

总结

从上一篇中对pull和push的探索我们可以发现，第二种似乎是一个更现代化和轻巧的解决方案——让人觉得更漂亮一些，当然，根据具体的需求自行定制才是最佳的解决方案。

Git + ZeroMQ 实现代码多端实时更新