微服务架构下的服务发布

参考: https://baijiahao.baidu.com/s?id=1721261469395070816&wfr=spider&for=pc
https://www.itmuch.com/work/microservice-deploy/

蓝绿发布

  • 对服务的新版本进行冗余部署, 一般新版本的机器规格和数量与旧版本保持一致, 此时只有旧版本对外提供服务, 新版本作为热备, 当服务进行版本升级时, 只需将流量全部切换到新版本即可, 旧版本作为热备, 如果上线后出现严重BUG, 只需将流量切回旧版本, 大大缩短故障恢复时间, 待新版本BUG修复完成并重新部署后, 再将旧版本流量切换到新版本
  • 蓝绿发布通过使用额外的机器资源来解决服务发布期间的不可用问题，当服务新版本出现故障时，也可以快速将流量切回旧版本
  • 优点：部署结构简单，运维方便；服务升级过程操作简单，周期短。
  • 缺点：资源冗余，需要部署两套生产环境；新版本故障影响范围大。
  • 补充: 当切换到新版本时，需要妥当处理未完成的业务和新的业务。

微服务全链路灰度解决方案 - 图1

滚动发布

  • 滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
  • 相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。
  • 这种方式也有很多缺点，例如：
    • 没有一个确定OK的环境。使用蓝绿部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。
    • 修改了现有的环境。
    • 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚。此时，脾气不好的程序猿很可能想掀桌子，因为回滚是一个痛苦，并且漫长的过程。
    • 有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。

灰度发布/金丝雀发布

  • 金丝雀发布的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。
  • 金丝雀发布的优点：按比例将流量无差别地导向新版本，新版本故障影响范围小；发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。
  • 金丝雀发布的缺点：流量无差别地导向新版本，可能会影响重要用户的体验；发布周期长。

微服务全链路灰度解决方案 - 图2

A/B测试

  • A/B 测试基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略, 只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于 Http Header 和 Cookie。
  • A/B 测试的优点：可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小；需要构建完备的监控平台，用于对比不同版本之间请求状态的差异。
  • A/B 测试的缺点：仍然存在资源冗余，因为无法准确评估请求容量；发布周期长。

微服务全链路灰度解决方案 - 图3

总结

  • 蓝绿部署：不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
  • 滚动发布：按批次停止老版本实例，启动新版本实例。
  • 灰度发布/金丝雀部署：不停止老版本，额外搞一套新版本，常常按照用户设置路由权重，例如90%的用户维持使用老版本，10%的用户尝鲜新版本。不同版本应用共存，经常与A/B测试一起使用，用于测试选择多种方案。

全链路灰度

全链路灰度治理策略主要专注于整个调⽤链，它不关⼼链路上经过具体哪些微服务，流量控制视⻆从服务转移⾄请求链路上，仅需要少量的治理规则即可构建出从⽹关到整个后端服务的多个流量隔离环境，有效保证了多个亲密关系的服务顺利安全发布以及服务多版本并⾏开发，进⼀步促进业务的快速发展

物理环境隔离

image.png

  • 需要为要灰度的服务搭建⼀套⽹络隔离、资源独⽴的环境，在其中部署服务的灰度版本, 同时由于与正式环境隔离, 需要冗余部署线上服务以及注册中心, 中间件等, 一般用于企业测试, 预发开发环境的搭建
  • 若机器数目过多, 会造成运维, 机器成本过大

    逻辑环境隔离

    image.png

全链路灰度的实现需要解决以下问题：
1.链路上各个组件和服务能够根据请求流量特征进⾏动态路由。
2.需要对服务下的所有节点进⾏分组，能够区分版本。
3.需要对流量进⾏灰度标识、版本标识。
4.需要识别出不同版本的灰度流量。

标签路由

image.png

节点打标

  • K8S可以在Pod模板中为节点添加标签
  • springCloud体系可以为业务容器添加标签”version=gray”的元数据

流量染色

  • 前端在发起请求时根据⽤户信息或者平台信息的不同对流量进⾏打标
  • 如果前端⽆法做到，我们也可以在微服务⽹关上对匹配特定路由规则的请求动态 添加流量标识
  • 流量在链路中流经灰度节点时，如果请求信息中不含有灰度标识，需要⾃动为其染⾊

分布式链路追踪

  • 分布式链路追踪技术对⼤型分布式系统中请求调⽤链路进⾏详细记录，核⼼思想就是通过⼀个
    全局唯⼀的 traceid 和每⼀条的 spanid 来记录请求链路所经过的节点以及请求耗时，其中
    traceid 是需要整个链路传递的。
  • 借助于分布式链路追踪思想，我们也可以传递⼀些⾃定义信息，⽐如灰度标识

image.png

逻辑环境隔离

⾸先，需要⽀持动态路由功能，对于 Spring Cloud、Dubbo 开发框架，可以对出⼝流量实现⾃定义 Filter，在该 Filter 中完成流量识别以及标签路由。同时需要借助分布式链路追踪技术完成流量标识链路传递以及流量⾃动染⾊。此外，需要引⼊⼀个中⼼化的流量治理平台，⽅便各个业务线的开发者定义⾃⼰的全链路灰度规则
image.png

RPC流量的全链路灰度方案

image.png