Nota. traducir: Service mesh es un fenómeno que aún no tiene una traducción estable al ruso (hace más de 2 años ofrecimos la opción "mesh for services", y un poco más tarde, algunos colegas comenzaron a promover activamente la combinación "service sieve") . Hablar constantemente sobre esta tecnología ha llevado a una situación en la que los componentes técnicos y de marketing están demasiado entrelazados. Este maravilloso material de uno de los autores del término original pretende brindar claridad a los ingenieros y no solo.
Cómic de
introducción
Si usted es un ingeniero de software que trabaja en algún lugar del área de sistemas back-end, el término "malla de servicio" probablemente ya se haya arraigado firmemente en su mente durante los últimos años. Gracias a una extraña coincidencia, esta frase se está apoderando cada vez más de la industria, y la exageración y las ofertas promocionales relacionadas están creciendo como una bola de nieve, volando colina abajo y sin mostrar signos de desaceleración.
La malla de servicios nació en las aguas turbias y tendenciosas del ecosistema nativo de la nube. Desafortunadamente, esto significa que gran parte de la controversia que lo rodea va desde "charlas bajas en calorías" hasta, para usar el término técnico, mentiras flagrantes. Pero si filtra todo el ruido, puede encontrar que la red de servicios tiene una función muy real, definida e importante.
En esta publicación, intentaré hacer exactamente eso: proporcionar una guía honesta, detallada y orientada a ingenieros sobre la red de servicios. Voy a responder más que solo la pregunta: "¿Lo que es?", - pero también "¿Para qué?"y "¿Porqué ahora?". Finalmente, trataré de explicar por qué (en mi opinión) esta tecnología en particular ha causado tanta expectación, que en sí misma es una historia interesante.
Кто я?
¡Hola a todos! Mi nombre es . soy uno de los creadores - el primer proyecto de malla de servicio y el proyecto que tiene la culpa de la aparición del término malla de servicio como tal (¡lo siento chicos!). (Nota trad.: Por cierto, en los albores de la aparición de este término, hace más de 2,5 años, ya traducimos el material inicial del mismo autor llamado ". ") yo también dirijo es una startup que crea cosas geniales de malla de servicio como Linkerd y .
Probablemente puedas adivinar que tengo una opinión muy sesgada y subjetiva sobre este tema. Sin embargo, intentaré mantener el sesgo al mínimo (con la excepción de una sección: “¿Por qué se habla tanto de la red de servicios?”, - en el que, no obstante, compartiré mis ideas preconcebidas). También haré todo lo posible para que esta guía sea lo más objetiva posible. En ejemplos concretos, me basaré principalmente en la experiencia de Linkerd, señalando las diferencias (si las hay) que conozco en la implementación de otros tipos de redes de servicios.
Bien, es hora de pasar a las golosinas.
¿Qué es una red de servicios?
A pesar de todo el bombo, la red de servicio es estructuralmente bastante simple. Es solo un grupo de proxies de espacio de usuario ubicados "junto a" servicios (hablaremos un poco sobre "cerca" más adelante), además de un conjunto de procesos de control. Los proxies se denominan colectivamente plano de datos, y los procesos de control se denominan plano de control. El plano de datos intercepta llamadas entre servicios y hace "cualquier cosa diferente" con ellos; el plano de control, respectivamente, coordina el comportamiento del proxy y le proporciona acceso, es decir, operador, a la API, permitiendo manipular y medir la red en su conjunto.
¿Qué es este proxy? Este es un proxy TCP de la categoría "Consciente de la capa 7" (es decir, "teniendo en cuenta" la séptima capa del modelo OSI) como HAProxy y NGINX. Puedes elegir un proxy a tu gusto; Linkerd usa un proxy Rust, llamado sin complicaciones . Lo hemos compilado específicamente para la malla de servicio. Otras mallas prefieren otros proxies (Envoy es una opción común). Sin embargo, elegir un proxy es solo una cuestión de implementación.
¿Qué hacen estos servidores proxy? Obviamente, actúan como proxy de llamadas hacia y desde los servicios (estrictamente hablando, actúan como proxys y proxys inversos, manejando llamadas entrantes y salientes). E implementan un conjunto de funciones que se enfoca en las llamadas. между servicios. Este enfoque en el tráfico entre servicios es lo que distingue a un proxy de malla de servicio de, por ejemplo, puertas de enlace API o proxies de ingreso (este último se enfoca en las llamadas que ingresan al clúster desde el mundo exterior). (Nota. traducir: Para ver una comparación de los controladores Kubernetes Ingress existentes, muchos de los cuales usan el Envoy ya mencionado, consulte .)
Entonces, descubrimos el plano de datos. El plano de control es más simple: es un conjunto de componentes que proporcionan toda la mecánica que el plano de datos necesita para funcionar de manera coordinada, incluido el descubrimiento de servicios, la emisión de certificados TLS, la agregación de métricas, etc. El plano de datos informa al plano de control sobre su comportamiento; a su vez, el plano de control proporciona una API que le permite cambiar y realizar un seguimiento del comportamiento del plano de datos en su conjunto.
A continuación se muestra un diagrama del plano de control y el plano de datos en Linkerd. Como puede ver, el plano de control incluye varios componentes diferentes, incluida una instancia de Prometheus que recopila métricas de servidores proxy, así como otros componentes como destination (descubrimiento de servicios), identity (autoridad certificadora, CA) y public-api (puntos finales para web y CLI). Por el contrario, el plano de datos es un simple proxy de linkerd junto a la instancia de la aplicación. Esto es solo un diagrama lógico; en una implementación del mundo real, es posible que tenga tres réplicas de cada componente del plano de control y cientos o miles de proxies en el plano de datos.
(Los cuadros azules en este diagrama representan los bordes de los pods de Kubernetes. Puede ver que los contenedores con el proxy linkerd están en el mismo pod que los contenedores de la aplicación. Este esquema se conoce como contenedor sidecar.)
La arquitectura de malla de servicio tiene varias implicaciones importantes. En primer lugar, dado que el trabajo de un proxy es interceptar llamadas entre servicios, una red de servicios solo tiene sentido si su aplicación se creó para un conjunto de servicios. malla uno puede usar con monolitos, pero esto es claramente redundante por el bien de un solo proxy, y es poco probable que su funcionalidad esté en demanda.
Otra consecuencia importante es que la red de servicios requiere enorme número de apoderados. De hecho, Linkerd encadena un proxy linkerd a cada instancia de cada servicio (otras implementaciones agregan un proxy a cada nodo/host/VM. Eso es mucho de todos modos). Tal uso activo de un proxy en sí mismo conlleva una serie de complicaciones adicionales:
- Los proxies en el plano de datos deben ser rápido, porque para cada llamada hay un par de llamadas al proxy: una del lado del cliente, otra del lado del servidor.
- Además, los apoderados deben ser pequeño и ligero. Cada uno consumirá recursos de memoria y CPU, y este consumo crecerá linealmente con la aplicación.
- Necesitará un mecanismo para implementar y actualizar una gran cantidad de proxies. Hacerlo manualmente no es una opción.
En general, la malla de servicios se ve así (al menos a vista de pájaro): implementa un grupo de proxies de espacio de usuario que "hacen algo" con el tráfico interno entre servicios, y usa el plano de control para monitorearlos y administrarlos.
Es hora de la pregunta "¿Por qué?"
¿Para qué sirve una malla de servicios?
Para aquellos que se encontraron por primera vez con la idea de una red de servicios, es perdonable estar un poco asombrados. El diseño de malla de servicio significa que no solo aumentará la latencia de la aplicación, sino que también consumir recursos y agregará un montón de nuevos mecanismos en la infraestructura. Primero, configura una red de servicios y luego, de repente, se encuentra con la necesidad de atender a cientos (si no miles) de proxies. La pregunta es, ¿quién se ofrecerá como voluntario para esto?
La respuesta a esta pregunta tiene dos partes. En primer lugar, los costos de transacción asociados con la implementación de estos proxies pueden reducirse significativamente debido a algunos cambios que ocurren en el ecosistema (más sobre esto más adelante).
En segundo lugar, dicho dispositivo es en realidad una excelente manera de introducir lógica adicional en el sistema. Y no solo porque se pueden agregar muchas características nuevas utilizando la red de servicios, sino también porque se puede hacer sin interferir con el ecosistema. De hecho, todo el modelo de malla de servicios se basa en este postulado: en un sistema multiservicio, pase lo que pase hacer servicios individuales, trafico entre ellos es el punto ideal para añadir funcionalidad.
Por ejemplo, en Linkerd (como en la mayoría de las mallas), la funcionalidad se centra principalmente en las llamadas HTTP, incluidas HTTP/2 y gRPC*. La funcionalidad es bastante rica: se puede dividir en tres clases:
- Funciones relacionadas confiabilidad. Solicitudes de reintento, tiempos de espera, enfoque controlado (división/redireccionamiento de tráfico), etc.
- Funciones relacionadas vigilancia. Agregación de tasas de éxito, retrasos y volúmenes de solicitudes para cada servicio o destinos individuales; construcción de mapas topológicos de servicios, etc.
- Funciones relacionadas seguridad. TLS mutuo, control de acceso, etc.
* Desde el punto de vista de Linkerd, gRPC prácticamente no es diferente de HTTP/2: solo usa protobuf en la carga útil. Desde el punto de vista de un desarrollador, estas dos cosas son, por supuesto, diferentes.
Muchos de estos mecanismos operan a nivel de solicitud (de ahí el "proxy L7"). Por ejemplo, si el servicio Foo realiza una llamada HTTP al servicio Bar, el proxy linkerd del lado de Foo puede equilibrar la carga de forma inteligente y enrutar las llamadas desde las instancias de Foo a Bar en función de la latencia observada; puede repetir la solicitud si es necesario (y si es idempotente); puede registrar el código de respuesta y el tiempo de espera, y así sucesivamente. De manera similar, el proxy linkerd en el lado de la barra puede rechazar una solicitud si no está permitida o si se excede el límite de solicitudes; puede arreglar el retraso por su parte, etc.
Los proxies también pueden “hacer algo” a nivel de conexión. Por ejemplo, un proxy linkerd en el lado Foo puede iniciar una conexión TLS, y un proxy linkerd en el lado Bar puede terminarla, y ambos lados pueden verificar los certificados TLS de los demás*. Esto proporciona no solo cifrado entre servicios, sino también una forma criptográficamente segura de identificar servicios: Foo y Bar pueden "probar" que son quienes dicen ser.
* "Amigo de un amigo" significa que el certificado del cliente también está verificado (TLS mutuo). En TLS "clásico", por ejemplo, entre un navegador y un servidor, se suele verificar el certificado de un solo lado (el servidor).
Ya sea que operen a nivel de solicitud o de conexión, es importante enfatizar que todas las características de Service Mesh son Operacional personaje. Linkerd no puede transformar la semántica de la carga útil, como agregar campos a un fragmento JSON o realizar cambios en un protobuf. Hablaremos de esta importante característica más adelante cuando hablemos de ESB y middleware.
Este es el conjunto de características que ofrece la red de servicios. Surge la pregunta: ¿por qué no implementarlos directamente en la aplicación? ¿Y por qué meterse con un proxy?
Por qué una red de servicios es una buena idea
Si bien las capacidades de la red de servicios son cautivadoras, su principal valor no radica realmente en las características. al final nosotros puede implementarlos directamente en la aplicación (más adelante veremos que este fue el origen de la malla de servicios). Para ponerlo en una oración, el valor de una malla de servicio es: proporciona una funcionalidad crítica para ejecutar software de servidor moderno de manera consistente, en toda la pila y con independencia del código de la aplicación.
Analicemos esta propuesta.
«Funciones críticas para ejecutar software de servidor moderno". Si está creando una aplicación de servidor transaccional conectada a Internet pública que acepta solicitudes del mundo exterior y las responde en poco tiempo, por ejemplo, una aplicación web, un servidor API y la gran mayoría de otras aplicaciones modernas, y si lo implementa como un conjunto de servicios que interactúan sincrónicamente entre sí, y si constantemente actualiza este software, agrega nuevas funciones y si se ve obligado a mantener este sistema en condiciones de funcionamiento durante la modificación, en este caso, felicitaciones , está creando un software de servidor moderno . Y todas esas excelentes funciones enumeradas anteriormente en realidad resultan ser críticas para usted. La aplicación debe ser confiable, segura y debe poder ver lo que está haciendo. Son estas preguntas las que la red de servicios ayuda a resolver.
(De acuerdo, mi convicción de que este enfoque es la forma moderna de crear software de servidor se ha colado en el párrafo anterior. Otros prefieren desarrollar monolitos, "microservicios reactivos" y otras cosas que no se incluyen en la definición anterior. Estas personas probablemente tengan una opinión que difiere de la mía, y a su vez, creo que están "equivocados" - aunque en cualquier caso, la malla de servicios no les es muy útil).
«Uniforme para toda la pila". Las características proporcionadas por la red de servicios no son solo críticas. Se aplican a todos los servicios de una aplicación, independientemente del idioma en el que estén escritos, el marco que utilicen, quién los escribió, cómo se implementaron y todas las demás sutilezas de su desarrollo y uso.
«Código de aplicación independiente". Por último, la red de servicios no solo proporciona una funcionalidad coherente en toda la pila, sino que lo hace de una forma que no requiere editar la aplicación. La base fundamental de la funcionalidad de una red de servicios, incluidas las tareas de configuración, actualización, operación, mantenimiento, etc., es puramente a nivel de plataforma y es independiente de la aplicación. La aplicación puede cambiar sin afectar la red de servicios. A su vez, la red de servicios puede cambiar sin intervención de ninguna aplicación.
En resumen, la red de servicios no solo proporciona una funcionalidad vital, sino que lo hace de forma global, uniforme e independiente de la aplicación. Y así, aunque la funcionalidad de una red de servicios se puede implementar en el código de servicio (por ejemplo, como una biblioteca incluida con cada servicio), este enfoque no proporcionará la uniformidad y la independencia que son tan valiosas en el caso de una red de servicios. .
¡Y todo lo que necesita hacer es agregar un montón de proxies! Lo prometo, muy pronto analizaremos los costos operativos asociados con la adición de estos proxies. Pero primero, detengámonos y miremos esta idea de independencia desde la perspectiva de varios gente.
¿A quién ayuda la red de servicios?
Por inconveniente que sea, para que una tecnología se convierta en una parte importante del ecosistema, debe ser aceptada por las personas. Entonces, ¿quién está interesado en una red de servicios? ¿Quién se beneficia de su uso?
Si desarrolla un software de servidor moderno, puede imaginar aproximadamente a su equipo como un grupo propietarios de serviciosquienes juntos desarrollan e implementan la lógica de negocios, y propietarios de la plataformainvolucrados en el desarrollo de la plataforma interna en la que se ejecutan estos servicios. En organizaciones pequeñas, estas pueden ser las mismas personas, pero a medida que la empresa crece, estos roles tienden a volverse más pronunciados e incluso divididos en sub-roles... (Hay mucho que decir aquí sobre la naturaleza cambiante de DevOps, el impacto organizativo de los microservicios, etc.) n. Pero por ahora, demos por sentadas estas descripciones).
Desde este punto de vista, los claros beneficiarios de la malla de servicios son los propietarios de la plataforma. Después de todo, el objetivo final del equipo de la plataforma es crear una plataforma interna en la que los propietarios de los servicios puedan implementar la lógica comercial y hacerlo de una manera que garantice su máxima independencia de los sombríos detalles de su funcionamiento. La red de servicios no solo ofrece las capacidades críticas para lograr este objetivo, sino que lo hace de una manera que, a su vez, no impone dependencias a los propietarios del servicio.
Los propietarios de los servicios también se benefician, aunque de forma más indirecta. El objetivo del propietario del servicio es ser lo más productivo posible en la implementación de la lógica del proceso comercial, y cuanto menos tenga que preocuparse por cuestiones operativas, mejor. En lugar de aplicar, por ejemplo, políticas de reintento o TLS, pueden concentrarse únicamente en el negocio y esperar que la plataforma se encargue del resto. Para ellos, esto es una gran ventaja.
El valor organizativo de tal división entre los propietarios de las plataformas y los servicios no puede subestimarse. creo que ella contribuye primario contribución al valor de la malla de servicios.
Aprendimos esta lección cuando uno de los primeros fans de Linkerd nos dijo por qué eligieron la red de servicio: porque les permitía "seguir hablando al mínimo". Aquí hay algunos detalles: los chicos de una gran empresa migraron su plataforma a Kubernetes. Dado que la aplicación trabajaba con información confidencial, querían cifrar todas las comunicaciones en los clústeres. Sin embargo, la situación se complicó por la presencia de cientos de servicios y cientos de equipos de desarrollo. La perspectiva de contactar a todos y convencerlos de incluir soporte para TLS en sus planes no les agradó en absoluto. Al instalar Linkerd, migraron responsabilidad desde desarrolladores (desde cuyo punto de vista era un problema innecesario) hasta jugadores de plataformas, para quienes esto era una prioridad de primer nivel. En otras palabras, Linkerd les estaba resolviendo no tanto un problema técnico como organizativo.
En definitiva, la malla de servicios no es, más bien, una solución técnica, sino socio técnico problemas (Gracias por introducir este término.
¿La red de servicios resolverá todos mis problemas?
Sí. ¡Quiero decir, no!
Al observar las tres clases de características descritas anteriormente (confiabilidad, seguridad y observabilidad), queda claro que la red de servicios no es una solución completa para ninguno de estos problemas. Aunque Linkerd puede enviar solicitudes repetidas (si sabe que son idempotentes), no está en condiciones de tomar decisiones sobre qué devolver al usuario si el servicio finalmente se cae; tales decisiones deben ser tomadas por la aplicación. Linkerd puede mantener estadísticas sobre las solicitudes exitosas, pero no puede analizar el servicio y proporcionar sus métricas internas: una aplicación debe tener un conjunto de herramientas de este tipo. Y aunque Linkerd es capaz de alojar mTLS, las soluciones de seguridad completas requieren mucho más.
Un subconjunto de las características en estas áreas que ofrece la malla de servicio están relacionadas con caracteristicas de la plataforma. Con esto me refiero a funciones que:
- Independiente de la lógica de negocio. La forma en que se construyen los histogramas de llamadas entre Foo y Bar es completamente independiente de si por qué Foo llama a Bar.
- Difícil de implementar correctamente. En Linkerd, los reintentos se parametrizan con todo tipo de elementos sofisticados, como presupuestos de reintentos. (reintentar presupuestos), ya que un enfoque simplista de la implementación de tales cosas seguramente conducirá a la aparición de la llamada "avalancha de solicitudes" (reintentar tormenta) y otros problemas específicos de los sistemas distribuidos.
- Más efectivo cuando se aplica consistentemente. El mecanismo TLS solo tiene sentido si se aplica en todas partes.
Debido a que estas funciones se implementan en la capa de proxy (y no en la capa de aplicación), la red de servicios las expone en la Plataforma, no aplicaciones. Por lo tanto, no importa en qué idioma están escritos los servicios, qué marco usan, quién los escribió y por qué. Los proxies funcionan más allá de todos estos detalles, y la base fundamental de esta funcionalidad, incluidas las tareas de configuración, actualización, operación, mantenimiento, etc., se encuentra únicamente a nivel de plataforma.
Ejemplos de capacidades de malla de servicio
En resumen, una red de servicios no es una solución completa para la confiabilidad, la observabilidad o la seguridad. El alcance de estas áreas implica la participación obligatoria de los propietarios de los servicios, equipos de Ops/SRE y otros stakeholders de la empresa. La malla de servicios solo proporciona una "rebanada" a nivel de plataforma para cada una de estas áreas.
¿Por qué la red de servicios se ha vuelto popular en este momento?
Probablemente se esté preguntando en este momento: OK, si la red de servicios es tan buena, ¿por qué no comenzamos a implementar millones de proxies en la pila hace diez años?
Hay una respuesta banal a esta pregunta: hace diez años todo el mundo construía monolitos y nadie necesitaba una red de servicios. Esto es cierto, pero en mi opinión, esta respuesta pierde el punto. Incluso hace diez años, el concepto de microservicios como una forma prometedora de crear sistemas a gran escala fue ampliamente discutido y aplicado en empresas como Twitter, Facebook, Google y Netflix. La percepción general, al menos en las partes de la industria con las que he estado en contacto, era que los microservicios son la "forma correcta" de construir sistemas grandes, incluso si era muy difícil.
Por supuesto, aunque había empresas que explotaban los microservicios hace diez años, no colocaron proxies en todos los lugares posibles para formar una red de servicios. Sin embargo, si observa detenidamente, hicieron algo similar: muchas de estas empresas exigieron el uso de una biblioteca interna especial para redes (a veces llamada biblioteca de clientes pesados, biblioteca de clientes gordos).
Netflix tenía Hysterix, Google tenía Stubby, Twitter tenía la biblioteca Finagle. Finagle, por ejemplo, ha sido obligatorio para cada nuevo servicio en Twitter. Manejó tanto el lado del cliente como del servidor de las conexiones, permitió solicitudes repetidas, enrutamiento de solicitudes compatible, equilibrio de carga y medición. Proporcionó una capa consistente de confiabilidad y observabilidad en toda la pila de Twitter, sin importar lo que estaba haciendo el servicio. Eso sí, solo funcionaba para lenguajes JVM y se basaba en un modelo de programación que había que utilizar para toda la aplicación. Sin embargo, su funcionalidad era casi la misma que la de la red de servicios. (En realidad, la primera versión de Linkerd era solo Finagle envuelto en forma de proxy).
Por lo tanto, hace diez años no solo había microservicios, sino también bibliotecas especiales de proto-service-mesh que resolvían los mismos problemas que resuelve la malla de servicios en la actualidad. Sin embargo, la red de servicios en sí no existía entonces. Tenía que haber otro turno antes de que ella apareciera.
Y aquí es donde radica la respuesta más profunda, oculta en otro cambio que ha tenido lugar en los últimos 10 años: ha habido una fuerte disminución en el costo de implementación de microservicios. Las empresas mencionadas anteriormente que usaban microservicios hace una década (Twitter, Netflix, Facebook, Google) eran empresas de gran escala y con enormes recursos. No solo tenían la necesidad, sino también la capacidad de crear, implementar y operar grandes aplicaciones basadas en microservicios. La energía y el esfuerzo que los ingenieros de Twitter han puesto para pasar de un enfoque monolítico a uno de microservicios es asombroso. (Honestamente, al igual que el hecho de que funcionó). Este tipo de maniobras de infraestructura era entonces imposible para las empresas más pequeñas.
Pasemos al presente. Hoy en día hay startups donde la proporción de microservicios a desarrolladores es de 5:1 (o incluso ) y, además, ¡se las arreglan con éxito! Si una startup de 5 personas puede operar 50 microservicios sin esfuerzo, entonces algo redujo claramente el costo de su implementación.
1500 microservicios en Monzo; cada línea es una regla de red prescrita que permite el tráfico
La drástica reducción en el costo de operación de los microservicios es el resultado de un solo proceso: creciente popularidad de los contenedores и orquestadores. Esta es precisamente la respuesta profunda a la pregunta de qué contribuyó al surgimiento de la red de servicios. La misma tecnología hizo que tanto la malla de servicios como los microservicios fueran atractivos: Kubernetes y Docker.
¿Por qué? Bueno, Docker resuelve un gran problema: el problema del empaquetado. Al empaquetar una aplicación y sus dependencias de tiempo de ejecución (fuera de la red) en un contenedor, Docker convierte la aplicación en una unidad fungible que se puede alojar y ejecutar en cualquier lugar. Al mismo tiempo, simplifica enormemente la operación. plurilingüe stack: dado que un contenedor es una unidad atómica de ejecución, no importa lo que haya dentro, ya sea una aplicación JVM, Node, Go, Python o Ruby, para fines operativos y de implementación. Simplemente lo ejecutas y listo.
Kubernetes lleva todo al siguiente nivel. Ahora que hay un montón de "cosas ejecutables" y muchas máquinas para ejecutarlas, existe la necesidad de una herramienta que pueda compararlas entre sí. En un sentido amplio, le das a Kubernetes muchos contenedores y muchas máquinas, y las empareja entre sí (por supuesto, este es un proceso dinámico y en constante cambio: los nuevos contenedores se mueven por el sistema, las máquinas se inician y se detienen, etc.). Sin embargo, Kubernetes tiene todo esto en cuenta).
Una vez que se configura Kubernetes, el tiempo que lleva implementar y operar un servicio no es muy diferente del costo de implementar y operar diez servicios (de hecho, es casi lo mismo para 100 servicios). Agregue a esto contenedores como un mecanismo de empaque que fomenta la implementación multilingüe, y tendrá un montón de nuevas aplicaciones implementadas como microservicios escritos en varios idiomas, justo el tipo de entorno para el que la red de servicios se adapta tan bien.
Entonces, llegamos a la respuesta a la pregunta de por qué la idea de una malla de servicios se ha vuelto popular en este momento: la uniformidad que proporciona Kubernetes para los servicios es directamente aplicable a las tareas operativas que enfrenta la malla de servicios. Empaqueta proxies en contenedores, le da a Kubernetes la tarea de pegarlos donde sea posible, ¡y listo! Como resultado, obtiene una red de servicios, mientras que Kubernetes controla toda la mecánica de su implementación. (Al menos a vista de pájaro. Por supuesto, hay muchos matices en este proceso).
En resumen: la razón por la que la malla de servicios se hizo popular ahora y no hace diez años es que Kubernetes y Docker no solo han aumentado significativamente necesita en él, simplificando la implementación de aplicaciones como conjuntos de microservicios multilingües, pero también redujo significativamente costos para su operación al proporcionar mecanismos para implementar y mantener parques de proxy de sidecar.
¿Por qué se habla tanto de la malla de servicios?
advertencia: En esta sección recurro a todo tipo de suposiciones, conjeturas, fabricaciones e información privilegiada.
La búsqueda de "malla de servicio" arrojará un montón de contenido reciclado, bajo en calorías, proyectos extraños y un caleidoscopio de distorsión digno de una cámara de eco. Cualquier nueva tecnología de moda tiene esto, pero en el caso de la red de servicios, el problema es especialmente agudo. ¿Por qué?
Bueno, en parte es mi culpa. He hecho todo lo posible para promocionar Linkerd y la red de servicios en cada oportunidad, a través de innumerables publicaciones de blog y artículos como este. Pero no soy tan poderoso. Para responder realmente a esta pregunta, necesitamos hablar un poco sobre la situación general. Y es imposible hablar de ello sin mencionar un proyecto: es una red de servicios de código abierto desarrollada conjuntamente por Google, IBM y Lyft.
(Esas tres empresas tienen roles muy diferentes: la participación de Lyft parece limitarse solo al nombre; son los autores de Envoy, pero no usan o están involucrados en el desarrollo de Istio. IBM está involucrada en el desarrollo de Istio y lo usa. Google es fuertemente involucrado en el desarrollo de Istio, pero que yo sepa, en realidad no lo usa).
El proyecto Istio destaca por dos cosas. En primer lugar, es el gran esfuerzo de marketing que Google, en particular, pone en su promoción. Estimo que la mayoría de las personas que actualmente conocen el concepto de malla de servicios lo conocieron por primera vez gracias a Istio. La segunda característica es la mala recepción de Istio. En este asunto, obviamente, soy una parte interesada, pero tratando de ser lo más objetivo posible, todavía no puedo evitar , no muy específico (aunque no único: systemd viene a la mente, ...) para un proyecto de código abierto.
(En la práctica, Istio parece tener problemas no solo con la complejidad y la UX, sino también con el rendimiento. Por ejemplo, durante realizado por un tercero, los expertos encontraron situaciones en las que la latencia de cola de Istio era 100 veces mayor que la de Linkerd, así como situaciones con falta de recursos, cuando Linkerd continuó funcionando correctamente e Istio dejó de funcionar por completo).
Dejando de lado mis teorías sobre por qué sucedió esto, creo que la exageración fuera de escala en torno a la red de servicios se debe a la participación de Google. Es decir, una combinación de los siguientes tres factores:
- promoción obsesiva de Istio por parte de Google;
- apropiada actitud de desaprobación y crítica hacia el proyecto;
- la reciente popularidad vertiginosa de Kubernetes, cuyo recuerdo aún está fresco.
Juntos, estos factores se unen en una especie de ambiente anóxico y embriagador en el que la capacidad de juicio racional se desvanece, dejando solo una extraña variedad de .
Desde el punto de vista de Linkerd, esto es... Lo describiría como una bendición a medias. Quiero decir, es genial que la red de servicios haya entrado en la corriente principal, lo que no fue el caso en 2016 cuando apareció Linkerd por primera vez y fue realmente difícil llamar la atención de la gente sobre el proyecto. Ahora no hay tal problema! Pero la mala noticia es que la situación de la red de servicios es tan confusa hoy en día que es casi imposible averiguar qué proyectos realmente pertenecen a la categoría de redes de servicios (y mucho menos averiguar cuál es el mejor para un caso de uso particular). Esto ciertamente se interpone en el camino de todos (y definitivamente, en algunos casos, Istio u otro proyecto es mejor que Linkerd, ya que este último no es una solución única para todos).
Por parte de Linkerd, nuestra estrategia ha sido ignorar el ruido, seguir centrándonos en resolver los problemas reales de la comunidad y, básicamente, esperar a que disminuya la exageración. Eventualmente, la exageración disminuirá y podremos continuar trabajando en paz.
Hasta entonces, todos tendremos que ser pacientes.
¿Me será útil la red de servicios, un modesto ingeniero de software?
El siguiente cuestionario ayudará a responder a esta pregunta:
¿Se ocupan exclusivamente de la implementación de la lógica empresarial? En este caso, la red de servicios no te será útil. Es decir, por supuesto, puede que le interese, pero idealmente, la red de servicios no debería afectar directamente a nada en su entorno. Sigue trabajando en lo que te pagan.
¿Mantiene una plataforma en una empresa que utiliza Kubernetes? Sí, en este caso necesita una malla de servicio (por supuesto, si no está usando K8 solo para ejecutar un procesamiento monolítico o por lotes, pero me gustaría preguntarle por qué necesita K8). Lo más probable es que te encuentres en una situación con muchos microservicios escritos por diferentes personas. Todos interactúan entre sí y están vinculados a una maraña de dependencias de tiempo de ejecución, y debe encontrar una manera de lidiar con todo esto. El uso de Kubernetes le permite elegir una malla de servicios "para usted". Para hacer esto, familiarícese con sus capacidades y características y responda a la pregunta de si alguno de los proyectos disponibles se adapta a usted (recomiendo comenzar su investigación con Linkerd).
¿Está ejecutando una plataforma para una empresa que NO usa Kubernetes pero usa microservicios? En este caso, la malla de servicios te será útil, pero su uso no será trivial. Por supuesto que puede imitar service mesh alojando un montón de proxies, pero una ventaja importante de Kubernetes es precisamente el modelo de implementación: el mantenimiento manual de estos proxies requerirá mucho más tiempo, esfuerzo y costo.
¿Estás a cargo de la plataforma en una empresa que trabaja con monolitos? En este caso, probablemente no necesite una malla de servicio. Si está trabajando con monolitos (o incluso conjuntos de monolitos) que tienen patrones de interacción bien definidos y que rara vez cambian, entonces la red de servicios tiene poco que ofrecerle. Así que puedes ignorarlo y esperar que desaparezca como un mal sueño...
Conclusión
Probablemente, la red de servicios aún no debería llamarse "la tecnología más publicitada del mundo"; este dudoso honor probablemente pertenezca a bitcoin o AI. Quizás esté entre los cinco primeros. Pero si rompe las capas de ruido y estruendo, queda claro que la red de servicios brinda beneficios reales a quienes crean aplicaciones en Kubernetes.
Me gustaría que probaras Linkerd, instalándolo en un clúster de Kubernetes (o incluso Minikube en una computadora portátil) y puedes ver por ti mismo de lo que estoy hablando.
Preguntas Frecuentes
- Si ignoro la malla de servicios, ¿desaparecerá?
- Debo decepcionarte: la red de servicio está con nosotros desde hace mucho tiempo.
— ¡Pero NO QUIERO usar una malla de servicio!
- Bueno, no es necesario! Simplemente lea mi cuestionario anterior para ver si al menos debería familiarizarse con sus conceptos básicos.
— ¿No es un buen ESB/middleware antiguo con una salsa nueva?
- Service mesh se ocupa de la lógica operativa, no semántica. bus de servicios empresariales (). Mantener esta separación ayuda a que la malla de servicios evite el mismo destino.
- ¿En qué se diferencia una malla de servicios de las puertas de enlace API?
Hay un millón de artículos sobre este tema. Solo busca en Google.
¿Es Envoy una malla de servicio?
- No, Envoy no es una red de servicios, es un servidor proxy. Se puede usar para organizar una red de servicios (y mucho más, es un proxy de propósito general). Pero por sí mismo, no es una red de servicios.
- Malla de servicio de red: ¿es una malla de servicio?
- No. A pesar del nombre, esta no es una red de servicios (¿cómo te gustan las maravillas del marketing?).
- ¿Ayudará la red de servicio con mi sistema asíncrono reactivo basado en la cola de mensajes?
- No, la malla de servicio no te ayudará.
- ¿Qué malla de servicio debo usar?
- , pan comido.
- ¡El artículo apesta! / El autor - ¡en el jabón!
— ¡Comparta el enlace con todos sus amigos para que se convenzan de esto!
Agradecimientos
Como puede adivinar por el título, este artículo se inspiró en el fantástico tratado de Jay Kreps "". Conocí a Jay hace diez años mientras hacía una entrevista en Linked In y desde entonces ha sido una inspiración para mí.
Si bien me gusta llamarme "desarrollador de Linkerd", la realidad es que soy más un mantenedor del archivo README.md en un proyecto. Trabajando en Linkerd hoy , , gente, y este proyecto no habría sido posible sin la increíble comunidad de colaboradores y usuarios.
Y por último, un agradecimiento especial al creador de Linkerd, (primus inter pares), quien, junto a mí hace muchos años, se lanzó de lleno en todo este alboroto con la malla de servicios.
PD del traductor
Lea también en nuestro blog:
- «";
- «";
- «";
- «";
- «".
Fuente: habr.com