灰度发布–集群剩余容量的概念loadcpumemorynetwork.ppt

Top 100 Case Studies Of The Years 全 球 软 件 案 例 研 究 峰 会 智库 Top 100 Case Studies Of The Years 全 球 软 件 案 例 研 究 峰 会 智库 1号店发布系统实战 李浩伟 运维架构师 1号店 1号店的飞速发展有目共睹，从刚刚起步到成为沪上家喻户晓的电商，也就短短几年的时间，在这成功的背后，除了大力宣传外，强大的开发力量支撑着业务的稳定发展。敏捷开发的同时，如何让产品最终交付，成为摆在我们面前的一道难题。 1号店从零开始打造了自己的发布系统，并成为行业内将敏捷开发落到实处的成功典范。在近两年的时间里，从最初通过脚本方式发布，到如今的每月发布量上千，自动化程度、可靠性和高效性大大提高，发布系统从“质”和“量”经历了不断完善。期间积累了一些心得，借此机会和大家一起分享交流。 案例简介 在两年的时间里，经历了针对不同应用场景发布方式 Staging自动发布 - 让开发/测试人员快速构建预发布环境 无人发布 – 最大程度降低人工干预，提高了发布的可靠性和高效性 灰度发布 - 不仅降低上线风险，同时也保障发布过程中整体服务的高可用性 发布的“质”和“量” 在互联网行业中，运维团队一直以苦逼的形象出现。还记得上家公司，新来的开发一直以为运维的职责，只是装系统和协助开发上线……。每天大量的上线需求，让运维疲于奔命，同时人为因素导致的上线事故层出不穷，遇到线上事故，运维和开发相互推卸责任，开发怪运维没有严格按照流程办事，运维嫌开发上线流程太频繁。 随着DevOps概念的提出，一切事物自动化成为运维的目标：日志平台、监控平台、变更平台等，当然也包括发布平台。发布平台初衷是为了解决发布过程由人工转向自动，如何保障发布的高效、可靠，避免因为一次发布变更造成线上事故，对发布平台提出了新的挑战。 不做苦逼的运维 主动出击 - 主动了解业务团队的实际需求，避免守株待兔 大胆创新 - 如提出无人发布的概念，最大程度降低人工干预 精益求精 - 从纯手工到半自动化到全自动化，从完成发布到不断提高发布过程的高效性和可靠性 成功要素 持续集成服务 (Jenkins) Artifact仓库 (FTP) Staging环境 Production环境 版本控制服务 (SVN) Test环境 持续交付的流程 无人发布 发布系统 Staging 自动发布 无人 人工 常规 灰度 Phase 1 Phase 2 Phase 3 Phase 4 自动化 阶段化 发展阶段 发布系统的发展历史 发布系统 Staging服务器 BUILD API DEPLOY EMAIL CHECKOUT PUT GET 预环境发布 发车周期（上线窗口） 检票（上线审核） 专车（紧急上线） 发布系统 整点发布 并行发布 依赖发布 无人发布 – 无人值守 静态发布 配置发布 程序发布 静态发布异常的发布单:[20150210140800771455S]YCC待发布的发布单:[20150210140800382964C]程序待发布的发布单:[20150210140800908353W]请正确处理已发布的发布单和待发布的发布单 无人发布 – 可靠性 POOL1 POOL2 POOL3 预发布 正式发布(软链接) 11:00 13:00 12:00 预发布 预发布 正式发布(软链接) 正式发布(软链接) 预发布目录 备份目录 工作目录 1.预发布 2.正式发布(软链接) 3.回滚(软链接) 无人发布 – 高效性 A A A B B B haproxy 检测到问题自动回滚 灰度发布 – 多阶段化及自动回滚 zookeeper集群 应用POOL 服务POOL 健康检查 更新服务列表 注册服务 haproxy 灰度发布 – 降低单台服务器对业务的影响 haproxy 发布系统 应用节点 1.disable命令 2.发布 3. 健康检查 4.enable命令 发布系统 detector zookeeper集群 服务节点 1.调用API 2.禁用节点 4.注册服务 3.发布 灰度发布 – 降低单台服务器对业务的影响II 2.集群剩余容量 ≈ 可用服务器的百分比 集群剩余容量下限 = 可容忍的集群剩余容量，即某一时刻的值等于该时刻的集群负载 灰度发布 – 集群剩余容量的概念 LOAD CPU Memory Network 1.集群负载 – 集群的繁忙程度 服务器1 服务器2 服务器3 服务器4 发布开始 发布结束 重启 应用恢复阶段 服务可用 服务不可用 重启 等待时间 100% 正式发布开始 正式发布结束 集群剩余容量 x% 服务阶段 服务阶段 应用恢复阶段 服务阶段 重启 等