大规模微服务场景下灰度发布与流量染色实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 大规模微服务场景下灰度发布与流量染色实践 刘超 网易云首席架构师
2. 微服务很热,互联网公司号称他能加速业务创新 最小可行化产品原则(MVP) 业 务 微 服 务 化 以最低成本、用最快、最简明的方式建立一个可用的产 品原型,通过市场、客户反馈,发起迭代、完善产品细 节。 两个匹萨原则 如果两个披萨不足以喂饱一个项目团队,这个团队可能就显 得太大了。沟通成本随人员增加成指数级增长:n(n-1)/2 康威定律 系统设计(产品结构)等同组织形式,每个设计系统的组织, 其产生的设计等同于组织之间的沟通结构。 全开源技术栈,平滑接入 技 术 中 台 化 创业公司初期资金少,多使用开源软件搭建,后期上 云必定要同开源软件兼容 SaaS化开放平台 初创公司没有时间和力量研究复杂的产品,往往希望 产品以SaaS化的形式存在 业务中台 支付中心 账号中心 技术中台 营销中心 用户画像中心 数据中台 持续集成 APM 分布式数据库 分布式消息队列 微服务框架 API网关 大数据平台 BI平台 容器平台 分布式事务 人工智能 实时计算 不同阶段套餐式专家咨询 初创公司在不同的阶段,需要不同的产品,架构, 有规律可循,可形成一定的套餐,配合专家咨询
3. 微服务很乱,看起来很好的东西为什么用起来一团乱麻 • 服务依赖管理:服务间直接调用, 调用记录 • 服务调用统计: • 服务接口规范:环境与接口 依赖混乱 无迹可寻,调用统计与分析无从谈起 规范缺失 ,维护困难 • 服务安全管理:安全靠白名单各自为战 • 服务治理能力:大量 重复代码 • 服务接口测试:拆分过程中接口 实现路由,分流,熔断,降级 行为不一致 ,隐藏Bug • 服务灰度发布:上线功能实现灰度借助 别人家的微服务 • 服务压力测试:对于峰值压力 无历史数据 ,靠运气 • 服务调用链分析:当服务请求缓慢, • 测试环境治理:测试 大量if-else 难以定位 问题点 环境多,难管理 ,不可能100个容器每组一套 我们家的微服务
4. 微服务有很多误解 不仅是服务拆分,而是有十二个要点 绝不是一个运动式的过程,应采用渐进模式 不仅仅是个技术问题,IT架构,应用架构,组织架构改变
5. 网易微服务和DevOps实践历程 1.手工化 3.工具化 5.DevOps 2.脚本化 4.平台化
6. 网易微服务和DevOps实践历程 手工化 单体应用 应用层: • 多为单体应用,应用数目少 开发写代码 物理机 运维管理资源负责部署 物理网络 资源层: • 应用和数据库多为物理机部署 • 应用直接使用物理网络 • 数据库使用Oracle 发布模式: • 开发运维隔离严重 • 发布处于手工化阶段 存在问题: • 资源申请慢,粒度不灵活 • 资源复用难,进程相互影响 • 上线依赖于人,部署风险高
7. 网易微服务和DevOps实践历程 脚本化 应用层: • 单体应用增多,成为烟囱 单体 应用 单体 应用 物理机 (Oracle) 单体 应用 单体 应用 单体 应用 开发写代码 虚拟化(Vmware) 物理机 物理网络 物理机 运维管理资源 负责部署 资源层: • 数据库继续使用Oracle,物理机部署 • 应用使用虚拟化Vwmare进行部署 • 直接使用物理网络 发布模式: • 虚拟化使得资源点即可得,粒度灵活,复用灵活,隔离性好 • 运维开始感受到压力,通过批量脚本解放人力 • 发布处于脚本化阶段 存在问题: • 发布脚本复杂逻辑不好实现 • 发布脚本多样,不成体系,难以维护 • 虚拟机依赖人工调度(Excel),共享存储限制规模 • 高可用依赖底层FT,HA,DR机制,无法区分业务优先级 • 网络,虚拟化,存储等基础设施无抽象化概念,复杂度高,全面 依赖运维,大量审批
8. 网易微服务和DevOps实践历程 引入服务化架构: 工程拆分 --> 服务拆分 服务统一注册、发现 业务日渐复杂,版本更新迭代遭遇瓶颈 服务治理平台——密密麻麻的调用关系 RPC透明封装
9. 网易微服务和DevOps实践历程 引入服务化架构后直接产生的一些问题与对策: 问题 对策 服务雪崩 (Failure Cascading) Bulkheading (Thread Pool、Queue) /Fail Fast 大量请求堆积、故障恢复慢 引入熔断机制 内网负载均衡维护代价较大,引起较多抖动问题 引入软负载均衡
10. 网易微服务和DevOps实践历程 前面问题开始暴露,并引入一些新问题: 服务器资源分配困难,服务器机型碎片化 一台服务器上多个进程互相影响、QoS难以保障 测试、开发环境数量大增,环境管理、部署更新困难 应用层服务数目增多 激活 云原生怪圈 资源层申请速度灵活 压力
11. 网易微服务和DevOps实践历程 云计算带来的改变,统一接口,抽象概念,租户自助 API网关 服务 注册 中心 业务服务层 共享服务层 服务 治理 平台 分布式缓存 消息 队列 分布式数据库 基于虚拟机PaaS中间件 配 置 中 心 日 志 中 心 基于 虚拟 机镜 像的 弹性 伸缩 测 试 平 台 基于虚拟机镜像的运行环境 云平台 OpenStack 物理机 (Oracle) 虚拟化(Vmware) 物理机 物理机 KVM 物理机 虚拟网络 物理机 • OpenStack实现接口统一,大部分部署工具支持其接口, 可基于开源工具实现发布的工具化和平台化 SDN 发 布 平 台 全 链 路 监 控 平 台 • Flavor抽象资源配比(4G 8G 计算优化型,网络优化型, 存储优化型),统一硬件配置,提升利用率,硬件上线 效率提升 • 自动调度代替人工调度,区域可用区抽象对机房机架交 换机的感知 • 云提供租户概念,有账号子账号体系,有quota,可以让 租户在管理员许可的范围内自助操作,加快环境部署速 度 • VPC屏蔽物理网络复杂性,冲突问题和安全问题,使得 租户可自行配置网络 • 基于虚拟机分层镜像发布和回滚机制,构建发布平台, 可实现大规模批量部署和弹性伸缩 • 基于虚拟机的PaaS托管中间件,简化租户创建,运维, 调优中间件的难度 物理网络 • 发布平台提供基于虚拟机镜像+PaaS中间件的统一编排 • 要求业务对于高可用性设计要在应用层完成 旧组件 升级组件 新组件
12. 网易微服务和DevOps实践历程 微服务框架与开源技术栈统一 将服务治理逻辑抽离、以无侵入方式实现、支持Spring Cloud、Dubbo等开源技术栈 打造CI/CD服务 基于Jenkins,衔接云计算环境、支持通过Agent部署软件包 抽象出产品、环境等多级概念,匹配实际研发情境
13. 统一微服务框架之前 业务代码 注册发现 Eureka Eureka 业务代码 业务代码 业务代码 注册发现 注册发现 注册发现 路由分流 路由分流 熔断降级 熔断降级 配置中心 配置中心 认证鉴权 认证鉴权 监控统计 监控统计 • 功能全部需要自己开发,在业务代码之外开发量大 • 配置和代码逻辑散落在各个工程 • 每增加一个功能,需要所有的业务重新发布上线。 服务发现(Eureka) 错误容忍(Hystrix) 负载均衡(Ribbon)增强示例
14. 统一微服务框架之后 业务代码 NSF Agent Agent 注册发现 注册发现 路由分流 路由分流 熔断降级 熔断降级 配置中心 配置中心 认证鉴权 认证鉴权 监控统计 监控统计 业务代码 -javaagent:/home/nsf-agent/nsf-agent.jar 统一界面 • 功能全部集中在agent中,开发仅需关注业务代码 • 配置在界面统一操作 • 增加或者删除功能,可通过界面配置实时更新
15. 微服务治理整体架构 多环境支持 后端服务发现 认证鉴权 大幅减少重复框架代码 统一组件版本配置 多语言支持 服务治理 熔断、降级 流量控制 多数据面接入 服务注册 服务发现 租户隔离性
16. 解决了哪些问题? 应用减负:通过Agent 和Sidecar 技术,对应用无成本增强 开发减负:以微服务治理框架为设计目标,大幅减少重复框架代码,避免 重复造轮子; 版本控制:统一组件版本配置,避免隐性问题 兼容性:兼容的HTTP、RPC调用。兼容非java应用 服务治理:根据业务线场景选择治理支持方法级别治理粒度 高性能:更低的性能损耗,并提供更细粒度的服务治理;
17. 网易发布平台NDP ⚫ Netease Deploy Platform ⚫ 分布式架构 ⚫ 功能: • 配置: 注册集群、自定义配置 • 构建: 标准或自定义构建 • 发布:一键发布、分批发布 • 支持应用状态、日志及历史查看 ⚫ 提供服务化 API
18. 网易发布平台NDP 1.7 w + 实例个数 10 w + 构建次数 50 w + 发布次数
19. 网易微服务和DevOps实践历程 新问题与对策: 问题 对策 排障复杂度高,传统监控服务无法满足需求 引入全链路跟踪服务 全链路跟踪服务与日志服务依据ID进行联系,以发现故障点上下文 近期支持OpenTracing 标准 难以进行演练、故障频出 引入故障注入服务 API版本混乱 一组服务通过API网关暴露服务 引入API管理、测试平台 自动Client SDK生成
20. 网易微服务和DevOps实践历程 新问题与对策: 问题 对策 CD服务模版管理混乱, 模版适用的镜像环境基准难以强制, 出现上千个无法重用的模版 2015年起拥抱容器标准 服务器生命周期管理复杂, 服务器下线或转移流程冗长 零散实现Auto Scaling 2015年拥抱Kubernetes标准 分布式事务支持方式多样 实现TCC中间件、事务消息队列等设施
21. 网易微服务和DevOps实践历程 服务 注册 中心 API网关 业务服务层 共享服务层 服务 治理 平台 分布式缓存 分布式数据库 消息 队列 配 置 中 心 基于 虚拟 机镜 像的 弹性 伸缩 日 志 中 心 测 试 平 台 基于容器镜像的运行环境 基于虚拟 机镜像的 运行环境 基于虚拟 机PaaS中 间件 Vmware 虚拟机 KVM虚拟 机 虚拟化(Vmware) 物理机 服 务 网 格 分 布 式 事 务 故 障 注 入 基于Git 的容器编 排,不可 改变基础 设施 基于容器的PaaS中间件 发 布 平 台 容器平台 Kubernetes KVM虚拟 机 云平台 OpenStack 物理机 (Oracle) 基于 容镜 像的 弹性 伸缩 物理机 虚拟网络 物理网络 物理机 OpenStack Ironic物理机发放 SDN KVM 物理机 物理机 物理机 公有 云 全 链 路 监 控 平 台
22. 环境交付提前,Dev和Ops的融合 Dev 开发,构建,测试 微服务 服务发现,配置中心,熔断降级 Kubernetes + Docker 容器化 Dockerfile,镜像环境交付 提供资源,部署,运维 OPs
23. 分层的镜像架构模型,帮助开发上手容器 应用功能 webapp, web-assets, git2consul, … 应用环境 jdk, consul, dumb-init, consul- template, node, nginx… OS和系统工具 debian
24. 一切皆代码,不可改变基础设施 • 代码是代码,配置是代码,单实例 运行环境Dockerfile是代码,多实 例运行环境编排文件是代码 • 提供标准化的构建 • 支持动态资源申请 • 支持资源编排部署 • 采用声明式风格 • 追踪变更,支持计划和审查 • 支持应用编排 • 支持模块化开发,可重用 • 避免繁琐的手工操作 monitor AUTOMATION SUPPORT DEPLOY edit job state review confirm merge components, editor / tool create sync GIT diff update trigger runner runner IaC engine (desired state) instance1 type: 4 cpu 8G memory CHANGE MGMT instance2 type: 4 cpu 8G memory env: online profile=common tomcat: 8.0 web-app: xxxx:xxxx:v1.2.3 provision instance3 present: no ARTIFACTS CD pipeline docker image configure vm instance1 openapi vm instance3 vm instance2 maven package CI baseline state vm image CLOUD RESOURCES DEV / CI K8S as a Service
25. 持续交付流水线 自动构建 自动部署 online-A pre online-B 确认/按需部署 NOS/镜像仓库 perf, … • 基于 GitFlow 协作流程 • 按需自动化构建及部署 • 完成持续交付系列流程 • 提供更通用的 Open API NOS/镜像仓库 release develop
26. 容器化带来的问题 服务规模越来越多,增加速度越来越快。 业务线展开后,需求迭代的速度越来越快。 对测试环境的需求指数性增加 应用层服务数目增多 激活 云原生怪圈 资源层申请速度灵活 压力
27. API网关的灰度发布和流量染色能力 API网关 (流量接入层) 路由 路由 插件 分流 流量 镜像 新上服务 定时开关 新上线 服务 99% 线上系 统A 维护 开关 API监 控 灰度发布 A/B测试 1% 认证 鉴权 治理 文档 报表 流量镜像 测试预发 线上系 统B 预发环 境
28. NSF服务治理平台的灰度发布和流量染色能力 微服务框架 (服务治理) 服务 目录 注册 发现 限流 熔断 降级 容错 路由 负载 均衡 参数 分流 拓扑 依赖 配置 中心 服务 监控 服务 告警 认证 鉴权 统计 概览 知识 库 服务 告警 监控 大屏 账户 审计 • 参数分流,可针对 Cookie、HTTP Header 或 Query String 的参数进 行正则表达式匹配分流 • 染⾊指链路⼊⼝服务对特定的请求进 ⾏染⾊,为请求带上特殊标识,如 header, query string等额外信息。 • 传递是⾮⼊⼝服务的⼯作,它们将链 路上游请求中的额外信息抽出,加 ⼊⾄下游请求中。
29. 基于流量染色的测试环境管理,仅需部署增量服务 1、整个测试环境共享一套基准环境,部署所有应用。 2、API网关层进行流量染色。 3、NSF Agent携带染色消息,并且染色在调用链上持续传递(小环境调用到基准环境后,还能路由回到小环境),按照同环 境优先的策略进行路由和消费。 4、若分支环境缺失相关应用,则路由到基准环境或择由基准换消费。
30. 流量染色效果 ⚫ ⚫ ⚫ ⚫ ⚫ 每个环境只需要部署修改了代码的应用(显著降低部署成本) 从客户端看来,每个小环境都能提供完整的功能(避免功能不全的干扰) 修改的逻辑在小环境中可以得到验证(便于验证,联调) 小环境之间彼此独立(隔离)。 环境合并和代码合并逻辑一致,统一在发布平台管理,谁后合并谁负责Merge
31. 基于流量染色的灰度发布
32. 基于流量染色的灰度发布 初始化预发环境和小流量环境 开启引流,进入持续发布周期 代码发布到预发环境进行回归, 预发环境为单节点部署 预发通过后发布到小流量环境,小 流量环境三节点部署,滚动发布 小流量环境,开发测试及时跟进, 观察异常情况,一旦碰到问题,第 一时间关闭流量入口。相关问题定 位debug可以在预发环境上进行。 所有发布到小流量环境的版本合集, 通过一个晚高峰的检测后,发布到 线上环境。
33. 全栈多环境多机房流量染色方案 总-分-总模型 负载均衡 API网关 跨机房流量分发统一管理 跨机房服务统一管理与治理 NSF 服务 治理 A A B APM 性能 管理 API网关 B B 当一个机房实例全挂时,实现 跨机房调用的流量染色 C C A NSF 服务 治理 C APM 性能 管理 应用层统一视图 Kubernetes集群 Kubernetes集群 多Kubernetes统一管理 统一发布平台 第一个总:统一发布平台对 接统一的多K8s管理平台, 有统一的灰度发布策略。 第二个分,多数据中心 kubernetes应分开部署的, 不建议一套Kubernetes跨多 个机房,但要保持网络连通 性。 第三个总,应用虽部署在多 数据中心的多个Kubernetes 中,但应使用统一服务治理 中心,形成统一的视图,可 通过染色识别当前的 kubernetes即可 同机房可部署多套 Kubernetes实现A/B测试, 也可应对Kubernetes的升级 风险问题
34. 云原生架构的一栈式工具链 CICD (开发流程管理) API网关 (流量接入层) 流水线管理 代 码 检 出 代 码 编 译 集 成 测 试 路由 镜 像 构 建 自 动 部 署 场景 用例 执行集 定时 执行 接口 Mock 覆盖率 历史 管理 批量 导入 接口 监控 单接口 用例 分流 流量 镜像 维护 开关 API监 控 认证 鉴权 治理 文档 报表 NSF (微服务框架 ) 开 发 集 群 GoAPI (测试平台) 路由 插件 测 试 集 群 服务 目录 注册 发现 限流 熔断 降级 容错 路由 负载 均衡 参数 分流 拓扑 依赖 配置 中心 服务 监控 服务 告警 认证 鉴权 统计 概览 知识 库 服务 告警 监控 大屏 账户 审计 数据库 事务 中间件 事务 多框架 支持 数据库 监控 性能 告警 自定义 数据 GTXS (分布式事务) 事务 补偿 TCC 事务 消息 事务 协调 统一 接入 低侵入 APM (应用性能监控) 运行时 拓扑 性能监 控 服务筛 选 调用链 调用栈 JVM 监控 NCE (容器平台 ) Pod & Deployment 网络 Calico, OVS 存储 Ceph 基础设施监控 弹性伸缩 滚动更新 日志中心

ホーム - Wiki
Copyright © 2011-2024 iteam. Current version is 2.139.0. UTC+08:00, 2024-12-28 10:42
浙ICP备14020137号-1 $お客様$