《从开发到上线-实战持续交付.pdf》由会员分享，可在线阅读，更多相关《从开发到上线-实战持续交付.pdf（27页珍藏版）》请在三一文库上搜索。
1、从开发到上线 实战持续交付 LI Daobing 七牛云存储 2014-11 北京 先推荐两本书 普通网站的架构 普通网站的架构 nginx 提供静态文件，分发动态请求 普通网站的架构 nginx 提供静态文件，分发动态请求 业务逻辑层 无状态设计，方便水平伸缩 普通网站的架构 nginx 提供静态文件，分发动态请求 业务逻辑层 无状态设计，方便水平伸缩 数据库 高可用架构（容灾），定时备份（容错） 普通网站的架构 nginx 提供静态文件，分发动态请求 业务逻辑层 无状态设计，方便水平伸缩 数据库 高可用架构（容灾），定时备份（容错） 用户上传的文件 跨机器同步/mogilefs/fastd
2、fs/公有云存储 普通网站的架构 nginx 提供静态文件，分发动态请求 业务逻辑层 无状态设计，方便水平伸缩 数据库 高可用架构（容灾），定时备份（容错） 用户上传的文件 跨机器同步/mogilefs/fastdfs/公有云存储 缓存层 降低数据库压力/如何保持数据一致/如何避免缓存机死亡之后雪崩 部署工具演化史 部署工具演化史 安装文档 (比如 wordpress) #要么线上修改，要么就得重装 部署工具演化史 安装文档 (比如 wordpress) #要么线上修改，要么就得重装 FTP/SFTP 上传 (比如 PHP) #适用面很窄，本地要做版本管理，否则很难 回滚 部署工具演化史 安装
3、文档 (比如 wordpress) #要么线上修改，要么就得重装 FTP/SFTP 上传 (比如 PHP) #适用面很窄，本地要做版本管理，否则很难 回滚 打包部署 (比如 Java 的 war 文件) #需要手动拷贝，多机情况下仍然要配 合其他部署系统 部署工具演化史 安装文档 (比如 wordpress) #要么线上修改，要么就得重装 FTP/SFTP 上传 (比如 PHP) #适用面很窄，本地要做版本管理，否则很难 回滚 打包部署 (比如 Java 的 war 文件) #需要手动拷贝，多机情况下仍然要配 合其他部署系统 做成系统安装包 #比较累，但大规模部署无压力，听说yahoo以前主要
4、是 这么部署的 部署工具演化史 安装文档 (比如 wordpress) #要么线上修改，要么就得重装 FTP/SFTP 上传 (比如 PHP) #适用面很窄，本地要做版本管理，否则很难 回滚 打包部署 (比如 Java 的 war 文件) #需要手动拷贝，多机情况下仍然要配 合其他部署系统 做成系统安装包 #比较累，但大规模部署无压力，听说yahoo以前主要是 这么部署的 capistrano #我们使用的，但配置一般建议单独管理 部署工具演化史 安装文档 (比如 wordpress) #要么线上修改，要么就得重装 FTP/SFTP 上传 (比如 PHP) #适用面很窄，本地要做版本管理，否则
5、很难 回滚 打包部署 (比如 Java 的 war 文件) #需要手动拷贝，多机情况下仍然要配 合其他部署系统 做成系统安装包 #比较累，但大规模部署无压力，听说yahoo以前主要是 这么部署的 capistrano #我们使用的，但配置一般建议单独管理 capistrano+puppet/salt #puppet和salt 可以用来解决配置问题 部署工具演化史 安装文档 (比如 wordpress) #要么线上修改，要么就得重装 FTP/SFTP 上传 (比如 PHP) #适用面很窄，本地要做版本管理，否则很难 回滚 打包部署 (比如 Java 的 war 文件) #需要手动拷贝，多机情况下
6、仍然要配 合其他部署系统 做成系统安装包 #比较累，但大规模部署无压力，听说yahoo以前主要是 这么部署的 capistrano #我们使用的，但配置一般建议单独管理 capistrano+puppet/salt #puppet和salt 可以用来解决配置问题 docker #很酷炫，但还不成熟 capistrano Ruby 社区的一个产品，主要解决一键部署/一键 回滚的问题 下载新的代码到releases 目录下的一个新的子 目录 链接配置文件, 日志目录 切换 current 链接 重启程序 回滚流程 切换 current 链接 重启程序 新的问题 如果你的系统盘毁了，你需要多久才能恢
7、复服务 如果你需要扩容100台机器，你需要花多久 系统上要安装哪些软件 要修改哪些配置 要配置哪些监控 puppet/salt puppet 都能很好地解决，不过比较偏运维，我就不 详细讲了，简单来说就是几点 所有配置入库，可以快速知道所有机器的配置情况 用模板简化配置(DRY) 用中心节点同时管理大量的机器 引入依赖和消息来确定配置更新后哪些服务需要重 启 cap+puppet的问题 我们在开发一个新的部署系统 程序和配置分离带来的问题，回滚的时候要同时回 滚程序和配置 伸缩性不够，机器量太多的时候性能下降 需要很多辅助程序来帮助开发人员在不登录的情况 下了解情况 自动测试/持续集成 持续集
8、成 是否要合并一个 pull request: github+travis 是否可以发布这个版本: jenkins jenkins 的额外好处 测试/代码质量的可视化 串起你的工具链 提交 issue 修改代码-提交PR（Pull Request) 持续集成通过-合并PR 持续集成通过 capistrano 部署 再次检验 关闭 issue 或者快速回滚 正规化 所有源码入库 特别是第三方的软件（你迟早会改的） 线上配置不要入代码库，软件和配置分离 密码/私钥不要入库，puppet 支持用模板替换 测试环境 集成测试不能保证不出任何问题 那么就搭一个测试环境吧 cap test deploy 与线上系统完全独立 注意要使用独立的 secret token 小入口 测试环境也不能保证不出任何问题 弄一个小入口 跟线上系统共用数据库和存储，缓存看情况 部署时先部署小入口 部署完成后跑测试或者人工查看 小入口没有问题之后才部署大入口 额外有点：方便调试 遗留问题 Go 语言的问题 编译，capistrano-scm-jenkins 可执行程序的分发 推送到内网 纯内网机器 Ubuntu approx Thanks for your attention