汽车生产线下线检测仪(EOL)的功能和概述。
 
   不知道是中国汽车整车企业的落后，造成了汽车配套厂家产品及技术的落后；还是相反，由于汽车配套厂家的技术及产品落后，造成了中国整车企业的落后。就像先有蛋，还是先有鸡一样，争论过来争论过去，总是没有一个定论。
 
    由来的汽车，从整体来说，还是以机械为主体的一个机械，但是随着电子技术的飞速发展，现在的汽车，月来越不像是原来的汽车了。原来的汽车，出了发电机，车灯外，基本上没有什么跟电发生联系的地方。现在呢，随便找个地方，跟电的联系都很紧密。发动机，电喷的；变速箱，自动的，底盘，高级些的电控，车门窗，电动的，转向系统，电动的，座椅，电动的。奥，很多了，太多了，都是电控或者电动的。
 
   我原来在一汽实习的时候，见到的是90年代算是比较先进的平头卡车，组装完成，下线的时候，检测的时候，就是看看各个车灯的情况，看看收音机的播放情况，ok，开到停车场即可。但是现在的车辆呢，这么多的电子元器件，这么多的控制器，如何进行车辆的下线检测呢？这是个问题。。。。。。
 
   国外的一些汽车厂商，根据实际的需求，对自己的配套厂商，提出了比较原始的要求，能够在下线的时候检测加装在车辆上的电子系统，提高产品的质量，提高产品的合格率，最主要的原因很多电子系统，在静态的情况下，并不能体现出电子系统的功能。就像安全气囊，在静态的情况下，怎么知道其控制系统的好坏呢？他的原理就是加速度传感器测试到达到自己原定参数的加速度后，启动引爆程序，产生气体，实现保护。要测试的话，就要设计一套电路，对安全气囊电路运行情况进行模拟测试，就很容易得出合格与否的结论。
 
  其他的电路，跟上面说的相类似。在国外，都有一套专门的测试电路，这些电路整理成一套东西，就是题目所说整车下线检测系统了，当然了，实际的系统，还是比这要复杂些的。
 --------------------- 
 作者：lgy9666 
 来源：CSDN 
 原文：https://blog.csdn.net/lgy9666/article/details/4344591 
 版权声明：本文为博主原创文章，转载请附上博文链接！
 
 
 
整车 EOL 下线诊断系统
 
https://blog.csdn.net/Hirain1234/article/details/83025472

 
文章目录
 
主观下线
客观下线
选举领头Sentinel
故障转移
修改从服务器的复制目标
 

 
主观下线
 
 
默认情况下，Sentinel哨兵会以每秒一次的频率向所有与它创建命令连接的实例（包括主服务器、从服务器、其他Sentinel）发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。
 
 
 
收到的有效回复为+PONG、-LOADING、-MASTERDOWN命令，其余都是无效回复（包括没有回复的）。
 
 
如果在down-after-milliseconds毫秒以内，sentinel收到的都是无效回复，那么这个源sentinel就会认为实例进入主观下线状态（就是自己认为的），同时修改实例结构中的flags属性，改为SRI_S_DOWN（主观下线的标志）
 
 
 
 
down-after-milliseconds毫秒不仅会成为Sentinel判断master进入主观下线的标准，还会成为Sentinel判断master 属下所有从服务器，以及所有同样监视master 的其他Sentinel进入主观下线的标准。
 
 
多个Sentinel设置的主观下线时长可能不同
 down-after-milliseconds 选项另一个需要注意的地方是，对于监视同一个主服务器的多个Sentinel来说，这些Sentinel所设置的down-after-milliseconds 选项的值也可能不同，因此，当一个Sentinel将主服务器判断为主观下线时，其他Sentinel可能仍然会认为主服务器处于在线状态。举个例子，如果Sentinell载入了以下配置:
 sentinel monitor master 127.0.0.1 6379 2
 sentinel down-after-milliseconds master 50000
 而Sentinel2则载入了以下配置:
 sentinel monitor master 127.0.0.16379 2
 sentinel down-after-milliseconds master 10000
 那么当master 的断线时长超过10000毫秒之后，Sentinel2会将master 判断为主观下线，而Sentinell却认为master仍然在线。只有当master的断线时长超过50000毫秒之后，Sentinel1和 Sentinel2才会都认为master进入了主观下线状态。
 
客观下线
 
当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了，它会向同样监视这一主服务器的其他Sentinel进行询问，看它们是否也认为主服务器已经进入了下线状态（可以是主观下线或者客观下线)。当Sentinel 从其他Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将从服务器判定为客观下线，并对主服务器执行故障转移操作。
根据其他Sentinel发回的SENTINEL is-master-down-by-addr命令回复，Sentinel将统计其他Sentinel同意主服务器已下线的数量，当这一数量达到配置指定的判断客观下线所需的数量时，Sentinel 会将主服务器实例结构flags属性的SRI_O_DOwN标识打开，表示主服务器已经进入客观下线状态，如下图
 
 
 
 
判断客观下线的数量是Sentinel配置参数中的quorum参数，超过这个值就会被认为客观下线。因为各个Sentinel中的quorum参数可能不同，也就是说对同一个实例，有的可能认为它已经下线了，有的认为它没有下线
 
 
选举领头Sentinel
 
当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头 Sentinel，并由领头Sentinel对下线主服务器执行故障转移操作。
 以下是Redis选举领头Sentinel的规则和方法:
 
所有在线的Sentinel都有被选为领头Sentinel的资格，换句话说，监视同一个主服务器的多个在线Sentinel 中的任意一个都有可能成为领头 Sentinel。
每次进行领头Sentinel选举之后，不论选举是否成功，所有Sentinel的配置纪元( configuration epoch)的值都会自增一次。配置纪元实际上就是一个计数器，并没有什么特别的。
在一个配置纪元里面，所有Sentinel都有一次将某个Sentinel 设置为局部领头Sentinel的机会，并且局部领头一旦设置，在这个配置纪元里面就不能再更改。
每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel。
当一个Sentinel(源Sentinel)向另一个Sentinel (目标Sentinel）发送SENTINELis-master-down-by-addr命令，并且命令中的runid参数不是*符号而是源Sentinel的运行ID时，这表示源Sentinel要求目标Sentinel将前者设置为后者的局部领头 Sentinel。
Sentinel设置局部领头 Sentinel的规则是先到先得:最先向目标Sentinel 发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel，而之后接收到的所有设置要求都会被目标Sentine1拒绝。
目标Sentinel在接收到SENTINEL is-master-down-by-addr命令之后，将向源Sentinel返回一条命令回复，回复中的leader_runid参数和leader_epoch参数分别记录了目标Sentinel的局部领头Sentinel的运行ID和配置纪元。
源Sentinel在接收到目标Sentinel返回的命令回复之后，会检查回复中leader_epoch参数的值和自己的配置纪元是否相同，如果相同的话，那么源Sentinel继续取出回复中的leader_runid参数，如果leader_runid参数的值和源Sentinel的运行ID一致，那么表示目标Sentinel将源Sentinel设置成了局部领头Sentinel。
如果有某个Sentinel被半数以上的Sentinel设置成了局部领头 Sentinel，那么这个Sentinel成为领头entinel。举个例子，在一个由10个Sentinel组成的Sentinel系统里面，只要有大于等于10/2+1=6个Sentinel将某个Sentinel设置为局部领头Sentinel，那么被设置的那个Sentinel就会成为领头Sentinel。
因为领头Sentinel的产生需要半数以上Sentinel的支持，并且每个Sentinel在每个配置纪元里面只能设置一次局部领头 Sentinel，所以在一个配置纪元里面，只会出现一个领头 Sentinel。
如果在给定时限内，没有一个Sentinel被选举为领头Sentinel，那么各个Sentinel将在一段时间之后再次进行选举，直到选出领头 Sentinel 为止。
 
故障转移
 
在选举产生出领头Sentinel之后，领头Sentinel将对已下线的主服务器执行故障转移操作，该操作包含以下三个步骤:
 
在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器。
让已下线主服务器属下的所有从服务器改为复制新的主服务器。
将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器。
 
 
 
新的主服务器是怎样挑选出来的
 领头Sentinel会将已下线主服务器的所有从服务器保存到一个列表里面，然后按照以下规则，一项一项地对列表进行过滤:
 1）删除列表中所有处于下线或者断线状态的从服务器，这可以保证列表中剩余的从服务器都是正常在线的。
 2）删除列表中所有最近五秒内没有回复过领头Sentinel的INFO命令的从服务器，这可以保证列表中剩余的从服务器都是最近成功进行过通信的。
 3）删除所有与已下线主服务器连接断开超过down-after-milliseconds * 10毫秒的从服务器:down-after-milliseconds 选项指定了判断主服务器下线所需的时间，而删除断开时长超过down-after-milliseconds * 10毫秒的从服务器，则可以保证列表中剩余的从服务器都没有过早地与主服务器断开连接，换句话说，列表中剩余的从服务器保存的数据都是比较新的。
 之后，领头Sentinel将根据从服务器的优先级，对列表中剩余的从服务器进行排序，并选出其中优先级最高的从服务器。
 如果有多个具有相同最高优先级的从服务器，那么领头Sentinel将按照从服务器的复制偏移量，对具有相同最高优先级的所有从服务器进行排序，并选出其中偏移量最大的从服务器（复制偏移量最大的从服务器就是保存着最新数据的从服务器)。
 最后，如果有多个优先级最高、复制偏移量最大的从服务器，那么领头 Sentinel将按照运行ID对这些从服务器进行排序，并选出其中运行ID最小的从服务器。
 
 
在领头Sentinel向被选中的从服务器发送SLAVEOF no one命令之后，领头Sentinel会以每秒一次的频率(平时是每十秒一次)，向被升级的从服务器发送INFO命令，并观察命令回复中的角色( role)信息，当被升级服务器的role从原来的slave变为master时，领头Sentinel就知道被选中的从服务器已经顺利升级为主服务器了。如下图
 
 
修改从服务器的复制目标
 
领头Sentinel向向从服务器发送SLAVEOF命令，让他们复制新的主服务器。
 
最后将下线的主服务器设置为从服务器，如果重新上线，就会成为新主服务器的从服务器
 

前言
 
其实所说的被挤下线功能，就是一个账号在A客户端保持登陆状态，然后又在B客户端进行了登陆操作，那么A客户端就会被顶下线
 
 
 
很多伙伴在开发自己公司产品的时候，一般都会考虑用户账号安全，或者用户账号功能限制等问题，这时候就要考虑到单点登陆的功能
 
 
 
使用
 
App如何知道该账户已经在其他设备上登陆了呢？有三种实现方式
 
api请求中后台返回特定的code。缺点是需要下次请求才知道被踢下线
使用推送。后台可以推送给APP，从而使APP得知已在其他地方登陆，可以及时响应
我们的项目中集成了环信的即时聊天，所以就使用了环信的监听器监听用户状态，用来判断是否已在其他地方登陆，实现挤下线功能
 
服务端需要返回 Token,每次在app登录时为 app 分配一个新的 token,如果在某次请求中 app 传递 token不是最新的,则视为需要重新登录，在token失效的情况下,返回约定好的code
 
环信
 
使用第三方的监听器。比如集成了环信，环信自身有提供连接状态的接听,通过监听环信的用户状态,从而达到监听app自身用户系统的效果
 
我们的项目中集成了环信的即时聊天，所以就使用了环信的监听器监听用户状态，用来判断是否已在其他地方登陆，实现挤下线功能。
 
具体实现： 
 1.首先在初始化环信的时候设置一个全局的监听器里面注册一个连接监听
 
// 注册连接监听
EMChatManager.getInstance()
.addConnectionListener(connectionListener);
 
2.实现这个连接监听的那个检测到连接断开的时候是用户被移除还是连接冲突即账号在其他地方登陆，做出相应的操作
 
// create the global connection listener
connectionListener = new EMConnectionListener() {
    @Override
    public void onDisconnected(int error) {
        if (error == EMError.USER_REMOVED) {
            onCurrentAccountRemoved();
        } else if (error == EMError.CONNECTION_CONFLICT) {
            onConnectionConflict();
        }
    }
    @Override
    public void onConnected() {
        // in case group and contact were already synced, we supposed to
        // notify sdk we are ready to receive the events
    }
};
 
3.我们关心账号在别处登陆，这个时候，我们一般要条红钻到MainActivity，然后强制弹出对话框提示用户重新登陆
 
/**
* 账号在别的设备登录
*/
protected void onConnectionConflict() {
    Intent intent = new Intent(appContext, MainActivity.class);
    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    intent.putExtra(Constant.ACCOUNT_CONFLICT, true);
    appContext.startActivity(intent);
}
 
这个地方检测到登陆冲突之后需要回到MainActivity，并为MainActivity携带了一个标识和一个标记位Intent.FLAG_ACTIVITY_TASK,表示在一个新的task中开启一个Activity,如果包含这个Activity的task已经在运行，那么这个Activity就回到前台显示，然后回调onNewIntent（）方法处理这个Intent 
 4.回到MainActivity中的onNewIntent()方法
 
@Override
protected void onNewIntent(Intent intent) {
    super.onNewIntent(intent);
    if (intent.getBooleanExtra(Constant.ACCOUNT_CONFLICT, false) && !isConflictDialogShow) {
        showConflictDialog();
    } else if (intent.getBooleanExtra(Constant.ACCOUNT_REMOVED, false)
            && !isAccountRemovedDialogShow) {
        showAccountRemovedDialog();
    }
}
 
首先会判断表示，如果时账户冲突就会提出对话框提示用户跳转登陆页面重新登陆，另外这个对话框是不能取消也不可关闭的
 
这样被顶下线功能就基本实现了
 
Token
 
1.创建一个token 
 首先我们要在服务端创建一个token的值，这个值是和userid以及手机号码绑定到一起的，也就是请求token的时候我们要给服务端传递当前设备以及用户id。token这个值就是客户端调用服务端的凭证 
 android中获取唯一标识 deviceid
 
//deviceId  
  public static String getDeviceId(Context context) {  
      TelephonyManager tm = (TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE);  
     if (tm == null) {  
         return "";  
     }  
     return "" + tm.getDeviceId();  
 }  
 
但是这个很多机器是无法获取到的这个值，所以后来改为mac地址，mac地址很好理解，就是用户上网的上网许可证，这个买手机的时候，你翻开电池就知道里面有一个标签！！
 
/** 
 * 获取MAC地址，注意：手机重启，mac地址为null； 
 *  
 * @param context 
 * @return mac地址； 
 */  
public static String getMac(Context context) {  
    if (context != null) {  
        WifiManager wifi = (WifiManager) context  
                .getSystemService(Context.WIFI_SERVICE);  
        WifiInfo info = wifi.getConnectionInfo();  
        return info.getMacAddress();  
    } else {  
        return "";  
    }  
}  
 
2.获取token 
 app进入时要先获取token,获取token的时候我们要给服务端传递当前设备的设备号，当我们换了设备后设备号变了，返回的token值也就变了，那么原设备的token相对来说就失效了，当在原设备和服务端有交互的时候会返回token失效，用户登陆注销要及时更新token值 
 3.请求交互携带token 
 每次客户端和服务端有任何交互的时候都要传递这个token参数，当我们在另一台设备登陆的时候原设备上存的token就失效了，因为数据库里当前用户的token已经在新设备获取token值的覆盖了，这样原设备请求时就回提示token值失效了 
 4.根据服务端返回码处理逻辑 
 事先客户端和服务端要约定好一个code码，咧如：我们约定返回码为99的时候代表token失效，那么当我们请求服务端返回值为99的时候就要提示您的登陆转台失效，请您重新登陆
 
switch (code) {  
    case 1:  
      break;  
    case 99://被踢下线  
      //Do Something  
      break;  
    }  
 
上面说了自己用自己的业务系统实现app单点的基本流程
 
 
总结
 
自己做些工作，运用服务端的token值完成逻辑并实现功能，还有我们可以集成三方的即时通讯sdk，这是最省事的，比如 环信sdk，腾讯云通讯sdk。这些都是有自己的监听用户状态的机制的，可以找到对应得监听直接加入自己的业务处理逻辑。

 
文章目录
 
前言
优雅下线
常见的下线方式
优雅的下线方式
   
灰度发布
蓝绿部署
滚动部署
金丝雀部署
  
 

 
前言
 
在生产环境中，如何保证在服务升级的时候，不影响用户的体验，这个是一个非常重要的问题。如果在我们升级服务的时候，会造成一段时间内的服务不可用，这就是不够优雅的。那什么是优雅的呢？主要就是指在服务升级的时候，不中断整个服务，让用户无感知，进而不会影响用户的体验，这就是优雅的。
 
实际上，优雅下线是目标，而不是手段，它是一个相对的概念，例如kill PID和kill -9 PID都是暴力杀死服务，相对于kill -9 PID来说，kill PID就是优雅的。但如果单独拿kill PID出来说，我们能说它是优雅的下线策略吗？肯定不是啊，就是这个道理。
 
因此，本文讲述的优雅下线仅能称之为“相对的优雅下线”，但相对于暴力的杀死服务，已经足够优雅了。常见的优雅解决方案，主要包括优雅下线和灰度发布。而实际上，灰度发布的范围就已经包含优雅下线了。最后，在本文中，我们主要讲述基于 Spring Cloud 和 Euraka 的优雅下线以及灰度发布。
 
优雅下线
 
常见的下线方式
 
方式一：kill PID
 
使用方式：kill java进程ID
 
该方式借助的是 Spring Boot 应用的 Shutdown hook，应用本身的下线也是优雅的，但如果你的服务发现组件使用的是 Eureka，那么默认最长会有 90 秒的延迟，其他应用才会感知到该服务下线，这意味着：该实例下线后的 90 秒内，其他服务仍然可能调用到这个已下线的实例。因此，该方式是不够优雅的 。
 
方式二：/shutdown端点
 
Spring Boot 提供了/shutdown端点，可以借助它实现优雅停机。
 
使用方式：在想下线应用的applicationyml中添加如下配置，从而启用并暴露/shutdown端点：
 
management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: shutdown
 
发送 POST 请求到/shutdown端点
 
curl -X http://你想停止的服务地址/actuator/shutdown
 
该方式本质和方式一是一样的，也是借助 Spring Boot 应用的 Shutdown hook 去实现的。
 
方式三：/pause端点
 
Spring Boot 应用提供了/pause端点，利用该端点可实现优雅下线。
 
使用方式：在想下线应用的application.yml中添加配置，从而启用并暴露/pause端点：
 
management:
  endpoint:
    # 启用pause端点
    pause:
      enabled: true
    # 启用restart端点，之所以要启用restart端点，是因为pause端点的启用依赖restart端点的启用
    restart:
      enabled: true
  endpoints:
    web:
      exposure:
        include: pause,restart
 
发送 POST 请求到/actuator/pause端点：
 
curl -X POST http://你想停止的服务实例地址/actuator/pause
 
执行后的效果类似下图：
 

 如图所示，该应用在 Eureka Server 上的状已被标记为DOWN，但是应用本身其实依然是可以正常对外服务的。在 Spring Cloud 中，Ribbon 做负载均衡时，只会负载到标记为UP的实例上。利用这两点，你可以：先用/pause端点，将要下线的应用标记为DOWN，但不去真正停止应用；然后过一定的时间（例如 90 秒，或者自己做个监控，看当前实例的流量变成 0 后）再去停止应用，例如kill应用。
 
缺点 & 局限
 
缺点
描述
不同的版本配置不大一样
早期的 Spring Cloud 版本中，pause端点是不依赖restart端点的
无法和 Eureka 的健康检查配合使用
如果你的服务发现组件用的是 Eureka，并且你的应用开启了健康检查eureka.client.healthcheck.enabled = true，那么/pause端点无效
方式四：/service-registry端点
 
使用方式：在想下线应用的application.yml中添加配置，从而暴露/service-registry端点：
 
management:
  endpoints:
    web:
      exposure:
        include: service-registry
 
发送 POST 请求到/actuator/service-registry端点：
 
curl -X "POST" "http://localhost:8000/actuator/service-registry?status=DOWN" \
   -H "Content-Type: application/vnd.spring-boot.actuator.v2+json;charset=UTF-8"
 
实行后的效果类似如下图：
 
 
优雅的下线方式
 
在上文中，我们讲述了四种常见的下线方式，对比来看，方式四 是一种比较优雅的下线方式。
 
在实际项目中，我们可以先使用/service-registry端点，将服务标记为DOWN，然后监控服务的流量，当流量为 0 时，即可升级该服务。当然，这里假设我们部署了多个服务实例，当一个服务实例DOWN掉之后，其他服务实例仍然是可以提供服务的，如果就部署一台服务的话，那么讨论优不优雅就没那么重要了。
 
除了上述的下线方式之外，还有一种利用EurekaAutoServiceRegistration对象达到优雅下线的目标。
 
执行eurekaAutoServiceRegistration.start()方法时，当前服务向 Eureka 注册中心注册服务；
执行eurekaAutoServiceRegistration.stop()方法时，当前服务会向 Eureka 注册中心进行反注册，注册中心收到请求后，会将此服务从注册列表中删除。
 
示例代码如下：
 
@RestController
@RequestMapping(value = "/graceful/registry-service")
public class GracefulOffline {

    @Autowired
    private EurekaAutoServiceRegistration eurekaAutoServiceRegistration;

    @RequestMapping("/online")
    public String online() {
        this.eurekaAutoServiceRegistration.start();
        return "execute online method, online success.";
    }

    @RequestMapping("/offline")
    public String offline() {
        this.eurekaAutoServiceRegistration.stop();
        return "execute offline method, offline success.";
    }
}
 
到这里，我们已经介绍了两种相对优雅的下线方式了。具体如何操作，我们可以根据实际上情况进行包装，或者利用自动化的脚本来实现更加优雅的下线方式。
 
灰度发布
 
蓝绿部署
 
蓝绿部署，英文名为 Blue Green Deployment，是一种可以保证系统在不间断提供服务的情况下上线的部署方式。
 
如何保证系统不间断提供服务呢？那就是同时部署两个集群，但仅对外提供一个集群的服务，当需要升级时，切换集群进行升级。蓝绿部署无需停机，并且风险较小。其大致步骤为：
 
部署集群 1 的应用（初始状态），将所有外部请求的流量都打到这个集群上
部署集群 2 的应用，集群 2 的代码与集群 1 不同，如新功能或者 Bug 修复等
将流量从集群 1 切换到集群 2
如集群 2 测试正常，就删除集群 1 正在使用的资源（例如实例），使用集群 2 对外提供服务
 
因为在使用蓝绿部署的方式时，我们需要控制流量，所以我们需要借助路由服务，如 Nginx 等。
 
滚动部署
 
滚动部署，英文名为 Rolling Update，同样是一种可以保证系统在不间断提供服务的情况下上线的部署方式。和蓝绿部署不同的是，滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。
 
如何做到细粒度平滑升级版本呢？滚动部署只需要一个集群，集群下的不同节点可以独立进行版本升级。比如在一个 12 节点的集群中，我们每次升级 4 个节点，并将升级后的节点重新投入使用，周而复始，直到集群中所有的节点都更新为新版本。
 
这种部署方式相对于蓝绿部署，更加节约资源，因为它不需要运行两个集群。但这种方式也有很多缺点，例如：
 
没有一个确定 OK 的环境。使用蓝绿部署，我们能够清晰地知道老版本是 OK 的，而使用滚动发布，我们无法确定。
修改了现有的环境。
如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新 100 个实例，每次更新 10 个实例，每次部署需要 5 分钟。当滚动发布到第 80 个实例时，发现了问题，需要回滚。这时，我们估计就要疯了。
有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。
 
并不是说滚动发布不好，滚动发布也有它非常合适的场景。
 
金丝雀部署
 
金丝雀部署又称灰度部署（或者，灰度发布），英文名为 Canary Deployment，是指在黑与白之间，能够平滑过渡的一种发布方式。
 
金丝雀的名称来源于「矿井中的金丝雀」，早在 17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感，空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
 
我们来看一下金丝雀部署的步骤：
 
准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件
从负载均衡列表中移除掉“金丝雀”服务器
升级“金丝雀”应用（切断原有流量并进行部署）
对应用进行自动化测试
将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）
如果“金丝雀”在线使用测试成功，升级剩余的其他服务器（否则就回滚）
 
在金丝雀部署中，常常按照用户量设置路由权重，例如 90% 的用户维持使用老版本，10% 的用户尝鲜新版本。不同版本应用共存，经常与 A/B 测试一起使用，用于测试选择多种方案。金丝雀部署比较典型的例子，就是我们在使用某个应用的时候，该应用邀请我们进行“内测”或者“新版本体验”，如果我们同意了，那么我们就成了金丝雀。
 
 
参考资料：
 
实用技巧：Spring Cloud中，如何优雅下线微服务？
Spring cloud系列20 实现服务优雅上下线
Spring Cloud 灰度发布解决方案
一文搞懂蓝绿部署和金丝雀发布
微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布