企业级CI/CD 持续集成/交付/发布

一:平滑发布与灰度发布

1、 什么叫平滑

在发布的过程中不影响用户的使用，系统不会因发布而暂停对外服务，不会造成用户短暂性无法访问；

2、什么叫灰度

发布后让部分用户使用新版本，其它用户使用旧版本，逐步扩大影响范围，最终达到全部更新的发布方式 ；
灰度发布与平滑发布其实是关联的。当服务器的数量只有一台的时候，不存在灰度发布，一旦发布了就是所有用户都更新了，所以这个时候只有平滑发布。当服务器数量大于一台的时候，只要每台服务器都能达到平滑发布的方式，然后设定好需要发布的服务器占比数量，就可以实现灰度发布了。

3、单台服务器的平滑发布模式

单机状态下，应用的持续服务主要依靠Nginx的负载均衡及自动切换功能；为了能够切换应用，需要在服务器中创建两个相同的独立应用，分配两个不同的端口，例如:
app1,端口 801
app2,端口 802
在 Nginx 中，将 app1,app2 作为负载均衡加载：
upstream myapp{
server 127.0.0.1:801; # app1
server 127.0.0.1:802; # app2
}

# 然后设置代理超时为1秒，以便在某个应用停止时及时切换到另一个应用：<br />server {<br />    listen 80;<br />    server_name localhost;<br />    location /{<br />    proxy_pass http://myapp;<br />    proxy_set_header Host $host;<br />    proxy_set_header X-Real-IP $remote_addr;<br />    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<br />    proxy_connect_timeout       1;<br />    proxy_read_timeout          1;<br />    proxy_send_timeout          1;<br />    }<br />}<br />    # 以上内容写在单独的配置文件中：/vhost/pub/pub_app.conf<br />    # 在nginx.conf里包含进去：<br />    # include /vhost/*.conf;<br />现在系统会均衡地分配用户访问 app1 与 app2<br />接下来我们进行平滑发布，我们先把app1停止，然后将新版本发布到app1中

1、 准备发布 app1 配置文件

新做一个配置文件 pub_app1_down.conf,内容中把 app1 停止掉：
upstream myapp{
server 127.0.0.1:801 down; //app1
server 127.0.0.1:802; //app2
}
# 将这个文件内容覆盖掉在原有的pub_app.conf
[root@qfedu.com ~]# cp -f /vhost/pub/pub_app1_down.conf /vhost/pub_app.conf

2、停止 app1 应用

平滑重新加载一下 nginx:
[root@qfedu.com ~]# service nginx reload
或者：
[root@qfedu.com ~]# /usr/local/nginx/sbin/nginx -s reload
# 此时所有的请求都转到了app2了；

3、更新 app1

现在可以通过各种方式来更新应用了，例如：压缩包方式：
[root@qfedu.com ~]# wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
[root@qfedu.com ~]# unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
# 其中：-o:不提示的情况下覆盖文件；-d:指定解压目录
# 步骤3.5 内部测试
# 如果需要的话，可以在这一步对 app1 进行内部测试，以确保应用的正确性；

4、准备发布 app2 配置文件

此时app1已经是最新版本的文件了，可以切换到app1来对外，
# 创建一个新的nginx配置文件:pub_app2_down.conf，设置为app1对外,app2停止即可：
upstream myapp{
server 127.0.0.1:801; # app1
server 127.0.0.1:802 down; # app2
}
# 将这个文件内容覆盖掉在原有的 pub_app.conf
[root@qfedu.com ~]# cp -f /vhost/pub/pub_app2_down.conf /vhost/pub_app.conf

5、切换到 app1 新版本应用

平滑重新一下nginx:
[root@qfedu.com ~]# service nginx reload
或者：
[root@qfedu.com ~]# /usr/local/nginx/sbin/nginx -s reload

此时所有的请求都转到了app1了，新版本开始运行；

6、更新 app2

7、恢复 app1,app2 同时对外

[root@qfedu.com ~]# cp -f /vhost/pub/pub_app.conf /vhost/pub_app.conf
# 平滑重新一下nginx:
[root@qfedu.com ~]# service nginx reload
或者：
[root@qfedu.com ~]# /usr/local/nginx/sbin/nginx -s reload
至此，整个应用都已经更新

8、 将各步骤中的脚本汇总如下

[pub.sh]
#============ 平滑发布 v1.0 ===============
#step 1
cp -f /vhost/pub/pub_app1_down.conf /vhost/pub_app.conf
#step 2
systemctl reload nginx
#step 3
wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
#step 4
cp -f /vhost/pub/pub_app2_down.conf /vhost/pub_app.conf
#step 5
systemctl reload nginx
#step 6
unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
#step 7
cp -f /vhost/pub/pub_app.conf /vhost/pub_app.conf
service nginx reload

============ 平滑发布 v1.0 ===============
# 备注：也可以充分利用 nginx 的宕机检测，省去步骤1，2，4，5，7；
# 简化后的脚本如下：
[pub_mini.sh]
#======== 简化版脚本 =============
wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
#========= over ===========

4、多台服务器平滑发布模式

• 有了单台平滑发布模式的基础，多台服务器就简单了。
• 每台服务器当作应用进行发布就可以了，由于nginx有宕机自动检测功能
• 只需要在每台服务器上先停止发布，然后更新文件，再启动就可以了
• 如果选择部分的服务器进行更新，那就是灰度了。

多台服务器平滑发布模式实验过程：
准备三台机器，一台用作web服务器端，一台用来做代理和负载均衡，一台用作客户端。
web服务器端部署：（192.168.112.135）
[root@localhost ~]# yum -y install nginx
[root@localhost ~]# mkdir /app1
[root@localhost ~]# echo “web-1” >/app1/index.html
[root@localhost ~]# mkdir /app2
[root@localhost ~]# echo “web-2” > /app2/index.html
[root@localhost ~]# cd /etc/nginx/conf.d/
[root@localhost conf.d]# vim app1.conf
server{
listen 801;
server_name localhost;
location / {
root /app1;
index index.html;
}
}
[root@localhost conf.d]# vim app2.conf
server{
listen 802;
server_name localhost;
location / {
root /app2;
index index.html;
}
}
然后用浏览器分别访问：（保证都能正常访问）
192.168.112.135:801
192.168.112.135:802
upstream端部署：（192.168.112.136）
[root@localhost nginx]# yum -y install nginx
[root@localhost nginx]# vim /etc/nginx/nginx.conf
upstream myapp{
server 192.168.112.135:801; # app1
server 192.168.112.135:802; # app2
}
location / {
proxy_pass http://myapp;
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 1;
proxy_read_timeout 1;
proxy_send_timeout 1;
}

[root@localhost nginx]# systemctl start nginx
然后客户端访问代理：
[root@localhost ~]# curl 192.168.112.136
web-1
[root@localhost ~]# curl 192.168.112.136
web-2
接着开始平滑模式测试：
先down app1服务：
[root@localhost nginx]# vim /etc/nginx/nginx.conf
upstream myapp{
server 192.168.112.135:801 down; # app1
server 192.168.112.135:802; # app2
}
[root@localhost nginx]# nginx -s reload
这时用客户端访问发现网站内容还能正常访问：
[root@localhost ~]# curl 192.168.112.136
web-2
[root@localhost ~]# curl 192.168.112.136
web-2
[root@localhost ~]# curl 192.168.112.136
web-2
更新app1内容：
[root@localhost conf.d]# echo “this is a new app” >/app1/index.html
然后再将app1放开，down app2：
[root@localhost nginx]# vim /etc/nginx/nginx.conf
upstream myapp{
server 192.168.112.135:801; # app1
server 192.168.112.135:802 down; # app2
}
[root@localhost nginx]# nginx -s reload
这时再用客户端访问，发现网站内容还能正常访问:
[root@localhost ~]# curl 192.168.112.136
this is a new app
[root@localhost ~]# curl 192.168.112.136
this is a new app
更新app2内容：
[root@localhost conf.d]# echo “this is a new app” >/app2/index.html
这时将app1和app2的服务都放开：
upstream myapp{
server 192.168.112.135:801; # app1
server 192.168.112.135:802; # app2
}
再用客户端访问，此时都能访问到新内容。
[root@localhost ~]# curl 192.168.112.136
this is a new app
[root@localhost ~]# curl 192.168.112.136
this is a new app
[root@localhost ~]# curl 192.168.112.136
this is a new app
[root@localhost ~]# curl 192.168.112.136

二:蓝绿发布、灰度发布和滚动发布

1.蓝绿发布

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

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

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

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

缺点

• 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
• 短时间内浪费一定资源成本；

• 基础设施无改动，增大升级稳定性。

  2.灰度发布

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

• 保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；

• 新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
• 用户无感知，平滑过渡。

缺点

• 自动化要求高

部署过程

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

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

3.滚动发布

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

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

• 用户无感知，平滑过渡；
• 节约资源。

缺点

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

部署过程

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

注意:
三种方式均可以做到平滑式升级，在升级过程中服务仍然保持服务的连续性，升级对外界是无感知的。那生产上选择哪种部署方法最合适呢？这取决于哪种方法最适合你的业务和技术需求。如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用。
如何选择？ 实际情况+发布方式的特点
蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。
灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。
滚动发布：按批次停止老版本实例，启动新版本实例。

三:Nexus3 搭建 maven 私服

1.Nexus3 简介

Maven是一个采用纯Java编写的开源项目管理工具.
Maven采用了一种被称之为Project Object Model(POM)概念来管理项目，所有的项目配置信息都被定义在一个叫做POM.xml的文件中,。
通过该文件Maven可以管理项目的整个生命周期，包括清除、编译，测试，报告、打包、部署等等。
目前Apache下绝大多数项目都已经采用Maven进行管理. 而Maven本身还支持多种插件, 可以方便更灵活的控制项目, 开发人员的主要任务应该是关注商业逻辑并去实现它, 而不是把时间浪费在学习如何在不同的环境中去依赖jar包,项目部署等。
maven和ant都是软件构建工具（软件管理工具),maven比ant更加强大，已经取代了ant,jar包的声明式依赖描述，maven有jar包的仓库。
Nexus3私服是架设在局域网的一种特殊的远程仓库，目的是代理远程仓库及部署第三方构件。有了私服之后，当 Maven 需要下载构件时，直接请求私服，私服上存在则下载到本地仓库；否则，私服请求外部的远程仓库，将构件下载到私服，再提供给本地仓库下载。


maven软件网址：https://maven.apache.org/

2.安装 maven

1、下载 maven

[root@qfedu.com ~]# wget http://mirrors.tuna.tsinghua.edu.cn/apache/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz

2、解压安装

[root@qfedu.com ~]# tar xf apache-maven-3.6.3-bin.tar.gz -C /usr/local/
[root@qfedu.com ~]# cd /usr/local/
[root@qfedu.com ~]# ln -s apache-maven-3.6.3/ maven

3、安装 java 环境

[root@qfedu.com ~]# tar xf jdk-8u201-linux-x64.tar.gz -C /usr/local/
[root@qfedu.com ~]# cd /usr/local/
[root@qfedu.com ~]# ln -s jdk1.8.0_251/ java

4、添加环境变量

[root@qfedu.com ~]# vim /etc/profile
在文件下方添加如下内容（这里的MAVEN_HOME需要改为你自己的maven解压目录）
export JAVA_HOME=/usr/local/java
export MAVEN_HOME=/usr/local/maven
export JRE_HOME=/usr/local/java/jre
export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH
export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$MAVEN_HOME/bin:$PATH
建议使用下面这种写法写环境变量，比较容易理解。

重载环境变量
[root@qfedu.com ~]# source /etc/profile

5、验证 java 和 maven 安装

[root@localhost ~]# java -version
java version “1.8.0_191”
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
[root@localhost ~]# mvn -v
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/maven
Java version: 9.0.1, vendor: Oracle Corporation, runtime: /usr/local/java
Default locale: en_US, platform encoding: UTF-8
OS name: “linux”, version: “3.10.0-693.el7.x86_64”, arch: “amd64”, family: “unix”

3.安装 nexus3

1、下载

由于专业版的nexus是收费的，所以我下载的是开源版 Nexus OSS,下载地址为 :
https://help.sonatype.com/repomanager3/download/download-archives—-repository-manager-3
[root@localhost ~]# cd /opt/
[root@localhost opt]# wget http://download.sonatype.com/nexus/3/nexus-3.24.0-02-unix.tar.gz

2、解压

[root@qfedu.com ~]# tar -zxf nexus-3.24.0-02-unix.tar.gz -C /usr/local
解压后会多出两个目录，nexus-3.24.0-02和sonatype-work

3、启动

[root@qfedu.com ~]# cd nexus-3.24.0-02/bin/
[root@qfedu.com ~]# ./nexus start

[root@bogon bin]# ss -anltp

看到如图所示内容表明我们已经启动成功了，浏览器输入http://localhost:8081即可访问。

注意：
启动后如果你立即访问可能发现什么都没有，不要急这个启动需要一定时间，30秒后到1分钟后再尝试访问，这个开始我以为出问题了


企业级CI/CD 持续集成/交付/发布
一:平滑发布与灰度发布
1、 什么叫平滑
在发布的过程中不影响用户的使用，系统不会因发布而暂停对外服务，不会造成用户短暂性无法访问；
2、什么叫灰度
发布后让部分用户使用新版本，其它用户使用旧版本，逐步扩大影响范围，最终达到全部更新的发布方式 ；
灰度发布与平滑发布其实是关联的。当服务器的数量只有一台的时候，不存在灰度发布，一旦发布了就是所有用户都更新了，所以这个时候只有平滑发布。当服务器数量大于一台的时候，只要每台服务器都能达到平滑发布的方式，然后设定好需要发布的服务器占比数量，就可以实现灰度发布了。
3、单台服务器的平滑发布模式
单机状态下，应用的持续服务主要依靠Nginx的负载均衡及自动切换功能；为了能够切换应用，需要在服务器中创建两个相同的独立应用，分配两个不同的端口，例如:
app1,端口 801
app2,端口 802
在 Nginx 中，将 app1,app2 作为负载均衡加载：
upstream myapp{
server 127.0.0.1:801; # app1
server 127.0.0.1:802; # app2
}

# 然后设置代理超时为1秒，以便在某个应用停止时及时切换到另一个应用：<br />server {<br />    listen 80;<br />    server_name localhost;<br />    location /{<br />    proxy_pass http://myapp;<br />    proxy_set_header Host $host;<br />    proxy_set_header X-Real-IP $remote_addr;<br />    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<br />    proxy_connect_timeout       1;<br />    proxy_read_timeout          1;<br />    proxy_send_timeout          1;<br />    }<br />}<br />    # 以上内容写在单独的配置文件中：/vhost/pub/pub_app.conf<br />    # 在nginx.conf里包含进去：<br />    # include /vhost/*.conf;<br />现在系统会均衡地分配用户访问 app1 与 app2<br />接下来我们进行平滑发布，我们先把app1停止，然后将新版本发布到app1中<br />1、 准备发布 app1 配置文件<br /># 新做一个配置文件 pub_app1_down.conf,内容中把 app1 停止掉：<br />    upstream myapp{<br />          server 127.0.0.1:801 down; //app1<br />          server 127.0.0.1:802; //app2<br />    }<br /># 将这个文件内容覆盖掉在原有的pub_app.conf<br />[root@qfedu.com ~]# cp -f /vhost/pub/pub_app1_down.conf /vhost/pub_app.conf<br />2、停止 app1 应用<br /># 平滑重新加载一下 nginx: <br />[root@qfedu.com ~]# service nginx reload<br />    或者：<br />[root@qfedu.com ~]# /usr/local/nginx/sbin/nginx -s reload<br /># 此时所有的请求都转到了app2了；<br />3、更新 app1<br /># 现在可以通过各种方式来更新应用了，例如：压缩包方式：<br />[root@qfedu.com ~]# wget [http://version.my.com/appudate/myapp/myapp-v3.2.32.tar](http://version.my.com/appudate/myapp/myapp-v3.2.32.tar)<br />[root@qfedu.com ~]# unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar<br /># 其中：-o:不提示的情况下覆盖文件；-d:指定解压目录<br /># 步骤3.5 内部测试<br /># 如果需要的话，可以在这一步对 app1 进行内部测试，以确保应用的正确性；<br />4、准备发布 app2 配置文件<br /># 此时app1已经是最新版本的文件了，可以切换到app1来对外，<br /># 创建一个新的nginx配置文件:pub_app2_down.conf，设置为app1对外,app2停止即可：    <br />    upstream myapp{<br />          server 127.0.0.1:801;      # app1<br />          server 127.0.0.1:802 down; # app2<br />    }<br /># 将这个文件内容覆盖掉在原有的 pub_app.conf<br />[root@qfedu.com ~]# cp -f /vhost/pub/pub_app2_down.conf /vhost/pub_app.conf<br />5、切换到 app1 新版本应用 <br /># 平滑重新一下nginx: <br />[root@qfedu.com ~]# service nginx reload<br /> 或者：<br />[root@qfedu.com ~]# /usr/local/nginx/sbin/nginx -s reload

此时所有的请求都转到了app1了，新版本开始运行；
6、更新 app2
7、恢复 app1,app2 同时对外
[root@qfedu.com ~]# cp -f /vhost/pub/pub_app.conf /vhost/pub_app.conf
# 平滑重新一下nginx:
[root@qfedu.com ~]# service nginx reload
或者：
[root@qfedu.com ~]# /usr/local/nginx/sbin/nginx -s reload
至此，整个应用都已经更新
8、 将各步骤中的脚本汇总如下
[pub.sh]
#============ 平滑发布 v1.0 ===============
#step 1
cp -f /vhost/pub/pub_app1_down.conf /vhost/pub_app.conf
#step 2
systemctl reload nginx
#step 3
wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
#step 4
cp -f /vhost/pub/pub_app2_down.conf /vhost/pub_app.conf
#step 5
systemctl reload nginx
#step 6
unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
#step 7
cp -f /vhost/pub/pub_app.conf /vhost/pub_app.conf
service nginx reload

============ 平滑发布 v1.0 ===============
# 备注：也可以充分利用 nginx 的宕机检测，省去步骤1，2，4，5，7；
# 简化后的脚本如下：
[pub_mini.sh]
#======== 简化版脚本 =============
wget http://version.my.com/appudate/myapp/myapp-v3.2.32.tar
unzip -o -d /home/wwwroot/app1/ myapp-v3.2.32.tar
unzip -o -d /home/wwwroot/app2/ myapp-v3.2.32.tar
#========= over ===========
4、多台服务器平滑发布模式
有了单台平滑发布模式的基础，多台服务器就简单了。
每台服务器当作应用进行发布就可以了，由于nginx有宕机自动检测功能
只需要在每台服务器上先停止发布，然后更新文件，再启动就可以了
如果选择部分的服务器进行更新，那就是灰度了。
二:蓝绿发布、灰度发布和滚动发布
1.蓝绿发布
项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。

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

最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。
特点
如果出问题，影响范围较大；
发布策略简单；
用户无感知，平滑过渡；
升级/回滚速度快。
缺点
需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
短时间内浪费一定资源成本；
基础设施无改动，增大升级稳定性。
2.灰度发布
灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。

特点
保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
用户无感知，平滑过渡。
缺点
自动化要求高
部署过程
从LB摘掉灰度服务器，升级成功后再加入LB；
少量用户流量到新版本；
如果灰度服务器测试成功，升级剩余服务器。
灰度发布是通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本的过程。
3.滚动发布
滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。

红色：正在更新的实例
蓝色：更新完成并加入集群的实例
绿色：正在运行的实例
特点
用户无感知，平滑过渡；
节约资源。
缺点
部署时间慢，取决于每阶段更新时间；
发布策略较复杂；
无法确定OK的环境，不易回滚。
部署过程
先升级1个副本，主要做部署验证；
每次升级副本，自动从LB上摘掉，升级成功后自动加入集群；
事先需要有自动更新策略，分为若干次，每次数量/百分比可配置；
回滚是发布的逆过程，先从LB摘掉新版本，再升级老版本，这个过程一般时间比较长；
自动化要求高。
注意:
三种方式均可以做到平滑式升级，在升级过程中服务仍然保持服务的连续性，升级对外界是无感知的。那生产上选择哪种部署方法最合适呢？这取决于哪种方法最适合你的业务和技术需求。如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用。
蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。
灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。
滚动发布：按批次停止老版本实例，启动新版本实例。
三:Nexus3 搭建 maven 私服
1.Nexus3 简介
Maven是一个采用纯Java编写的开源项目管理工具.
Maven采用了一种被称之为Project Object Model(POM)概念来管理项目，所有的项目配置信息都被定义在一个叫做POM.xml的文件中,。
通过该文件Maven可以管理项目的整个生命周期，包括清除、编译，测试，报告、打包、部署等等。
目前Apache下绝大多数项目都已经采用Maven进行管理. 而Maven本身还支持多种插件, 可以方便更灵活的控制项目, 开发人员的主要任务应该是关注商业逻辑并去实现它, 而不是把时间浪费在学习如何在不同的环境中去依赖jar包,项目部署等。
maven和ant都是软件构建工具（软件管理工具),maven比ant更加强大，已经取代了ant,jar包的声明式依赖描述，maven有jar包的仓库。
Nexus3私服是架设在局域网的一种特殊的远程仓库，目的是代理远程仓库及部署第三方构件。有了私服之后，当 Maven 需要下载构件时，直接请求私服，私服上存在则下载到本地仓库；否则，私服请求外部的远程仓库，将构件下载到私服，再提供给本地仓库下载。

2.安装 maven
1、下载 maven
[root@qfedu.com ~]# wget http://mirrors.tuna.tsinghua.edu.cn/apache/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
2、解压安装
[root@qfedu.com ~]# tar xf apache-maven-3.6.3-bin.tar.gz -C /usr/local/
[root@qfedu.com ~]# cd /usr/local/
[root@qfedu.com ~]# ln -s apache-maven-3.6.3/ maven
3、安装 java 环境
[root@qfedu.com ~]# tar xf jdk-8u201-linux-x64.tar.gz -C /usr/local/
[root@qfedu.com ~]# cd /usr/local/
[root@qfedu.com ~]# ln -s jdk1.8.0_251/ java
4、添加环境变量
[root@qfedu.com ~]# vim /etc/profile
在文件下方添加如下内容（这里的MAVEN_HOME需要改为你自己的maven解压目录）
export JAVA_HOME=/usr/local/java
export MAVEN_HOME=/usr/local/maven
export JRE_HOME=/usr/local/java/jre
export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH
export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$MAVEN_HOME/bin:$PATH
重载环境变量
[root@qfedu.com ~]# source /etc/profile
5、验证 java 和 maven 安装
[root@localhost ~]# java -version
java version “1.8.0_191”
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
[root@localhost ~]# mvn -v
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/maven
Java version: 9.0.1, vendor: Oracle Corporation, runtime: /usr/local/java
Default locale: en_US, platform encoding: UTF-8
OS name: “linux”, version: “3.10.0-693.el7.x86_64”, arch: “amd64”, family: “unix”
3.安装 nexus3
1、下载
由于专业版的nexus是收费的，所以我下载的是开源版 Nexus OSS,下载地址为 :
https://help.sonatype.com/repomanager3/download/download-archives—-repository-manager-3
[root@localhost ~]# cd /opt/
[root@localhost opt]# wget http://download.sonatype.com/nexus/3/nexus-3.24.0-02-unix.tar.gz
2、解压
[root@qfedu.com ~]# tar -zxf nexus-3.24.0-02-unix.tar.gz -C /usr/local
解压后会多出两个目录，nexus-3.24.0-02和sonatype-work
3、启动
[root@qfedu.com ~]# cd nexus-3.24.0-02/bin/
[root@qfedu.com ~]# ./nexus start
看到如图所示内容表明我们已经启动成功了，游览器输入http://localhost:8081即可访问。
注意：
启动后如果你立即访问可能发现什么都没有，不要急这个启动需要一定时间，30秒后到1分钟后再尝试访问，这个开始我以为出问题了

注意 ：
点击右上角的sign in登录，新版首次登录需要
cat /usr/local/sonatype-work/nexus3/admin.password
获取密码。

4、仓库介绍

按图中标识顺序点击，就可以看到有这些仓库，现在分别介绍它们，分为三种类型：
proxy：是远程仓库的代理。比如说在nexus中配置了一个central repository的proxy，当用户向这个proxy请求一个artifact，这个proxy就会先在本地查找，如果找不到的话，就会从远程仓库下载，然后返回给用户，相当于起到一个中转的作用。　　　　
Hosted：是宿主仓库，用户可以把自己的一些构件，deploy到hosted中，也可以手工上传构件到hosted里。比如说oracle的驱动程序，ojdbc6.jar，在central repository是获取不到的，就需要手工上传到hosted里，一般用来存放公司自己的jar包；
Group：是仓库组，在maven里没有这个概念，是nexus特有的。目的是将上述多个仓库聚合，对用户暴露统一的地址，这样用户就不需要在pom中配置多个地址，只要统一配置group的地址就可以了右边那个Repository Path可以点击进去，看到仓库中artifact列表。不过要注意浏览器缓存，当你的项目希望在多个repository使用资源时就不需要多次引用了，只需要引用一个group即可。
maven-public：maven-central、maven-release和maven-snapshot三个库的合集。
maven-release：用来存放release版本的jar包。
maven-snapshot：用来存放snapshot版本的jar包。

5、向 nexus3 私服上传 jar 包

1、准备环境
1、创建3rd_part库

点击左侧的 repository\repositories 后,在右侧点击 create repository

然后选择maven2(hosted),填写如下

跳到首页后选择maven-public

将3rd_part移到member中,即将3rd_part由maven-public管理，点击save

至此,创建仓库完成
2、创建 3rd_part 管理用户
创建用户: 用户名/密码-dev/dev123

2、直接浏览器
使用dev/dev123登陆，点击upload

填写上传jar包的信息后，点击upload


可以看到已经上传成功