线上版本灰度发布策略

从接触运维开始,最苦逼的事情就是业务上线,为什么这么说? 就是因为有了很多的大坑队友。不是因为开发的童鞋漏提代码,就是因为测试童鞋线下测试的不到位导致代码扔到线上后出现各种问题,各种404。近期和各位童鞋研究了应对这种现象的解决方案,得到了如下结果:

上线分为如下几种等级:测试发布、预发布、灰度发布、正式发布,下面分来来针对这四种发布介绍下区别。

测试发布:写完程序在线下测试,测试的过程和结果成为测试发布。

预发布:程序经历过测试发布后要把代码在线上部署一套(和生产环境一模一样的环境),使用生产环境的数据库等等应用,测试人员在线上进行测试,测试的过程不影响生产环境使用.

灰度发布:程序经历过预发布后下一步就是灰度发布。使用线上的生产环境进行测试,使用对象是部分客户,这种过程称之为灰度发布。

正式发布:代码经历过上述三种测试后,基本可以确定ok了,就可以进行代码正式发布了。环境使用生产环境,客户是全部客户。

以上讲述了四种发布的区别以及作用,接下来继续说说前几天预发布的过程。



预发布的意思是,我们自己的测试人员使用线上的环境线上的数据进行线上测试,但是还不能影响线上正常用的使用,解决办法如下:

根据公网ip进行反向代理,本部门的公网ip是固定的,那么当客户访问的时候,如果是本部门的公网ip的话,nginx进行方向代理到新代码tomcat上,如果非本部门的公网ip,那么代理到原有tomcat上,拓扑如下:

nginx代码:动态请求的规则下面这么写

upstream jljerp {
           server 192.168.1.190:8001  weight=20 max_fails=2 fail_timeout=30s;
           ip_hash;
                }
upstream jljerp_rc {
           server 192.168.1.190:8004  weight=20 max_fails=2 fail_timeout=30s;
           ip_hash;
                }
server {
    listen       80;
    server_name  jljerp.jinlejia.com;
        root   /var/www/index;
        index  index.html index.htm;
location / {
          proxy_set_header HOST   $host;
          proxy_set_header X-Real-IP      $remote_addr;
          proxy_set_header X-Forwarded-FOR $proxy_add_x_forwarded_for;
          proxy_connect_timeout 600;
          proxy_read_timeout 600;
          proxy_send_timeout 600;
        #  预发布规则,这个地址是部门内部公网地址,当这个地址过来的请求转发到新tomcat上
        if ($remote_addr  ~* "202.106.0.20") {
          proxy_pass      http://jljerp_rc;
        }
        # 如果不是本部门ip请求,按照原有规则进行原有生产环境进行转发
          proxy_pass      http://jljerp;
              }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

nginx代码:静态请求的规则这么写(换汤不换药)

server {
    listen      80;
    server_name  www.a.com;

        root   /var/www/a;
        index  index.html index.htm;

    location / {
        #  预发布规则,如果是本部门的公网的ip,访问这个目录下的地址
         if ($remote_addr  ~* "202.106.0.20"){
               root    /var/www/b;
               }
    }
# 由于字体使用跨域的方式进行的调用,默认浏览器拒绝访问,加上这个location就可以在其他域名下访问这个域名的字体了
    location ~* \.(eot|ttf|woff|svg|otf|woff2)$ {
             add_header Access-Control-Allow-Origin *;
    }

    error_page  404 500 502 503 504  /404.html;
    location = /404.html {
        root   /usr/share/nginx/html;
    }
}

上述就是整个过程,并非权威,有问题欢迎大家指正

时间: 2024-07-29 00:07:58

线上版本灰度发布策略的相关文章

线上的活动发布平台最优选-创成汇

在如今这个"大众创新,万众创业"的时代,各地政府.各大投资机构及各大众创空间为了更好的鼓励,孵化创新性企业,都纷纷开始办起各类创新创业大赛,大赛有了,下一步该寻找的就是要在哪里发布大赛,除去政府机构网站外还可以在一些线上的活动发布平台,活动发布平台一般都会有其自身的项目库.宣传渠道.及专业的项目征集人员.例如创成汇. 创成汇是国内专业的创新创业成果转化平台,采用大数据.智慧智能等新兴技术理念和互联互享等先进产业模式,有效整合优质创投资源.在承办大赛方面也是有丰富经验的,就近而言,除了前

TFS线上生成环境发布历程

继前文 TFS在项目中Devops落地进程(上) TFS在项目中DevOps落地进程(下) 自从之前将开发环境使用TFS进行了自动化之后,就享受在此成果中,其他后续进度就停顿了好一段时间. 毕竟在我们这对于开发而言,做出代码交出发布包事情就结束了,而我们的TFS已经完美的将这个流程给自动化掉了. 本文将聚焦在TFS发布到线上生产环境中所做的一些工作和实践,如果只是纠结于如何使用TFS可以参考上面的2个链接. 之前的线上发布流程 说下我们大概的背景,我们的程序上线流程目前还是相对传统一些,大体是:

MySQL 5.6.24 线上版本配置文件解析

线上MySQL服务器配置文件解析 innodb_buffer_pool_size 非常重要的一个参数,用于配置InnoDB的缓冲池,如果数据库中只有哦Innodb表,则推荐配置量为总内存的75% select  engine,round(sum(data_length + index_length)/1024/1024,1) as 'Total MB' from information_schema.tables  where table_schema not in ('information_

Git常用命令和场景(二)--线上版本回退

代码上线后,会遇到有问题的,有bug的,通常,最直接的就是回退到前面的某个版本: 1. 首先使用git log查看要回退到的版本 [python] view plaincopy [[email protected] my]$ git log commit ff3f2238f33256c9d3436e235c1c34d3b8147fe8 Merge: 248cba8 944274f Author: lixinglei <[email protected]> Date:   Thu Jul 4 1

利用友盟定位iOS线上版本项目的崩溃位置

引言 当我们的项目打包上传苹果商店之后,出现的崩溃问题不会想在XCode中那么明显了,那么我们就要对项目的crash日志进行分析,至此,友盟的崩溃分析作用就体现出来了. 前提 你的项目中集成了友盟 能获取到项目的dSYM文件 什么是 dSYM 文件 Xcode 编译项目后,我们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的 dSYM 文件,位于 /Users/<用户

安卓热修复,android打补丁,不用发版本就能实时的解决一些线上版本的bug

背景 当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App.测试. 向各个应用市场和渠道换包.提示用户升级.用户下载.覆盖安装.有时候仅仅是为了修改了一行代码, 也要付出巨大的成本进行换包和重新发布. 这时候就提出一个问题:有没有办法以补丁的方式动态修复紧急Bug, 不再需要重新发布App,不再需要用户重新下载,覆盖安装? 搜索发现有这3种方式可以实现(至于其他的方式,暂不清楚) 1.dexposed     github https:/

小程序真机调试图片可以成功上传,但是线上版本和体验版手机上上传老保图片报错?

配置好上传的域名 上传的图片的域名后来更换了但是小程序后台没换,重新加下就好了. 灵感链接: https://developers.weixin.qq.com/community/develop/doc/00004449ea460025fde8f3ebb56c00 原文地址:https://www.cnblogs.com/pikachuworld/p/11565497.html

[转]线上GC故障解决过程记录

排查了三四个小时,终于解决了这个GC问题,记录解决过程于此,希望对大家有所帮助.本文假定读者已具备基本的GC常识和JVM调优知识,关于JVM调优工具使用可以查看我在同一分类下的另一篇文章: http://my.oschina.net/feichexia/blog/196575 背景说明 发生问题的系统部署在Unix上,发生问题前已经跑了两周多了. 其中我用到了Hadoop源码中的CountingBloomFilter,并将其修改成了线程安全的实现(详情见:AdjustedCountingBloo

一次线上GC故障解决过程记录

排查了三四个小时,终于解决了这个GC问题,记录解决过程于此,希望对大家有所帮助.本文假定读者已具备基本的GC常识和JVM调优知识,关于JVM调优工具使用可以查看我在同一分类下的另一篇文章: http://my.oschina.net/feichexia/blog/196575 背景说明 发生问题的系统部署在Unix上,发生问题前已经跑了两周多了. 其中我用到了Hadoop源码中的CountingBloomFilter,并将其修改成了线程安全的实现(详情见:AdjustedCountingBloo