心里苦,了解业界常见服务发布手段~

前言

最近上线需求,服务发布成功后,不一会,告警群就开始滴滴滴,我一看,擦 空指针了,赶紧根据堆栈以及error日志定位到问题代码的行数,根据代码调用上下文迅速判断出出现空指针场景,提了个fix上线,让leader审批下,然后就被批斗怎么每次都出bug......

哎,虽然在测试环境一切正常,但总有测不到的场景,一上线,问题就暴露出来了,而且不同于绝大多数公司存在单点部署,滚动升级的策略,我们发布就是 一把梭哈,出事了就回滚或者赶紧修

借这个坏心情,整理一下业界常见的服务上线发布方式及流程~


服务发布方式

梭哈

目前我们的服务部署了5台机器

  1. 再起同等数量的机器,部署新的代码
  2. 都起来了之后,将流量全切到新机器上
  3. 下线旧机器

称这种方式为梭哈 毫不过分,即使发现告警后及时进行回滚,回滚也需要一定时间,错误代码承接了全部流量,纯纯的风险最大化的操作。


单点部署、滚动升级

目前我们的服务部署了10台机器

  1. 选择一台机器进行部署
  2. 单点部署完毕后,进入容器内部观察一段时间日志,是否存在error日志(如果流量较少不好观察,可以再选择一台或多台机器进行部署,具体是业务场景而定)
  3. 观察一段时间后,如果不存在error日志,代码运行正常,此时可选择滚动升级
  4. 选择每个滚动升级的数量,比如选择3,则每次滚动升级三台机器,直至全部升级完毕

通过上述发布流程,我们可以看到一个字: 经过一段时间的单点部署、日志观察,我们能够及时的发现代码问题,将事故最小化


蓝绿发布

目前我们的服务部署了10台机器

  1. 再起同等数量的机器,部署新的代码
  2. 进行流量控制,逐步将流量切换到新机器上,直至100%
  3. 此时,新旧机器并行存在 ,当然,流量切换期间如果出现任何异常直接将流量再切换到旧机器上,保证服务的稳定性
  4. 流量切换完毕后,新旧机器同时存在,此时再验证一段时间,如果没问题的话再下掉旧机器

蓝绿发布 存在与梭哈 相似之处,都是新起同等数量的机器 ,不过在之后的流量切换上做了稳妥机制,采用逐步切流的方式,来减小可能的事故影响

最后在流量切换完毕后,不会尽快下掉旧机器,新旧机器会并行存在一段时间,避免可能因为业务场景流量小不能够及时暴露问题,等流量全切后才暴露出来

此时,由于旧机器还存在,回滚只需要切流量即可~


灰度发布(金丝雀发布)

目前我们的服务部署了10台机器

  1. 再起小部分机器,比如一两台,形成灰度集群,部署新代码
  2. 引入小部分流量到灰度集群上去进行验证
  3. 验证失败,则将所有流量切回旧机器
  4. 验证成功,即可进行全量发布

灰度发布过程中引入了小部分流量进行验证,能够尽快发现问题,不过灰度发布一般容量有限,只会使用少部分机器,这样的话小流量情况下有些问题是无法暴露的,也算是一种缺点~


结尾

本文整理了业界一些常见服务发布方式及其流程,没有原理干货,hh,敬请谅解~

参考: 有赞灰度发布与蓝绿发布实践

相关推荐
程序员岳焱21 分钟前
Java 与 MySQL 性能优化:Java 实现百万数据分批次插入的最佳实践
后端·mysql·性能优化
FrankYoou25 分钟前
Jenkins 与 GitLab CI/CD 的核心对比
java·docker
一位摩羯座DBA27 分钟前
Redhat&Centos挂载镜像
linux·运维·centos
麦兜*1 小时前
Spring Boot启动优化7板斧(延迟初始化、组件扫描精准打击、JVM参数调优):砍掉70%启动时间的魔鬼实践
java·jvm·spring boot·后端·spring·spring cloud·系统架构
KK溜了溜了1 小时前
JAVA-springboot 整合Redis
java·spring boot·redis
大只鹅1 小时前
解决 Spring Boot 对 Elasticsearch 字段没有小驼峰映射的问题
spring boot·后端·elasticsearch
ai小鬼头1 小时前
AIStarter如何快速部署Stable Diffusion?**新手也能轻松上手的AI绘图
前端·后端·github
天河归来1 小时前
使用idea创建springboot单体项目
java·spring boot·intellij-idea
weixin_478689762 小时前
十大排序算法汇总
java·算法·排序算法
码荼2 小时前
学习开发之hashmap
java·python·学习·哈希算法·个人开发·小白学开发·不花钱不花时间crud