Redis es un sistema de almacenamiento de valor clave de alto rendimiento que se usa ampliamente en la arquitectura de microservicios. Si queremos utilizar las funciones avanzadas proporcionadas por el modo de clúster de Redis, necesitamos realizar cambios en el código del cliente, lo que trae algunas dificultades en la actualización y el mantenimiento de la aplicación. Con Istio y Envoy, podemos implementar la fragmentación de datos de Redis Cluster insensible al cliente sin modificar el código del cliente y proporcionar funciones avanzadas de gestión del tráfico, como la separación de lectura y escritura y la duplicación del tráfico.
Clúster de Redis
Un uso común de Redis es como caché de datos. Al agregar una capa de caché de Redis entre el servidor de la aplicación y el servidor de la base de datos, se puede reducir una gran cantidad de operaciones de lectura en la base de datos por parte del servidor de la aplicación, y se puede evitar el riesgo de una respuesta lenta o incluso el tiempo de inactividad del servidor de la base de datos bajo mucha presión, y se puede mejorar significativamente la solidez de todo el sistema. El principio de Redis como caché de datos se muestra en la figura:
En un sistema a pequeña escala, el único Redis que se muestra en la figura anterior puede implementar bien la función de la capa de caché. Cuando la cantidad de datos que se deben almacenar en caché en el sistema es grande, un servidor Redis no puede cumplir con los requisitos de almacenamiento en caché de todos los servidores de aplicaciones; al mismo tiempo, cuando falla una sola instancia de Redis, se enviará una gran cantidad de solicitudes de lectura directamente al servidor de base de datos back-end, lo que resultará en un servidor de base de datos transitorio La presión excesiva afecta la estabilidad del sistema. Podemos usar Redis Cluster para fragmentar los datos almacenados en caché y colocar diferentes datos en diferentes fragmentos de Redis para mejorar la capacidad de la capa de caché de Redis. En cada fragmento de Redis, también se pueden usar varios nodos de réplica para compartir la carga de solicitudes de lectura almacenadas en caché y lograr una alta disponibilidad de Redis. El sistema que usa Redis Cluster se muestra a continuación:
Como puede ver en la figura, en el modo Clúster de Redis, el cliente necesita enviar operaciones de lectura y escritura de diferentes claves a diferentes nodos de Redis en el clúster de acuerdo con las reglas de fragmentación del clúster, por lo que el cliente debe comprender la topología del Clúster de Redis. Esto hace que sea imposible para nosotros migrar sin problemas una aplicación usando el modo de nodo independiente de Redis a Redis Cluster sin modificar el cliente. Además, dado que el cliente necesita comprender la topología interna de Redis Cluster, también conducirá al acoplamiento del código del cliente y la operación y mantenimiento de Redis Cluster. Por ejemplo, para lograr la separación de lectura y escritura o la duplicación del tráfico, es necesario modificar el código de cada cliente y volver a implementarlo. .
En este escenario, podemos colocar un servidor proxy Envoy entre el servidor de aplicaciones y el Clúster de Redis, y Envoy es responsable de enrutar las solicitudes de lectura y escritura de la caché emitidas por la aplicación al nodo de Redis correcto. En un sistema de microservicio, hay una gran cantidad de procesos de aplicación que necesitan acceder al servidor de caché. Para evitar puntos únicos de falla y cuellos de botella de rendimiento, implementamos un proxy Envoy para cada proceso de aplicación en forma de Sidecar. Al mismo tiempo, con el fin de simplificar la gestión de estos proxies, podemos utilizar Istio como plano de control para configurar de manera uniforme todos los proxies Envoy, como se muestra en la siguiente figura:
En la parte siguiente de este artículo, presentaremos cómo administrar Redis Cluster a través de Istio y Envoy, realizar particiones de datos que no son sensibles al cliente y estrategias de enrutamiento avanzadas como separación de lectura y escritura y duplicación de tráfico.
Implementar Istio
El protocolo Redis ya es compatible con Pilot, pero la función es débil. Solo puede configurar una ruta predeterminada para el proxy de Redis y no es compatible con el modo de clúster de Redis. Es imposible realizar la fragmentación de datos del filtro de Redis, la separación de lectura y escritura, la duplicación de tráfico y otra gestión avanzada del tráfico Caracteristicas. Para permitir que Istio entregue la configuración relacionada con Redis Cluster al Envoy Sidecar, modificamos el código relacionado con la configuración de EnvoyFilter para admitir la operación "REPLCAE" de EnvoyFilter. La operación PR Implement REPLACE revisada para el parche EnvoyFilter se envió a la comunidad de Istio, se fusionó con la rama principal y se lanzará en versiones posteriores de Istio.
En el momento de escribir este artículo, la última versión 1.7.3 de Istio aún no ha incorporado este PR. Así que construí una imagen piloto para habilitar la operación "REPLACE" de EnvoyFilter. Al instalar Istio, necesitamos especificar la imagen piloto en el comando istioctl, como se muestra en la siguiente línea de comando:
$ cd istio-1.7.3/bin
$ ./istioctl install --set components.pilot.hub=zhaohuabing --set components.pilot.tag=1.7.3-enable-ef-replaceNota: Si su versión de Istio es más reciente que la 1.7.3 y se ha incorporado el PR, puede usar directamente la duplicación piloto predeterminada en la versión de Istio.
Implementar Redis Cluster
Descargue el código relevante utilizado en el siguiente ejemplo de https://github.com/zhaohuabing/istio-redis-culster :
$ git clone https://github.com/zhaohuabing/istio-redis-culster.git
$ cd istio-redis-culsterCreamos un espacio de nombres "redis" para implementar Redis Cluster en este ejemplo.
$ kubectl create ns redis
namespace/redis createdImplemente Statefulset y Configmap del servidor Redis.
$ kubectl apply -f k8s/redis-cluster.yaml -n redis
configmap/redis-cluster created
statefulset.apps/redis-cluster created
service/redis-cluster createdVerificar la implementación de Redis
Confirme que el nodo de 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 117sCrear clúster de Redis
En los pasos anteriores, implementamos 6 nodos de Redis usando Statefulset, pero actualmente estos 6 nodos siguen siendo independientes entre sí y no forman un clúster. Aquí usamos los cluster createcomandos de Redis para estos nodos, un Clúster de 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.Verificar el clúster de Redis
Podemos usar el cluster infocomando para ver la información de configuración y los nodos miembros de Redis Cluster Cluster para verificar que el clúster se haya creado correctamente.
$ 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:416Implementar el cliente de prueba
Implementamos un cliente para enviar comandos de prueba:
$ kubectl apply -f k8s/redis-client.yaml -n redis
deployment.apps/redis-client createdDistribuya la configuración de Envoy relacionada con Redis Cluster a través de Istio
En los siguientes pasos, enviaremos la configuración relacionada con Redis Cluster a Envoy Sidecar a través de Istio para habilitar las funciones avanzadas de Redis Cluster sin cambiar el cliente, incluida la fragmentación de datos, la separación de lectura y escritura y la duplicación del tráfico.
Crear clúster de Envoy Redis
Envoy proporciona un Envoy Cluster de tipo "envoy.clusters.redis" para conectarse al back-end Redis Cluster. Envoy obtendrá la topología del back-end Redis Cluster a través del Cluster, incluyendo cuántos fragmentos, cada fragmento es responsable Qué ranuras y qué nodos se incluyen en el fragmento para distribuir las solicitudes de los clientes a los nodos de Redis correctos.
Utilice EnvoyFilter para crear el clúster de Envoy Redis necesario:
$ kubectl apply -f istio/envoyfilter-custom-redis-cluster.yaml
envoyfilter.networking.istio.io/custom-redis-cluster createdCrear proxy de Envoy Redis
El LDS predeterminado de Istio está configurado con el filtro de proxy TCP, debemos reemplazarlo con el filtro de proxy de Redis.
Dado que la operación "REPLACE" de EnvoyFilter aún no se admite en 1.7.3, primero debemos actualizar la definición CRD de EnvoyFilter antes de crear EnvoyFilter:
$ kubectl apply -f istio/envoyfilter-crd.yaml
customresourcedefinition.apiextensions.k8s.io/envoyfilters.networking.istio.io configuredUtilice EnvoyFilter para reemplazar el filtro de proxy TCP con el filtro de proxy de Redis para que Envoy pueda enviar por proxy las solicitudes de operación de Redis de los 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 createdVerificar la función de Redis Cluster
Ahora que todo está listo, verifiquemos las distintas funciones de Redis Cluster.
Fragmentación de datos de Redis
Después de enviar la configuración definida en EnvoyFilter a Envoy a través de Istio, Envoy puede descubrir automáticamente la topología del back-end Redis Cluster y distribuir automáticamente la solicitud al nodo correcto en Redis Cluster de acuerdo con la clave en la solicitud del cliente.
De acuerdo con el resultado de la línea de comando en el paso anterior de creación de Redis Cluster, podemos ver la topología del Redis Cluster: hay tres fragmentos en el clúster, y cada fragmento tiene un nodo maestro y un nodo esclavo (réplica). El cliente accede al Clúster de Redis a través del Envoy Proxy implementado en el mismo Pod, como se muestra en la siguiente figura:
Las direcciones de nodo maestro y esclavo de cada fragmento en 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 - 16383Nota: Si implementa este ejemplo en su propio clúster de K8s, la dirección IP y la topología de cada nodo en Redis Cluster pueden ser ligeramente diferentes, pero la estructura básica debería ser similar.
Intentamos enviar varias claves diferentes a Rdeis Cluster desde las setsolicitudes de los clientes :
$ 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
OKDesde la perspectiva del cliente, todas las solicitudes son exitosas, podemos usar el scancomando para ver los datos en cada nodo en el lado del servidor:
Vea los datos en el fragmento [0], el nodo principal es redis-cluster-0 y el nodo esclavo es 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
bVea los datos en el fragmento [1], el nodo maestro es redis-cluster-1 y el nodo esclavo es 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
cVerifique los datos en el fragmento [2], el nodo maestro es redis-cluster-2 y el nodo esclavo es 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 se puede ver en los resultados de verificación anteriores, el conjunto de datos del cliente se distribuye a los tres fragmentos en el clúster de Redis. Envoy Redis Proxy implementa automáticamente el proceso de distribución de datos. El cliente no percibe el clúster de Redis de fondo. Para el cliente, la interacción con el clúster de Redis es la misma que la interacción con un solo nodo de Redis.
Con este método, podemos migrar sin problemas Redis en el sistema de un solo nodo al modo de clúster cuando la escala del negocio de aplicaciones se expande gradualmente y la presión sobre un solo nodo de Redis es demasiado alta. En el modo de clúster, los datos de diferentes claves se almacenan en caché en diferentes fragmentos de datos. Podemos aumentar la cantidad de nodos de réplica en los fragmentos para expandir un fragmento o aumentar el número de fragmentos para expandir todo el clúster. , Para hacer frente a la mayor presión de datos debido a la expansión empresarial. Dado que Envoy puede percibir la topología del clúster de Redis Cluster, y Envoy completa la distribución de datos, todo el proceso de migración y expansión no requiere un cliente y no afectará el funcionamiento normal del negocio en línea.
Separación de lectura y escritura de Redis
En un fragmento de Redis, generalmente hay un nodo maestro y uno o más nodos esclavos (réplica). El nodo maestro es responsable de escribir las operaciones y sincronizar los cambios de datos en el nodo esclavo. Cuando la presión de la operación de lectura de la aplicación es relativamente alta, podemos agregar más réplicas al fragmento para compartir la carga de la operación de lectura. Envoy Redis Rroxy admite la configuración de diferentes estrategias de lectura:
- MASTER: Solo lee datos del nodo Master. Este modo es necesario cuando el cliente requiere una fuerte consistencia de datos. Este modo ejerce mucha presión sobre el maestro y no se pueden usar varios nodos para cargar la operación de lectura compartida en el mismo fragmento.
- PREFER_MASTER: primero lea los datos del nodo principal. Cuando el nodo principal no esté disponible, lea los datos del nodo réplica.
- REPLICA: Solo lee datos del nodo Replica. Dado que el proceso de replicación de datos de Master a Replica se realiza de forma asíncrona, es posible leer datos caducados de esta manera, por lo que es adecuado para escenarios donde el cliente no tiene altos requisitos de consistencia de datos. En este modo, se pueden utilizar varios nodos de réplica para compartir la carga de lectura del cliente.
- PREFER_REPLICA: primero lee los datos del nodo réplica y lee los del nodo maestro cuando el nodo réplica no está disponible.
- CUALQUIERA: lee datos de cualquier nodo.
En el EnvoyFilter publicado anteriormente, configuramos la estrategia de lectura de Envoy Redis Proxy en "REPLICA", por lo que las operaciones de lectura del cliente solo deben enviarse al nodo Replica. Usemos el siguiente comando para verificar la estrategia de separación lectura-escritura:
Al iniciar una serie de acciones clave del cliente es "b" gety 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> En la topología anterior de Redis Cluster, hemos aprendido que la clave "b" pertenece al fragmento Shard [0]. Podemos ordenar redis-cli monitorpara ver el comando slice Master y el nodo réplica recibido.
Nodo maestro:
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitorNodo esclavo:
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitorComo puede verse en la figura, todas las getsolicitudes se envían al nodo Replica Envoy.
Duplicación de tráfico de Redis
Envoy Redis Proxy admite la duplicación de tráfico, es decir, las solicitudes enviadas por el cliente se envían simultáneamente a un servidor / clúster Redis duplicado. La duplicación de tráfico es una función muy útil. Podemos utilizar la duplicación de tráfico para importar datos en línea desde el entorno de producción al entorno de prueba para usar datos en línea para simular la aplicación de la manera más realista posible sin afectar la línea Uso normal por parte de los usuarios de Internet.
Creamos un nodo Redis de un solo nodo para usarlo como servidor espejo:
$ kubectl apply -f k8s/redis-mirror.yaml -n redis
deployment.apps/redis-mirror created
service/redis-mirror createdUtilice EnvoFilter para habilitar la estrategia de duplicación:
$ 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 configuredAl iniciar una serie de acciones clave del cliente es "b" gety 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 monitorvista Command Master, réplica y nodo reflejado recibido respectivamente.
Nodo maestro:
$ kubectl exec redis-cluster-0 -c redis -n redis -- redis-cli monitorNodo esclavo:
$ kubectl exec redis-cluster-4 -c redis -n redis -- redis-cli monitorNodo espejo:
$ 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 monitorComo puede verse en la figura, todas las setsolicitudes se envían al Envoy, un nodo espejo.
Principio de implementación
En los pasos anteriores, creamos dos objetos de configuración EnvoyFilter en Istio. Estos dos EnvoyFilter modifican la configuración del proxy Envoy, que incluye principalmente dos partes: configuración del filtro de red del proxy de Redis y configuración del clúster de Redis.
El siguiente EnvoyFilter reemplaza el filtro de red de proxy TCP en el oyente creado por Pilot para el servicio Redis y lo reemplaza con un filtro de red del tipo "type.googleapis.com/envoy.config.filter.network.redis_proxy.v2.RedisProxy". La ruta predeterminada del proxy de Redis apunta a "custom-redis-cluster" y se configuran la estrategia de separación de lectura y escritura y la estrategia de duplicación de tráfico.
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 replicaEl siguiente EnvoyFilter crea un clúster de tipo "envoy.clusters.redis" en el CDS emitido por Pilot: "custom-redis-cluster", el clúster utilizará el comando CLUSTER SLOTS para consultar un nodo aleatorio en el clúster de Redis para el clúster La estructura de la topología y guarde la estructura de la topología localmente para distribuir las solicitudes del cliente a los nodos de Redis correctos en el clúster.
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: 5resumen
En este artículo se describe cómo usar Envoy para proporcionar fragmentación de datos de Redis independiente del cliente para aplicaciones de microservicio y cómo usar Istio para administrar de manera uniforme la configuración de Redis Cluster de varios agentes Envoy en el sistema. Podemos ver que el uso de Istio y Envoy puede simplificar en gran medida la codificación y configuración del cliente usando Redis Cluster, y la estrategia de operación y mantenimiento de Redis Cluster se puede modificar en línea para lograr una gestión avanzada del tráfico, como la separación de lectura y escritura y la duplicación del tráfico. Por supuesto, la introducción de Istio y Envoy no redujo la complejidad de todo el sistema, sino que concentró el mantenimiento de Redis Cluster desde el código de aplicación disperso hasta la capa de infraestructura de la red de servicios. En correspondencia con la mayoría de los desarrolladores de aplicaciones, su valor comercial proviene principalmente del código de la aplicación y no es rentable invertir mucha energía en dicha infraestructura. Se recomienda utilizar directamente el servicio TCM (Tencent Cloud Mesh) nativo de la nube de Service Mesh en Tencent Cloud para introducir rápidamente las capacidades de gestión de tráfico y gobernanza de servicios de Service Mesh para aplicaciones de microservicio, sin la necesidad de prestar atención a la instalación, el mantenimiento y la actualización de la propia infraestructura de Service Mesh. Y otros asuntos.