作者：十眠
审核 & 校对：望陶、亦盏
编辑 & 排版：雯燕

往年双 11，云原生中间件实现了开源、自研、商业化三位一体，全面降级到中间件云产品。MSE 微服务治理通过 Dubbo3.0 撑持了阿里团体外围业务双 11 的流量洪峰，截止目前团体内 50% 的用户曾经习惯应用 MSE 微服务治理 HSF 和 Dubbo3.0 利用，明天咱们来细聊一下 MSE 服务治理专业版中的全链路灰度能力，以及它在生产大规模实际的一些场景。

背景

微服务架构下，有一些需要开发，波及到微服务调用链路上的多个微服务同时产生了改变，须要通过灰度公布形式来更好地管制新版本服务上线的危险和爆炸半径。通常每个微服务都会有灰度环境或分组来承受灰度流量，咱们心愿通过进入上游灰度环境的流量，也能进入上游灰度的环境中，确保 1 个申请始终在灰度环境中传递，即便这个调用链路上有一些微服务没有灰度环境，这些利用申请上游的时候仍然可能回到灰度环境中。通过 MSE 提供的全链路灰度能力，能够在不须要批改任何您的业务代码的状况下，可能轻松实现上述能力。

MSE 微服务治理全链路灰度特点

全链路灰度作为 MSE 服务治理专业版中的拳头性能，具备以下六大特点

• 可通过定制规定引入精细化流量

除了简略地依照比例进行流量引入外，咱们还反对 Spring Cloud 与 Dubbo 流量按规定引入，Spring Cloud 流量可依据申请的 cookie、header、param 参数或随机百分比引入流量，Dubbo 流量可依照服务、办法、参数来引入。

• 全链路隔离流量泳道

1) 通过设置流量规定对所需流量进行“染色”，“染色”流量会路由到灰度机器。

2) 灰度流量携带灰度标往上游传递，造成灰度专属环境流量泳道，无灰度环境利用会默认抉择未打标的基线环境。

• 端到端的稳固基线环境

未打标的利用属于基线稳固版本的利用，即稳固的线上环境。当咱们将公布对应的灰度版本代码，而后能够配置规定定向引入特定的线上流量，管制灰度代码的危险。

• 流量一键动静切流

流量规定定制后，可依据需要进行一键停启，增删改查，实时失效。灰度引流更便捷。

• 低成本接入，基于 Java Agent 技术实现无需批改一行业务代码

MSE 微服务治理能力基于 Java Agent 字节码加强的技术实现，无缝反对市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本，用户不必改一行代码就能够应用，不须要扭转业务的现有架构，随时可上可下，没有绑定。只需开启 MSE 微服务治理专业版，在线配置，实时失效。

• 具备无损高低线能力，使得公布更加丝滑

利用开启 MSE 微服务治理后就具备无损高低线能力，大流量下的公布、回滚、扩容、缩容等场景，均能保障流量无损。

大规模生产实践的场景

本文次要介绍 MSE 微服务治理在反对大客户过程中总结形象进去的罕用的几个全链路灰度计划生产落地实际的场景。

场景一：对通过机器的流量进行主动染色，实现全链路灰度

• 进入带 tag 的节点后续调用优先选择带有雷同 tag 的节点，即对通过 tag 节点的流量进行“染色”。
• 有 tag 的调用链路上找不到雷同 tag 的节点，则 fallback 到无 tag 的节点。
• 有 tag 的调用链路通过无 tag 的节点，如果链路后续调用有 tag 的节点，则复原 tag 调用的模式。

场景二：通过给流量带上特定的 header 实现全链路灰度

客户端通过在申请中减少制订环境的标识，接入层依据示意进行转发至示意对应环境的网关，对应环境的网关通过隔离插件调用标识对应的我的项目隔离环境，申请在业务我的项目隔离环境中闭环。

场景三：通过自定义路由规定来进行全链路灰度

通过在灰度申请中减少指定的 header，且整条调用链路会将该 header 透传下去，只需在对应的利用配置该 header 相干的路由规定，带指定 header 的灰度申请进入灰度机器，即可按需实现全链路流量灰度。

全链路灰度的实际

咱们如何疾速取得上述同款全链路灰度的能力呢？上面我会带大家从 0 到 1 疾速搭建咱们的全链路灰度能力。

咱们假如利用的架构由 Ingress-nginx 以及后端的微服务架构（Spring Cloud）来组成，后端调用链路有 3 跳，购物车（a），交易中心（b），库存核心（c），他们通过 Nacos 注册核心做服务发现，客户端通过客户端或者是 H5 页面来拜访后端服务。

前提条件

装置 Ingress-nginx 组件

拜访容器服务控制台，关上利用目录，搜寻 ack-ingress-nginx，抉择命名空间 kube-system，点击创立，装置实现后，在 kube-system 命名空间中会看到一个 deployment ack-ingress-nginx-default-controller，表明装置胜利。

$ kubectl get deployment -n kube-system
NAME                                      READY   UP-TO-DATE   AVAILABLE   AGE
ack-ingress-nginx-default-controller      2/2     2            2           18h

开启 MSE 微服务治理专业版

• 点击开明 MSE 微服务治理专业版 以应用全链路灰度能力。
• 拜访容器服务控制台，关上利用目录，搜寻 ack-mse-pilot，点击创立。
• 在 MSE 服务治理控制台，关上 K8s 集群列表，抉择对应集群，对应命名空间，并关上微服务治理。

部署 Demo 应用程序

将上面的文件保留到 ingress-gray.yaml 中，并执行 kubectl apply -f ingress-gray.yaml 以部署利用，这里咱们将要部署 A, B, C 三个利用，每个利用别离部署一个基线版本和一个灰度版本。

# A 利用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-a
  name: spring-cloud-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-a
  template:
    metadata:
      annotations:
        msePilotCreateAppName: spring-cloud-a
      labels:
        app: spring-cloud-a
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-a
        ports:
        - containerPort: 20001
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 10
          periodSeconds: 30
      
# A 利用 gray 版本
---            
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-a-new
  name: spring-cloud-a-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-a-new
  strategy:
  template:
    metadata:
      annotations:
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-a
      labels:
        app: spring-cloud-a-new
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        - name: profiler.micro.service.tag.trace.enable
          value: "true"
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-a-new
        ports:
        - containerPort: 20001
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20001
          initialDelaySeconds: 10
          periodSeconds: 30
            
# B 利用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-b
  name: spring-cloud-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-b
  strategy:
  template:
    metadata:
      annotations:
        msePilotCreateAppName: spring-cloud-b
      labels:
        app: spring-cloud-b
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-b:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-b
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 10
          periodSeconds: 30
            
# B 利用 gray 版本  
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-b-new
  name: spring-cloud-b-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-b-new
  template:
    metadata:
      annotations:
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-b
      labels:
        app: spring-cloud-b-new
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-b:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-b-new
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20002
          initialDelaySeconds: 10
          periodSeconds: 30
            
# C 利用 base 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-c
  name: spring-cloud-c
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-c
  template:
    metadata:
      annotations:
        msePilotCreateAppName: spring-cloud-c
      labels:
        app: spring-cloud-c
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:0.1-SNAPSHOT
        imagePullPolicy: Always
        name: spring-cloud-c
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 10
          periodSeconds: 30
            
# C 利用 gray 版本
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: spring-cloud-c-new
  name: spring-cloud-c-new
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-cloud-c-new
  template:
    metadata:
      annotations:
        alicloud.service.tag: gray
        msePilotCreateAppName: spring-cloud-c
      labels:
        app: spring-cloud-c-new
    spec:
      containers:
      - env:
        - name: LANG
          value: C.UTF-8
        - name: JAVA_HOME
          value: /usr/lib/jvm/java-1.8-openjdk/jre
        image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:0.1-SNAPSHOT
        imagePullPolicy: IfNotPresent
        name: spring-cloud-c-new
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 20003
          initialDelaySeconds: 10
          periodSeconds: 30

# Nacos Server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nacos-server
  name: nacos-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nacos-server
  template:
    metadata:
      labels:
        app: nacos-server
    spec:
      containers:
      - env:
        - name: MODE
          value: standalone
        image: nacos/nacos-server:latest
        imagePullPolicy: Always
        name: nacos-server
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
      dnsPolicy: ClusterFirst
      restartPolicy: Always

# Nacos Server Service 配置
---
apiVersion: v1
kind: Service
metadata:
  name: nacos-server
spec:
  ports:
  - port: 8848
    protocol: TCP
    targetPort: 8848
  selector:
    app: nacos-server
  type: ClusterIP

入手实际

场景一：对通过机器的流量进行主动染色，实现全链路灰度

有时候，咱们能够通过不同的域名来辨别线上基线环境和灰度环境，灰度环境有独自的域名能够配置，假如咱们通过拜访 www.gray.com 来申请灰度环境，拜访 www.base.com 走基线环境。

调用链路 Ingress-nginx -> A -> B -> C，其中 A 能够是一个 spring-boot 的利用。

留神：入口利用 A 的 gray 和 A 的 base 环境，须要在 MSE 服务治理控制台关上 A 利用的依照流量比例透传开关，示意开启向后透传以后环境的标签的性能。这样，当 Ingress-nginx 路由 A 的 gray 之后，即便申请中没有携带任何 header，因为开启了此开关，所以往后调用的时候会主动增加 x-mse-tag:gray 这个 header，其中的 header 的值 gray 来自于 A 利用配置的标签信息。如果原来的申请中带有 x-mse-tag:gray 则会以原来申请中的标签优先。

针对入口利用 A，配置两个 k8s service, spring-cloud-a-base 对应 A 的 base 版本，spring-cloud-a-gray 对应 A 的 gray 版本。

apiVersion: v1
kind: Service
metadata:
  name: spring-cloud-a-base
spec:
  ports:
    - name: http
      port: 20001
      protocol: TCP
      targetPort: 20001
  selector:
    app: spring-cloud-a

---
apiVersion: v1
kind: Service
metadata:
  name: spring-cloud-a-gray
spec:
  ports:
    - name: http
      port: 20001
      protocol: TCP
      targetPort: 20001
  selector:
    app: spring-cloud-a-new

配置入口的 Ingress 规定，拜访 www.base.com 路由到 A 利用的 base 版本，拜访 www.gray.com 路由到 A 利用的 gray 版本。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.base.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-gray
spec:
  rules:
  - host: www.gray.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-gray
          servicePort: 20001
        path: /

后果验证

此时，拜访 www.base.com 路由到 基线环境

curl -H"Host:www.base.com" http://106.14.155.223/a
A[172.18.144.155] -> B[172.18.144.120] -> C[172.18.144.79]

此时，拜访 www.gray.com 路由到灰度环境

curl -H"Host:www.gray.com" http://106.14.155.223/a
Agray[172.18.144.160] -> Bgray[172.18.144.57] -> Cgray[172.18.144.157]

进一步的，如果入口利用 A 没有灰度环境，拜访到 A 的 base 环境，又须要在 A -> B 的时候进入灰度环境，则能够通过减少一个非凡的 header x-mse-tag 来实现，header 的值是想要去的环境的标签，例如 gray。

curl -H"Host:www.base.com"  -H"x-mse-tag:gray" http://106.14.155.223/a
A[172.18.144.155] -> Bgray[172.18.144.139] -> Cgray[172.18.144.8]

能够看到第一跳，进入了 A 的 base 环境，然而 A->B 的时候又从新回到了灰度环境。

这种应用形式的益处是，配置简略，只须要在 Ingress 处配置好规定，某个利用须要灰度公布的时候，只须要在灰度环境中部署好利用，灰度流量天然会进入到灰度机器中，如果验证没问题，则将灰度的镜像公布到基线环境中；如果一次变更有多个利用须要灰度公布，则把他们都退出到灰度环境中即可。

最佳实际

• 给所有灰度环境的利用打上 gray 标，基线环境的利用默认不打标。
• 线上常态化引流 2% 的流量进去灰度环境中
   

场景二：通过给流量带上特定的 header 实现全链路灰度

有些客户端没法改写域名，心愿能拜访 www.demo.com 通过传入不同的 header 来路由到灰度环境。例如下图中，通过增加 x-mse-tag:gray 这个 header，来拜访灰度环境。

这个时候 demo 的 Ingress 规定如下，留神这里减少了 nginx.ingress.kubernetes.io/canary 相干的多条规定

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.demo.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-gray
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "x-mse-tag"
    nginx.ingress.kubernetes.io/canary-by-header-value: "gray"
    nginx.ingress.kubernetes.io/canary-weight: "0"
spec:
  rules:
  - host: www.base.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-gray
          servicePort: 20001
        path: /

后果验证

此时，拜访 www.demo.com 路由到基线环境

curl -H"Host:www.demo.com" http://106.14.155.223/a
A[172.18.144.155] -> B[172.18.144.56] -> C[172.18.144.156]

如何拜访灰度环境呢？只须要在申请中减少一个 header x-mse-tag:gray 即可。

curl -H"Host:www.demo.com"  -H"x-mse-tag:gray" http://106.14.155.223/a
Agray[172.18.144.82] -> Bgray[172.18.144.57] -> Cgray[172.18.144.8]

能够看到 Ingress 依据这个 header 间接路由到了 A 的 gray 环境中。

更进一步

还能够借助 Ingress 实现更简单的路由，比方客户端曾经带上了某个 header，想要利用现成的 header 来实现路由，而不必新增一个 header，例如下图所示，假如咱们想要 x-user-id 为 100 的申请进入灰度环境。

只须要减少上面这 4 条规定:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.demo.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base-gray
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "x-user-id"
    nginx.ingress.kubernetes.io/canary-by-header-value: "100"
    nginx.ingress.kubernetes.io/canary-weight: "0"
spec:
  rules:
  - host: www.demo.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-gray
          servicePort: 20001
        path: /

拜访的时候带上非凡的 header，满足条件进入灰度环境

curl -H"Host:www.demo.com"  -H"x-user-id:100" http://106.14.155.223/a
Agray[172.18.144.93] -> Bgray[172.18.144.24] -> Cgray[172.18.144.25]

不满足条件的申请，进入基线环境:

curl -H"Host:www.demo.com"  -H"x-user-id:101" http://106.14.155.223/a
A[172.18.144.91] -> B[172.18.144.22] -> C[172.18.144.95]

相比场景一这样的益处是，客户端的域名不变，只须要通过申请来辨别。

场景三：通过自定义路由规定来进行全链路灰度

有时候咱们不想要主动透传且主动路由，而是心愿微服务调用链上下游上的每个利用能自定义灰度规定，例如 B 利用心愿管制只有满足自定义规定的申请才会路由到 B 利用这里，而 C 利用有可能心愿定义和 B 不同的灰度规定，这时应该如何配置呢，场景参见如下图：

留神，最好把场景一和二中配置的参数革除掉。

第一步，须要在入口利用 A 处（最好是所有的入口利用都减少该环境变量，包含 gray 和 base）减少一个环境变量：alicloud.service.header=x-user-id，x-user-id 是须要透传的 header，它的作用是辨认该 header 并做主动透传。

留神这里不要应用 x-mse-tag, 它是零碎默认的一个 header，有非凡的逻辑。

第二步，在两头的 B 利用处，在 MSE 控制台配置标签路由规定

第三步，在 Ingress 处配置路由规定，这一步参考场景二，并采纳如下配置：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: spring-cloud-a-base
spec:
  rules:
  - host: www.base.com
    http:
      paths:
      - backend:
          serviceName: spring-cloud-a-base
          servicePort: 20001
        path: /
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: 'true'
    nginx.ingress.kubernetes.io/canary-by-header: x-user-id
    nginx.ingress.kubernetes.io/canary-by-header-value: '100'
    nginx.ingress.kubernetes.io/canary-weight: '0'
  name: spring-cloud-a-gray
spec:
  rules:
    - host: www.base.com
      http:
        paths:
          - backend:
              serviceName: spring-cloud-a-gray
              servicePort: 20001
            path: /

后果验证

测试验证，拜访灰度环境，带上满足条件的 header，路由到 B 的灰度环境中。

curl 120.77.215.62/a -H "Host: www.base.com" -H "x-user-id: 100" 
Agray[192.168.86.42] -> Bgray[192.168.74.4] -> C[192.168.86.33]

拜访灰度环境，带上不满足条件的 header，路由到 B 的 base 环境中。

curl 120.77.215.62/a -H "Host: www.base.com" -H "x-user-id: 101" 
A[192.168.86.35] -> B[192.168.73.249] -> C[192.168.86.33]

去掉 Ingress Canary 配置，拜访 base A 服务（基线环境入口利用须要加上 alicloud.service.header 环境变量），带上满足条件的 header，路由到 B 的灰度环境中。

curl 120.77.215.62/a -H "Host: www.base.com" -H "x-user-id: 100" 
A[192.168.86.35] -> Bgray[192.168.74.4] -> C[192.168.86.33]

拜访 base 环境，带上不满足条件的 header，路由到 B 的 base 环境中。

curl 120.77.215.62/a -H "Host: www.base.com" -H "x-user-id: 101" 
A[192.168.86.35] -> B[192.168.73.249] -> C[192.168.86.33]

总结

20 分钟疾速实际完具备很大技术难度的全链路灰度能力，全链路灰度其实并不是那么难！

基于 MSE 服务治理的全链路灰度能力，咱们能够疾速落地企业级的全链路灰度能力，以上三种场景是咱们在生产实践中大规模落地的规范场景，当然咱们能够基于 MSE 服务治理的能力依据本人的业务个性化定制与适配；即便在多种流量起源的背景下，也能做到依照业务定制精准引流。

同时 MSE 服务治理专业版的可观测性能力使得灰度有效性失去可掂量，灰没灰到，灰得咋样，做到“心里有数”。

灰度流量秒级监控

标准公布流程

日常公布中，咱们经常会有如下一些谬误的想法：

• 这次改变的内容比拟小，而且上线要求比拟急，就不须要测试间接公布上线好了。
• 公布不须要走灰度流程，疾速公布上线即可。
• 灰度公布没有什么用，就是一个流程而已，公布完就间接公布线上，不必期待察看。
• 尽管灰度公布很重要，然而灰度环境很难搭建，耗时耗力 优先级并不高。

这些想法都可能让咱们进行一次谬误的公布，不少故障是因为公布间接或间接引起。因而晋升公布的品质，缩小谬误的产生，是无效缩小线上故障的一个关键环节。做到平安的公布，咱们须要标准公布的流程。

尾

随着微服务的风行，越来越多公司应用了微服务框架，微服务以其高内聚、低耦合等个性，提供了更好的容错性，也更适应业务的疾速迭代，为开发人员带来了很多的便利性。然而随着业务的倒退，微服务拆分越来越简单，微服务的治理也成了一个比拟令人头疼的问题。

单单拿全链路灰度来看，为了保障利用新版本上线前的性能正确性的验证同时须要兼顾利用公布的效率，如果咱们利用的规模很小，咱们能够间接通过保护多套环境来保障公布的正确性。然而当咱们的业务倒退到宏大且复杂程度时，假如咱们的零碎由 100 个微服务形成，即便测试 / 灰度环境每个服务占用 1 到 2 个 pod，那么多套环境下来咱们须要面临微小的老本与运维环境带来的效率的挑战。

有没有更加简略且高效的办法来解决微服务治理的难题？

MSE 微服务引擎将推出服务治理专业版，提供开箱即用且残缺业余的微服务治理解决方案，帮忙企业更好地实现微服务治理能力。如果您的零碎也能够像本文形容的那样，疾速具备残缺的全链路灰度能力，并基于该能力进行进一步的微服务治理实际，不仅能够节俭主观的人力与老本，还能够让您的企业在微服务畛域的摸索更加有底气。

理解更多相干信息，请扫描下方二维码或搜寻微信号（AlibabaCloud888）增加云原生小助手！获取更多相干资讯！