一文搞懂蓝绿发布、灰度发布和滚动发布

应用程序升级面临最大挑战是新旧业务切换,将软件从测试的最后阶段带到生产环境,同时要保证系统不间断提供服务。

长期以来,业务升级渐渐形成了几个发布策略:蓝绿发布、灰度发布和滚动发布,目的是尽可能避免因发布导致的流量丢失或服务不可用问题。

一、 蓝绿发布
项目逻辑上分为AB组,在项目系统时,首先把A组从负载均衡中摘除,进行新版本的部署。B组仍然继续提供服务。

1

当A组升级完毕,负载均衡重新接入A组,再把B组从负载列表中摘除,进行新版本的部署。A组重新提供服务。

2

最后,B组也升级完成,负载均衡重新接入B组,此时,AB组版本都已经升级完成,并且都对外提供服务。

特点

  • 如果出问题,影响范围较大;
  • 发布策略简单;
  • 用户无感知,平滑过渡;
  • 升级/回滚速度快。

缺点

  • 需要准备正常业务使用资源的两倍以上服务器,防止升级期间单组无法承载业务突发;
  • 短时间内浪费一定资源成本;
  • 基础设施无改动,增大升级稳定性。

蓝绿发布在早期物理服务器时代,还是比较昂贵的,由于云计算普及,成本也大大降低。

二、 灰度发布

灰度发布只升级部分服务,即让一部分用户继续用老版本,一部分用户开始用新版本,如果用户对新版本没什么意见,那么逐步扩大范围,把所有用户都迁移到新版本上面来。

3

特点

  • 保证整体系统稳定性,在初始灰度的时候就可以发现、调整问题,影响范围可控;
  • 新功能逐步评估性能,稳定性和健康状况,如果出问题影响范围很小,相对用户体验也少;
  • 用户无感知,平滑过渡。

缺点

  • 自动化要求高

部署过程

  • 从LB摘掉灰度服务器,升级成功后再加入LB;
  • 少量用户流量到新版本;
  • 如果灰度服务器测试成功,升级剩余服务器。

灰度发布是通过切换线上并存版本之间的路由权重,逐步从一个版本切换为另一个版本的过程。

三、 滚动发布

滚动发布是指每次只升级一个或多个服务,升级完成后加入生产环境,不断执行这个过程,直到集群中的全部旧版本升级新版本。

4

  • 红色:正在更新的实例
  • 蓝色:更新完成并加入集群的实例
  • 绿色:正在运行的实例

特点

  • 用户无感知,平滑过渡;
  • 节约资源。

缺点

  • 部署时间慢,取决于每阶段更新时间;
  • 发布策略较复杂;
  • 无法确定OK的环境,不易回滚。

部署过程

  • 先升级1个副本,主要做部署验证;
  • 每次升级副本,自动从LB上摘掉,升级成功后自动加入集群;
  • 事先需要有自动更新策略,分为若干次,每次数量/百分比可配置;
  • 回滚是发布的逆过程,先从LB摘掉新版本,再升级老版本,这个过程一般时间比较长;
  • 自动化要求高。

小结

综上所述,三种方式均可以做到平滑式升级,在升级过程中服务仍然保持服务的连续性,升级对外界是无感知的。那生产上选择哪种部署方法最合适呢?这取决于哪种方法最适合你的业务和技术需求。如果你们运维自动化能力储备不够,肯定是越简单越好,建议蓝绿发布,如果业务对用户依赖很强,建议灰度发布。如果是K8S平台,滚动更新是现成的方案,建议先直接使用。

  • 蓝绿发布:两套环境交替升级,旧版本保留一定时间便于回滚。
  • 灰度发布:根据比例将老版本升级,例如80%用户访问是老版本,20%用户访问是新版本。
  • 滚动发布:按批次停止老版本实例,启动新版本实例。

原文:https://www.cnblogs.com/nulige/articles/10929182.html 1

MySQL的四种事务隔离级别

一、事务的基本要素(ACID)

1、原子性(Atomicity):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节。事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体,就像化学中学过的原子,是物质构成的基本单位。

2、一致性(Consistency):事务开始前和结束后,数据库的完整性约束没有被破坏 。比如A向B转账,不可能A扣了钱,B却没收到。

3、隔离性(Isolation):同一时间,只允许一个事务请求同一数据,不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱,在A取钱的过程结束前,B不能向这张卡转账。

4、持久性(Durability):事务完成后,事务对数据库的所有更新将被保存到数据库,不能回滚。

二、事务的并发问题

1、脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据

2、不可重复读:事务 A 多次读取同一数据,事务 B 在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果 不一致。

3、幻读:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录,当系统管理员A改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样,这就叫幻读。

小结:不可重复读的和幻读很容易混淆,不可重复读侧重于修改,幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行,解决幻读需要锁表

三、MySQL事务隔离级别

事务隔离级别 脏读 不可重复读 幻读
读未提交(read-uncommitted)
不可重复读(read-committed)
可重复读(repeatable-read)
串行化(serializable)

 

 

Spring事务管理中@Transactional的propagation参数

所谓事务传播性,就是被调用者的事务与调用者的事务之间的关系。举例说明。

//in A.java
Class A {
    @Transactional(propagation=propagation.REQUIRED)
    public void aMethod {
        B b = new B();
        b.bMethod();
    }
}
//in B.java
Class B {
    @Transactional(propagation=propagation.REQUIRED)
    public void bMethod { //something }
}

在上面这个例子中,传播性被设为了REQUIRED,注意,这是默认值,也即不进行该参数配置等于配置成REQUIRED。

REQUIRED的含义是,支持当前已经存在的事务,如果还没有事务,就创建一个新事务。在上面这个例子中,假设调用aMethod前不存在任何事务,那么执行aMethod时会自动开启一个事务,而由aMethod调用bMethod时,由于事务已经存在,因此会使用已经存在的事务(也就是执行aMethod之前创建的那个事务)。

对于这样的配置,如果bMethod过程中发生异常需要回滚,那么aMethod中所进行的所有数据库操作也将同时被回滚,因为这两个方法使用了同一个事务。

MANDATORY的含义是,支持当前已经存在的事务,如果还没有事务,就抛出一个异常。如果上例中aMethod的传播性配置为MANDATORY,我们就无法在没有事务的情况下调用aMethod,因此,传播性为MANDATORY的方法必定是一个其他事务的子事务,当逻辑上独立存在没有意义或者可能违反数据、事务完整性的时候,就可以考虑设置这样的传播性设置。

NESTED的含义是,在当前事务中创建一个嵌套事务,如果还没有事务,那么就简单地创建一个新事务。

REQUIRES_NEW的含义是,挂起当前事务,创建一个新事务,如果还没有事务,就简单地创建一个新事务。

请注意以上两者的区别,大多数情况下一上两种传播性行为是类似的,不过在事务回滚的问题上,以上两者有很大的区别。

首先,REQUIRES_NEW会创建一个与原事务无关的新事务,尽管是由一个事务调用了另一个事务,但却没有父子关系。

如果bMethod的传播性是REQUIRES_NEW,而抛出了一个异常,则bMethod一定会被回滚,而如果aMethod捕获并处理了这个bMethod抛出的异常,那么aMethod仍有可能成功提交。当然,如果aMethod没有处理这个异常,那么aMethod也会被回滚。

如果aMethod在bMethod完成后出现了异常,那么bMethod已经提交而无法回滚,只有aMethod被回滚了。

而对于NESTED,虽然也会创建一个新事务,但是这个事务与调用者是有父子关系的相互依存的。

如果bMethod的传播性是NESTED,而抛出了一个异常,事务的回滚行为与REQUIRES_NEW是一致的。

但是如果aMethod在bMethod完成后出现了异常,bMethod同样也会被回滚。因为事实上,EJB中没有对于NESTED传播性的类似实现,NESTED并不是真正启动了一个事务,而是开启了一个新的savepoint。

NEVER的含义很简单,就是强制要求不在事务中运行,如果当前存在一个事务,则抛出异常,因此如果bMethod传播性是NEVER,则一定抛出异常。

NOT_SUPPORTED的含义是,强制不在事务中运行,如果当前存在一个事务,则挂起该事务。

SUPPORTS的含义是,支持当前事务,如果没有事务那么就不在事务中运行。SUPPORTS传播性的逻辑含义比较模糊,因此一般是不推荐使用的。