灰度架构设计方案.docxVIP

灰度架构设计方案 2021-10-11 前言 灰度发布并非是近几年才衰亡的概念，诞生有肯定的年头了，但至今，绝大多数中小型互联网企业的发布流程中仍旧缺少对灰度环境的支持，其次要缘由在于大家对灰度的认知及成本等方面的综合考虑。我前段时间曾就职于一家初创型互联网企业，就发布流程而言，用“脏乱差”来描述好像并不为过，并且，大部分人对环境的认知也仅限于开发（DEV）、测试(FAT)，以及生产(PRO)，从严谨性和专业性等2个角度来看，这并不合理。互联网企业的一大特点就是服务的功能变动特别频繁，自然发布的节拍也随之变得急促起来，缺少预发布环境和灰度环境的支撑，高频的服务发布往往会伴随着巨大的风险，以及那令人极度绝望的服务质量。因而，本文将重点争辩一种平滑的服务发布方式，以便于挂念企业有效降低风险的影响范围。 何为灰度发布 据史书记载，在中国古代的东汉末年三国时期，曹操为了弥补军饷的不足，特地设立了发丘中郎将，摸金校尉等军衔，专司盗墓取财，贴补军饷之用，由此开启了倒斗的先例。据隋代医家巢元方撰写的《诸病源候论》一书记载“入井冢墓毒瓦斯候”，因而后来的盗墓者们在每次下墓前，都会先将几只金丝雀（又名：白玉）放至鸟笼中，然后将鸟笼系上绳子后投放至墓中，如图1所示。由于金丝雀具备特殊的呼吸系统结构，使得它们天生就对空气中含有的有害气体格外敏感，因而，当金丝雀被投放至墓中由于晕倒而不再鸣叫时，则表示墓中含有较高浓度的有害气体，不宜下墓，反之，就表示相对平安，这就是灰度发布（也被称之为金丝雀发布）的起源。 灰度发布，简约来说，就是通过定制一系列的规章和策略，先将一小部分的用户作为金丝雀，让其恳求路由到新服务上进行观看，待运转正常后，再逐渐导流更多的用户到灰度环境中；当然，假如初期灰度环境的机器数量不多，为了避开系统容量被持续递增的用户流量撑爆而产生宕机，我们还需要实时扩容灰度环境的机器数量以便于支撑更多的用户访问。当全部的用户都顺当切换到新服务上后，再停机之前的老版本服务，即可完成灰度发布。在此大家需要留意，就算灰度期新版本服务存在问题，我们也能够快速将流量切换回来。总之，实施灰度发布的目的就在于试错，尽可能把握和缩小问题的影响范围，从而保障绝大多数用户可用；换个角度看，产品经理们自然也期望能够在最低的试错成本下收集用户的使用反馈（ABtest，灰度发布的其中一种表现方式），以便于更好的完善和改进当前产品。 灰度策略设计 最常见的灰度策略就是指定白名单，只要在白名单中的那部分用户才允许被路由到灰度环境中。通常，这类用户要么是内测用户，要么是企业内部成员。除此之外，对于一个成熟的灰度产品而言，灰度策略的支持绝不应当如此单薄，比如像：访问权重比例、IP段，甚至是用户画像（依据目标用户群体的喜好、年纪、性别等一系列用户特征来进行灰度用户筛选）等策略也理应支持。 ? 大家思考下，假设我们仅期望全站10%的用户访问灰度环境，访问权重的算法应当如何设计？最简约的做法就是提前load出全部用户然后选择出其中10%的用户比例，虽然可以这样做，但我并不建议大家接受这样的方式，首先是机警性的问题，其次，当用户基数较大时，这样的筛选方式无疑是低效的，况且用户数量每天都在发生变化。这里我为大家供应一种相对机警且格外简约的权重算法，如下所示： UIDmod100 ? 假设UID是相对有序的，当得出余数后，再与指定的比例值进行比较（这里的比例值为10%），假如UID % 100 = 10，那么我们就可以将目标用户指定为一个灰度用户，并将其路由到灰度环境中。接受求余算法实现动态机警的权重把握虽然格外简约，但仍旧存在肯定的不足，比如，当全站用户基数相对较小时，其误差会变得较大；其次，在做加法时（比如权重比例从10%上调至20%），必定会导致某些固定用户每次都被命中，因而我们往往需要添加计算因子来避开这样的情况消灭。 流量的切分 灰度发布的核心技术问题就是流量应当如何切分，以及在哪里进行切分。实际上灰度规律与业务规律本身是无关的，我们并不应当将灰度规律耦合在业务代码中，因而，将接入层网关作为流量的切分入口再适合不过，如图1所示： 图1 基于网关实现流量切分 灰度规章的配置，我们需要单独引入一个规章配置中心，并通过Redis的Pub/Sub模式将灰度规章进行下发，由网关层担任加载前者下发的规章内容。当网关接收到用户恳求后，首先会从Header中解析出相应的灰度标记，假如当前用户为灰度用户，就将流量切分到灰度环境，反之切分到生产环境。在此大家需要留意，客户端恳求头中所带的灰度标记，需要从规章配置中心处猎取，也就是说，当客户端启动时，优先恳求规章配置中心，假如命中规章，则每次恳求网关时都会带上灰度标记，如图2所示： 图1 灰度流程1 大家思考下，假设用户A为灰度用户，待我们实