DevOps云原生极简转型之道

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 极简 —— DevOps云原生转型之道 曾海剑
2. 讲师简介 多年云原生架构、微服务架构、持续交付架构 实战经验。多语言全栈开发者,热衷以码会友。 曾海剑 ee.msup.com.cn 负责持续交付平台以及云原生基础设施的架构 设计、部署实施与运营支撑,指导并支撑运营 商十多个合作商、五百多人的研发团队、八十 多个项目、两百多个微服务向DevOps云原生 成功转型。
3. 议题 DevOps云原生转型驱动力 转型之痛 极简实践 - Dory 3
4. 转型驱动力 以瀑布模式进行开发管理, 交付周期长,应变需求难, 开发返工多。 返工多 软件质量低:长期通过运 维来弥补软件质量的缺陷。 运维质量低:救火式抢通 故障。 工程质量低:熬夜式工程 割接。 质量低 研发角度 人员流失快 不同部门不同项目, 环境各自部署,维护 各自承担。 统维难 运维角度 定位难:出现故障难 于定位是研发问题还 是运维问题。 沟通成本高:研发与 运维沟通成本高。 定位难 4
5. DevOps – 解决研发痛点 研发过程核心痛点 —— 浪费、质量 人员流失 vs 价值沉淀 5
6. 容器化 – 解决运维痛点 第一代:物理机 第二代:虚拟化 第三代:容器化 统一硬件资源 统一应用运行环境 独立安装 独立部署 独立维护 应用迁移 难 需抢通抢 修 水平扩展 难 高可用难 研发与运维分工界面不清 V S 统一打包 统一部署 统一维护 应用迁移 易 水平扩展 易 内置高可 用 故障迁移 研发与运维分工界面清晰 6
7. 议题 DevOps云原生转型驱动力 转型之痛 极简实践 - Dory 7
8. 普及之痛 折腾了快一个月了, 怎么还不行? T__T 这个很简单, 这里点一下鼠标就可以了 我 满级大佬 入门 坎 精通 8
9. 人才之痛 全栈专家 工具整合难 人员要求高 沟通成本高 9
10. 踩坑历程 • 自主权交给开发人员 • 开发人员自己动手,丰衣足食 • 释放研发效能团队的接入与运维 工作量 保姆阶段 放养阶段 1 自助阶段 2 • 研发效能团队建工具链 • 开发人员自己配置流水线 3 • 开发人员提需求 • 研发效能团队配置流水线 • 把配置变成编排 • 开发人员自助编排流水线 累死研发效能团队 开发人员不懂工具链,不懂k8s。 组织培训费时费力不讨好。 10
11. 研发效能的思考 减负 增效 学习成本 沟通成本 让小白研发也能使用 配置成本 让小白运维也能维护 11
12. 议题 DevOps云原生转型驱动力 转型之痛 极简实践 - Dory 12
13. 现有方案的不足 面向人群 开源 开源 DevOps专家 DevOps专家 优点 • • 灵活 插件丰富 缺点 • • • • 灵活 专家系统 整合难度大 横向扩展难 • 灵活 • GitOps • • • • 灵活 专家系统 整合难度大 横向扩展难 开源 DevOps专家 Kubernetes专家 • 灵活 • Kubernetes深度整合 • • • • 灵活 专家系统 整合难度大 非容器对接功能不足 13
14. 设计初衷 – 极简 简化复杂的技术 简化复杂的流程 简化复杂的权限 开发团队能力参差不齐 降低接入门槛 降低调试沟通工作量 把复杂的流程原子化 面向结果 隐藏复杂的环境就绪流程 隐藏复杂的编排发布流程 通过统一接口编排能力 简化权限体系 面向多租户共用云环境 大道至简 先甜后苦 14
15. Dory – 极简上云引擎 • 面向普通研发人员 • 可快速调测 • 轻量 • 开箱即用 • 易扩展 • 可弹性伸缩 • 灵活 • GitOps • 兼容多种架构 • …… 15
16. Dory 架构 - DevOps云原生治理 • 分布式 • 弹性高 • 易扩展 • 全容器 • 多云编排 • 协同治理 16
17. 全编排能力 17
18. 流程编排 动态编排 vs 静态编排 面向异构云 多模块流水线 vs 单模块流水线 面向微服务群组 面向运维 18
19. 资源编排 异构云编排 多云编排 开发环境 晋级 应用编排 编排应用在云原生环境的启 动方式、健康检查方式、计 算资源、存储资源、网络资 源等配置 测试环境 晋级 动态应用 正式环境 19 静态应用
20. 服务编排 – 进化 n SpringCloud(微服务1.0) l 以开发方式实现服务治理 l 适用于Java语言 l 兴起于2014 l 诞生背景:虚拟化 n Istio(微服务2.0) l 以配置方式实现服务治理 l 不受语言限制 l 兴起于2018 l 诞生背景:容器化 20
21. 服务编排 – 灰度发布 n 割接 n 梯度升级 l Kubernetes原生支 持 n 蓝绿发布 l Istio服务网格支持 n 金丝雀发布 l Istio服务网格支持 n AB测试 l Istio服务网格支持 21
22. 服务编排 – 微服务群组混合发布策略 n 蓝绿发布 l 测试人员通过test域名访问测试版本 l 普通用户通过www域名访问生产版本 n AB测试 l 普通用户访问www域名,具备特定http header能够体验测试版本 l 其他用户通过www域名访问生产版本 n 金丝雀发布 l 普通用户访问www域名,服务网格分配一定比 例(例如10%)随机流量的用户能够体验测试 版本 22
23. 发布晋级 分支 流水线 环境 开发过程晋级 开发 ➤ 发布晋级 发布过程晋级 develop分支 develop流水线 开发环境 晋级 晋级 staging分支 staging流水线 晋级 晋级 release分支 晋级 测试环境 晋级 release流水线 正式环境 23
24. Dory演示 24
25. Dory的特点 简单 • 为小白研发人员量身定制 • 无需DevOps云原生专业 知识背景 轻量 • 极低的运行资源需求 • 毫秒级调度效率 • 极小的执行文件 • 支持快速部署 弹性 • 可横向伸缩 • 支持水平扩缩容 快速 开箱即用 • 项目即开即用,流水线和 环境即开即通 低成本 • 研发团队人员能力要求低 • 运维团队人员能力要求 • 运维团队人员数量要求少 25
26. Dory的特点 动态多模块 • • GitOps 一条流水线支持多个微服务 模块 • 实现基础设施即代码IaC 动态识别多个微服务模块, • 所有配置代码化版本化 每次运行流程都可以不一样 能力全 • • • 提供数百个API接口以及 覆盖各种类型环境: webhook能力,轻松与企业 kubernetes、openstack、 流程整合 vmware、hosts • 通过编排接口灵活编排适应 各种企业持续交付场景 • 开放 覆盖持续交付全生命周期各 个环节 灵活 提供丰富的插件体系 易扩展 • 执行步骤环境可以通过自定 义容器进行扩展 • 流水线步骤可以通过自定义 步骤快速扩展 26
27. Dory的效益 引入前 接入门槛 • 研发团队需要培训学习k8s与jenkins。 • 研发效能团队需要提供两周保姆式辅导培 不需要学习k8s和istio即可自己发布应用和进行灰 度发布。 • 研发效能团队提供半小时使用培训。 研发效能团队需要提供六周保姆式接入联 • 新项目接入即开即通。 调,调通流水线。 • 加入新项目代码,复制配置,十五分钟调通流水线。 • 新增微服务模块需要单独接入联调。 • 自助增加微服务模块。 • 每双周一次工程割接上线。 • 修改几行代码立刻发布到测试环境联调测试。 • 每天50次从源代码到测试环境发布。 • 研发团队无需熟悉k8s与istio,人员要求低。 接入效率 成本分析 • 训。 • 调试效率 引入后 • 研发团队需要有熟悉k8s与jenkins的专家。 • 研发效能团队0.75+0.25人,支撑80个项目,200 • 研发效能团队3人全职支撑2个项目接入。 个微服务模块,13个开发商,500人研发团队的接 入与支撑。 27
28. Dory的版本 Dory-EE 企业版(商用) Dory-CE 社区版(开源) 助力企业 DevOps云原生转型 助力小团队 DevOps云原生转型 (即将开源) Simplicity is the Future of DevOps & CloudNative 28
29. 欢迎来撩 以码会友: https://github.com/cookeem 29
30. 关注msup公众号 获取更多工程效能实践案例

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-17 05:44
浙ICP备14020137号-1 $bản đồ khách truy cập$