pushguide发布系统，是汽车之家正在使用的代码发布系统。「代码上线」是运维日常工作中最重要的一部分。在没有发布系统之前， 所有的业务都需要运维来手动上线。 上线工作对运维人员来说是不小的工作量。 为了解放生产力，提高上线效率，我们开发了该系统。

1. 背景
（1）野蛮生长阶段
业务线自己各自为战，没有统一的代码规范， 发布流程。 上线之前提交上线单通知运维人员手动上线。这种模式的缺点不言而喻，运维人员需要随时待命， 从上线部署到最后验证， 有问题的话回滚都需要运维人员全程手动完成，费事费力。
（2）统一规范，使用发布系统发布
业务线接入ci和发布系统之后， 业务方通过ci打包自己的代码， 通过发布系统自助完成发布。如发布代码有问题，可以在系统上直接选择要回滚的版本。 运维人员只需要配置好要发布的模块即可。大大解放了运维的工作量。同时，各个业务线需要按照统一规范组织自己代码结构才能够使用发布系统。

2. 设计原则
什么样的系统更适合于汽车之家的业务？ 首要要满足不同业务线的不同项目类型的发布，这些类型包括.net项目、java web项目、windows计划任务等。 其次，公司有大量的windows服务器， 发布系统需要同时支持windows和linux。最终我们选择基于saltstack自动化运维配置工具设计开发发布系统， 使用该工具的好处如下：
（1）python开发，和运维开发的技术栈一致。对于以后的扩展，二次开发都很方便
（2）快速, 原生提供了http api支持
（3）支持windows

3. 发布系统架构
3.1 发布系统的整体架构
发布系统前端通过salt api与salt master进行通信， 发布任务描述信息到salt master。salt master通过salt命令调用我们自己开发的模块来完成一次发布任务。

3.2 发布系统与其他系统如何合作完成代码发布
我们需要通过ci系统来打包代码，通过配管系统来部署代码运行环境，如tomcat等等。通过ci以及配管系统提供的接口，我们在发布系统中获取到发布的版本和配置的tomcat信息

3.3 发布系统对上线流程的抽象
我们把一次上线流程抽象成以下四个阶段
（1）准备阶段
（2）发布前阶段
（3）发布阶段
（4）发布后阶段
为了支持不同发布类型和可扩展性， 我们通过继承抽象出不同的类来完成一次上线流程，如下所示：

4. 遇到的问题
作为重要的代码发布系统， 稳定性上一定要有可靠的保证， 这样才能让业务方人员放心大胆的使用系统发布代码。但是在发布系统的使用过程中我们也遇到了一些问题。
4.1 确保salt的稳定性
由于pushguide是基于saltstack来完成代码的发布，所以对saltstack的运维又显得很重要。在前期的使用的我们经常遇到由于salt的问题导致发布系统出现不可用的情况。所以我们优化了整个salt的架构。通过使用多机房multi master来保证salt的稳定性。关于salt的高可用方案，网络上也有一些其他做法如加入代理层，重写returner模块等方法。但从效果看，目前的multi master可以满足我们现在的发布需求。
4.2 代码的规范
系统使用前期，由于业务方的代码不够规范，比如我们在现实场景中会遇到有的业务方把业务代码和日志文件放在一起，代码目录非常大，导致发布的失败。所以对于发布系统的来说，我们不能仅仅是发布代码， 同时可以制定代码，目录规范来约束业务方规范自己的代码。
4.3 监控
对于发布系统web服务的监控自然是必不可少的， 同时我们还定时对接入发布系统的主机salt minion连通性进行检测， 发现有salt minion不可用情况及时处理， 避免在发布时失败的情况

上一篇：新站怎么在两个月时网站权重达到1 日均流量突破1000ip

下一篇：从SEO优化角度选虚拟主机还是云服务器？