关于腾讯云:在-Istio-中实现-Redis-集群的数据分片读写分离和流量镜像

Redis 是一个高性能的 key-value 存储系统，被宽泛用于微服务架构中。如果咱们想要应用 Redis 集群模式提供的高级个性，则须要对客户端代码进行改变，这带来了利用降级和保护的一些艰难。利用 Istio 和 Envoy，咱们能够在不批改客户端代码的前提下实现客户端无感知的 Redis Cluster 数据分片，并提供读写拆散、流量镜像等高级流量治理性能。

Redis 的一个常见用处是用作数据高速缓存。通过在应用服务器和数据库服务器之间退出一个 Redis 缓存层，能够缩小应用服务器对数据库的大量读操作，防止数据库服务器在大压力下响应迟缓甚至宕机的危险，显著增强整个零碎的健壮性。Redis 作为数据缓存的原理如图所示：

在一个小规模的零碎中，上图所示的单个 Redis 就能够很好地实现缓存层的性能。当零碎中须要缓存的数据量较大时，一个 Redis 服务器无奈承当所有应用服务器的缓存需要；同时单个 Redis 实例生效时也会导致大量读申请被间接发送到后端的数据库服务器上，导致数据库服务器刹时压力超标，影响零碎的稳定性。咱们能够采纳 Redis Cluster 来对缓存数据进行分片，将不同的数据放到不同的 Redis 分片中，以进步 Redis 缓存层的容量能力。在每个 Redis 分片中，还能够采纳多个 replica 节点对缓存的读申请进行负载分担，并实现 Redis 的高可用。采纳了 Redis Cluster 的零碎如下图所示：

从图中能够看到，在 Redis Cluster 模式下，客户端须要依据集群的分片规定将不同 key 的读写操作发送到集群中不同的 Redis 节点上，因而客户端须要理解 Redis Cluster 的拓扑构造，这导致咱们无奈在不批改客户端的状况下将一个应用 Redis 独立节点模式的利用平滑迁徙到 Redis Cluster 上。另外，因为客户端须要理解 Redis Cluster 的外部拓扑，也将导致客户端代码和 Redis Cluster 运维上的耦合，例如要实现读写拆散或者流量镜像的话，就须要批改每个客户端的代码并重新部署。

这种场景下，咱们能够在应用服务器和 Redis Cluster 之间搁置一个 Envoy 代理服务器，由 Envoy 来负责将利用收回的缓存读写申请路由到正确的 Redis 节点上。一个微服务零碎中存在大量须要拜访缓存服务器的利用过程，为了防止单点故障和性能瓶颈，咱们以 Sidecar 的模式为每个利用过程部署一个 Envoy 代理。同时，为了简化对这些代理的管理工作，咱们能够采纳 Istio 作为管制面来对立对所有 Envoy 代理进行配置, 如下图所示：

在本文的后续局部，咱们将介绍如何通过 Istio 和 Envoy 来治理 Redis Cluster，实现客户端无感知的数据分区，以及读写拆散、流量镜像等高级路由策略。

Pilot 中曾经反对了 Redis 协定，但性能较弱，只能为 Redis 代理配置一个缺省路由，而且不反对 Redis Cluster 模式，无奈实现 Redis filter 的数据分片、读写拆散、流量镜像等高级流量治理性能。为了让 Istio 能够将 Redis Cluster 相干的配置下发到 Envoy Sidecar 上，咱们批改了 EnvoyFilter 配置相干代码，以反对 EnvoyFilter 的 “REPLCAE” 操作。该批改的 PR Implement REPLACE operation for EnvoyFilter patch 曾经提交到 Istio 社区，并合入到了主分支中，将在 Istio 后续的版本中公布。

在撰写本文的时候，最新的 Istio 公布版本 1.7.3 中尚未合入该 PR。因而我构建了一个 Pilot 镜像，以启用 EnvoyFilter 的 “REPLACE” 操作。在装置 Istio 时，咱们须要在 istioctl 命令中指定采纳该 Pilot 镜像，如上面的命令行所示：

$ cd istio-1.7.3/bin
$ ./istioctl install --set components.pilot.hub=zhaohuabing --set components.pilot.tag=1.7.3-enable-ef-replace

备注：如果你采纳的 Istio 版本新于 1.7.3，并且曾经合入了该 PR，则能够间接采纳 Istio 版本中缺省的 Pilot 镜像。

请从 https://github.com/zhaohuabin… 下载上面示例中须要用到的相干代码：

$ git clone https://github.com/zhaohuabing/istio-redis-culster.git
$ cd istio-redis-culster

咱们创立一个 “redis” namespace 来部署本例中的 Redis Cluster。

$ kubectl create ns redis
namespace/redis created

部署 Redis 服务器的 Statefulset 和 Configmap。

$ kubectl apply -f k8s/redis-cluster.yaml -n redis
configmap/redis-cluster created
statefulset.apps/redis-cluster created
service/redis-cluster created

确认 Redis 节点曾经启动并失常运行：

$ kubectl get pod -n redis
NAME              READY   STATUS    RESTARTS   AGE
redis-cluster-0   2/2     Running   0          4m25s
redis-cluster-1   2/2     Running   0          3m56s
redis-cluster-2   2/2     Running   0          3m28s
redis-cluster-3   2/2     Running   0          2m58s
redis-cluster-4   2/2     Running   0          2m27s
redis-cluster-5   2/2     Running   0          117s

在下面的步骤中，咱们采纳 Statefulset 部署了 6 个 Redis 节点，但目前这 6 个节点还是互相独立的，并未造成一个集群。上面咱们采纳 Redis 的 cluster create 命令将这些节点组成一个 Redis Cluster。

$ kubectl exec -it redis-cluster-0 -n redis -- redis-cli --cluster create --cluster-replicas 1 $(kubectl get pods -l app=redis-cluster -o jsonpath='{range.items[*]}{.status.podIP}:6379' -n redis)
Defaulting container name to redis.
Use 'kubectl describe pod/redis-cluster-0 -n redis' to see all of the containers in this pod.
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 172.16.0.72:6379 to 172.16.0.138:6379
Adding replica 172.16.0.201:6379 to 172.16.1.52:6379
Adding replica 172.16.0.139:6379 to 172.16.1.53:6379
M: 8fdc7aa28a6217b049a2265b87bff9723f202af0 172.16.0.138:6379
   slots:[0-5460] (5461 slots) master
M: 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c 172.16.1.52:6379
   slots:[5461-10922] (5462 slots) master
M: 0b86a0fbe76cdd4b48434b616b759936ca99d71c 172.16.1.53:6379
   slots:[10923-16383] (5461 slots) master
S: 94b139d247e9274b553c82fbbc6897bfd6d7f693 172.16.0.139:6379
   replicates 0b86a0fbe76cdd4b48434b616b759936ca99d71c
S: e293d25881c3cf6db86034cd9c26a1af29bc585a 172.16.0.72:6379
   replicates 8fdc7aa28a6217b049a2265b87bff9723f202af0
S: ab897de0eca1376558e006c5b0a49f5004252eb6 172.16.0.201:6379
   replicates 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.
>>> Performing Cluster Check (using node 172.16.0.138:6379)
M: 8fdc7aa28a6217b049a2265b87bff9723f202af0 172.16.0.138:6379
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c 172.16.1.52:6379
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: 94b139d247e9274b553c82fbbc6897bfd6d7f693 172.16.0.139:6379
   slots: (0 slots) slave
   replicates 0b86a0fbe76cdd4b48434b616b759936ca99d71c
M: 0b86a0fbe76cdd4b48434b616b759936ca99d71c 172.16.1.53:6379
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
S: ab897de0eca1376558e006c5b0a49f5004252eb6 172.16.0.201:6379
   slots: (0 slots) slave
   replicates 4dd6c1fecbbe4527e7d0de61b655e8b74b411e4c
S: e293d25881c3cf6db86034cd9c26a1af29bc585a 172.16.0.72:6379
   slots: (0 slots) slave
   replicates 8fdc7aa28a6217b049a2265b87bff9723f202af0
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

咱们能够采纳 cluster info 命令查看 Redis Cluster 的配置信息和 Cluster 中的成员节点，以验证集群是否创立胜利。

$ kubectl exec -it redis-cluster-0 -c redis -n redis -- redis-cli cluster info 
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:206
cluster_stats_messages_pong_sent:210
cluster_stats_messages_sent:416
cluster_stats_messages_ping_received:205
cluster_stats_messages_pong_received:206
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:416

咱们部署一个客户端，以用于发送测试命令:

$ kubectl apply -f k8s/redis-client.yaml -n redis
deployment.apps/redis-client created

在上面的步骤中，咱们将通过 Istio 向 Envoy Sidecar 下发 Redis Cluster 相干配置，以在无需改变客户端的状况下启用 Redis Cluster 的高级性能，包含数据分片、读写拆散和流量镜像。

Envoy 提供了 “envoy.clusters.redis” 类型的 Envoy Cluster 来连贯后端的 Redis Cluster，Envoy 会通过该 Cluster 获取后端 Redis Cluster 的拓扑构造，包含有多少个分片（shard），每个分片负责哪些 slot，以及分片中蕴含哪些节点，以将来自客户端的申请散发到正确的 Redis 节点上。

采纳 EnvoyFilter 来创立所需的 Envoy Redis Cluster：

$ kubectl apply -f istio/envoyfilter-custom-redis-cluster.yaml
envoyfilter.networking.istio.io/custom-redis-cluster created

Istio 缺省下发的 LDS 中配置的是 TCP proxy filter，咱们须要将其替换为 Redis Proxy filter。

因为 1.7.3 中尚不反对 EnvoyFilter 的 “REPLACE” 操作，咱们首先须要更新 EnvoyFilter 的 CRD 定义，而后能力创立该 EnvoyFilter：

$ kubectl apply -f istio/envoyfilter-crd.yaml 
customresourcedefinition.apiextensions.k8s.io/envoyfilters.networking.istio.io configured

采纳 EnvoyFilter 来将 TCP proxy filter 替换为 Redis Proxy filter，以使 Envoy 能够代理来自客户端的 Redis 操作申请：

$ sed -i .bak "s/\${REDIS_VIP}/`kubectl get svc redis-cluster -n redis -o=jsonpath='{.spec.clusterIP}'`/" istio/envoyfilter-redis-proxy.yaml
$ kubectl apply -f istio/envoyfilter-redis-proxy.yaml
envoyfilter.networking.istio.io/add-redis-proxy created

当初所有就绪，上面咱们来验证 Redis Cluster 的各项性能。

咱们通过 Istio 将 EnvoyFilter 中定义的配置下发到 Envoy 后，Envoy 就可能主动发现后端 Redis Cluster 的拓扑构造，并依据客户端申请中的 key 将申请主动散发到 Redis Cluster 中正确的节点上。

依据后面创立 Redis Cluster 步骤中的命令行输入，咱们能够看出该 Redis Cluster 的拓扑构造：Cluster 中有三个分片，每个分片中有一个 Master 节点，一个 Slave(Replica) 节点。客户端通过和其部署在同一个 Pod 中的 Envoy Proxy 拜访 Redis Cluster，如下图所示：

Redis Cluster 中各个分片的 Master 和 Slave 节点地址：

Shard[0] Master[0]  redis-cluster-0 172.16.0.138:6379   replica  redis-cluster-4 172.16.0.72:6379  -> Slots 0 - 5460 
Shard[1] Master[1]  redis-cluster-1 172.16.1.52:6379    replica  redis-cluster-5 172.16.0.201:6379 -> Slots 5461 - 10922
Shard[2] Master[2]  redis-cluster-2 172.16.1.53:6379    replica  redis-cluster-3 172.16.0.139:6379 -> Slots 10923 - 16383

备注：如果你在本人的 K8s cluster 中部署该示例，那么 Redis Cluster 中各个节点的 IP 地址和拓扑构造可能稍有不同，但根本构造应该是相似的。

咱们尝试从客户端向 Rdeis Cluster 发送一些不同 key 的 set 申请:

$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster
redis-cluster:6379> set a a
OK
redis-cluster:6379> set b b
OK
redis-cluster:6379> set c c
OK
redis-cluster:6379> set d d
OK
redis-cluster:6379> set e e
OK
redis-cluster:6379> set f f
OK
redis-cluster:6379> set g g
OK
redis-cluster:6379> set h h
OK

从客户端来看，所有的申请都胜利了，咱们能够应用 scan 命令在服务器端查看各个节点中的数据：

查看分片 Shard[0] 中的数据，master 节点是 redis-cluster-0 slave 节点是 redis-cluster-4。

$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli --scan
b
f
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli --scan
f
b

查看分片 Shard[1] 中的数据，master 节点是 redis-cluster-1 slave 节点是 redis-cluster-5。

$ kubectl exec redis-cluster-1 -c redis -n redis -- redis-cli --scan
c
g
$ kubectl exec redis-cluster-5 -c redis -n redis -- redis-cli --scan
g
c

查看分片 Shard[2] 中的数据，master 节点是 redis-cluster-2 slave 节点是 redis-cluster-3。

$ kubectl exec redis-cluster-2 -c redis -n redis -- redis-cli --scan
a
e
d
h
$ kubectl exec redis-cluster-3 -c redis -n redis -- redis-cli --scan
h
e
d
a

从下面的验证后果中能够看到，客户端设置的数据被散发到了 Redis Cluster 中的三个分片中。该数据散发过程是由 Envoy Redis Proxy 主动实现的，客户端并不感知后端的 Redis Cluster，对客户端而言，和该 Redis Cluster 的交互与和一个繁多 Redis 节点的交互是雷同的。

采纳该办法，咱们能够在利用业务规模逐步扩张，繁多 Redis 节点压力过大时，将零碎中的 Redis 从单节点无缝迁徙到集群模式。在集群模式下，不同 key 的数据被缓存在不同的数据分片中，咱们能够减少分片中 Replica 节点的数量来对一个分片进行扩容，也能够减少分片个数来对整个集群进行扩大，以应答因为业务一直扩大而减少的数据压力。因为 Envoy 能够感知 Redis Cluster 集群拓扑，数据的散发由 Envoy 实现，整个迁徙和扩容过程无需客户端，不会影响到线上业务的失常运行。

在一个 Redis 分片中，通常有一个 Master 节点，一到多个 Slave（Replica）节点，Master 节点负责写操作，并将数据变动同步到 Slave 节点。当来自利用的读操作压力较大时，咱们能够在分片中减少更多的 Replica，以对读操作进行负载分担。Envoy Redis Rroxy 反对设置不同的读策略：

MASTER： 只从 Master 节点读取数据，当客户端要求数据强一致性时须要采纳该模式。该模式对 Master 压力较大，在同一个分片内无奈采纳多个节点对读操作进行负载分担。
PREFER_MASTER： 优先从 Master 节点读取数据，当 Master 节点不可用时，从 Replica 节点读取。
REPLICA： 只从 Replica 节点读取数据，因为 Master 到 Replica 的数据复制过程是异步执行的，采纳该形式有可能读取到过期的数据，因而实用于客户端对数据一致性要求不高的场景。该模式下能够采纳多个 Replica 节点来分担来自客户端的读负载。
PREFER_REPLICA： 优先从 Replica 节点读取数据，当 Replica 节点不可用时，从 Master 节点读取。
ANY： 从任意节点读取数据。

在后面下发的 EnvoyFilter 中，咱们将 Envoy Redis Proxy 的读策略设置为了 “REPLICA”，因而客户端的读操作应该只会被发送到 Replica 节点。让咱们应用上面的命令来验证读写拆散的策略:

通过客户端发动一系列 key 为 “b” 的 get 和 set 操作：

$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster

redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> set b bb
OK
redis-cluster:6379> get b
"bb"
redis-cluster:6379>

在后面的 Redis Cluster 拓扑中，咱们曾经得悉 key “b” 属于 Shard[0] 这个分片。咱们能够通过命令 redis-cli monitor 查看该分片中 Master 和 Replica 节点中收到的命令。

Master 节点：

$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitor

Slave 节点:

$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitor

从下图中能够看到，所有 get 申请都被 Envoy 发送到了 Replica 节点上。

Envoy Redis Proxy 反对流量镜像，行将客户端发送的申请同时发送到一个镜像 Redis 服务器 / 集群上。流量镜像是一个十分有用的性能，咱们能够应用流量镜像将生产环境中的线上数据导入到测试环境中，以应用线上数据对利用进行尽可能实在的模仿测试，同时又不会影响到线上用户的失常应用。

咱们创立一个单节点的 Redis 节点，用做镜像服务器：

$ kubectl apply -f k8s/redis-mirror.yaml -n redis 
deployment.apps/redis-mirror created
service/redis-mirror created

采纳 EnvoFilter 来启用镜像策略：

$ sed -i .bak "s/\${REDIS_VIP}/`kubectl get svc redis-cluster -n redis -o=jsonpath='{.spec.clusterIP}'`/" istio/envoyfilter-redis-proxy-with-mirror.yaml
$ kubectl apply -f istio/envoyfilter-redis-proxy-with-mirror.yaml
envoyfilter.networking.istio.io/add-redis-proxy configured

通过客户端发动一系列 key 为 “b” 的 get 和 set 操作：

$ kubectl exec -it `kubectl get pod -l app=redis-client -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-client -n redis -- redis-cli -h redis-cluster
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> get b
"b"
redis-cluster:6379> set b bb
OK
redis-cluster:6379> get b
"bb"
redis-cluster:6379> set b bbb
OK
redis-cluster:6379> get b
"bbb"
redis-cluster:6379> get b
"bbb"

能够通过命令 redis-cli monitor 别离查看 Master、Replica 和镜像节点中收到的命令。

Master 节点:

$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitor

Slave 节点:

$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitor

镜像节点:

$ kubectl exec -it `kubectl get pod -l app=redis-mirror -n redis -o jsonpath="{.items[0].metadata.name}"` -c redis-mirror -n redis -- redis-cli monitor

从下图中能够看到，所有 set 申请都被 Envoy 发送到了一份镜像节点上。

在下面的步骤中，咱们在 Istio 中创立了两个 EnvoyFilter 配置对象。这两个 EnvoyFilter 批改了 Envoy 代理的配置，次要包含两局部内容：Redis Proxy Network Filter 配置和 Redis Cluster 配置。

上面的 EnvoyFilter 替换了 Pilot 为 Redis Service 创立的 Listener 中的 TCP Proxy Network Filter，将其替换为一个 “type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy” 类型的 Network Filter。该 Redis Proxy 的缺省路由指向 “custom-redis-cluster”，并且配置了读写拆散策略和流量镜像策略。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: add-redis-proxy
  namespace: istio-system
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      listener:
        name: ${REDIS_VIP}_6379             # Replace REDIS_VIP with the cluster IP of "redis-cluster service
        filterChain:
          filter:
            name: "envoy.filters.network.tcp_proxy"
    patch:
      operation: REPLACE
      value:
        name: envoy.redis_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy
          stat_prefix: redis_stats
          prefix_routes:
            catch_all_route:
              request_mirror_policy:            # Send requests to the mirror cluster
              - cluster: outbound|6379||redis-mirror.redis.svc.cluster.local
                exclude_read_commands: True     # Mirror write commands only:
              cluster: custom-redis-cluster
          settings:
            op_timeout: 5s
            enable_redirection: true
            enable_command_stats: true
            read_policy: REPLICA               # Send read requests to replica

上面的 EnvoyFilter 在 Pilot 下发的 CDS 中创立了一个 “envoy.clusters.redis” 类型的 Cluster：“custom-redis-cluster”，该 Cluster 会采纳 CLUSTER SLOTS 命令向 Redis 集群中的一个随机节点查问集群的拓扑构造，并在本地保留该拓扑构造，以将来自客户端的申请散发到集群中正确的 Redis 节点上。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-redis-cluster
  namespace: istio-system
spec:
  configPatches:
  - applyTo: CLUSTER
    patch:
      operation: INSERT_FIRST
      value:
        name: "custom-redis-cluster"
        connect_timeout: 0.5s
        lb_policy: CLUSTER_PROVIDED
        load_assignment:
          cluster_name: custom-redis-cluster
          endpoints:
          - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: redis-cluster-0.redis-cluster.redis.svc.cluster.local
                    port_value: 6379
            - endpoint:
                address:
                  socket_address:
                    address: redis-cluster-1.redis-cluster.redis.svc.cluster.local
                    port_value: 6379
            - endpoint:
                address:
                  socket_address:
                    address: redis-cluster-2.redis-cluster.redis.svc.cluster.local
                    port_value: 6379
            - endpoint:
                address:
                  socket_address:
                    address: redis-cluster-3.redis-cluster.redis.svc.cluster.local
                    port_value: 6379
            - endpoint:
                address:
                  socket_address:
                    address: redis-cluster-4.redis-cluster.redis.svc.cluster.local
                    port_value: 6379
            - endpoint:
                address:
                  socket_address:
                    address: redis-cluster-5.redis-cluster.redis.svc.cluster.local
                    port_value: 6379
        cluster_type:
          name: envoy.clusters.redis
          typed_config:
            "@type": type.googleapis.com/google.protobuf.Struct
            value:
              cluster_refresh_rate: 5s
              cluster_refresh_timeout: 3s
              redirect_refresh_interval: 5s
              redirect_refresh_threshold: 5

本文介绍了如何应用 Envoy 为微服务利用提供客户端无感知的 Redis 数据分片，以及如何通过 Istio 来对立管理系统中多个 Envoy 代理的 Redis Cluster 配置。咱们能够看到，采纳 Istio 和 Envoy 能够大大简化客户端应用 Redis Cluster 的编码和配置工作，并且能够在线批改 Redis Cluster 的运维策略，实现读写拆散、流量镜像等高级流量治理。当然，引入 Istio 和 Envoy 并未缩小整个零碎的复杂度，而是将 Redis Cluster 保护的工作从各个扩散的利用代码中集中到了服务网格基础设施层。对应宽广利用凋谢者来说，其业务价值次要来自于利用代码，将大量精力投入此类基础设施是不太划算的。倡议间接采纳腾讯云上的云原生 Service Mesh 服务 TCM（Tencent Cloud Mesh），为微服务利用疾速引入 Service Mesh 的流量治理和服务治理能力，而无需再关注 Service Mesh 基础设施本身的装置、保护、降级等事项。

https://rancher.com/blog/2019…
https://medium.com/@fr33m0nk/…
Implement REPLACE operation for EnvoyFilter patch

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！

关于腾讯云:在-Istio-中实现-Redis-集群的数据分片读写分离和流量镜像

Redis Cluster

部署 Istio

部署 Redis Cluster

验证 Redis 部署

创立 Redis Cluster

验证 Redis Cluster

部署测试用客户端

通过 Istio 下发 Redis Cluster 相干的 Envoy 配置

创立 Envoy Redis Cluster

创立 Envoy Redis Proxy

验证 Redis Cluster 性能

Redis 数据分片

Redis 读写拆散

Redis 流量镜像

实现原理

小结

参考文档

Just My Socks（注册教程内含优惠码）

关于腾讯云:在-Istio-中实现-Redis-集群的数据分片读写分离和流量镜像

Redis Cluster

部署 Istio

部署 Redis Cluster

验证 Redis 部署

创立 Redis Cluster

验证 Redis Cluster

部署测试用客户端

通过 Istio 下发 Redis Cluster 相干的 Envoy 配置

创立 Envoy Redis Cluster

创立 Envoy Redis Proxy

验证 Redis Cluster 性能

Redis 数据分片

Redis 读写拆散

Redis 流量镜像

实现原理

小结

参考文档

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）