「灰度发布JAVA」灰度发布方案

今天给各位分享灰度发布JAVA的知识，其中也会对灰度发布方案进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、全链路压测流量模型
• 2、服务优雅下线
• 3、什么是JAVA开发环境，测试环境及生产环境，及它的过程
• 4、灰度发布（一）

全链路压测流量模型

现在全链路越来越火，各大厂商也纷纷推出了自己的全链路压测测试方案。特别是针对全链路压测流量模型，各家方案都有所不同。最近我看了一些这方面的资料，有一些感悟。分享给大家。

全链路压测流量模型的梳理呢，这里就先不讲了，各家公司自有司情在。因为主要是全链路压测模型的实现，其实实现也对应了流量模型的梳理结果。

业界常用的三种方一种：是基于业务模型的实现，一种是基于真实流量的录制回放，最后一种是灰度分流。

这个是一种比较常用的方式。首先要对公司业务模型进行梳理，也就是说对公司的业务链路进行梳理。这里的业务链路可能会比较复杂，不是像很多案例中到的了就非常流行畅的一条链路，中间很有可能会出现各种各样的支路。如果图图形化展示的话，某一条链路应该就是一个树形结构。树形结构的开始是用户的入口页一般就是入口页面的登陆，或者说是首页接口。树形结构的右侧是用户的出口，这里根据业务模型不同，用户的出口会非常的多，所以大多数来时候来讲，这就是一个分叉的树形结构。

要对这样的流量模型进行实现。是比较困难的。首先要梳理出这样的业务模型，就不太容易，再加上接口的相互调用啊，数据之间的相互依赖又可能是复杂程度增加一个量级。所以一般的实现方式就是做归拢。将比较复杂的树形结构简单化，或者干脆将以个业务联络分解成n个列有链路。然后分别实现。最终将流量汇聚，就变成了整个业务链路的流量模型实现。

在业务模型实现这个方向，各家都有不同的实现方式啊，基本上就分为工具以及脚本实现。我自己不怎么用工具做过接口的性能测试，全都是使用java和groovy脚本去实现的。首先，我会实现一个基于接口的业务测试框架，将每一个接口封装成一个方法。接口的参数即是这个方法的参数。然后将每一个用户封装成一个对象。将用户的各种信息变成这个对象的属性。然后用户在请求不同的接口的时候对用户的属性进行赋值这样就达到了一个参数传递的目的。然后通过调用不同的方法，我们就可以实现对不同接口的请求。通过控制参数或者说接口请求的频率，我们就可以达到控制当前用户。在整个业务链的走向。

基于流量录制和回放，这个是最容易实现的方式。也是最容易贴近真实情况的方式。哦，我接触到的主要有一个回放模型，就是用golang语言写的goreply。go语言的性能是非常好的，用于性能测试足够满足用户的需求。大多数公司都会选择在原生引擎的基础上做一些封装。然后对对业务进行一些兼容，最主要的还是适配流量来源。通常流量的来源是通过日志文件来获取的，但是我看行业内也有通过一些固定的流量存储分析引擎去完成。这里的技术我不是太熟，也就不多分享啦。

我觉得基于流量录制回放这种模式有一个比较难以解决的问题：流量的不可见性。一般来说，录制流量会非常大。介于几十万上百万之间。这么规模大的流量，是很难对他进行可视化的。常遇到的一个问题，就是对于一些请求量非常小的接口。录制的时候可能会录丢。还有一种就是录制流量的时间范围不会太广。那么录制出来的流量文件只能反映录制时的流量模型，并不能反映其他录制时间段的流量模型。如果某个服务的流量是根据时间变化的。那么就需要对多个时间段都录制流量，然后进行合并。由于流量的不可见性，所以对流量的模型进行分析，就会显得比较麻烦。

这是我在某个会议上看到大佬分享的一个方案。灰度大家听的可能比较多的是灰度发布。就是将服务或者app更新范围限制在某些一批人，或者说某个地理范围。这里讲的灰度分流，其实核心上差不多，就是将线上的一部分流量转到某些机器上。以实现对这些机器所在服务的一些压测。这种方案。基于线上流量完成，所以几乎不需要测试。投入过多的资源进行开发实现。这种方案有点儿基于业务模型和基于流量录制取了一个中间态。既能保证流量的真实有效性。又可以避免开发测试脚本带来的负担。

这种方式对于公司的架构，主或者说是分流的实现来说，技术难度是比较高的。因为他用的全都是用户的真实数据，所以一旦出现问题的话，这个问题影响范围不太可控，而且比较严重。对于接收灰度分流流量的机器来说，压测流量完全真实。但是他也无法避免基于流量录制，回放同样的问题。就是流量的不可见性以及流量与时间可能存在于一个关联关系并不是线性的。甚至这一点流量的灰度分流还不如流量的录制与回放。我想这也是。我身边接触到的公司，都没有采用这种方案的原因吧。

服务优雅下线

在生产环境中，如何保证在服务升级的时候，不影响用户的体验，这个是一个非常重要的问题。如果在我们升级服务的时候，会造成一段时间内的服务不可用，这就是不够优雅的。那什么是优雅的呢？主要就是指在服务升级的时候，不中断整个服务，让用户无感知，进而不会影响用户的体验，这就是优雅的。

实际上，优雅下线是目标，而不是手段，它是一个相对的概念，例如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端点，可以借助它实现优雅停机。

使用方式：在想下线应用的application.yml中添加如下配置，从而启用并暴露/shutdown端点：

发送 POST 请求到/shutdown端点

curl -X http://你想停止的服务地址/actuator/shutdown

该方式本质和方式一是一样的，也是借助 Spring Boot 应用的 Shutdown hook 去实现的。

方式三：/pause端点

Spring Boot 应用提供了/pause端点，利用该端点可实现优雅下线。

使用方式：在想下线应用的application.yml中添加配置，从而启用并暴露/pause端点：

发送 POST 请求到/actuator/pause端点：

curl -X POST http://你想停止的服务实例地址/actuator/pause

该应用在 Eureka Server 上的状态会被标记为DOWN，但是应用本身其实依然是可以正常对外服务的。在 Spring Cloud 中，Ribbon 做负载均衡时，只会负载到标记为UP的实例上。

利用这两点，你可以：先用/pause端点，将要下线的应用标记为DOWN，但不去真正停止应用；然后过一定的时间（例如 90 秒，或者自己做个监控，看当前实例的流量变成 0 后）再去停止应用，例如kill应用。

方式四：/service-registry端点

使用方式：在想下线应用的application.yml中添加配置，从而暴露/service-registry端点：

发送 POST 请求到/actuator/service-registry端点：

在上文中，我们讲述了四种常见的下线方式，对比来看，方式四 是一种比较优雅的下线方式。

在实际项目中，我们可以先使用/service-registry端点，将服务标记为DOWN，然后监控服务的流量，当流量为 0 时，即可升级该服务。当然，这里假设我们部署了多个服务实例，当一个服务实例DOWN掉之后，其他服务实例仍然是可以提供服务的，如果就部署一台服务的话，那么讨论优不优雅就没那么重要了。

除了上述的下线方式之外，还有一种利用EurekaAutoServiceRegistration对象达到优雅下线的目标。

执行eurekaAutoServiceRegistration.start()方法时，当前服务向 Eureka 注册中心注册服务；

执行eurekaAutoServiceRegistration.stop()方法时，当前服务会向 Eureka 注册中心进行反注册，注册中心收到请求后，会将此服务从注册列表中删除。

到这里，我们已经介绍了两种相对优雅的下线方式了。具体如何操作，我们可以根据实际上情况进行包装，或者利用自动化的脚本来实现更加优雅的下线方式。

什么是JAVA开发环境，测试环境及生产环境，及它的过程

1、开发环境

顾名思义，开发同学开发时使用的环境，每位开发同学在自己的dev分支上干活，提测前或者开发到一定程度，各位同学会合并代码，进行联调。

2、测试环境

也就是我们测试同学干活的环境啦，一般会由测试同学自己来部署，然后在此环境进行测试。bug修复后，需要发版更新测试环境来回归bug。

3、回归环境

回归bug的环境，其实就是我们的测试环境，在测试环境上测试、回归验证bug。

4、预发布环境

测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量。

预发布环境和生产环境区别：

1）预发环境中新功能为最新代码，其他功能代码和生产环境一致。

2）预发环境和生产环境的访问域名不同。

注意事项：

1）预发布环境一般会连接生产环境的数据库，测试时要注意，以免产生脏数据，影响生产环境的使用。

5、生产环境

即线上环境，用户使用的环境。由特定人员来维护，一般人没有权限去修改。

另外，还有个灰度发布，发生在预发布环境之后，生产环境之前。

生产环境一般会部署在多台机器上，以防某台机器出现故障，这样其他机器可以继续运行，不影响用户使用。灰度发布会发布到其中的几台机器上，验证新功能是否正常。如果失败，只需回滚这几台机器即可。

灰度发布（一）

一、术语

1、灰度周期，由测试/用户决定

2、金丝雀的故事

3、产品说的AB测试

4、客户端APP的灰度，版本更新交由后台控制

5、Java Agent

6、互联网APP常见的玩法

最后灰度发布是什么？

---- 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

二、灰度能做什么

1、白天发布，不用等到晚上11点，夜深人静的时候。

2、应用程序的新旧版本需要共存一段时间，用于做AB测试。

3、把新版本程序当做金丝雀，不影响真实用户的请求。

三、灰度不能做什么

1、应用程序在发布的时候，重启的时候足够安全吗，会影响线上用户吗？

2、线上灰度验证的时候，发现出问题然而开发不能及时修复，程序需要回滚，假如有已执行的数模，也需要回滚，怎么办？

3、它能够帮助我们远程断点或btrace新版本的应用程序吗？

四、灰度的实现

1、必备的条件有：

2、染色的流程

3、灰度规则

支持按流量比例和精准分配两种。精准可以是userId、IP、设备号等，只要http header能取出的key，都将支持配置到灰度规则。

4、传递灰度标识

在网关层进行打上标签，常用做法就是http header增加一个key。（kong plugin 安装灰度插件）

按链路访问顺序，由上往下进行传递，这里为了减少业务方的接入成本，采用java agent技术，做到对业务的完全透明。（java应用程序加载灰度agent的jar包）

5、灰度发布的流程

五、发布的方式有哪些

除了灰度发布，还有重要的蓝绿发布。

（灰度是允许新旧版本同时存在，蓝绿则规定在同一个环境下，要么是新版本，要么是回滚到旧版本）。

一般地，建议在预发环境下，实现蓝绿发布。在预发环境未验证通过前，预发环境是新版本，而生产环境是旧版本。

六、灰度发布带来了哪些问题

1、预期的流量是要打到灰度节点的，最后却打到正常节点了。如何核实？

现在一般的做法是通过traceId，查询kibana的日志。

2、灰度标识在全链路的整个链路传递的过程中，容易被服务或组件丢失。如何排查到底是哪个组件导致的？

3、日志与监控

日志需要采集，做法和jvm日志一样采用ELK。日志中需要包含程序的版本号、IP等关键信息。

关于灰度发布JAVA和灰度发布方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。