阿里巴巴在DevOps实践中的创新和思考-精简

2018中国·上海阿里巴巴在DevOps实践中的创新和思考林帆花名金戟，阿里巴巴研发效能事业部技术专家前ThoughtWorks高级DevOps技术咨询师国内早期的DevOps和容器技术实践者和传播者CNUT全球运维大会、CSDN架构峰会一线讲师丰富的一线开发和运维工程经验著有《CoreOS实践之路》和《容器即服务：从零构建企业级容器集群》两本书籍123更简，从Gitflow到Aoneflow更快，从部署10分钟到10秒更轻，从虚拟硬件到虚拟服务今天的话题代码管理，从Gitflow到AoneflowAoneflow文章被问及最多的两个问题阿里巴巴的研发模式为什么没有走向“单主干(trunkbased)”？•项目规模大，Aoneflow在持续集成和特性隔离之间做了平衡•开发者习惯，平台的支持情况•许多新的小型项目也在尝试单主干模式Aoneflow就是简化的Gitflow？•两者除了都有“特性分支”和“发布分支”以外，流程和机制完全不同集成时间滞后•特性分支在功能完成前，“不敢”随意合并回Develop分支，造成代码集成时间严重滞后代码集中冲突•每次功能完成后进行“大集成”，十分容易出现大范围代码冲突特性易合难分•特性一旦集成到Develop分支便难以再次分离，单个特性问题可能导致整体发布延期分支关系复杂•发布分支拉出后，直到合回主干，若有特性修改或Hotfix需要维护多处CherryPick合并Gitflow有什么问题？阿里人为何偏爱Aoneflow？•保留“特性分支”的工作方式，便于大型团队协作•简化Gitflow的复杂分支策略，上手容易•灵活的特性分支组合集成，集成后亦可快速剥离•实现“准持续集成”•略低于单主干，远高于Gitflow的集成频率•选择性的特性持续集成（方便灵活，但其实并非优点）Aoneflow的开发者(用户)视角masterfeature/demo-1feature/demo-2release/testingrelease/stagingrelease/prod从开发角度来看主干和发布分支始终存在主干对应线上最新的稳定版本发布分支对应各个环境正在测试的版本开发者通过平台从主干创建特性分支Aoneflow的开发者(用户)视角masterfeature/demo-1feature/demo-2release/testingrelease/stagingrelease/prod发布分支的生命周期由平台自动管理开发者选择了几个特性分支在平台的测试环境页轻轻一点于是组成了测试环境的发布分支Aoneflow的开发者(用户)视角masterfeature/demo-1feature/demo-2release/testingrelease/stagingrelease/prod开发者只关心向特性分支提交代码所有提交自动合并到发布分支上Aoneflow的开发者(用户)视角masterfeature/demo-1feature/demo-2feature/demo-3release/stagingrelease/prodrelease/testing特性1被废除了，临时增加了特性3开发者为特性3创建特性分支然后在平台上轻轻一点发布分支重建了剔除了特性1增加了特性3Aoneflow的开发者(用户)视角masterfeature/demo-2feature/demo-3feature/demo-4release/prodrelease/stagingrelease/testingfeature/demo-5(master+demo-2+demo-3+demo-4+demo-5)(master+demo-2+demo-3+demo-4)(master+demo-2+demo-3+demo-4)每个发布分支有独立的交付流水线当流水线上的测试验证完成就可以将特性列表一键拷贝进入到下一级发布分支流水线Aoneflow的开发者(用户)视角masterfeature/demo-2feature/demo-3feature/demo-4release/prodrelease/stagingrelease/testingfeature/demo-5(master+demo-5)(master)(master)待发布特性一路晋级进入正式环境发布分支正式环境发布成功自动合并正式发布分支到主干与此同时所有发布分支自动重建已发布的特性分支自动删除一切恢复平静，等待下一个迭代的到来release/prodAoneflow的平台视角构建部署自动测试人工验证构建部署自动测试人工验证构建安全检查灰度部署灰度验证①feature/demo-1②feature/demo-2③feature/demo-4④feature/demo-5①feature/demo-1②feature/demo-2③feature/demo-4①feature/demo-1②feature/demo-2③feature/demo-4正式部署正式验证合并主干集成特性清单集成特性清单集成特性清单特性清单拷贝特性清单拷贝平台承担的能力•创建特性分支•管理发布分支•定义发布流水线•其他琐碎环节自动化
(譬如：正式发布后的收尾)release/testingrelease/stagingrelease/prodAoneflow的代码仓库视角masterrelease/testingrelease/stagingrelease/prodfeature/demo-1feature/demo-2feature/demo-3feature/demo-4feature/demo-5hotfix在用户看来始终存在的发布分支，其实一直在被平台频繁重建…分支模式集成频率多版本并行开发需求中途撤销打包方式单主干所有提交立即集成特性开关手工剔除代码一次打包多次部署Aoneflow指定多个特性的提交频繁集成特性分支删除特性分支每个发布分支分别打包Gitflow整个特性完成后进行“大集成”特性分支（且需严格控制特性合并时间）合并开发分支前：删除特性分支合并开发分支后：手工剔除代码开发分支和发布分支分别打包•单主干→持续集成最佳实践+理想模式•Aoneflow→适应阿里现状的改进模式•Gitflow→历史遗产几种分支模式的比较构建部署，从10分钟到10秒典型的Java项目构建部署过程更新代码编译构建容器镜像生成上传镜像到中心仓库单元测试从中心仓库下载镜像停止旧容器启动新容器健康检查等待启动完成典型的Java项目构建部署过程猜一猜在阿里最复杂的单个应用正常构建部署一次需要多久？一阶段优化：Maven依赖树缓存构建慢的应用特点•项目规模庞大•普遍使用Maven构建•依赖中包含SNAPSHOT版本的库依赖数目众多的三方包，Maven解析大型依赖树非常耗时，为了确保构建正确，每个SNAPSHOT版本的依赖都需要连接中心仓库做时间戳对比，进一步影响依赖树解析效率。依赖树解析占据了整个编译过程80%的时间时间线数据分析编译构建½镜像创建和传输¼服务部署和启动¼更新代码≈0pom文件是否变化解析依赖缓存的依赖树是否有效开始构建缓存pom文件和依赖树直接复用缓存的依赖树是否否是构建服务器Maven私服仓库缓存pom文件中的snapshot依赖清单新的snapshot版本库上传通知构建服务器将所有依赖此snapshot的缓存依赖树设为无效一阶段优化：Maven依赖树缓存一阶段优化结果•构建时间普遍缩短，部分典型应用构建时长缩短超过80%•大型应用部署总耗时减少一半•应用镜像的生成和传输成为优化后的部署性能瓶颈一阶段优化：Maven依赖树缓存二阶段优化：主包部署容器给了开发者创造环境的自由，但也带来了更大的发布包(镜像)和相应更长的包制作和传输时间…有人想到了阿里Pouch的P2P镜像传输协议，但那只适用于大量分发基础镜像既要灵活又要速度，我们最终做了一个违背“业界最佳实践”的决定主包部署镜像部署只生成主包Dockerfile是否变化Dockerfile中涉及的文件是否变化用户手工触发构建生成并传输容器镜像是否*为偶然的“误判”留退路*根据配置的不同，可以是tgz/jar/war等格式的包否否是是二阶段优化：主包部署在一定条件下对测试环境的服务放弃不可变基础设施在容器上进行主包部署二阶段优化结果•测试环境发包速度从分钟级降到秒级•从部分灰度用户推广到集团大部分BU•应用自身重启耗时成为最后时间瓶颈三阶段优化：增量部署服务启动慢不是平台的错，但它的确成为了拖慢了部署总时长的最后瓶颈…所以…Java应用部署能够不重启吗？JVM有个Hotswap机制在特定的条件下，似乎值得一试前提：符合主包部署条件仅生成完整主包生成增量部署包*主要用于版本回滚判定改动内容是否适用Hotswap生成完整主包Hotswap热部署主包部署主包部署是否出错兜底三阶段优化：增量部署在符合主包部署条件的基础上只修改方法体或新增类的测试环境服务使用JavaHotswap热部署无需重启服务三阶段优化结果•整个构建部署过程最快10秒•代码提交测试环境“立即”生效*原始Hotswap只支持修改方法体，这里使用的是改良版的Hotswap机制平均10分钟最快10秒钟服务集群，从虚拟硬件到虚拟服务物理机虚拟机容器特性环境硬件级虚拟化1→10软件级虚拟化1→100服务级虚拟化1→1000*搭配容器使用无虚拟化1→1虚拟化实质是资源的隔离和复用物理机OSHypervisorOS物理机OSOSAppAppAppApp物理机OSAppAppContainerDaemonAppApp物理机还能更轻量吗？虚拟机容器虚拟机和容器的虚拟化方式什么是服务级虚拟化容器已经将计算资源复用的损耗降到极低，但容器中的服务似乎总还是有许多空闲的时候…能否让一个服务分身到多个集群里发挥作用，让这些闲着的时段都利用起来呢？但是消息会串号吧？虚拟链路其实我们都不陌生•金丝雀发布•灰度部署•A/B测试•…用户A用户B路由判断阿里的特性环境普通集群使用特性环境加入本地服务服务A服务A服务B服务C服务D服务B服务C服务D服务A服务B服务C服务D服务A服务B服务C服务D服务B服务C服务A服务D服务A[云端][云端][云端][云端][云端]服务B服务C服务D[本地][本地]服务B[云端][云端][本地]环境1环境2特性环境1特性环境2特性环境1特性环境2公共基础环境公共基础环境假设服务调用链路为：ABCDBA特性环境的上帝视角服务B服务C服务D服务C服务A特性环境-1特性环境-2特性环境-3公共基础环境服务A服务B服务C服务D基于服务域名的动态路由基于用户身份的链路隔离特性环境的开发者视角服务A服务C服务B服务D坐拥整个集群感觉就像所有服务就在本地随意断点、单步调试、修改、重新部署服务都不会影响其他人特性环境-1特性环境-2特性环境-3[本地][云端][云端][云端]特性环境的团队视角特性环境-1特性环境-2相互可见服务A[本地]服务B[本地]服务C服务D[云端][云端]服务A[本地]服务C服务D[云端][云端]服务B[云端]互不影响开发者同一时刻只能属于一个特性环境特性环境的团队视角特性环境-1特性环境-2服务A[本地]服务C服务D[云端][云端]服务B[云端]切换环境服务A[本地]服务C服务D[云端][云端]服务B[本地]快速组队协作虚拟化方式复用资源类型通用性隔离度复用度硬件级虚拟化（虚拟机）设备资源复用（CPU和内存等）强（可跨操作系统类型运行任何应用）高（资源完全隔离）低（通常低于1:10）软件级虚拟化（容器）设备资源复用（CPU和内存等）较强（可运行相同内核类型的任何应用）较高（共享内核，命名空间隔离）较高（通常低于1:100，可与虚拟机联用）服务级虚拟化（特性环境）服务资源复用弱（仅限同类服务集群之间共享应用）低（仅具有访问路由级别的隔离）高（可达1:100以上，通常与容器联用）几种虚拟化方式的比较DevOps，回