Dans cet article, nous décrirons comment nous avons déployé Service Mesh, résolu certains problèmes de l'architecture des microservices et réduit la charge des développeurs et des ingénieurs d'infrastructure.
Pourquoi nous avions besoin d'un maillage de service
Le service Mesh gagne en popularité. Je pense que cela n'a plus de sens de définir et de décrire tout pourquoi cela pourrait être utile. Si vous ne savez pas de quoi il s'agit, mais que votre entreprise dispose de nombreuses équipes, de services ou que vous allez partager un monolithe, vous devez vous familiariser avec le sujet. Vous pouvez commencer par traduire un article écrit par le créateur du premier projet Service Mesh, William Morgan.
Au cours de la dernière année, le nombre d'équipes de produits dans l'entreprise a augmenté de 1,5 fois. Au moment d'écrire ces lignes, nous avons plus de 20 équipes, presque tout le monde a des développeurs. Avec l'augmentation de leur nombre, le développement du monolithe n'est pas devenu plus facile, c'est pourquoi nous avons commencé à nous orienter plus activement vers l'architecture de microservices. Bien que nous soyons plutôt au début de notre voyage, cependant, il y a déjà 3-4 ans, les services à des fins diverses ont commencé à se multiplier à une vitesse décente.
Bien sûr, plus il y a de services, plus il est difficile de les suivre, plus il est difficile de les gérer et de configurer l'infrastructure. Cela serait particulièrement difficile dans un système traditionnel dans lequel il existe un mur entre les développeurs et les administrateurs. Par conséquent, parallèlement à la création de microservices, nous avons commencé à confier la majeure partie de la responsabilité du lancement et du fonctionnement du service aux développeurs, en fournissant Ops-exam en tant que service. Cependant, les développeurs, bien sûr, ne connaissent pas toutes les subtilités de la mise en place de l'infrastructure.
Service Mesh combine et résume très bien les développeurs tels que:
- Découverte de service
- Traçage distribué;
- Coupure de circuit / nouvelles tentatives / délais d'attente;
- Interactions de surveillance / télémétrie et bien d'autres.
, , 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 .
- — , .
: