关于蓝绿发布、灰度以及滚动发布的记录
蓝绿发布项目逻辑上分为AB组,在项目升级时,首先把A组从负载均衡中摘除,进行新版本的部署。B组仍然继续提供服务。
当A组升级完毕,负载均衡重新接入A组,再把B组从负载列表中摘除,进行新版本的部署。A组重新提供服务。
最后,B组也升级完成,负载均衡重新接入B组,此时,AB组版本都已经升级完成,并且都对外提供服务。
特点
如果出问题,影响范围较大;
发布策略简单;
用户无感知,平滑过渡;
升级/回滚速度快。
缺点
需要准备正常业务使用资源的两倍以上服务器,防止升级期间单组无法承载业务突发;
短时间内浪费一定资源成本;
基础设施无改动,增大升级稳定性。
蓝绿发布在早期物理服务器时代,还是比较昂贵的,由于云计算普及,成本也大大降低。
灰度发布灰度发布只升级部分服务,即让一部分用户继续用老版本,一部分用户开始用新版本,如果用户对新版本没什么意见,那么逐步扩大范围,把所有用户都迁移到新版本上面来。
特点
保证整体系统稳定性,在初始灰度的时候就可以发现、调整问题,影响范围可控;
新功能逐步评估性能,稳定性和健康状况,如果出问题影响范围很小,相对用户体验也少;
用户无感知,平滑过渡。
缺点 ...
关于RBAC的总结-上
1. 什么是RBACRBAC,全称是 Role-Based Access Control ,也就是基于角色的访问控制。RBAC认为权限授权的过程可以抽象地概括为:Who是否可以对What进行How的访问操作,并对这个逻辑表达式进行判断是否为True的求解过程。也即是将权限问题转换为What、How的问题。Who、What、How构成了访问权限三元组。
2. 为什么需要RBAC2.1 原始权限控制在没有RBAC的时候,如果需要对用户授权,则需要直接将权限授予客户,如下图:
张三可以管理商品,同时可以对商品进行审核;李四只能管理商品,无法审核;
对于这种情况存在以下问题:
当用户数量很多的时候,需要对每一个用户执行授权操作;
当权限新增或者删除的时候,也是需要每个用户单独执行;
当想要快速去除某一部分人的某一部分权限时,操作复杂;
2.2 RBAC针对传统模式的情况,RBAC通过它的权限三元组进行了解决,如图:
在RBAC模型里面,有3个基础组成部分,分别是:用户、角色和权限。通过增加角色,权限与角色进行关联,同时用户与角色进行关联,来解决上面的问题。
当新增用户时,只需要关联角色, ...
关于RBAC的总结-下
关于实现方案的简单记录 通过关于RBAC实现的方案记录-上,我们了解到了RBAC的一些基础知识,下面是实际使用中的一些案例情况。
1. 简单模式在常见的平台中,一般会内置超级管理员角色以及admin/root的账号,默认拥有一些或者全部的权限。同时还会内置限制,只有超级管理员才能创建角色、给角色授权,其他的角色是无权操作这些的。对于这种情况,使用的就是RBAC0的模型,有以下特点:
只有超级管理员可以创建角色、授权角色;
所有角色都是平级,修改授权时,不会对其他角色造成影响;
2. 级联模式对于级联模式,使用的就是RBAC1的模型,对角色进行分层,使得角色之间有继承关系。它的特点如下:
创建角色时,需要选父级角色;
对上级角色的授权进行修改时,主要是删减,会影响到子角色,需要自动对齐;
此时根据业务需求,就可以满足:
允许超级管理员操作角色和权限;
也允许将角色操作下放至其他角色,进行数据权限限制;
超级管理员修改角色A的权限时,权限自动收敛,所以A的子角色自动变化;
如果同时将角色和权限的操作下放至其他角色,可能会出现的情况如下:
角色A添加了一个权限,是否允许超级管理 ...


