趁热记录下，给未来的自己
1 | 事务场景说明
要完结的事务场景：
- 能够依据单个用户id或许批量用户id，判别是否需求灰度该用户/批量用户
- 能够依据恳求头字段（可动态设定的任意kv），判别是否需求走灰度服务
2 | 具体完结计划
这儿选用 SpringCloudGateway（SCG） + Nacos + GitlabRunner 来完结整个自动化的灰度发布。
- SCG：统一的流量进口 + 正常/灰度服务选择分发逻辑处理
- Nacos：loadbalancer 提供方，经过 metadata 保护灰度服务
- GitlabRunner：灰度服务布置的自动化 CICD Pipeline 处理
下面分别从以上这三个组件来搭建。
2.1 | SCG
直接上代码，经过注释解说。
- GrayLoadBalancerClientFilter: 自界说灰度服务负载均衡过滤器
/**
* 经过GrayLoadBalancer过滤实例
*/
@Component
@Slf4j
public class GrayLoadBalancerClientFilter implements GlobalFilter, Ordered {
@Resource
private LoadBalancerClientFactory clientFactory;
@Resource
private CustomProperty customProperty;
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
URI url = exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR);
ServerWebExchangeUtils.addOriginalRequestUrl(exchange, url);
if (url == null || BizConstant.HTTP.equalsIgnoreCase(url.getScheme())) {
return chain.filter(exchange);
}
return doFilter(exchange, chain, url);
}
private Mono<Void> doFilter(ServerWebExchange exchange, GatewayFilterChain chain, URI url) {
return this.choose(exchange).doOnNext(res -> {
if (!res.hasServer()) {
throw NotFoundException.create(true, "Unable to find instance for ".concat(url.getHost()));
}
URI uri = exchange.getRequest().getURI();
String overrideScheme = null;
DelegatingServiceInstance delegatingServiceInstance = new DelegatingServiceInstance(res.getServer(), overrideScheme);
URI reqUrl = this.reconstructURI(delegatingServiceInstance, uri);
if (log.isDebugEnabled()) {
log.debug("GrayLoadBalancerClientFilter url chosen: {}", reqUrl.toString());
}
exchange.getAttributes().put(ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR, reqUrl);
}).then(chain.filter(exchange));
}
private URI reconstructURI(DelegatingServiceInstance delegatingServiceInstance, URI originalUri) {
return LoadBalancerUriTools.reconstructURI(delegatingServiceInstance, originalUri);
}
private Mono<Response<ServiceInstance>> choose(ServerWebExchange exchange) {
URI uri = exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR);
if (uri == null) {
throw new MMException("{} is null", ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR);
}
GrayLoadBalancer loadBalancer = new GrayLoadBalancer(clientFactory.getLazyProvider(uri.getHost(), ServiceInstanceListSupplier.class), uri.getHost(), customProperty);
return loadBalancer.choose(this.createRequest(exchange));
}
private Request createRequest(ServerWebExchange exchange) {
return new DefaultRequest(exchange.getRequest().getHeaders());
}
@Override
public int getOrder() {
return FILTER_ORDER_GRAY;
}
}
NOTE
FILTER_ORDER_GRAY 是一个 int 常量，其值不能随意界说(如-1,0,1,2之类)。从下表能够看到，SCG 的 LoadBalancerClientFilter 履行次序是 10100，那么 GrayLoadBalancerClientFilter 的履行次序必须 > 10100 （否则自界说的 Filter 里就会有变量未被赋值）, 这儿假定 FILTER_ORDER_GRAY = 10110
- GrayLoadBalancer: 灰度发布负载均衡战略
/**
* 灰度发布负载均衡战略
*/
@Slf4j
public class GrayLoadBalancer implements ReactorServiceInstanceLoadBalancer {
private ObjectProvider<ServiceInstanceListSupplier> serviceInstanceListSupplierProvider;
private String serviceId;
private CustomProperty customProperty;
public GrayLoadBalancer(ObjectProvider<ServiceInstanceListSupplier> serviceInstanceListSupplierProvider, String serviceId, CustomProperty customProperty) {
this.serviceId = serviceId;
this.serviceInstanceListSupplierProvider = serviceInstanceListSupplierProvider;
this.customProperty = customProperty;
}
@Override
public Mono<Response<ServiceInstance>> choose(Request request) {
HttpHeaders headers = (HttpHeaders) request.getContext();
if (this.serviceInstanceListSupplierProvider != null) {
ServiceInstanceListSupplier supplier = this.serviceInstanceListSupplierProvider.getIfAvailable(NoopServiceInstanceListSupplier::new);
return supplier.get().next().map(item -> getInstanceResponse(item, headers));
}
return null;
}
private Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> instances, HttpHeaders headers) {
if (instances.isEmpty()) {
return getServiceInstanceEmptyResponse();
}
return getServiceInstanceResponseByUidsOrGrayTag(instances, headers);
}
/**
* 从nacos获取服务实例列表，并依据战略回来灰度服务的实例还是正常服务的实例
*/
private Response<ServiceInstance> getServiceInstanceResponseByUidsOrGrayTag(List<ServiceInstance> instances, HttpHeaders headers) {
List<ServiceInstance> grayInstances = new ArrayList<>();
List<ServiceInstance> normalInstances = new ArrayList<>();
for (ServiceInstance instance : instances) {
Map<String, String> metadata = instance.getMetadata();
// nacos元数据包含“gray-tag”的key值,且value="true"，则判定为灰度实例
String isGrayInstance = metadata.get(BizConstant.GRAY_TAG);
if (BizConstant.TRUE.equals(isGrayInstance)) {
grayInstances.add(instance);
} else {
normalInstances.add(instance);
}
}
//没有灰度服务，直接回来
if (grayInstances.isEmpty()) {
return new DefaultResponse(chooseOneInstance(normalInstances));
}
//有灰度服务，判别是否需求灰度
if (checkIfNeedGray(headers)) {
log.info("gray service of {} will be called", this.serviceId);
return new DefaultResponse(chooseOneInstance(grayInstances));
}
return new DefaultResponse(chooseOneInstance(normalInstances));
}
/**
* 从实例列表中获取其中一个实例的战略完结，这儿选用的是随机挑选
* pick strategy 能够依据事务需求，在这个方法里改写
*/
private ServiceInstance chooseOneInstance(List<ServiceInstance> serviceInstances) {
// strategy 1：可用的里面随机选择一个
int size = serviceInstances.size();
if (size == 1) {
return serviceInstances.get(0);
}
Random rand = new Random();
int random = rand.nextInt(size);
return serviceInstances.get(random);
}
/**
* 灰度判别逻辑：
* 1. 判别恳求header里是否用灰度标识的 kv，有则走灰度服务
* 2. 假如 1 不满意，则判别恳求的用户 id 是否在灰度用户池中，有则走灰度服务
* 3. 1 和 2 都不满意，走正常服务
*/
private boolean checkIfNeedGray(HttpHeaders headers) {
String grayTag = headers.getFirst(BizConstant.GRAY_TAG);
if (grayTag != null) {
if (BizConstant.TRUE.equalsIgnoreCase(grayTag)) {
// todo 可扩展点：目前是只判别header里是否有BizConstant.GRAY_TAG的kv不为空且v="true"，后面v能够改为版别号
return true;
}
}
String uid = headers.getFirst(BizConstant.UID);
if (uid != null && customProperty.getGraySetting().getGrayUids().contains(uid)) {
return true;
}
return false;
}
private Response<ServiceInstance> getServiceInstanceEmptyResponse() {
log.warn("No servers available for service: " + this.serviceId);
return new EmptyResponse();
}
}
- Https2HttpFilter：将进入网关的 https 恳求转换为 http 恳求
/**
* https scheme to http
*/
@Component
@Slf4j
public class Https2HttpFilter implements GlobalFilter, Ordered {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
ServerHttpRequest request = exchange.getRequest();
URI originalUri = request.getURI();
ServerHttpRequest.Builder mutate = request.mutate();
String forwardUri = request.getURI().toString();
if (forwardUri != null && forwardUri.startsWith(BizConstant.HTTPS)) {
try {
URI mutatedUri = new URI(BizConstant.HTTP,
originalUri.getUserInfo(),
originalUri.getHost(),
originalUri.getPort(),
originalUri.getPath(),
originalUri.getQuery(),
originalUri.getFragment());
mutate.uri(mutatedUri);
} catch (Exception e) {
log.error(e.getMessage());
throw new MMException("Https related error");
}
}
ServerHttpRequest build = mutate.build();
return chain.filter(exchange.mutate().request(build).build());
}
@Override
public int getOrder() {
return FILTER_ORDER_HTTPS_2_HTTP;
}
}
NOTE
FILTER_ORDER_HTTPS_2_HTTP 是一个 int 常量，需求满意 LoadBalancerClientFilter 的履行次序(10100) < FILTER_ORDER_HTTPS_2_HTTP < FILTER_ORDER_GRAY (10110)。这儿能够假定 FILTER_ORDER_HTTPS_2_HTTP = 10105。之所以需求加一个Https2HttpFilter 过滤器，是因为假如 https 恳求直接进入到 GrayLoadBalancerClientFilter 会报 NotSslRecordException 证书过错。
2.2 | Nacos
Nacos 主要做一件事情：经过 metadata 保护灰度服务。
经过 webUI 的修改按钮能够实时的新增修改 metadata。
那么，如何在代码侧装备呢？
能够直接在bootstrap.yml添加以下字段：
spring:
cloud:
nacos:
discovery:
metadata:
# 假如${gray}变量不存在，则gray-tag=false
gray-tag: ${gray:false}
2.3 | GitlabRunner
gitlab-runner 主要是 kube_deploy.yml 和 .gitlab-ci.yml 的一个联动装备
- kube_deploy.yml添加以下环境变量：
apiVersion: apps/v1
kind: Deployment
metadata:
name: ccc-deploy
namespace: ccc
spec:
template:
spec:
containers:
- env:
- name: gray
value: "gray-tag" # 这儿的gray-tag值 将会在在.gitlab-ci.yml的脚本中被替换
- .gitlab-ci.yml 灰度服务布置 gitlab-runner 脚本要害部分：
...
stages:
- k8s-deploy
k8s-deploy-gray-service:
stage: k8s-deploy
script:
- echo "=============== 开始 k8s 布置使命 ==============="
- sed -i "s/gray-tag/true/g" kube_deploy.yml # 这
- kubectl apply -f kube_deploy.yml
only:
- /^tag_gray_.*$/
k8s-deploy-normal-service:
stage: k8s-deploy
script:
- echo "=============== 开始 k8s 布置使命 ==============="
- sed -i "s/gray-tag/false/g" kube_deploy.yml # 这儿替换 gray-tag 为 false
- kubectl apply -f kube_deploy.yml
only:
- /^tag_normal_.*$/
...
此刻，当打了一个以 tag_gray_ 开始的 tag 之后，kube_deploy.yml里的gray-tag就会被替换成 true，那么，nacos 的元数据上就会有一个gray-tag=true的标签，就会走灰度服务的发布流程。同理，以 tag_normal_ 开始的 tag，就会走正常服务的发布流程。
把这段脚本嵌入到 pipeline 之后，就能够经过 tag 的方式，自动化布置灰度/正常服务了。
3 | 后续 TODO
目前完结的是后端服务的灰度发布，一个完整的灰度，还包含了前端运用的灰度，后续会就前端的灰度发布再做一次收拾。
4 | 运用版别说明
实战依靠版别
| Group | Spring Cloud | Spring Cloud | Spring Cloud | Spring Cloud Alibaba Nacos | Spring Cloud Alibaba Nacos |
|---|---|---|---|---|---|
| Component | Hoxton.SR3 | Gateway | LoadBalancer | Config | Discovery |
| Version | – | 2.2.2.RELEASE | 2.2.2.RELEASE | 2.2.5.RELEASE | 2.2.5.RELEASE |
需求留意的
在 Spring Cloud 全家桶中，开始的网关运用的是 Netflix 的 Zuul 1x 版别，但是由于其功能问题，Spring Cloud 在苦等 Zuul 2x 版别未果的情况下，推出了自家的网关产品，取名叫 Spring Cloud Gateway （以下简称 SCG)，根据Webflux，经过底层封装Netty，完结异步IO，大大地提示了功能。
Zuul 1x 版别
本质上就是一个同步Servlet，选用多线程堵塞模型进行恳求转发。简单讲，每来一个恳求，Servlet容器要为该恳求分配一个线程专门负责处理这个恳求，直到响应回来客户端这个线程才会被释放回来容器线程池。假如后台服务调用比较耗时，那么这个线程就会被堵塞，堵塞期间线程资源被占用，不精干其它事情。我们知道Servlet容器线程池的大小是有限制的，当前端恳求量大，而后台慢服务比较多时，很容易耗尽容器线程池内的线程，形成容器无法接受新的恳求。且不支持任何长连接，如websocket
NOTE 由于两个网关的底层架构不一致，负载均衡的逻辑也彻底不一致，本文只讨论 Spring Cloud Gateway 配合 Nacos 来完结灰度发布（ Spring Cloud Zuul 网关的灰度发布不打开）。
至此，结合 SpringCloudGateway + Nacos + GitlabRunner 的全自动灰度服务搭建和发布实战全部完结。
开启成长之旅！这是我参加「日新计划 2 月更文挑战」的第 2 天，点击检查活动详情
