🥇Casos de uso da malla de servizos

Nota. transl.O autor deste artigo (Luc Perkins) é defensor dos desenvolvedores en CNCF, fogar de proxectos de código aberto como Linkerd, SMI (Service Mesh Interface) e Kuma (por certo, preguntácheste algunha vez por que Istio non está nesta lista?). Noutro intento de achegar unha mellor comprensión da moda da "malla de servizos" á comunidade DevOps, enumera 16 capacidades clave que proporcionan estas solucións.

Hoxe malla de servizo ― é un dos temas máis candentes da enxeñaría de software (e con razón!). Creo que esta tecnoloxía é incriblemente prometedora e soño con presenciar a súa adopción xeneralizada (cando teña sentido, por suposto). Non obstante, aínda permanece envolta no misterio para a maioría da xente. Mesmo aqueles que familiarizado con con el, a miúdo teñen dificultades para formular as súas vantaxes e o que é exactamente (incluído o meu servidor). Neste artigo, tentarei corrixir a situación enumerando os diversos casos de uso "grexas de servizo"*.

* Nota do tradutor: De agora en diante neste artigo, esta tradución ("malla de servizo") usarase para o termo aínda novo malla de servizo.

Pero primeiro quero facer algúns comentarios:

Nunca traballei con mallas de servizos nin as empreguei fóra de proxectos realizados para a miña propia formación. Por outra banda, escribín moitísima documentación para a malla de servizos interna de Twitter en 2015 (nin sequera se chamaba "malla de servizos" naquel entón) e contribuín ao sitio web e á documentación de Linkerd, polo tanto, significa algo.
A miña lista é provisional e incompleta. Sen dúbida, hai casos prácticos cos que non me atopei e é probable que xurdan outros novos co tempo a medida que a tecnoloxía evolucione e se faga máis popular.
Ao mesmo tempo, non todas as implementacións de malla de servizos existentes admiten todos os casos de uso anteriores. Polo tanto, afirmacións como "unha malla de servizos pode..." deberían interpretarse como "certas, e quizais incluso todas, as implementacións populares de malla de servizos poden...".
A orde dos exemplos non importa.

Lista curta:

descubrimento de servizos;
cifrado;
autenticación e autorización;
balanceamento de carga;
interrupción de circuíto;
escalado automático;
despregamentos canarios;
despregamentos azul-verdes;
revisión sanitaria;
deslastre de carga;
espello do tráfico;
illamento;
limitación da taxa de solicitudes, reintentos e tempos de espera;
telemetría;
auditoría;
visualización.

1. Descubrimento de servizos

TL;DR: Conéctate a outros servizos da rede usando nomes sinxelos.

Os servizos deberían ser capaces de "atoparse" automaticamente uns ós outros usando nomes axeitados, como service.api.production, pets/staging ou cassandraOs entornos na nube caracterízanse pola súa elasticidade e un só nome pode ocultar varias instancias de servizo. Claramente, nunha situación así, é fisicamente imposible codificar todos os enderezos IP.

Ademais, cando un servizo descobre outro, debería poder enviar solicitudes a ese servizo sen medo a que acaben na entrada dunha instancia inactiva. Noutras palabras, a malla de servizos debe supervisar o estado de todas as instancias de servizo e manter a lista de hosts o máis actualizada posible.

Cada malla de servizos implementa a detección de servizos de forma diferente. Actualmente, o método máis común é delegar a procesos externos como o DNS de Kubernetes. No pasado, en Twitter, usabamos un sistema de nomes para este propósito. FinagleAdemais, a tecnoloxía de malla de servizos permite crear mecanismos de nomes personalizados (aínda que aínda non atopei ningunha implementación de SM con tal funcionalidade).

2. Cifrado

En resumo: elimine o tráfico non cifrado entre os servizos e faga que este proceso sexa automatizado e escalable.

É reconfortante saber que os atacantes non poden penetrar na túa rede interna. Os cortafuegos fan un gran traballo para previr isto. Pero que ocorre se un pirata informático entra? Poderá facer o que queira co teu tráfico de servizos interno? Esperemos que iso non ocorra. Para evitar este escenario, debes implementar unha rede de confianza cero, na que todo o tráfico entre os servizos estea cifrado. A maioría das mallas de servizos modernas conseguen isto mediante a autenticación mutua. TLS (TLS mutuo, mTLS). Nalgúns casos, mTLS funciona en nubes e clústeres enteiros (creo que as comunicacións interplanetarias algún día terán unha estrutura similar).

Por suposto, para a malla de servizos mTLS opcionalCada servizo pode xestionar o seu propio TLS, pero iso significa atopar unha forma de xerar certificados, distribuílos entre os hosts do servizo e incluír código na aplicación para cargar estes certificados desde ficheiros. Ah, e non esquezas renovar estes certificados a intervalos regulares. As mallas de servizos automatizan mTLS usando sistemas como SPIFFE, que, á súa vez, automatizan o proceso de emisión e rotación de certificados.

3. Autenticación e autorización

En resumo: establece quen inicia a solicitude e determina que poden facer antes mesmo de que a solicitude chegue ao servizo.

Os servizos a miúdo queren saber, quen fai unha solicitude (autenticación) e, usando esta información, decide, que Este suxeito está autorizado a facer (autorización). Neste caso, o pronome "quen" pode referirse a:

Outros servizos. Isto chámase "autenticación" par'a"Por exemplo, o servizo web quere acceder ao servizo dbAs mallas de servizos adoitan resolver este tipo de problemas mediante mTLS, cos certificados actuando como o identificador necesario.
Algúns usuarios humanos. Isto chámase "autenticación" solicitude"Por exemplo, o usuario haxor69 quere mercar unha lámpada nova. As grellas de servizo proporcionan varios mecanismos, por exemplo, Tokens web JSON.
Moitos de nós fixemos isto no código da nosa aplicación. Chega unha solicitude e revisamos unha táboa. users, atopamos o usuario e comparamos o contrasinal, despois comprobamos a columna permissions etc. No caso dunha malla de servizos, isto ocorre incluso antes de que a solicitude chegue ao servizo.

Unha vez que establecemos de quen provén a solicitude, debemos determinar que pode facer ese suxeito. Algunhas mallas de servizos permiten definir políticas básicas (con respecto a quen pode facer que) en forma de ficheiros YAML ou na liña de comandos, mentres que outras ofrecen integración con marcos de traballo como Abre axente de políticasO obxectivo final é garantir que os seus servizos acepten calquera solicitude coa confianza de que provén dunha fonte fiable. и Esta acción está permitida.

4. Balanceo de carga

TL;DR: Distribuír a carga entre as instancias de servizo segundo un patrón específico.

O "servizo" dentro dunha sección de servizo adoita consistir en varias instancias idénticas. Por exemplo, o servizo actual cache consta de 5 copias e mañá o seu número podería aumentar a 11. Solicitudes enviadas a cache, deben distribuírse segundo un obxectivo específico. Por exemplo, para minimizar a latencia ou maximizar a probabilidade de alcanzar unha instancia saudable. O algoritmo de rotación por turnos é o máis empregado, pero hai moitos outros, como o método de orde ponderada. (ponderada) consultas (podes seleccionar obxectivos preferidos), soar (anel) método de hash (usando hash consistente para os hosts augas arriba) ou método de menos solicitudes (dáse preferencia á instancia con menos solicitudes).

Os balanceadores de carga clásicos tamén ofrecen outras funcións, como o almacenamento en caché HTTP e a protección DDoS, pero non son particularmente relevantes para o tráfico leste-oeste (é dicir, o tráfico que flúe dentro dun centro de datos, nota do tradutor) (a aplicación típica dunha malla de servizos). Aínda que non se require unha malla de servizos para o balanceamento de carga, si permite definir e controlar as políticas de balanceamento de carga para cada servizo desde un plano de control centralizado, eliminando así a necesidade de implementar e configurar balanceadores de carga separados na pila de rede.

5. Corte de circuíto

En resumo: detén o tráfico cara ao servizo problemático e controla os danos nos peores casos.

Se por calquera razón un servizo non pode xestionar o tráfico, a malla de servizos ofrece varias opcións para resolver este problema (outras serán discutidas nas seccións correspondentes). A interrupción do circuíto é a opción máis grave para desconectar un servizo do tráfico. Non obstante, é inútil por si soa: é necesario un plan de reserva. Pode incluírse contrapresión. (contrapresión) a servizos que cumpren solicitudes (só lembra configurar a túa malla de servizos para isto!), ou, por exemplo, poñer a páxina de estado en vermello e redirixir os usuarios a outra versión da páxina cunha "balea caendo" ("Twitter non funciona").

As cuadrículas de servizos permítenche non só determinar, onde seguirá un peche e que seguirá. Neste caso, "cando" pode incluír calquera combinación de parámetros especificados: o número total de solicitudes durante un determinado período, o número de conexións simultáneas, solicitudes pendentes, intentos activos, etc.

Probablemente non queiras abusar dos interruptores, pero é bo saber que tes un plan de reserva en caso de emerxencias.

6. Escalado automático

TL;DR: Aumentar ou diminuír o número de instancias de servizo segundo criterios especificados.

As mallas de servizos non son planificadores, polo que non o fan levar a cabo Escalamento independente. Non obstante, poden proporcionar información que os programadores poden usar para tomar decisións. Dado que as mallas de servizos teñen acceso a todo o tráfico entre os servizos, dispoñen de información exhaustiva sobre o que está a suceder: que servizos están a experimentar problemas, cales están infrautilizados (a súa capacidade asignada está a ser desperdiciada) e así sucesivamente.

Por exemplo, Kubernetes escala os servizos en función do uso da CPU e da memoria dos pods. (Vexa o noso informe)Autoescalado e xestión de recursos en Kubernetes"- aprox. trad.), pero se decides escalar en función de calquera outra métrica (no noso caso, relacionada co tráfico), necesitarás unha métrica dedicada. algo así mostra como facer isto usando enviado, Istio и Prometeu, pero o proceso en si é bastante complexo. Queremos que a malla de servizos o simplifique, permitíndonos simplemente establecer condicións como "aumentar o número de instancias de servizo" auth, se o número de solicitudes en espera para ser executadas supera o límite durante un minuto.

7. Implementacións de Canary

En resumo: proba novas funcionalidades ou versións dun servizo nun subconxunto de usuarios.

Digamos que estás a desenvolver un produto SaaS e estás a piques de lanzar unha nova versión interesante. Probáchelo en fases e funciona perfectamente. Pero aínda che preocupa como funcionará en condicións reais. Noutras palabras, necesitas probar a nova versión en escenarios reais sen arriscar a confianza dos usuarios. As implementacións de Canary son perfectas para isto. Permiten demostrar unha nova funcionalidade a un subconxunto de usuarios. Este subconxunto podería estar formado polos teus usuarios máis fieis, os que usan a versión gratuíta do produto ou usuarios dispostos a servir como cobaias.

As mallas de servizos conségueno permitíndoche especificar criterios que determinan quen ve que versión da túa aplicación e, a seguir, dirixir o tráfico en consecuencia. Non obstante, nada cambia para os propios servizos. A versión 1.0 dun servizo asume que todas as solicitudes proveñen de usuarios que deberían velas, e a versión 1.1 asume o mesmo para os seus propios usuarios. Mentres tanto, podes variar a porcentaxe de tráfico entre as versións antiga e nova, redirixindo un número crecente de usuarios á nova versión se é estable e os teus "suxeitos de proba" o aproban.

8. Implementacións azul-verdes

En resumo: lanza unha nova funcionalidade xenial, pero prepárate para revertela inmediatamente.

Significado despregamentos azul-verdes A idea é lanzar un novo servizo "azul", executándoo en paralelo co antigo servizo "verde". Se todo vai ben e o novo servizo funciona ben, o antigo pode pecharse gradualmente. (Desafortunadamente, algún día este novo servizo "azul" tamén correrá o mesmo destino que o "verde" e desaparecerá...) As implementacións azul-verdes difiren das implementacións canarias en que a nova funcionalidade abrangue todo á vez usuarios (non unha parte); o obxectivo aquí é ter un "porto de copia de seguridade" listo no caso de que algo saia mal.

As mallas de servizos ofrecen unha forma moi cómoda de probar un servizo "azul" e cambiar instantaneamente a un "verde" que funcione en caso de problema. Ademais, tamén proporcionan unha gran cantidade de información (consulta "Telemetría" a continuación) sobre o rendemento do servizo "azul", o que axuda a determinar se está listo para a produción completa.

Nota. transl.Podes ler máis sobre as diferentes estratexias de despregamento en Kubernetes (incluíndo as xa mencionadas, Canary, Blue/Green e outras) en Este artigo.

9. Revisión de saúde

En resumo: monitoriza que instancias de servizo están en bo estado e responde ás que se volvan incorrectas.

Revisión sanitaria (revisión de saúde) axuda a decidir se as instancias de servizo están listas para recibir e procesar tráfico. Por exemplo, no caso dos servizos HTTP, unha comprobación de estado pode ter o aspecto dunha solicitude GET a un punto final. /healthResposta 200 OK significará que a instancia está en bo estado, mentres que calquera outra significará que non está lista para recibir tráfico. As mallas de servizos permítenche especificar tanto o método de comprobación do estado como a frecuencia coa que se realiza. Esta información pódese usar para outros fins, como o balanceo de carga e a interrupción de circuítos.

Polo tanto, as comprobacións de estado non son un caso de uso independente, senón que se empregan normalmente para acadar outros obxectivos. Ademais, dependendo dos resultados das comprobacións de estado, poden ser necesarias accións externas a outros obxectivos da malla de servizos: por exemplo, actualizar unha páxina de estado, crear un problema de GitHub ou presentar un tícket JIRA. E a malla de servizos ofrece un mecanismo cómodo para automatizar todo isto.

10. Deslastre de carga

En resumo: Redireccionar o tráfico en resposta a un pico temporal no uso.

Se un servizo está sobrecargado de tráfico, podes redirixir temporalmente parte dese tráfico a outra localización (é dicir, "soltalo" ou "vertelo") (galpón) (por exemplo, a un servizo de copias de seguridade ou a un centro de datos, ou a un centro permanente prensa tema. Como resultado, o servizo continuará a procesar algunhas solicitudes en lugar de fallar e deter o procesamento de todas as solicitudes. A eliminación de carga é preferible á interrupción da cadea, pero aínda non é desexable usala en exceso. Axuda a evitar fallos en cascada que poderían provocar o colapso dos servizos augas abaixo.

11. Paralelización/creación de espellos do tráfico

En resumo: envía unha solicitude a varios lugares á vez.

Ás veces é necesario enviar unha solicitude (ou unha selección de solicitudes) a varios servizos simultaneamente. Un exemplo típico é enviar unha parte do tráfico de produción a un servizo de probas. O servidor web de produción principal envía a solicitude ao servizo posterior. products.production e só a el. E a malla de servizos copia intelixentemente esta solicitude e envíaa a products.staging, da que o servidor web nin sequera ten coñecemento.

Outro caso de uso relacionado para a malla de servizos que se pode implementar sobre a paralelización do tráfico é probas de regresiónImplica enviar as mesmas solicitudes a diferentes versións dun servizo e comprobar se todas as versións se comportan de xeito idéntico. Aínda non vin unha implementación de malla de servizos cun sistema integrado de probas de regresión como Diffy, pero a idea en si mesma semella prometedora.

12. Illamento

En resumo: Divide a túa malla de servizos en miniredes.

Tamén coñecido como segmentaciónO illamento é a arte de dividir unha malla de servizos en segmentos loxicamente separados que descoñecen uns dos outros. O illamento é algo similar á creación de redes privadas virtuais. A diferenza clave é que aínda se poden gozar de todos os beneficios dunha malla de servizos (como a detección de servizos), pero con maior seguridade. Por exemplo, se un atacante consegue penetrar nun servizo nunha subrede, non poderá ver que servizos se están a executar noutras subredes nin interceptar o seu tráfico.

Tamén pode haber vantaxes organizativas. Pode que queiras dividir os servizos en subredes segundo a estrutura da túa empresa e aliviar aos desenvolvedores da carga cognitiva de ter que facer un seguimento de toda a malla de servizos.

13. Limitación da taxa de solicitude, reintentos e tempos de espera

En resumo: xa non é necesario incluír tarefas de xestión de solicitudes que requiren moito tempo na base de código.

Todas estas cousas poderían considerarse casos de uso separados, pero decidín combinalas debido a unha característica común: descargan as tarefas de xestión do ciclo de vida das solicitudes que normalmente manexan as bibliotecas de aplicacións. Se estás a desenvolver un servidor web Ruby on Rails (non integrado coa malla de servizos) que realiza solicitudes a servizos de backend a través de gRPC, a aplicación terá que decidir por si mesma que facer se fallan N solicitudes. Tamén terá que determinar canto tráfico poden manexar estes servizos e codificar estes parámetros mediante unha biblioteca especial. Ademais, a aplicación terá que decidir cando desistir e deixar que a solicitude caduque (mediante un tempo de espera). E para cambiar calquera dos parámetros anteriores, o servidor web terá que ser detido, reconfigurado e reiniciado.

Delegar estas tarefas á malla de servizos non só elimina a necesidade de que os desenvolvedores de servizos pensen nelas, senón que tamén permite consideralas de forma máis holística. Se se trata dunha cadea complexa de servizos, por exemplo, A -> B -> C -> D -> E, débese considerar todo o ciclo de vida da solicitude. Se a tarefa consiste en ampliar os tempos de espera no servizo C, ten sentido facelo todo á vez, en lugar de facelo por partes: actualizar o código do servizo e esperar a que se acepte a solicitude de extracción e o sistema de CI implemente o servizo actualizado.

14. Telemetría

TL;DR: Recolle toda a información necesaria (e a non totalmente necesaria) dos servizos.

A telemetría é un termo xenérico que inclúe métricas, rastrexo distribuído e rexistro. As mallas de servizos ofrecen mecanismos para recoller e procesar os tres tipos de datos. Aquí é onde as cousas se volven un pouco confusas, xa que o número de opcións posibles é abrumador. Para a recollida de métricas, hai Prometeu e outras ferramentas que se poden usar para recoller rexistros fluented, Loki, Vector etc (por exemplo, ClickHouse co noso caseta de troncos para K8s — nota do tradutor), para o rastrexo distribuído existe Jaeger etc. Cada malla de servizos pode ser compatible con algunhas ferramentas e non con outras. Será interesante ver se o proxecto pode Telemetría aberta proporcionar certa converxencia.

Neste caso, a vantaxe da tecnoloxía de malla de servizos é que os contedores sidecar poden, en principio, recoller todos os datos anteriores dos seus servizos. Noutras palabras, tes un sistema unificado de recollida de telemetría á túa disposición e a malla de servizos pode procesar toda esta información de diversas maneiras. Por exemplo:

rexistros de cola dun determinado servizo na CLI;
Monitorizar o volume de solicitudes desde o panel de mando da malla de servizos;
recoller trazas distribuídas e reenvialas a un sistema como Jaeger.

Atención, xuízo subxectivo: En xeral, a telemetría é unha área onde non é desexable unha intervención intensa da malla de servizos. Recompilar información básica e rastrexar algunhas "métricas de ouro" sobre a marcha, como as taxas de éxito e a latencia, está ben, pero esperemos que non sexamos testemuñas da aparición de pilas de Frankenstein que intentan substituír sistemas especializados, algúns dos cales xa están probados e ben estudados.

15. Auditoría

TL;DR: Quen esquece as leccións da historia está condenado a repetilas.

A auditoría é a arte de monitorizar eventos importantes nun sistema. No caso dunha malla de servizos, isto pode significar rastrexar quen realizou solicitudes a puntos finais específicos de servizos específicos ou cantas veces ocorreu un determinado evento relacionado coa seguridade no último mes.

É evidente que a auditoría está estreitamente relacionada coa telemetría. A diferenza é que a telemetría adoita asociarse a cousas como o rendemento e a integridade técnica, mentres que a auditoría pode estar relacionada con cuestións legais e doutro tipo que van máis alá do ámbito estritamente técnico (por exemplo, o cumprimento do Regulamento Xeral de Protección de Datos da UE, RGPD).

16. Vista previa

TL;DR: Longa vida a React.js, a fonte das interfaces caprichosas.

Pode haber un termo máis axeitado, pero non o coñezo. Simplemente refírome a unha representación gráfica da malla de servizos ou dalgúns dos seus compoñentes. Estas visualizacións poden incluír indicadores como a latencia media, información de configuración do contedor lateral, resultados da comprobación de estado e alertas.

Traballar nun ambiente orientado aos servizos está asociado a unha carga cognitiva moito maior que en His Maxesty the Monolith. Polo tanto, a presión cognitiva debería reducirse a toda costa. Unha interface gráfica sinxela para unha malla de servizos, que permita aos usuarios premer un botón e obter o resultado desexado, podería ser crucial para o crecemento desta tecnoloxía.

Non foron incluídos na lista

Ao principio tiña a intención de incluír algúns casos de uso máis na lista, pero despois decidín non facelo. Aquí están, xunto cos motivos da miña decisión:

Centro de datos múltiplesNa miña opinión, este non é tanto un caso de uso como unha área de aplicación estreita e específica para mallas de servizos ou un certo conxunto de funcións como a detección de servizos.
Entrada e saídaEsta é unha área relacionada, pero limiteime (quizais artificialmente) ao caso de uso do "tráfico leste-oeste". A entrada e a saída merecen un artigo separado.

Conclusión

Iso é todo por agora! Repito, esta lista é moi xeral e probablemente incompleta. Se cres que me pasei algo por alto ou cometin un erro, ponte en contacto comigo en Twitter (@lucperkins). Por favor, observe as normas de decencia.

PS do tradutor

A ilustración principal do artigo está baseada nunha imaxe do artigo "Que é unha malla de servizos (e cando usala)?"(por Gregory MacKinnon). Mostra como algunhas das funcionalidades das aplicacións (en verde) migraron á malla de servizos que proporciona as conexións entre elas (en azul)."

Lea tamén no noso blog:

Fonte: www.habr.com