关于蓝绿发布、灰度以及滚动发布的记录
蓝绿发布项目逻辑上分为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添加了一个权限，是否允许超级管理 ...