一、灰度发布:

注:现在我们进入了容器化时代,一般都会用容器,如:k8s,像用nginx写lua脚本或者自己开发,过时了

1.灰度发布的定义:
灰度发布是互联网产品常用的一种方式(传统行业一般不用),顾名思义灰就是介于黑与白之间的颜色,就是在黑与白之间平滑过渡的一种产品发布方式。产品发布者会根据某种规则,让一部分用户使用老系统,一部分使用新系统,在此过程中,可能将会逐步完善产品,灰度发布完成后,所有用户将使用新产品功能。

小故事:灰度发布又称为金丝雀发布。旷工在下矿洞是面临的一个重要危险是矿井中的毒气,他们想到一个办法来辨别矿井中是否有毒气,矿工们随身携带一只金丝雀下矿井,金丝雀对毒气的抵抗能力比人类要弱,在毒气环境下会先挂掉起到预警的作用。
它背后的原理是:用较小的代价试错,即使出现了严重的错误(出现了毒气),系统总体的损失也是可承受的或者是非常小的(失去了一只金丝雀)

2.灰度发布的目的:
传统行业一般用不上灰度发布,因为传统行业一般使用瀑布模式开发产品,迭代周期长,有足够的的时间测试,另外一般传统产品用户量小,也可停机部署;
而互联网产品需要快速迭代开发,又要保证质量,保证刚上线的系统,一旦出现问题很快控制局面,就需要设计一套灰度发布系统。

灰度发布的作用是,可以根据配置,将用户的流量导到新上线的系统上,来快速验证新的功能,而一旦出问题,也可以马上恢复。

iOS App发布灰度 灰度发布技术_灰度


3.灰度发布的系统架构:

a.微服务时代:通过动态路由实现 反向代理层与网关都可以做灰度发布

配置中心配置不同的灰度发布配置,请求过来的时候,进入网关,网关去获取配置中心的灰度配置策略,然后将流量打到新旧系统。

iOS App发布灰度 灰度发布技术_iOS App发布灰度_02


b.容器时代:网关无需配置 ingress是一种规则,ingress-nginx,可以可视化配置,性能很高,不需要自己再写规则。

硬负载:F5,redware
软负载:lvs、nginx、haproxy、(公有云:SLB(soft LB))、(k8s(ingress-nginx))
网关:gateway、zuul、kong

注:不是所有的系统都适合灰度发布,如果涉及数据,还需要将数据恢复
4.灰度发布协议设置:
根据自己的业务设计就可;如利用uid、token、IP、tag等;
举例:
Nginx:Lua扩展Nginx实现灰度策略转发;本地部署Agent,接受服务配置管理平台下发的灰度策略,更新nginx配置,优雅重启nginx服务。
网关层:集成配置管理平台客户端SDK,接收服务配置管理平台下发的灰度策略。

下游服务新版服务注册到注册中心,通过版本号控制是否开启。

4.1场景一:不涉及数据

iOS App发布灰度 灰度发布技术_iOS App发布灰度_03


4.2场景二:涉及数据,灰度产生的数据也是真实数据,不可轻易删除

策略:新旧库分离,双写,

  • 灰度发布前的准备:将旧数据复制到新库,同步数据时,用MQ缓存中断写入请求
  • 灰度发布时,双写新旧DB
  • 灰度发布完成,去掉双写,只写新DB

4.3场景三:APP发布

iOS App发布灰度 灰度发布技术_运维_04

二、原生K8S策略-蓝绿测试

蓝绿测试:直接切换服务;

优点:简单粗暴,可进可退,不行就再切回来

缺点:直接切服务,所有的流量都过来的,绿是否能扛得住

iOS App发布灰度 灰度发布技术_灰度_05

三、原生K8S策略-灰度发布

iOS App发布灰度 灰度发布技术_压力测试_06

四、Ingress-Nginx策略:

iOS App发布灰度 灰度发布技术_压力测试_07

五、容器云灰度发布-Ingress:

iOS App发布灰度 灰度发布技术_压测_08

六、ServiceMesh策略:

iOS App发布灰度 灰度发布技术_iOS App发布灰度_09

七、全链路压测:(利用影子表)

1.定义:
基于线上的真实环境和实际业务场景,通过模拟海量数据的用户请求,来对整个系统链路进行压力测试。
2压测目的:找问题,测极限

  • 验证新上线功能的稳定性
  • 验证峰值流量下服务的稳定性与伸缩性
  • 对线上服务进行更准确的容量评估
  • 找到系统的瓶颈并针对性优化

2.压测工具:

JMeter:java写的,起来占资源

TCPCopy:比较重量级,适合微博等读多写少的场景

Apache ab:

wrk:推荐使用,轻量级,C写的

iOS App发布灰度 灰度发布技术_运维_10

3.压测方案
压测条件:

  • 为了模拟更真实的环境,压测机器与线上机器等同配置,仿照线上机器部署情况部署,同时压测一个机器上所有服务
  • 压测尽可能使用真实数据

方案一(推荐,业内常用):复用线上环境压测:
对请求打标记,压测数据利用数据库中间件写入影子表

  • 低峰期,如晚上3点
  • 读请求没关系
  • 写请求使用影子表,shardingsphere,sharding jdbc都支持影子表

方案二(一般不用):构造全套线上环境:
成本太高,一般不适用

4.全链路压测方案核心技术:

iOS App发布灰度 灰度发布技术_压力测试_11

  • 4.1压测标识的穿透:
    对于跨线程的透传:java应用使用ThreadLocal对象,ThreadLoad会为每个线程创建一个副本,用来保存线程自身的副本变量;利用InheritableThreadLocal的特性,对于父线程ThreadLoad中的变量会传递给子线程,保证压测标识的传递。
    对于跨进程(服务)的透传:存储在定长Header中,添加了压测标识的属性字段,以保证传输中始终带着测试标识;mtest字段
  • 4.2压测服务隔离: 通常在深夜低峰期进行,在低峰期隔离出一批空闲的机器进行压测,将正常的流量与测试流量在机器级别隔离,从而降低压测对服务集群带来的影响。
  • 4.3压测数据隔离: 使用影子表对数据进行隔离