灰度发布系统架构设计

标签: 灰度 系统架构 设计 | 发表时间:2021-04-20 06:20 | 作者:PHP开源社区
出处:https://juejin.cn/tag/%E6%9E%B6%E6%9E%84

灰度发布的定义

互联网产品需要快速迭代开发上线,又要保证质量,保证刚上线的系统,一旦出现问题可以很快控制影响面,就需要设计一套灰度发布系统。

灰度发布系统的作用,可以根据配置,将用户的流量导到新上线的系统上,来快速验证新的功能,而一旦出现问题,也可以马上的修复,简单的说,就是一套A/B Test系统。

灰度发布允许带着bug上线,只要bug不是致命的,当然这个bug是不知道的情况下,如果知道就要很快的改掉

简单灰度发布系统的设计

灰度简单架构如上图所示,其中的必要组件如下:

1、策略的配置平台,存放灰度的策略

2、灰度功能的执行程序

3、注册中心,注册的服务携带ip/Port/name/version

有了上面三个组件,才算一个完整的灰度平台

灰度的策略

灰度必须要有灰度策略,灰度策略常见的方式有以下几种

1、基于Request Header进行流量切分

2、基于Cookie进行流量切分

3、基于请求参数进行流量切分

举例:根据请求中携带的用户uid进行取模,灰度的范围是百分之一,那么uid取模的范围就是100,模是0访问新版服务,模是1~99的访问老版服务。

灰度发布策略分为两类,单策略和组合策略

单策略:比如按照用户的uid、token、ip进行取模

组合策略:多个服务同时灰度,比如我有A/B/C三个服务,需要同时对A和C进行灰度,但是B不需要灰度,这个时候就需要一个tag字段,具体实现在下文详述

灰度发布具体的执行控制

在上面的简单灰度发布系统架构中我们了解到,灰度发布服务分为上游和下游服务,上游服务是具体的执行灰度策略的程序,这个服务可以是nginx,也可以是微服务架构中的网关层/业务逻辑层,下面我们就来分析一下不同的上游服务,如何落地

Nginx

如果上游服务是nginx,那么就需要nginx通过Lua扩展nginx实现灰度策略的配置和转发,因为nginx本身并不具备灰度策略的执行

通过lua扩展实现了灰度策略的执行,但是问题又来了,nginx本身并不具备接收配置管理平台的灰度策略,这个时候应该怎么办呢?

解决方案:本地部署Agent(需要自己开发),接收服务配置管理平台下发的灰度策略,更新nginx配置,优雅重启Nginx服务

0网关层/业务逻辑层/数据访问层

只需要集成配置管理平台客户端SDK,接收服务配置管理平台下发的灰度策略,在通过集成的SDK进行灰度策略的执行即可

灰度发布复杂场景

下面举例两个稍微复杂的灰度发布场景,灰度策略假设都按照uid取模灰度百分之一的用户,看一下如何实现。

场景1:调用链上同时灰度多个服务

功能升级涉及到多个服务变动,网关层和数据访问层灰度,业务逻辑层不变,这个时候应该如何进行灰度?

解决方案:

经过新版本网关层的请求,全部打上tag T,在业务逻辑层根据tag T进行转发, 标记Tag T的请求全部转发到新版数据访问层服务上,没有tag T的请求全部转发到老版数据访问层上。

场景2:涉及数据的灰度服务

涉及到数据的灰度服务,一定会使用到数据库,使用到数据库就会涉及到你使用数据库前后的表字段不一致,我老版本是A/B/C三个字段,新版本是A/B/C/D四个字段。这时新版的灰度,就不能往老版的数据库进行修改了,这个时候就需要把数据copy一份出来做这个事情了

数据库其实并没有灰度的概念,这个时候我们只能把数据重新拷贝一份出来进行读和写,因为这时你的写必须是全量的(双写),不能说90%的数据写入到老版本,10%的数据写入到新版本,因为这个时候你会发现两个数据库的数据都不是全量的。

离线全量复制数据的过程中一定会有数据丢失,这个时候就需要业务逻辑层写一份数据到MQ中,等数据同步完成之后,新版的数据访问层再将MQ的数据写入到新版本的DB中,实现数据的一致性,这个也是引入MQ的主要目的。

灰度过程中需要对两个数据库的数据进行对比,观察数据是否一致。这样不管是灰度失败,放弃新版DB,还是灰度成功切换到新版DB,数据都不会产生丢失。

相关 [灰度 系统架构 设计] 推荐:

灰度发布系统架构设计

- - 掘金 架构
互联网产品需要快速迭代开发上线,又要保证质量,保证刚上线的系统,一旦出现问题可以很快控制影响面,就需要设计一套灰度发布系统. 灰度发布系统的作用,可以根据配置,将用户的流量导到新上线的系统上,来快速验证新的功能,而一旦出现问题,也可以马上的修复,简单的说,就是一套A/B Test系统. 灰度发布允许带着bug上线,只要bug不是致命的,当然这个bug是不知道的情况下,如果知道就要很快的改掉.

网购秒杀系统架构设计

- - 企业架构 - ITeye博客
秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必须会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪. 用户在秒杀开始前,通过不停刷新浏览器页面以保证不会错过秒杀,这些请求如果按照一般的网站应用架构,访问应用服务器、连接数据库,会对应用服务器和数据库服务器造成极大的负载压力.

O2O供应链系统架构设计

- - 美团技术团队
本文是美团技术沙龙第一期, O2O技术架构与实践上的分享内容. 请在微信搜索“美团技术团队”关注我们的公众账号,了解更多活动信息. 英国知名供应链专家Martin Christopher曾经说过一句非常深刻的话:“21世纪的竞争不是企业和企业之间的竞争,而是供应链和供应链之间的竞争. 在风云变幻、寡头纷争的O2O战场,美团屡出重拳并步步为营,战绩不俗.

Netflix系统架构设计方案

- - DockOne.io
【编者的话】Netflix是全球最大的在线视频网站之一,它是怎么设计的呢. 这篇文章介绍了Netflix系统架构的设计方案. 原文: Netflix System Architecture. 我们来讨论一下如何设计Netflix. 相信每个人都会通过某些网站或应用在线追剧或者看电影,而Netflix是我最喜欢的在线视频网站,不过今天我不推荐任何电影,相反,我想展示的是Netflix背后令人惊艳的系统逻辑.

解剖Twitter:Twitter系统架构设计分析

- flychen50 - 互联网的那点事
随着信息爆炸的加剧,微博客网站Twitter横空出世了. 用横空出世这个词来形容Twitter的成长,并不夸张. 从2006年5月Twitter上线,到2007年12月,一年半的时间里,Twitter用户数从0增长到6.6万. 又过了一年,2008年12月,Twitter的用户数达到5百万. Twitter网站的成功,先决条件是能够同时给千万用户提供服务,而且提供服务的速度要快.

海尔电商峰值系统架构设计最佳实践

- - 博客园_知识库
  多数电商平台都会经历相似的过程,流量和业绩每年以几倍至十几倍的速度增长,每年都要接受几次大规模、全方位的系统检阅,例如双11、周年庆等购物狂欢节,期间流量和订单可能是日常的十几倍甚至几十倍,产生的峰值对平台形成极其强烈的冲击,对电商平台的架构带来巨大的考验. 因此,对电商平台的规划和架构工作不仅要高瞻远瞩,而且要细致入微,否则将导致平台无法满足高速增长的业务发展,细微处的失误也可能造成严重后果,不仅影响业务指标的实现,还可能导致对系统进行重新架构,劳时费力又伤钱.

基于Hadoop的Clearinghouse系统架构设计

- - CSDN博客架构设计推荐文章
1 Clearinghouse(数据交换中心)介绍.        Clearinghouse(数据交换中心)是随着异构组织之间共享空间数据而产生的,它的目标是建立一个虚拟空间数据机制,用来收集空间数据的元数据和发布服务,以便高效的获取空间数据,同时利用空间数据提供决策支持. 通常建立Clearinghouse的基本途径是通过一套元数据标准,收集各个组织中空间数据的元数据,通过服务接口帮助用户确定存在哪些数据,以及获取这些数据的方式等.

分布式会话跟踪系统架构设计与实践

- - 美团点评技术团队
本文整理自美团点评技术沙龙第08期:大规模集群的服务治理设计与实践. 美团点评技术沙龙由美团点评技术团队主办,每月一期. 每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 目前沙龙会分别在北京、上海和厦门等地举行,要参加下一次最新沙龙活动. 赶快关注微信公众号“美团点评技术团队”.

从0开始设计Twitter系统架构

- - DockOne.io
【编者的话】Twitter是全球最大的社交网络之一,如果让我们从0开始设计twitter的系统架构,该怎么做呢. 这篇文章简单介绍了设计类twitter系统的思路并在最后给出了参考设计. 原文: Twitter System Architecture. Twitter是全球领先的在线社交网络服务,用户可以在这里发布和阅读被称为“推文(tweets)”的短消息.