文字内容
1. DevOps下的架构思考 DevCloud高级架构师 何代义
4. DevOps,软件工程在敏捷思想的发展与演进 DevOps Continuous Delivery Continuous Integration Agile Development 拥抱变化 快速迭代 强调开发人员提交了新代码之后, 立刻自动的进行构建、(单元)测 试。根据测试结果,确定新代码和 原有代码能否正确地集成在一起; 重视自动化测试验证结果,对可能 出现的一些问题进行预警,以保障 最终合并的代码没有问题; 在持续集成的基础上,将集成后的代 码部署到更贴近真实运行环境的(如 类生产环境)中。交付给质量团队或 者用户,以供评审。如果评审通过, 代码就进入生产阶段。 持续交付并不是指软件每一个改动都 要尽快部署到产品环境中,它指的是 任何代码修改都可以在任何时候实施 部署。手动部署,有部署的能力,但 不一定部署。 持续部署则是部署活动是自动的,是 持续交付的最高阶段 促进研发(应用程序/软件工程)、 技术运营(运维)部门之间的沟通、 协作与整合,持续交付可靠的软件 产品和服务。通过快速反馈提升用 户体验和研发效率。 DevOps是以业务驱动的软件交付方 法。从需求到交付生产环境,研发 与运维间紧密协的文化运动与实践。 DevOps文化更注重沟通,快速获得 用户反馈提升创新能力。 需求 BAC KLO G 研发 构建 评估 改进 团队协作 可交付产品 运维 REL EAS E
5. 互 动 支持DevOps,架构及架构延展角度需要考虑什么问题? 3
6. 可DevOps单元 架构类型 拆分可DevOps单元 单元的架构属性思考 单元的自治性 架构问题 改造路径探索 术业有专攻 资源、中间件:云化平台能力 研发过程:DevOps工具链和环境 运维能力:DevOps运维平台 4
7. 1.1 适合DevOps商业敏捷的架构模式 5
8. 1.2 系统拆分为颗粒度合适的可DevOps的单元,是架构支持DevOps 的基础 尽量垂直划分服务; 比较独立的新业务优先采 用微服务架构; 优先抽象通用服务; 优先抽象比较容易识别的, 边界比较明显的服务; 优先抽象核心服务; 采用绞杀者模式。 WEB UI WEB UI WEB UI MQ 负载均衡 负载均衡 MQ 负载均衡 缓存 缓存 后端服务 后端服务 DB 单点登录 后端服务 单点登录 DB DB table2 table1 WEB UI WEB UI MQ MQ API GATEWAY API GATEWAY 缓存 详情页 老系统 订单 库存 购物车 DB DB DB DB 6 CACHE 下单 老系统 订单 库存 价格 DB DB DB DB
9. 1.3.可靠性、性能、可扩展性、安全性、隐私性等问题的新思想 可靠性:数据的可靠性、服务的可靠性,故障下如何恢复,服务的自愈等; 性能:基于公共底座的性能如何设计?数据的I/O、状态信息的存储、依赖服务的性能? 可扩展性:数据的扩展性、状态缓存的可扩展性、服务的可扩展性; 安全性:访问安全、服务安全、数据安全 隐私性:用户数据隔离、用户数据脱敏 7
10. 1.4 DevOps单元应实现自服务 服务可被其他应用或开发者自助发现,自助按需获取,自助使用并计量, 自助服务管理。 自服务的前提是高度自治 发现 从易用性的角度,暴露友好的交互方式(Web界面、 管理 获取 服务 命令行、SDK…), 使能应用或开发者简单、高效的使用其提供的功能 8 使用 计量
11. 1.5 传统软件改造为可DevOps的软件方法:Phase-Driven Approach 新老架构并存 开闭原则 持续演进 9 云服务优先 善用模式
12. 1.6 可DevOps迁移路径参考案例分享 2 迁 移 前 架 构 3 新增功能基于云端 数据与业务解耦 应用Strangler模式逐 云服务优先:RDS 步演进老系统 MySQL替换数据中心 数据异步同步 的Oracle 1 云、数据中心 版本灰度并存 智能路由 云端代理 10
13. 2.1 软件分层、专业聚焦,平台化,避免小团队全栈能力构建,使能 DevOps 充分使用云基础设施和平台服务(IaaS/PaaS),基于IaaS/PaaS动态分配资源。 业务服务 业务服务 。。。 aPaaS 资源编排和调度 弹性计算 ECS、AS、ELB 弹性网络 VPC… 分布式 消息队列 分布式 缓存 弹性存储 EVS、OBS… 分工细化,专业团队提供专业云服务 自治云服务承载架构复杂度 11 数据库 镜像 安全 监控 … 1. 依赖资源的动态编 排和调度服务 2. 通过接口使用服务, 而不是自己构建
14. 2.2 工具链及环境:支持服务/微服务DevOps的工具链及环境 支持微服务DevOps独立并行开发、测试,经过Gamma类生产环境验证,实现灰度发 布和频繁快速上线,并持续反馈与演进。 过程 需求 设计&开发&测试 发布 生产环境 微服务流水线1 Build Alpha Beta 微服务流水线2 Alpha Beta Gamma … … Build … Source … 需求 分析 Source … 关键 活动 Gamma 网上质量和用量数据实时反馈回研发 12 自动化监控 自动化 发布评审 灰度发布 分析反馈 自运营云服务
15. 2.3 自动化运维-基于数据分析的全方位故障监控 系统能够自动化部署、升级和扩缩容,支持自动化监控、告警、故障的定界定位和故障自愈。 业务/服务的颗粒度更小,交付部署 更频繁。迫切需要增强对服务、服 务所部署的软硬件环境的全方位监 控、评估能力;构建针对各类日志 、KPI数据、告警事件等的数据采集 分析平台。 13
16. 支持DevOps的服务化架构实践:小批量持续发布 将大任务分解为可以迅速完成的较小任务,以服务化/微服务架构模式进行敏捷交付 ,细粒度持续向生产环境发布。 服务内部高内聚,小批量频持续发布 服务之间松耦合,并行开发独立部署 过 去 现 在 需求 上线 设计 设计 部署 发布 开发 上线 设计 部署 开发 测试 发布 测试 上线 部署 设计 部署 开发 测试 发布 上线发布 上线 设计 部署 开发 测试 发布 开发 测试 Google交付模式案例 微服务间可并行开发独立部署和发布,在服务内部将特性分 解为细粒度的任务,实现特性高质量持续发布,快速获取用 户反馈并持续改进。 14
17. 支持DevOps的服务化架构实践:自动化部署 自动化部署:以完全一致的方式自动化地将应用或服务部署到Dev、SDV、SIT、类生产、 生产等各个环境, 并对部署进行自动化验证。 一次打包,随处部署 在环境变量中保存配置信息,避免放在源码或配 置文件中。 禁止手动修应用配置 区分不同生命周期的运行环境,包括创建、发布、 运行,要相互隔离,避免配置不一致。 让最快的测试先失败 根据环境复杂程度和自动化测试时间,环境逐步 接近生产环境,逐步增加发布信心。 15