自动化部署打破混乱之墙 助力开发、运维、测试协同作战

自动化部署之于DEVOPS

DevOps概念自2009年提出，目的是为了解决传统模式下的运维之痛，在传统模式下开发和运维存在混乱之墙，开发要不断的迭代新版本上线新功能，但是运维关注的是稳定，DevOps旨在打破这道混乱之墙，让开发、运维、测试协同作战，提高研发效率，实现高效交付。

在传统模式中，运维人员都把时间花在哪里呢？如下图，运维团队一半(47%)的时间都花在了与部署有关的工作中，如果实现了自动化部署便可以解放运维人力，提高运维人员的工作效率。

苏宁的自动化部署演进

苏宁从2009年开始从传统的零售企业进行互联网转型，随着互联网转型苏宁的系统架构苏宁的系统架构发展经历了如下几个阶段：

第一代架构：POS+ERP支撑线下规模扩张

在信息建设初期，苏宁上线SAP/ERP，建立线下多门店之间的库存共享，同时打通上游供应商的ERP系统，实现企业协同。该时期苏宁部署方式为运维手动部署，部署效率低。这个时候苏宁的IT体系还在起步阶段还没有自研的能力。

第二代架构：WCS+POS双线作战

互联网作用突显，顾客消费习惯变迁，产业升级，新的商业模式兴起，需要快速布局，抢滩线上渠道，上线了IBM WCS电子商务套件。WCS的上线虽可以支持线上核心业务，布局线上渠道，但WCS对互联网分布式应用支持不足，难以适应业务的快速增长，所以苏宁开始组件自身的架构和技术能力。

这时候苏宁的业务系统主要采用IBM的企业级WAS（WebSphere Application Server）作为中间件，WAS的部署方式开始同样是运维手动部署，2014年苏宁的自动化部署平台上线，实现了自动化部署，但是WAS的部署需要比较繁琐的流程，比如停/启Node节点、同步Node节点、分批停启Server等，耗时较长，在集群规模较大时部署时间能长达2小时。

第三代架构 前中后架构重塑 O2O融合

拥抱开源：

随着苏宁业务的不断扩展，商用套件的问题也越来越凸显出来，套装软件扩展性不强，WCS套件顶配小型机难支撑，所以苏宁启动了整个架构的重塑和重建。去商用套装，服务拆分，苏宁选用的中间件是较为成熟的开源中间件Wildfly，模式为集群模式。

相较WAS，Wildfly集群模式的部署时间有了较大的提升，平均在20分钟至30分钟，同时这个阶段90%的测试以及生产部署都在自动化部署平台进行， 用户只要在平台上点击启动部署，生产的部署便会自动完成，并且保证服务的不间断。

部署架构优化：

到了2017年苏宁的系统数达到了3000+，研发人员人数达到了5000+，服务器数量达到10万+。

这个时候原来的Wildfly集群模式的弊端也凸显了出来，Wildfly集群架构的部署需要频繁调用CLI进行应用停止、卸载、部署、启动，同时Wildfly的Master服务器需要跟其他Slave进行通信，下发CLI接收到相关的动作，这个通信的时间往往比较长，以应用停止为例，Wildfly集群模式一般需要2分钟；Master服务器存在单点故障的风险，当Master服务器的控制台不可用，整个集群虽然应用服务不会中断，但是无法进行集群的配置、部署等操作；Wildfly集群模式还存在一些其他的问题，比如集群失联等。

为此苏宁对系统架构进行了调整，这次采用的是Wildfly的Standalone模式，在Standalone模式下，每个服务器都是独立的存在， 不需要由Master统一的控制，该模式不存在集群模式的特有的问题，比如控制台不可用、 集群失联等。 Standalone模式比集群模式的部署速度也有很大的提升。

多数据中心多技术栈：

随着业务快速发展，产品交付频率及速度要求越来越高，对部署过程系统的稳定性要求也越来越高，同时随着新技术栈、新部署架构的不断引入，多数据中心的建设，各产品中心对不同部署架构的自动化部署需求越来越迫切，期望部署过程中可以对业务做到无感知，保证业务的稳定性，能够随时部署，遇到问题随时回滚。自动化部署平台逐渐不能满足多元化的快速发展的自动化部署要求，同时自动化部署平台也面临多项挑战：

• 多数据中心部署

随着苏宁业务的扩展，业务量的不断提高，苏宁的底层的基础设施也在同步发展，多活数据中心、灾备数据中心也逐步交付使用, 后期异地灾备数据中心也 已经提上日程，但是自动化部署平台对多数据中心部署管理功能不够完善。

• 自定义的部署流程

新的技术栈如Node.js、Go、Lua等，新的部署架构如Jboss Standalone部署架构，新的虚拟化方式如Docker，原有的部署逻辑是基于特定的部署架构，部署模式无法扩展，不能灵活配置。

自动化部署平台重构

为解决各产品中心交付频率快、部署过程不影响业务，可以随时部署的要求，同时考虑自动化部署的安全性及稳定性，应对多技术栈多开发语言的自动化部署需求，我们构建了新的自动化部署平台–ODIN。

多数据中心的自动化部署

为支持多数据中心的部署管理，我们对部署架构进行了重大调整，ODIN采用Master-Slave架构，每个数据中心都部署一套Slave节点，负责其数据中心的部署任务，部署调度统一由Master负责。每个数据中心会有独立的构件中心，所有的版本包会分发到各自数据中心的构件中心。每个数据中心的部署都是对应的Slave节点负责从本数据中心的构件中心取包部署。

可自定义的部署步骤及流程

用户可针对不同的技术栈语言，及部署步骤要求定义及编排符合自己的部署步骤及流程。部署步骤可以是平台提供的通用功能，也可以用户定义的shell脚本，多个步骤组成一个步骤集。多个步骤集组成一个部署流程。

部署大数据

部署过程多纬度数据统计， 如部署数、部署耗时统计等。可以帮助用户侧以及平台侧，分析部署规律评估平台部署能力和部署效率，提升平台；部署耗时统计可以帮助用户发现哪些步骤是部署过程中耗时比较久的步骤，并进行针对性优化 。

部署自助化

部署过程常常会遇到需要人为手动介入的情况，用户多数时候是手工线下进行处理，比如进程管理、查看服务器的启动日志，运维人员每天花费大量的时间解决用户部署过程中的各种各样的问题，所以在ODIN，我们开发了部署自运维功能，让用户自行针对不同的场景进行自运维操作，解放运维人力。

秒级部署

影响部署效率的主要因素分为：应用包的分发；平台任务调度；应用停启时间等，为此我们在这几个方面进行了性能提升。

智能分发

当服务器规模变大时应用包分发的时间也线性增加。下图为某系统A的生产部署截图，部署组机器规模221台；，某系统B生产部署截图 ，部署组机器规模5台。

分析：当服务器规模较大时，取包步骤的时间会变的非常长。究其原因，一台的虚拟机的所在的物理机的网卡为千兆网（1000Mbit/秒），构件中心的服务器为虚拟机，那么构件中心的理论下行带宽只有1000Mbit/秒=125MB/秒。假设一个部署包50MB，机器规模为100，则完成取包步骤的时间为100台*5MB/125MB/秒=40秒。这个时间只是理论值，因为虚拟机之间网络带宽存在争抢，同时同一时间可能还有其他系统正在进行生产部署，也存在对构件中心的带宽争抢，所以实际的取包速度会更慢。

虽然提高构件中心的下行带宽可以看似可以解决取包慢的问题，但是随着公司业务的发展，机器规模势必会越来越大，构件中心的下行带宽随着时间的推移也迟早又会变成瓶颈。我们期望的是彻底解决取包的问题。

方案描述：我们换个角度思考这个问题，取包一定要在执行部署的时候执行吗？可以提前执行吗？答案当然是可以，就像变魔术一样，虽然看起来是部署的时候进行的取包，其实包已经在服务器上了。

方案设计：在执行生产部署时，与测试环境不同，生产部署需要先进行编译打包，生成构件，然后提交部署执行部署动作。所以我们的方案就是在生成构件的时候，智能识别被打出的代码包将来可能发布的集群，立即将打好的生产包推送到目标服务器的临时目录，当执行部署的时候部署包已经在服务器上了，只要将部署包从临时目录移动到部署目录即可。这个机制类似于CDN缓存，只不过每台服务器自己充当了CDN的缓存。

如下图为智能分发改造后取包步骤时间对比，从202秒提高到3秒左右，取包速度提高了83倍。

精准调度

我们来回过头来看下，系统A和系统B的部署单的其他步骤，以环境检查步骤为例：

分析：在机器规模比较大的时候，与网络带宽无关其他步骤也会受到影响。从ODIN的Slave执行部署的机制上分析，需要与目标机建立执行通道，然后执行相应的部署动作，比如取包、停server，slave执行完动作后反馈给master，master下发下一步动作，Master和Slave之间是无状态的，相同部署组的不同步骤间执行的slave可能不同。经过压测验证每个Slave并发建链的上限为50。

结论：当机器规模较大时花费在与服务器建链时间是非常可观的，而且执行不同的步骤还存在重复建链的问题
方案描述：参考取包速度优化的解决思路是否可以提前建链？由于无法准确预测部署开始执行的时间，假如事先建链slave将可能长时间保持一些无用的连接，造成资源浪费并可能降低slave的性能，故该方案不可行。既然无法避免建链过程，那么能不能将建链的次数降到最少。

方案设计：前面提到Master和Slave之间是无状态的，相同部署组的不同步骤间执行的slave可能不同。那么只要保证某台机器在部署过程中的每个步骤都由固定slave执行，同时该slave在部署过程中保持该连接达到连接复用的目的，即精确调度。

如下图为实现精确调度改造后生成部署配置文件步骤时间对比，从9秒提高到0.7秒左右，部署速度提高了12倍。

总结

ODIN从2017年1月份上线时，支撑平均每天100+的部署单数，到今天平均每天部署4000+单，ODIN平台已经成为苏宁的自动化部署的主要支撑平台。

目前ODIN平台2.0版本已经在规划中，新版本的ODIN会有哪些令人期待的新特性呢？让产品中心随时随地部署，流量全方位立体式控制，将生产发布对用户的影响降低到最小，即7*24小时部署；平台自动定时部署，不需要人工值守，遇到部署问题智能解决，多重手段验证部署结果，AI人工智能辅助决策，自动化生产测试，即无人值守部署；急速部署，30秒？1秒？没有最快只有更快。

作者简介

陈浩宇，苏宁易购 IT 总部数据云公司开发工具研发中心经理，苏宁DEVOPS体系OPS方向负责人，对DevOps理念有很深的掌握。8 年从业背景，计算机系硕士研究生，主导“奥丁“自动化部署平台产品研发。该产品支撑苏宁控股集团八大产业 4000+ 系统快速、稳定的自动化部署，保障电商平台的各系统版本的快速迭代上线。