Embed Size (px)
Citation preview
先推荐两本书
普通⺴⽹网站的架构
普通⺴⽹网站的架构• nginx
• 静态⽂文件服务，分发动态请求
普通⺴⽹网站的架构• nginx
• 静态⽂文件服务，分发动态请求
• 业务逻辑层
• 消除状态，⽅方便⽔水平伸缩
普通⺴⽹网站的架构• nginx
• 静态⽂文件服务，分发动态请求
• 业务逻辑层
• 消除状态，⽅方便⽔水平伸缩
• 数据库
• ⾼高可⽤用架构，定时备份
普通⺴⽹网站的架构• nginx
• 静态⽂文件服务，分发动态请求
• 业务逻辑层
• 消除状态，⽅方便⽔水平伸缩
• 数据库
• ⾼高可⽤用架构，定时备份
• ⽤用户上传的⽂文件
• 跨机器同步/mogilefs/fastdfs/公有云存储
普通⺴⽹网站的架构• nginx
• 静态⽂文件服务，分发动态请求
• 业务逻辑层
• 消除状态，⽅方便⽔水平伸缩
• 数据库
• ⾼高可⽤用架构，定时备份
• ⽤用户上传的⽂文件
• 跨机器同步/mogilefs/fastdfs/公有云存储
• 缓存层
• 降低数据库压⼒力/如何保持数据⼀一致/如何避免缓存机死亡之后雪崩
部署⼯工具演化史
部署⼯工具演化史• 安装⽂文档 (⽐比如 wordpress) #要么线上修改，要么就得重装
部署⼯工具演化史• 安装⽂文档 (⽐比如 wordpress) #要么线上修改，要么就得重装
• FTP/SFTP 上传 (⽐比如 PHP) #适⽤用⾯面很窄，本地要做版本管理，否则很难回滚
部署⼯工具演化史• 安装⽂文档 (⽐比如 wordpress) #要么线上修改，要么就得重装
• FTP/SFTP 上传 (⽐比如 PHP) #适⽤用⾯面很窄，本地要做版本管理，否则很难回滚
• 打包部署 (⽐比如 Java 的 war ⽂文件) #需要⼿手动拷⻉贝，多机情况下仍然要配合其他部署系统
部署⼯工具演化史• 安装⽂文档 (⽐比如 wordpress) #要么线上修改，要么就得重装
• FTP/SFTP 上传 (⽐比如 PHP) #适⽤用⾯面很窄，本地要做版本管理，否则很难回滚
• 打包部署 (⽐比如 Java 的 war ⽂文件) #需要⼿手动拷⻉贝，多机情况下仍然要配合其他部署系统
• 做成系统安装包 #⽐比较累，但⼤大规模部署⽆无压⼒力，听说yahoo以前主要是这么部署的
部署⼯工具演化史• 安装⽂文档 (⽐比如 wordpress) #要么线上修改，要么就得重装
• FTP/SFTP 上传 (⽐比如 PHP) #适⽤用⾯面很窄，本地要做版本管理，否则很难回滚
• 打包部署 (⽐比如 Java 的 war ⽂文件) #需要⼿手动拷⻉贝，多机情况下仍然要配合其他部署系统
• 做成系统安装包 #⽐比较累，但⼤大规模部署⽆无压⼒力，听说yahoo以前主要是这么部署的
• capistrano #我们使⽤用的，但配置⼀一般建议单独管理
部署⼯工具演化史• 安装⽂文档 (⽐比如 wordpress) #要么线上修改，要么就得重装
• FTP/SFTP 上传 (⽐比如 PHP) #适⽤用⾯面很窄，本地要做版本管理，否则很难回滚
• 打包部署 (⽐比如 Java 的 war ⽂文件) #需要⼿手动拷⻉贝，多机情况下仍然要配合其他部署系统
• 做成系统安装包 #⽐比较累，但⼤大规模部署⽆无压⼒力，听说yahoo以前主要是这么部署的
• capistrano #我们使⽤用的，但配置⼀一般建议单独管理
• capistrano+puppet/salt #puppet和salt 可以⽤用来解决配置问题
部署⼯工具演化史• 安装⽂文档 (⽐比如 wordpress) #要么线上修改，要么就得重装
• FTP/SFTP 上传 (⽐比如 PHP) #适⽤用⾯面很窄，本地要做版本管理，否则很难回滚
• 打包部署 (⽐比如 Java 的 war ⽂文件) #需要⼿手动拷⻉贝，多机情况下仍然要配合其他部署系统
• 做成系统安装包 #⽐比较累，但⼤大规模部署⽆无压⼒力，听说yahoo以前主要是这么部署的
• capistrano #我们使⽤用的，但配置⼀一般建议单独管理
• capistrano+puppet/salt #puppet和salt 可以⽤用来解决配置问题
• docker #很酷炫，但还不成熟
capistrano• Ruby 社区的⼀一个产品，主要解决⼀一键部署/⼀一键回滚的问题
• 下载新的代码到releases ⺫⽬目录下的⼀一个新的⼦子⺫⽬目录
• 链接配置⽂文件, ⽇日志⺫⽬目录
• 切换 current 链接
• 重启程序
新的问题
• 如果你的系统盘毁了，你需要多久才能恢复服务
• 如果你需要扩容100台机器，你需要花多久
• 系统上要安装哪些软件
• 要修改哪些配置
• 要配置哪些监控
puppet/salt• puppet 都能很好地解决，不过⽐比较偏运维，我就不详细讲了，简单来说就是⼏几点
• 所有配置⼊入库，可以快速知道所有机器的配置情况
• ⽤用模板简化配置
• 同时管理⼤大量的机器
• ⽤用依赖和消息来简化复杂性
cap+puppet的问题
• 我们在开发⼀一个新的部署系统
• 程序和配置分离带来的问题，回滚的时候要同时回滚程序和配置
• 伸缩性不够，机器量太多的时候性能下降
• 需要很多辅助程序来帮助开发⼈人员在不登录的情况下了解情况
⾃自动测试/持续集成• 持续集成
• 是否要合并⼀一个 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
