复杂系统灰度发布工程效率实践 汪洪恩
2020-03-01 215浏览
- 1.复杂系统灰度发布 汪洪恩 顺丰科技资深架构师 工程效率探索
- 2.自我介绍
- 3.自我介绍 科技改变物流，物流改变生活 业务模式快速迭代演进 汪洪恩 微信 wanghongen
- 4.目录 01 当我们谈灰度时我们谈什么 02 灰度实施关键 03 应用灰度之外 04 精益工程效率
- 5.当我们谈灰度时我们谈什么 什么是灰度发布 灰度 = 金丝雀？ 灰度 = 金丝雀到全量升级的中间阶段？ 灰度 = A/B测试？
- 6.分析差异找准定位 技术手段按应用和运维分层考虑 A/B测试 运维能力层 灰度看作模式之上的综合解决方案 应用能力层 定位 特性开关 灰度 蓝绿 金丝雀 滚动
- 7.目标 目标是什么 • 提高可用性？ • 影响可控？ 提高发版效率？ 新特性低成本试错？ 可用性目标 – 远景 • 版本质量、服务保障、发布方式都影响可用性。 拆解合适的目标 – 现实 • 发布影响可控 • 持续提升交付的工程效率 胸怀远景目标，适应现实环境 利用技术手段解决实施中的问题。
- 8.可控 模式 分组+分流控制 粒度&边界 确定单服务、项目域内、跨项目域的处理规则 阶段 分组、分流、完善持续交付（简化、加速、可度量）
- 9.持续交付优化的决策点 不同的持续交付实现，类似的决策点 测试管理 环境管理 01 配置管理 分支策略 依赖管理 回滚策略 分库策略 团队协作 静态检查 生命周期 环境自描述 自动化测试 快速搭建 Mock与回放 容器技术 混沌测试 02 移动端交付 03 构建集成 04 构建规范 构建资源弹性 镜像的空间及效率 流水线 效率 05 发布及监控 发布 Immutable 监控 06
- 10.效率 持续提升环境的一致性 dev sit uat/prod dev sit 持续降低部署一套环境的开销 • 多环境、多用途，低成本灵活部署，提高协作效率 DEV SIT DEV-A SIT-A UAT UAT-A PROD PROD-A PROD-B uat/prod
- 11.小结 01 灰度发布，基础模式之上的综合解决方案 • 定位 • 目标 可用性远景，聚焦影响受控和工程效率提升 • 可控 • 效率
- 12.复杂系统实施灰度的关键 实施灰度，关键问题有哪些 特别是不同技术栈，混合技术栈的情况下 发布模式、分组&分流
- 13.发布模式回顾&选型策略 0% 100% 分组是控制基础，分流逐步升级 5% 95% 项目特点决定基础模式选型 •架构简单，规模庞大，优选金丝雀型 •架构复杂，规模不大，优选蓝绿型 •规模的权重更大 •常需基础模式的灵活运用
- 14.服务发现模式 Registry DNS Server 1 … Server n Client Client LB Proxy 服务发现模式 Registry HOST LB Client Server 1 … Server n • 集中代理 • 嵌入式LB • SideCar式LB 现实情况通常是一种混合 Server 1 … Server n
- 15.分组+分流的主线 NS Client Server 1 … Server n LB 客 户 端 元 数 据 组 id 终端类型 分组 规则 版本… 版本 机房… 服 务 端 元 数 据 组 按需选取元数据和规则 •客户端、服务端给出元数据组； •基于设定的规则进行路由，完成平滑升级，多活等多种需求
- 16.应用分组 Group A Service 1 V1.0 Service 2 V1.0 Project A Project B Config Group B Service 1 V2.0 Service 2 V2.0 分组便于对流量做精确控制 •选择合适的粒度 •组内默认方式分流，组间做精准分流控制 分组也是资源隔离的基础 •资源隔离的一个关键点是配置的隔离 •分组关联的资源，归于绑定的配置集中 分组技术手段多样，常需混用
- 17.分流模式 – 组内默认 Group A Server 1 … Server n Client 利用服务发现原生能力组内流控 Group=“A” 多用于后端服务间调用的场景 •同一项目域内 Registry 有利工程效率，优选 Group=“B” Group B Client Server n+1 … Server n+m •只需关注目标分组，不需关注流控细节 •分组信息部署决定，应用自身不需过多关注
- 18.分流模式 – 动态规则 Group A Client Server 1 … Server n city=“shenzhen” 基于业务语义路由 •携带信息方式，如：HEADER、 parameters、cookies •预置路由配置，各阶段动态启用不同配置。 前端/移动端请求场景 Registry •前端/移动端有决定灰度范围的语义信息 city=“shanghai” Group B Client Server n+1 … Server n+m 跨项目域场景
- 19.小结 02 基础发布模式的选型 两组元数据加规则是主线 分组的目的 • 决定了分流控制的粒度； • 明确了资源隔离的粒度。 两种分流控制模式 • 尽量用组内默认模式； • 阶段和范围的控制，也是重要决策点
- 20.应用灰度之外 解决衍生问题，工程实施落地 • 工程实施还需解决的典型衍生问题，如： ü 跨版本服务间的一致性 ü 中间件的配合 ü 前端/移动端协同 • 下面结合案例讨论可行的策略。
- 21.v1 业务 一致性 Group A 示例场景：配送网络、网络游戏 事务1 1 1 事务2 2 v2 3 4 2 Service1 v1 2 Service2 v1 3 业务优先在组内完成 Service1 V1 Group B 否则结合分流策略及兼容处理来解决 业务1 业务2 1 2 2 3 Service1 V1 Service2 V1 Service2 V2 4 Service1 v2 4 Service2 v2
- 22.灰度范围选择策略 子域能业务闭环 • 取一个或若干个子域作为灰度范围 子域不能业务闭环 • 优先考虑虚拟一组数据结构做灰度； • 否则，需重点考虑兼容性处理。
- 23.Group A TopicA 中间件 Topic kafka为例，存在需分发到特定分组的场景 Group A 两种模式 Group B • 生产方Topic唯一，消费方负责分发，不同分组有独立 的Topic - 项目域间 • 不同分组使用独立的Topic进行隔离 - 项目域内 Group B Dispatcher TopicB TopicA TopicB 分发系统 分发方式演进 独立的分发系统 借助实时计算平台实现 业务逻辑中处理 在应用内部处理 Kafka streams 利用MQ自身集成的实 时计算能力
- 24.中间件 Redis为例，分布式缓存默认数据共享 • 数据结构不兼容时，才考虑例外处理 Config DEV DEV-A SIT SIT-A 分布式配置中心 • 部署时指定分组，分组对应配置，配置对应相关资 源，应用自身不需关心资源差异； • 分组是在环境之上虚拟的边界，部署时基于少数变 量即可正确运行。 UAT UAT-A PROD PROD-A PROD-B
- 25.前端协同 前端灰度可以是自主升级或指定范围推送 • 注意和后台服务灰度的协同，根据业务需要选择合适的方式 静态资源需采用合适的“版本控制策略”做控制 • 比如更新虚拟静态资源名强制刷新，虚拟静态资源根据灰度策略指向实际地址； • 对于前端，还需合适的 “有效期策略”、“CDN缓存策略” 移动端灰度要考虑移动发布平台的利用
- 26.兼容性 JSON作为DTO的接口 存储 • 字段（KV对）只增不改； • 至少向前兼容一个版本，不再使用的标记 deprecated ，定期清理； • 变化频繁，紧耦合的一组字段用JSON存； • 变更较大时，单做升级方案处理； 计划变更字段 计划变更字段 V1 Json V2 Json K1，V1 K1，V1 新增字段 … … Kn，Vn Kn，Vn 列名1 新增字段 列名2 列名3 Add Update Kn+1， Vn+1 列名1 列名2 列名3 列名4
- 27.可测试性 设定预发验证场景并准备数据 • 业务数据：虚拟 > 可闭环子域 > 不可闭环 • 场景覆盖主业务流程 持续提高测试自动化程度和效率 • 必要时对验证数据进行标记 真实 虚拟
- 28.小结 03 中间件也需明确分组&分流策略 一致性&灰度范围选取策略 • 识别一致性问题，并遵从策略解决； • 灰度范围，首先基于业务需要，复杂场景需考虑选取策略 前端协同 • 前端/移动端，关注发布协同 兼容性、可测试性 • 关注更高的兼容性要求； • 设计阶段就考虑可测试性，并持续探索优化
- 29.持续提升工程效率 兼顾交付效率和影响可控 • 高效的工具链是提升工程效率的基础； • 在持续交付之中考虑如何平衡
- 30.整合灰度发布 Build Serving Eventing 集成灰度发布能力 • K8s上基于CRD、Operator基础框架 • 对灰度发布的资源和流程进行整合 • 简化上层使用的复杂度。 参考右图Knative的思路 K8s Service v1 K8s Deployment v1 Knative KPA v1 K8s Service v2 Knative Deployment v2 Knative KPA v2 Istio Virtual Service Knative Service
- 31.声明式发布定义 声明式integration定义 声明式软件包定义 声明式部署定义 DSL 应用框架 Camel-K TEKTON buildkit 云原生的持续部署 云化的基础架构
- 32.兼顾交付效率和影响可控 关键是发布粒度 • 满足兼容性约束时，各服务可 以独立的交付节奏进行细粒度 的灰度发布； • 需协同发布时，支持多服务整 体做灰度发布 单 服 务 系 统 整 体
- 33.小结 04 资源和流程的封装+声明式部署定义，简化操作 • 云化基础架构之上，基本的部署和运维操作有大幅简化； • 即使更复杂的发布策略，经过封装，也能简化上层操作。 兼顾效率和可控，在于发布粒度可灵活调整 • 还可明确预发、灰度、全量各阶段，细化其中操作，并持续探索优化
- 34.One more thing 𝒇 𝝎 =𝐹 𝒇 t = ( ∫'( 𝒇 '*+, dt t e
- 35.
- 36.
