En este artículo, describiremos cómo implementamos Service Mesh, resolvimos algunos de los problemas en la arquitectura de microservicios y redujimos la carga en desarrolladores e ingenieros de infraestructura.
¿Por qué necesitábamos una malla de servicio?
Service Mesh está ganando popularidad. Creo que no tiene sentido una vez más definir y describir todo por qué podría ser útil. Si no sabe de qué se trata, pero su empresa tiene muchos equipos, servicios o si va a compartir un monolito, entonces debe familiarizarse con el tema. Puede comenzar traduciendo un artículo escrito por el creador del primer proyecto de Service Mesh, William Morgan.
Durante el año pasado, el número de equipos de productos en la compañía ha crecido 1.5 veces. Al momento de escribir este artículo, tenemos más de 20 equipos, casi todos tienen desarrolladores. Con el aumento en su número, el desarrollo del monolito no se hizo más fácil, por lo tanto, comenzamos a avanzar más activamente hacia la arquitectura de microservicios. Si bien estamos más bien al comienzo de nuestro viaje, sin embargo, hace ya 3-4 años, los servicios para diversos fines comenzaron a multiplicarse con una velocidad decente.
Por supuesto, cuantos más servicios, más difícil es hacer un seguimiento de ellos, más difícil es administrarlos y la configuración de la infraestructura. Esto sería especialmente difícil en un sistema tradicional en el que hay un muro entre desarrolladores y administradores. Por lo tanto, simultáneamente con la creación de microservicios, comenzamos a dar la mayor parte de la responsabilidad del lanzamiento y la operación del servicio a los desarrolladores, proporcionando el examen Ops como un servicio. Sin embargo, los desarrolladores, por supuesto, no conocen todas las sutilezas de la configuración de la infraestructura.
Service Mesh combina con éxito y resúmenes de desarrolladores tales como:
- Descubrimiento de servicio
- Rastreo distribuido;
- Rotura de circuito / reintentos / tiempos de espera;
- Monitoreo / interacciones de telemetría y muchos otros.
, , Docker-. Nomad, Consul. , Kubernetes , Nomad .
, Kubernetes, , HashiCorp-.
Nomad Docker- ( QEMU, raw/isolated fork/exec Java). Consul Service Discovery DNS-.
Nomad- Consul-. - ( ), .
Nomad Consul . Consul , (node), healthcheck . (TCP, HTTP, gRPC, script). Nomad key-value Consul Vault, , -. Nomad consul-template.
Nomad, Consul HTTP API, , , Nomad , — ip-port - healthcheck. , k8s Pod, Allocation, .
, , operations engineer. , , : , , .
HashiCorp-, . Service Mesh , Redis .
Service Mesh
Service Mesh : (data plane control plane). Data plane , - . control plane, . .
— sidecar ( Pod’e/). , .
Service Mesh . Linkerd linkerd-proxy, Consul Connect Istio third-party . Envoy Lyft. open source , .
, :
- Service Mesh 2018 . , .
- .
- control plane .
control plane
control plane — , Service Mesh . , , . , , .
Service Mesh , Mesh, . Envoy , , , .
Envoy data plane
Envoy sidecar- . sidecar-, . . (ingress) Consul, (egress) -. , , , .
: Nomad .
Service Discovery
Service Discovery? , ? sidecar, control plane agent, control plane API, API Consul API Envoy. endpoint discovery (EDS). «» - Consul. Envoy , .
Prometheus. Envoy , , Circuit Breaker - . :
, , Vizceral Netflix:
— , . , - . , Envoy Distributed tracing Zipkin/Jaeger (X-b3-headers).
, , Jaeger Elastic APM (Application Performance Management). — Kibana, . Elastic , , , Jaeger, , APM Distributed tracing. Jaeger-, Envoy, , , , Elastic APM. Jaeger, Elastic APM , HTTP- trace-id . Jaeger , Elastic , .
Service Mesh . — . HTTP/1, TCP Redis. Mesh , . , . , Service Mesh.
Ops- Mesh: , , Canary, . , Istio .
Service Mesh
, Service Mesh:
- — .
- Service Discovery , - . c-plane 10 , , , , . , . Envoy 150 RAM, . , 100 RPS, 30 .
- . 2–3 .
- — , .
: