Redis é um sistema de armazenamento de valor-chave de alto desempenho amplamente usado na arquitetura de microsserviço. Se quisermos usar os recursos avançados fornecidos pelo modo de cluster Redis, precisamos fazer alterações no código do cliente, o que traz algumas dificuldades na atualização e manutenção do aplicativo. Usando o Istio e o Envoy, podemos implementar fragmentação de dados do Redis Cluster sem conhecimento do cliente sem modificar o código do cliente e fornecer funções avançadas de gerenciamento de tráfego, como separação de leitura e gravação e espelhamento de tráfego.
Cluster Redis
Um uso comum do Redis é como cache de dados. Ao adicionar uma camada de cache Redis entre o servidor de aplicativos e o servidor de banco de dados, um grande número de operações de leitura no banco de dados pelo servidor de aplicativos pode ser reduzido e o risco de resposta lenta ou até mesmo tempo de inatividade do servidor de banco de dados sob forte pressão pode ser evitado e a robustez de todo o sistema pode ser significativamente aprimorada. O princípio do Redis como um cache de dados é mostrado na figura:
Em um sistema de pequena escala, o único Redis mostrado na figura acima pode implementar bem a função da camada de cache. Quando a quantidade de dados que precisa ser armazenada em cache no sistema é grande, um servidor Redis não pode atender aos requisitos de armazenamento em cache de todos os servidores de aplicativos; ao mesmo tempo, quando uma única instância do Redis falha, um grande número de solicitações de leitura é enviado diretamente para o servidor de banco de dados back-end, resultando em servidor de banco de dados temporário A pressão excessiva afeta a estabilidade do sistema. Podemos usar o Redis Cluster para fragmentar os dados em cache e colocar diferentes dados em diferentes fragmentos do Redis para melhorar a capacidade da camada de cache do Redis. Em cada fragmento do Redis, vários nós de réplica também podem ser usados para compartilhar a carga de solicitações de leitura em cache e obter alta disponibilidade do Redis. O sistema que usa o Redis Cluster é mostrado abaixo:
Como você pode ver na figura, no modo Redis Cluster, o cliente precisa enviar operações de leitura e gravação de diferentes chaves para diferentes nós Redis no cluster de acordo com as regras de fragmentação do cluster, portanto, o cliente precisa entender a topologia do Redis Cluster. Isso torna impossível para nós migrar suavemente um aplicativo usando o modo de nó independente do Redis para o Redis Cluster sem modificar o cliente. Além disso, como o cliente precisa entender a topologia interna do Redis Cluster, isso também levará ao acoplamento do código do cliente e da operação e manutenção do Redis Cluster. Por exemplo, para conseguir separação de leitura e gravação ou espelhamento de tráfego, é necessário modificar o código de cada cliente e reimplantar. .
Nesse cenário, podemos colocar um servidor proxy Envoy entre o servidor de aplicativos e o Redis Cluster, e o Envoy é responsável por rotear as solicitações de leitura e gravação de cache emitidas pelo aplicativo para o nó Redis correto. Em um sistema de microsserviço, há um grande número de processos de aplicativo que precisam acessar o servidor de cache. Para evitar pontos únicos de falha e gargalos de desempenho, implantamos um proxy Envoy para cada processo de aplicativo na forma de Sidecar. Ao mesmo tempo, para simplificar o gerenciamento desses proxies, podemos usar o Istio como o plano de controle para configurar uniformemente todos os proxies Envoy, conforme mostrado na figura a seguir:
Na parte seguinte deste artigo, apresentaremos como gerenciar o Redis Cluster por meio do Istio e do Envoy, realizar o particionamento de dados não sensível ao cliente e estratégias de roteamento avançadas, como separação de leitura e gravação e espelhamento de tráfego.
Implante o Istio
O protocolo Redis já é compatível com o Pilot, mas sua função é fraca. Ele só pode configurar uma rota padrão para o proxy Redis e não é compatível com o modo Redis Cluster. Não é possível implementar a fragmentação de dados do filtro Redis, separação de leitura e gravação, espelhamento de tráfego e outro gerenciamento avançado de tráfego Recursos. Para permitir que o Istio forneça configuração relacionada ao Redis Cluster para o Envoy Sidecar, modificamos o código relacionado à configuração do EnvoyFilter para oferecer suporte à operação "REPLCAE" do EnvoyFilter. A operação REPLACE revisada do PR Implement para o patch EnvoyFilter foi enviada à comunidade do Istio, incorporada ao branch principal e será lançada nas versões subsequentes do Istio.
No momento em que este artigo foi escrito, este PR ainda não foi incorporado na versão 1.7.3 do Istio mais recente. Portanto, construí uma imagem piloto para permitir a operação "REPLACE" do EnvoyFilter. Ao instalar o Istio, precisamos especificar a imagem Pilot no comando istioctl, conforme mostrado na seguinte linha de comando:
$ cd istio-1.7.3/bin
$ ./istioctl install --set components.pilot.hub=zhaohuabing --set components.pilot.tag=1.7.3-enable-ef-replaceObservação: se sua versão do Istio for mais recente que 1.7.3 e o PR tiver sido incorporado, você pode usar diretamente o espelhamento do Pilot padrão na versão do Istio.
Implantar Redis Cluster
Faça download do código relevante usado no exemplo a seguir em https://github.com/zhaohuabing/istio-redis-culster :
$ git clone https://github.com/zhaohuabing/istio-redis-culster.git
$ cd istio-redis-culsterCriamos um namespace "redis" para implantar o Redis Cluster neste exemplo.
$ kubectl create ns redis
namespace/redis createdImplante o Statefulset e o Configmap do servidor Redis.
$ kubectl apply -f k8s/redis-cluster.yaml -n redis
configmap/redis-cluster created
statefulset.apps/redis-cluster created
service/redis-cluster createdVerifique a implantação do Redis
Confirme se o nó Redis está funcionando normalmente:
$ 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 117sCriar Redis Cluster
Nas etapas acima, implantamos 6 nós do Redis usando Statefulset, mas atualmente esses 6 nós ainda são independentes uns dos outros e não formam um cluster. Aqui usamos os cluster createcomandos do Redis para esses nós um Cluster do Redis.
$ 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.Verifique o Redis Cluster
Podemos usar o cluster infocomando para visualizar as informações de configuração e os nós de membros do Redis Cluster Cluster para verificar se o cluster foi criado com êxito.
$ 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:416Implantar o cliente de teste
Implementamos um cliente para enviar comandos de teste:
$ kubectl apply -f k8s/redis-client.yaml -n redis
deployment.apps/redis-client createdDistribuir a configuração do Envoy relacionada ao Redis Cluster por meio do Istio
Nas etapas a seguir, enviaremos a configuração relacionada ao Redis Cluster ao Envoy Sidecar por meio do Istio para ativar as funções avançadas do Redis Cluster sem alterar o cliente, incluindo fragmentação de dados, separação de leitura e gravação e espelhamento de tráfego.
Criar Cluster Envoy Redis
O Envoy fornece um Cluster de Envoy do tipo "envoy.clusters.redis" para se conectar ao Redis Cluster de back-end. O Envoy obterá a topologia do Redis Cluster de back-end por meio do Cluster, incluindo quantos fragmentos cada fragmento é responsável Quais slots e nós estão incluídos no shard para distribuir solicitações de clientes para os nós Redis corretos.
Use EnvoyFilter para criar o Cluster Envoy Redis necessário:
$ kubectl apply -f istio/envoyfilter-custom-redis-cluster.yaml
envoyfilter.networking.istio.io/custom-redis-cluster createdCriar Envoy Redis Proxy
O LDS padrão do Istio é configurado com filtro de proxy TCP, precisamos substituí-lo pelo filtro Redis Proxy.
Como a operação "REPLACE" do EnvoyFilter ainda não é compatível com 1.7.3, primeiro precisamos atualizar a definição CRD do EnvoyFilter antes de criar o EnvoyFilter:
$ kubectl apply -f istio/envoyfilter-crd.yaml
customresourcedefinition.apiextensions.k8s.io/envoyfilters.networking.istio.io configuredUse o EnvoyFilter para substituir o filtro de proxy TCP pelo filtro Redis Proxy para que o Envoy possa fazer proxy para solicitações de operação Redis de clientes:
$ 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 createdVerifique a função do Redis Cluster
Agora que tudo está pronto, vamos verificar as várias funções do Redis Cluster.
Fragmentação de dados Redis
Depois de enviarmos a configuração definida no EnvoyFilter para o Envoy por meio do Istio, o Envoy pode descobrir automaticamente a topologia do Redis Cluster de back-end e distribuir automaticamente a solicitação para o nó correto no Redis Cluster de acordo com a chave na solicitação do cliente.
De acordo com a saída da linha de comando na etapa anterior da criação do Redis Cluster, podemos ver a topologia do Redis Cluster: Existem três fragmentos no cluster e cada fragmento possui um nó mestre e um nó escravo (réplica). O cliente acessa o Cluster Redis por meio do Envoy Proxy implantado no mesmo pod, conforme mostrado na figura a seguir:
Os endereços de nó mestre e escravo de cada fragmento no Redis Cluster:
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 - 16383Observação: se você implantar este exemplo em seu próprio cluster K8s, o endereço IP e a topologia de cada nó no Redis Cluster podem ser ligeiramente diferentes, mas a estrutura básica deve ser semelhante.
Tentamos enviar várias chaves diferentes para o cluster Rdeis a partir de setsolicitações do cliente :
$ 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
OKDa perspectiva do cliente, todas as solicitações são bem-sucedidas, podemos usar o scancomando para visualizar os dados em cada nó no lado do servidor:
Visualize os dados em shard [0], o nó mestre é redis-cluster-0 e o nó escravo é 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
bVisualize os dados no shard [1], o nó mestre é redis-cluster-1 e o nó escravo é 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
cVisualize os dados no shard [2], o nó mestre é redis-cluster-2 e o nó escravo é 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
aComo pode ser visto nos resultados da verificação acima, o conjunto de dados pelo cliente é distribuído para os três shards no Redis Cluster. O processo de distribuição de dados é implementado automaticamente pelo Envoy Redis Proxy. O cliente não percebe o Redis Cluster de back-end. Para o cliente, a interação com o Redis Cluster é a mesma que a interação com um único nó Redis.
Usando esse método, podemos migrar perfeitamente o Redis no sistema do modo de nó único para o modo de cluster quando a escala de negócios do aplicativo está se expandindo gradualmente e a pressão em um único nó do Redis é muito alta. No modo de cluster, os dados de chaves diferentes são armazenados em cache em fragmentos de dados diferentes. Podemos aumentar o número de nós de réplica nos fragmentos para expandir um fragmento ou aumentar o número de fragmentos para expandir todo o cluster , Para fazer frente à crescente pressão de dados devido à expansão dos negócios. Como o Envoy pode perceber a topologia de cluster do Redis Cluster e a distribuição de dados é concluída pelo Envoy, todo o processo de migração e expansão não requer um cliente e não afetará a operação normal dos negócios online.
Separação de leitura e gravação do Redis
Em um fragmento do Redis, geralmente há um nó mestre e um ou mais nós escravos (réplica) .O nó mestre é responsável por gravar as operações e sincronizar as alterações de dados no nó escravo. Quando a pressão da operação de leitura do aplicativo é alta, podemos adicionar mais réplicas ao shard para compartilhar a carga da operação de leitura. O Envoy Redis Rroxy oferece suporte à configuração de diferentes estratégias de leitura:
- MASTER: Leia apenas os dados do nó Master. Este modo é necessário quando o cliente requer consistência forte de dados. Este modo coloca muita pressão no Mestre e vários nós não podem ser usados para carregar e compartilhar a operação de leitura no mesmo fragmento.
- PREFER_MASTER: leia primeiro os dados do nó mestre. Quando o nó mestre não estiver disponível, leia os dados do nó de réplica.
- RÉPLICA: só ler dados do nó de réplica. Como o processo de replicação de dados do mestre para a réplica é executado de forma assíncrona, é possível ler dados expirados dessa forma, portanto, é adequado para cenários em que o cliente não tem altos requisitos de consistência de dados. Nesse modo, vários nós de réplica podem ser usados para compartilhar a carga de leitura do cliente.
- PREFER_REPLICA: leia os dados do nó da réplica primeiro e leia os do nó mestre quando o nó da réplica não estiver disponível.
- QUALQUER: Leia os dados de qualquer nó.
No EnvoyFilter emitido anteriormente, definimos a estratégia de leitura do Envoy Redis Proxy como "REPLICA", portanto, as operações de leitura do cliente devem ser enviadas apenas para o nó Replica. Vamos usar o seguinte comando para verificar a estratégia de separação de leitura e gravação:
Ao iniciar uma série de ações principais do cliente é "b" gete 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> Na topologia de Cluster Redis anterior, aprendemos que a chave "b" pertence ao fragmento Shard [0]. Podemos comandar redis-cli monitorpara visualizar a fatia de comando do nó mestre e da réplica recebida.
Nó mestre:
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitorNó escravo:
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitorComo pode ser visto na figura, todas as getsolicitações são enviadas ao nó Replica Envoy.
Espelhamento de tráfego Redis
O Envoy Redis Proxy oferece suporte ao espelhamento de tráfego, ou seja, as solicitações enviadas pelo cliente são enviadas simultaneamente a um servidor / cluster Redis espelhado. O espelhamento de tráfego é uma função muito útil. Podemos usar o espelhamento de tráfego para importar dados online do ambiente de produção para o ambiente de teste para usar os dados online para simular o aplicativo da forma mais realista possível, sem afetar a linha Uso normal por usuários na Internet.
Criamos um nó Redis de nó único para ser usado como servidor espelho:
$ kubectl apply -f k8s/redis-mirror.yaml -n redis
deployment.apps/redis-mirror created
service/redis-mirror createdUse EnvoFilter para ativar a estratégia de espelhamento:
$ 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 configuredAo iniciar uma série de ações principais do cliente é "b" gete 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"Por comando, redis-cli monitorexiba Comando mestre, réplica e nó espelhado recebido respectivamente.
Nó mestre:
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitorNó escravo:
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitorNó de espelho:
$ 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 monitorPode ser visto na figura, todas as setsolicitações são enviadas para o Envoy um nó espelho.
Princípio de implementação
Nas etapas acima, criamos dois objetos de configuração EnvoyFilter no Istio. Esses dois EnvoyFilter modificam a configuração do proxy Envoy, que inclui principalmente duas partes: configuração do Filtro de rede do Redis Proxy e configuração do Redis Cluster.
O EnvoyFilter abaixo substitui o filtro de rede proxy TCP no ouvinte criado pelo Pilot for Redis Service e o substitui por um filtro de rede do tipo "type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy". A rota padrão desse Redis Proxy aponta para "custom-redis-cluster" e a estratégia de separação de leitura e gravação e a estratégia de espelhamento de tráfego são configuradas.
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 replicaO seguinte EnvoyFilter cria um Cluster do tipo "envoy.clusters.redis" no CDS emitido pelo Pilot: "custom-redis-cluster", o Cluster usará o comando CLUSTER SLOTS para consultar um nó aleatório no cluster Redis A estrutura da topologia e salva a estrutura da topologia localmente para distribuir as solicitações do cliente para os nós do Redis corretos no cluster.
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: 5resumo
Este artigo descreve como usar o Envoy para fornecer fragmentação de dados do Redis sem conhecimento do cliente para aplicativos de microsserviço e como usar o Istio para gerenciar uniformemente a configuração do Redis Cluster de vários agentes do Envoy no sistema. Podemos ver que o uso do Istio e do Envoy pode simplificar muito a codificação e a configuração do cliente usando o Redis Cluster, e a estratégia de operação e manutenção do Redis Cluster pode ser modificada online para obter gerenciamento de tráfego avançado, como separação de leitura e gravação e espelhamento de tráfego. Obviamente, a introdução do Istio e do Envoy não reduziu a complexidade de todo o sistema, mas concentrou a manutenção do Redis Cluster do código do aplicativo espalhado para a camada de infraestrutura da grade de serviço. Correspondendo à maioria dos desenvolvedores de aplicativos, seu valor comercial vem principalmente do código do aplicativo e não é econômico investir muita energia em tal infraestrutura. Recomenda-se adotar diretamente o serviço TCM nativo da nuvem Service Mesh (Tencent Cloud Mesh) no Tencent Cloud para introduzir rapidamente os recursos de gerenciamento de tráfego e governança de serviço do Service Mesh para aplicativos de microsserviço sem ter que prestar atenção à instalação, manutenção e atualização da própria infraestrutura do Service Mesh. E outros assuntos.