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

在上一篇中我们介绍了一下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 实现代码多端实时更新

植入部分

如果您觉得文章不错,可以通过赞助支持我。

如果您不希望打赏,也可以通过关闭广告屏蔽插件的形式帮助网站运作。

标签: 知识

添加新评论