微服务云平台及DEVOPS培训.ppt

  1. 1、本文档共59页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
LB 负载均衡 灰度发布典型流程: 可部分更新服务,并选择更新的实例数 如果更新成功,更新会暂停 可将部分流量引导至新实例,进行测试 如果测试通过,可继续更新剩余实例 如果测试失败,可将服务回滚至旧版本 在任何阶段如果更新发生错误,可将服务回滚到旧版本 真正的灰度发布需要实现应用容器化、数据库分布化以及负载均衡的无状态切换 灰度发布与容器化(基于K8s或Mesos) DevOps与云平台的关系 DevOps在大Paas规划中的定位 DevOps是大Paas平台规划中的核心组成部分,有了DevOps能力才使快速交付、热修复和灰度发布成为可能 SaaS PaaS IaaS 通用fu’wu X86服务器 Docker VM Power 网络\存储 … 网络\存储 基础设施 业务 能力 渠道中心 客户中心 营销中心 产品中心 客服中心 资源中心 订单中心 支付中心 开通中心 合作伙伴 计费中心 结算中心 账务中心 信用中心 账单中心 策略中心 IDE开发工具 开发需求 BUG管理 版本管理 发布管理 开发流水线 企业内部应用 CRM ECS ESOP …… 对外能力提供 数据共享 电信接口 社会服务 …… IPS Docker引擎 多租户管理 资源管理 组件超市 集群管理 系统管理 服务管理 软件资产管理 业务服务 技术服务 COMFRAME CSF DADB Log4X Amber AICache 关系数据库 AMBER 规则引擎 负载均衡 负载均衡 MSG FS 弹性计算服务 大数据服务 规则中心 统一事件中心 日志处理框架 二维码 权限管理框架 消息处理中心 资源调度与编排 应用生命周期管理 技术能力服务与管理 仓库 技术组件 统一异常处理 灰度发布 热修复平台 调用连分析 日志分析 配置管理 审批管理 系统配置 Paas平台门户 运营方OP 使用方OP 提供方OP DevOps Cloud PART 01 微服务介绍 PART 02 持续集成持续构建 PART 03 Devops介绍 传统软件开发模式 移动互联网时代的特征就是快,产品的决策快、推出快、迭代快、变革快,快能抓住机遇、掌握主动。 生态变化 产品应用变化 渠道变化 商业模式变化 客户行 为变化 快 DevOps 开发 运维 QA 阶段 要求 开发 业务架构:多中心、能力开放 技术架构:SOA、微服务、技术组件标准化/服务化 QA 持续集成 自动化测试 运维 快速发布、滚动升级、灰度发布、弹性伸缩 开发、测试、生成环境的标准化 案例分析:支撑系统有2000多万行代码,代码构建一次需要40多分钟;由于各个应用之间错综复杂,在集中提交代码模式下构建发布失败率超过20%;一次产品发布需要2周以上的时间 流程 方法 工具 互联网业务的变化 需求提出 需求分析 功能设计 代码开发 测试验证 发布上线 运维监控 1-2个月长周期交付 无法及时响应需求变化 需求从提出到上线反馈时间长 1-2周短周期交付 快速响应需求变化 自动化测试保证质量 瀑布式开发 敏捷 开发 瀑布式开发和敏捷开发 业务人员 开发 测试人员 运维人员 最终用户 想法 市场 计划和需求 开发和测试 发布和部署 反馈和优化 持续业务计划和需求分析 协作式开发 持续测试 持续监控 持续发布和部署 DevOps 精益和敏捷原理 持续改进、持续反馈、持续优化 DevOps理念 基本原则 项目不停、需求不断 持续迭代、持续交付 Devops的基本定义 敏捷开发 CI/CD 自动化测试 代码扫描工具 成果展示 建立融合型的敏捷开发团队 业务 PO Master 团队 运维 提供业务需求及相关素材、负责需求澄清说明及验收确认 需求转化拆分为用户故事、面向团队代表客户进行需求跟踪 协助团队完成迭代任务、排除团队面临的障碍、确保团队遵守敏捷开发规则 根据需求实现迭代承诺并交付、完成迭代开发中的各项工程实践任务 在团队实现需求时提出运维建议并在迭代评审时进行确认 迭代启动会 迭代计划会 每日立会 迭代评审 迭代回顾 迭代开始前3天进行,评估分析可以进入迭代的需求范围,后续进行需求分析,时长1小时 迭代开始前1天进行,根据完成分析的需求进行迭代任务拆分,估算任务工作量,时长1小时 迭代中每天早上9点40分准时开始,团队成员讲述任务完成情况,时长15分钟 迭代结束后进行迭代评审,演示并验证交付的需求,展示单元测试和自动化测试结果,时长1小时 迭代评审后进行迭代回顾,总结迭代中的经验教训,确定下迭代的改进内容,时长30分钟 敏捷团队与会议 敏捷宣言的价值观(四大宣言) 个体和交互?重于?过程和工具? 工作的软件?重于?详尽的文档? 客户合作?重于?合同谈判? 响应变化?重于?遵循计划 三 种 角 色 五 大 会 议 敏捷的进度

文档评论(0)

锦绣中华 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档