ARK方舟的自我拯救之路 - 驴妈妈DevOps实践

ARK方舟的自我拯救之路 - 驴妈妈DevOps实践

前言-啰嗦一下，交代一下背景和“黑”历史

驴妈妈在配置发布自动化这块也摸索、尝试了多年，中间取得了些成绩，也走了些弯路，但是总体来说，并没有系统性解决问题：开发/测试/配置 抱怨不小，甚至有人在知乎上吐槽：开发上线一个需求过程是“2天写代码，3天搞环境”。痛定思痛，在2018年底由架构牵头，联合配置和运维团队一起，启动了DevOps落地项目-ARK方舟。看名字，大家就知道，这是一个技术自我拯救，自我正名的过程。通过它，我们希望能系统性达成 开发/测试/运维 提质增效目标，同时平台要保证扩展性，对未来可能的新技术快速支持（插一句，怎么理解系统性解决，我的理解是：有思路，有方案，可能一时目标还无法完全达成，但是我们按照既定方案，分阶段逐步实施，可以最终完全达成目标；与之相对的就是：头疼医头脚疼医脚，按下葫芦浮起瓢）

DevOps并不是一个全新的概念，不过很长时间，这个概念并没有很好的落地，主要是因为：1）没有统一的技术落地标准/方案 2）小的公司不太需要 3）而达到一定规模的公司，多多少少都有自己的一些摸索和实践，系统多，平台多，部门多，难统一

但是最近一段时间，这项技术有加速落地的趋势，这主要得益于：

1. 互联网发展进入到了一个精细化管理阶段：很多公司都有提质增效的诉求
2. 云技术的推广与普及：很多企业都采用混合云的架构，大大简化了PAAS管理难度。这一方面对管理提出更高要求，同时也使技术实施难度降低
3. 阿里等大厂的宣传与布道：不管是双11那不断创纪录的GMV，还是那极高的单工程师产出，不断刺激着CXO，使DevOps成效也逐步深入人心

直面趋势，我们在前面也做了不少摸索与尝试，也遇到一些问题，我想很多人也踩过同样的坑：

1. 多个系统/平台自成体系，系统间数据没有互动。比如代码准备上线了，我们需要另外一个平台执行一下自动化测试和检查代码覆盖率
2. 过于关注 CI/CD，对于资源管理重视度不够
3. “开发-测试-仿真-生产” 是一个完整的过程，但是我们往往只是生产自动化支持比较好，而其他环节支持很薄弱
4. 简单上 k8s+docker 技术方案，不能解决问题

遇坑，我们就把坑填了，当然不能靠人肉来填，我们要用满满“黑科技”

项目实施过程与“黑科技”

下面我们就来说一下项目实施过程和一些解决方案上的“黑科技” （干货时间）
项目实施，目标很重要。在 CI/CD/CO 这些宽泛目标基础上，我们结合ORK方法，以明确的目标为抓手，协同多个部门共同协作

老板的要求：

1. 持续集成，持续交付
2. 流程自动化
3. 提高开发效率
4. 提高交付质量

结合自身需求，制定的几个具体目标

1. 快速开发/测试环境搭建
2. 无中断/无感发布支持
3. 开发/测试/仿真/生产 全流程支持，多状态无缝跃迁
4. 资源集中管理

产品的“黑科技”

我们看一下上述这些目标，都是用什么“黑科技”来解决的，实施后效果怎么样

“黑科技”1：插件式开发/测试环境搭建

方案:

1．多环境组织架构：由不同版本完全独立环境，变为多版本插件式并存，如下所示：

2．依据访问IP的动态路由

3．多人自由编组（内部称为“圈子”）

效果:

— “黑”历史：“2天写代码，3天搞环境”
— 被拯救后：

1. 2~3 天搭建一套新环境，变为1小时搭建完成，而且只需要维护几个工程
2. 本地启动后，立即接入，立即联调开发
3. 修改什么，启动什么，甚至利用公共的UI，调式本地的后台服务
4. 多人自由编组，协同开发

“黑科技”2：无感/无中断发布

方案:

方案核心是流量切换。我们主要用java技术方案，生产容器的重启，难免造成单个容器计算中断。我们方案是：在重启前，关闭掉这个容器的流量，这个过程我们称为 Pullout，这时候，容器在一个“空”的状态，不处理任何业务逻辑，这时候再重启就没有任何影响；在重启加载完成后，我们再打开这个容器的流量，我们称之为 Pushin，这样该容器可以正常处理业务逻辑了。
我们分布式服务框架用的是DUBBO方案，所以上述控制的流量，就有2个方面流量：HTTP流量和DUBBO服务调用流量。其中在HTTP流量控制上，我们是用Kong来动态控制upstream target实现的；在DUBBO流量控制上，我们结合zookeeper注册中心，定制化DUBBO内部路由机制来实现的

效果:

— “黑”历史：

1. 一发布，业务就被有中断情况，外部流程中断，业务产生投诉或赔偿
2. 为了降低业务影响，改成凌晨发布
3. 第二天工作没有状态
4. 打的费用报销

— 被拯救后

1. 发布无感，发布过程中业务正常运转
2. 任何时间，想发布就发布

其他“黑科技”还有：

1. 全流程支持，开发资源（代码/参数配置/脚本）META信息自由流转
2. 模版化 Jenkins 编译 / 多版本编译隔离
3. CMDB资源集中管理
4. 。。。

项目小结

下面是我们系统目前功能概况截图：

这个是整个系统的架构图：

虽然经历半年多的努力，我们项目已经取得了不错效果，原来的抱怨也逐步转为好评。不过我们知道，和大厂相比，我们还有不小的差距（但是自信有些地方还是有超越的，先盲目自信一下），同时我们也知道，在有限投入情况下，很难一步吃成胖子，另外跑太快也容易跑偏。所以对项目整体的规划，参考自动驾驶分级标准，我们也分为4个阶段，下面是各个阶段重要里程碑：
— 目前 L2

1. 完成资源集中管理
2. “开发-测试-仿真-生产”全流程打通与支持，流程自动化
3. 多IDC支持

— L3

1. 自动化/智能运维
2. 弹性扩展

— L4

• …

交流与合作

综上所述，大家可以看出，我们这个过程是一个 “借鉴+学习+自我摸索” 过程，很多方面可能还是井底之蛙。如果我们的“黑”历史，也是你的痛点，欢迎来一起抱头痛哭；如果你有更好的方式/方案，也欢迎来拍砖

抱头或拍砖的微信：