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

1. 阿里巴巴在DevOps 实践中的创新和思考 2018 中国·上海

2. 林帆花名金戟，阿里巴巴研发效能事业部技术专家前ThoughtWorks高级DevOps技术咨询师国内早期的DevOps和容器技术实践者和传播者 CNUT全球运维大会、CSDN架构峰会一线讲师丰富的一线开发和运维工程经验著有《CoreOS实践之路》和《容器即服务：从零构建企业级容器集群》两本书籍

3. 今天的话题 1 更简，从Gitflow到Aoneflow 2 更快，从部署10分钟到10秒 3 更轻，从虚拟硬件到虚拟服务

4. 代码管理，从Gitflow到Aoneflow

5. Aoneflow文章被问及最多的两个问题阿里巴巴的研发模式为什么没有走向“单主干(trunk based)”？ • 项目规模大，Aoneflow在持续集成和特性隔离之间做了平衡 • 开发者习惯，平台的支持情况 • 许多新的小型项目也在尝试单主干模式 Aoneflow就是简化的Gitflow？ • 两者除了都有“特性分支”和“发布分支”以外，流程和机制完全不同

6. Gitflow有什么问题？集成时间滞后 • 特性分支在功能完成前，“不敢”随意合并回 Develop分支，造成代码集成时间严重滞后代码集中冲突 • 每次功能完成后进行“大集成”，十分容易出现大范围代码冲突特性易合难分 • 特性一旦集成到Develop分支便难以再次分离，单个特性问题可能导致整体发布延期分支关系复杂 • 发布分支拉出后，直到合回主干，若有特性修改或Hotfix需要维护多处CherryPick合并

7. 阿里人为何偏爱Aoneflow？ • 保留“特性分支”的工作方式，便于大型团队协作 • 简化Gitflow的复杂分支策略，上手容易 • 灵活的特性分支组合集成，集成后亦可快速剥离 • 实现“准持续集成” • 略低于单主干，远高于Gitflow的集成频率 • 选择性的特性持续集成（方便灵活，但其实并非优点）

8. Aoneflow的开发者(用户)视角从开发角度来看主干和发布分支始终存在 master feature/demo-1 feature/demo-2 release/testing release/staging release/prod 主干对应线上最新的稳定版本发布分支对应各个环境正在测试的版本开发者通过平台从主干创建特性分支

9. Aoneflow的开发者(用户)视角发布分支的生命周期由平台自动管理 master feature/demo-1 feature/demo-2 release/testing release/staging release/prod 开发者选择了几个特性分支在平台的测试环境页轻轻一点于是组成了测试环境的发布分支

10. Aoneflow的开发者(用户)视角 master 开发者只关心向特性分支提交代码所有提交自动合并到发布分支上 feature/demo-1 feature/demo-2 release/testing release/staging release/prod

11. Aoneflow的开发者(用户)视角 master 特性1被废除了，临时增加了特性3 开发者为特性3创建特性分支然后在平台上轻轻一点发布分支重建了剔除了特性1 feature/demo-2 增加了特性3 feature/demo-1 feature/demo-3 release/staging release/prod release/testing

12. Aoneflow的开发者(用户)视角每个发布分支有独立的交付流水线 master feature/demo-2 当流水线上的测试验证完成就可以将特性列表一键拷贝进入到下一级发布分支流水线 feature/demo-3 feature/demo-4 feature/demo-5 (master + demo-2 + demo-3 + demo-4 + demo-5) (master + demo-2 release/staging + demo-3 + demo-4) release/testing release/prod (master + demo-2 + demo-3 + demo-4)

13. Aoneflow的开发者(用户)视角 master feature/demo-2 feature/demo-3 feature/demo-4 待发布特性一路晋级进入正式环境发布分支正式环境发布成功自动合并正式发布分支到主干 feature/demo-5 与此同时所有发布分支自动重建已发布的特性分支自动删除一切恢复平静，等待下一个迭代的到来 release/testing (master + demo-5) release/staging (master) release/prod release/prod (master)

14. Aoneflow的平台视角 release/staging release/testing 构建部署自动测试人工验证特性清单拷贝集成 ① 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/prod 合并主干

15. Aoneflow的代码仓库视角 hotfix master feature/demo-1 feature/demo-2 feature/demo-3 feature/demo-4 feature/demo-5 release/testing release/staging release/prod 在用户看来始终存在的发布分支，其实一直在被平台频繁重建…

16. 几种分支模式的比较分支模式集成频率多版本并行开发需求中途撤销打包方式单主干所有提交立即集成特性开关手工剔除代码一次打包多次部署 Aoneflow 指定多个特性的提交频繁集成特性分支删除特性分支每个发布分支分别打包 Gitflow 整个特性完成后特性分支（且需严格合并开发分支前：删除特性分支开发分支和发布分进行“大集成” 控制特性合并时间）合并开发分支后：手工剔除代码支分别打包 • 单主干 → 持续集成最佳实践+理想模式 • Aoneflow → 适应阿里现状的改进模式 • Gitflow → 历史遗产

17. 构建部署，从10分钟到10秒

18. 典型的Java项目构建部署过程编译构建单元测试上传镜像到中心仓库更新代码健康检查等待启动完成容器镜像生成停止旧容器启动新容器从中心仓库下载镜像

19. 典型的Java项目构建部署过程猜一猜在阿里最复杂的单个应用正常构建部署一次需要多久？

20. 一阶段优化：Maven依赖树缓存构建慢的应用特点更新代码 ≈0 编译构建 > ½ • 项目规模庞大 • 普遍使用Maven构建镜像创建和传输 < ¼ 服务部署和启动 < ¼ 时间线数据分析依赖数目众多的三方包， Maven解析大型依赖树非常耗时，为了确保构建正确，每个SNAPSHOT版本的依赖都需要连接中心仓库做时间戳对比，进一步影响依赖树解析效率。 • 依赖中包含SNAPSHOT版本的库 80% 的时间依赖树解析占据了整个编译过程

21. 一阶段优化：Maven依赖树缓存新的snapshot 版本库上传通知构建服务器是将所有依赖此 snapshot的缓存依赖树设为无效缓存pom文件中的snapshot 依赖清单 Maven私服仓库 pom文件是否变化否解析依赖缓存pom文件和依赖树否缓存的依赖树是否有效是直接复用缓存的依赖树开始构建构建服务器

22. 一阶段优化：Maven依赖树缓存一阶段优化结果 • 构建时间普遍缩短，部分典型应用构建时长缩短超过80% • 大型应用部署总耗时减少一半 • 应用镜像的生成和传输成为优化后的部署性能瓶颈

23. 二阶段优化：主包部署容器给了开发者创造环境的自由，但也带来了更大的发布包(镜像)和相应更长的包制作和传输时间… 有人想到了阿里Pouch的P2P镜像传输协议，但那只适用于大量分发基础镜像既要灵活又要速度，我们最终做了一个违背“业界最佳实践”的决定

24. 二阶段优化：主包部署在一定条件下对测试环境的服务放弃不可变基础设施是 Dockerfile 是否变化 Dockerfile中涉及的文件是否变化在容器上进行主包部署是是二阶段优化结果 • 测试环境发包速度从分钟级降到秒级 • 从部分灰度用户推广到集团大部分BU 否否用户手工触发构建 * 为偶然的“误判”留退路否生成并传输容器镜像只生成主包镜像部署主包部署 • 应用自身重启耗时成为最后时间瓶颈 * 根据配置的不同，可以是tgz/jar/war等格式的包

25. 三阶段优化：增量部署服务启动慢不是平台的错，但它的确成为了拖慢了部署总时长的最后瓶颈… 所以…Java应用部署能够不重启吗？ JVM有个Hotswap机制在特定的条件下，似乎值得一试

26. 三阶段优化：增量部署在符合主包部署条件的基础上只修改方法体或新增类的测试环境服务使用Java Hotswap热部署无需重启服务平均 10分钟前提：符合主包部署条件最快 10秒钟否 * 原始Hotswap只支持修改方法体，这里使用的是改良版的Hotswap机制仅生成完整主包三阶段优化结果 • 整个构建部署过程最快10秒 • 代码提交测试环境“立即”生效主包部署判定改动内容是否适用Hotswap 是生成完整主包生成增量部署包 * 主要用于版本回滚出错兜底主包部署 Hotswap 热部署

27. 服务集群，从虚拟硬件到虚拟服务

28. 虚拟化实质是资源的隔离和复用物理机虚拟机容器无虚拟化硬件级虚拟化软件级虚拟化 1 → 1 1 → 10 1 → 100 特性环境服务级虚拟化 1 → 1000 * 搭配容器使用

29. 虚拟机和容器的虚拟化方式 App App App OS App App OS App OS Hypervisor OS Container Daemon App OS 物理机物理机物理机物理机虚拟机容器 App 还能更轻量吗？

30. 什么是服务级虚拟化容器已经将计算资源复用的损耗降到极低，但容器中的服务似乎总还是有许多空闲的时候… 能否让一个服务分身到多个集群里发挥作用，让这些闲着的时段都利用起来呢？但是消息会串号吧？

31. 虚拟链路其实我们都不陌生 • 金丝雀发布 • 灰度部署 • A/B测试 •… 用户A 用户B http://demo.devopsdays.com/index.html 路由判断

32. 阿里的特性环境假设服务调用链路为： A > B > C > D > B > A 特性环境1 环境2 环境1 服务A 服务A 特性环境1 特性环境2 服务B 服务A 服务B 服务B 服务C 服务C 特性环境2 服务B 服务A [本地] [本地] 服务C 服务B [云端] [本地] 服务D 服务D [云端] [云端] 服务C 服务A 服务D 服务B 服务C 服务D 公共基础环境普通集群使用特性环境服务D 服务A 服务B 服务C 服务D [云端] [云端] [云端] [云端] 公共基础环境加入本地服务

33. 特性环境的上帝视角特性环境-1 服务B 服务C 服务A 基于服务域名的动态路由基于用户身份的链路隔离特性环境-2 服务D 服务C 服务B 服务C 公共基础环境特性环境-3 服务A 服务D

34. 特性环境的开发者视角 [云端] 特性环境-1 服务D 服务B 服务C [云端] 服务A [本地] 坐拥整个集群特性环境-2 [云端] 感觉就像所有服务就在本地特性环境-3 随意断点、单步调试、修改、重新部署服务都不会影响其他人

35. 特性环境的团队视角特性环境-1 服务C 服务A [云端] [本地] 服务C [云端] 服务D 开发者同一时刻只能属于一个特性环境服务B 相互可见特性环境-2 [云端] [云端] [云端] 服务D 服务B [本地] 互不影响服务A [本地]

36. 特性环境的团队视角服务C 服务A 特性环境-1 [云端] 服务C [云端] 服务D [本地] [云端] 特性环境-2 [云端] 服务D 服务B [云端] 服务B 切换环境 [本地] 服务A 快速组队协作 [本地]

37. 几种虚拟化方式的比较虚拟化方式复用资源类型通用性隔离度复用度硬件级虚拟化（虚拟机）设备资源复用（CPU和内存等）强（可跨操作系统类型运行任何应用）高（资源完全隔离）低（通常低于1:10）软件级虚拟化（容器）设备资源复用（CPU和内存等）较强较高较高（可运行相同内核类型（共享内核，命名空（通常低于1:100，的任何应用）间隔离）可与虚拟机联用）服务资源复用弱低高（仅限同类服务集群之（仅具有访问路由级（可达1:100以上，间共享应用）别的隔离）通常与容器联用）服务级虚拟化（特性环境）

38. DevOps，回归效能与协同

39. DevOps的核心在于效能和协同 Aoneflow 缓存构建/主包部署/增量部署提升效能优化协同提升效能优化协同简化分支管理提高集成频率既能区分特性开发又能组合特性联调减少部署等待时间加速测试反馈周期特性环境提升效能优化协同提高资源利用率 "独占"集群方便调试同组隔离联调跨组互不影响快速切换组队

40. 这些与DevOps相关的话题持续集成敏捷精益提升效能优化协同提升效能优化协同自动化流水线提交代码即部署避免"最后一刻集成" 尽早暴露集成问题迭代开发减少浪费轻量Scrum流程披萨饼规模团队交流优于文档容器技术微服务设计提升效能优化协同提升效能优化协同基础设施即代码运行环境开箱即用统一"环境定义语言" 开发者参与环境设计便于异构技术栈服务独立升级便于快速迭代架构反映领域模型服务边界清晰

41. 只要目标与方向清晰，创新不需要规则束缚

42. "最佳实践"都是别人的，适合自己才是最好的！

43. THANKS We Are Hiring ^^: jinji.lf@alibaba-inc.com Website： chinadevopsdays.org/ Global Website: www.devopsdays.org/events/2018-shanghai/ Official Email: organizers-shanghai-2018@devopsdays.org Official Wechat