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

如果无法正常显示，请先停止浏览器的去广告插件。

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 基础设施监控弹性伸缩滚动更新日志中心