In diesem Artikel beschreiben wir, wie wir Service Mesh bereitgestellt, einige Probleme der Microservice-Architektur gelöst und die Belastung für Entwickler und Infrastrukturingenieure verringert haben.
Warum wir ein Service Mesh brauchten
Service Mesh wird immer beliebter. Ich denke, es macht keinen Sinn, noch einmal alles zu definieren und zu beschreiben, warum es nützlich sein könnte. Wenn Sie nicht wissen, worum es geht, Ihr Unternehmen jedoch über viele Teams und Services verfügt oder Sie einen Monolithen gemeinsam nutzen möchten, sollten Sie sich mit dem Thema vertraut machen. Sie können beginnen, indem Sie einen Artikel übersetzen , der vom Schöpfer des ersten Service Mesh-Projekts, William Morgan, geschrieben wurde.
Im vergangenen Jahr hat sich die Anzahl der Produktteams im Unternehmen um das 1,5-fache erhöht. Zum Zeitpunkt dieses Schreibens haben wir mehr als 20 Teams, fast jeder hat Entwickler. Mit der Zunahme ihrer Anzahl wurde die Entwicklung des Monolithen nicht einfacher, daher begannen wir, uns aktiver der Mikroservice-Architektur zuzuwenden. Während wir uns eher am Anfang unserer Reise befinden, begannen sich die Dienste für verschiedene Zwecke bereits vor drei bis vier Jahren mit angemessener Geschwindigkeit zu vermehren.
Je mehr Dienste verfügbar sind, desto schwieriger ist es natürlich, den Überblick über sie zu behalten, desto schwieriger ist es, sie und die Infrastrukturkonfiguration zu verwalten. Dies wäre besonders schwierig in einem traditionellen System, in dem es eine Mauer zwischen Entwicklern und Administratoren gibt. Daher haben wir gleichzeitig mit der Erstellung von Microservices begonnen, den Entwicklern den größten Teil der Verantwortung für den Start und den Betrieb des Dienstes zu übertragen und Ops-Prüfung als Dienst anzubieten. Entwickler kennen jedoch natürlich nicht alle Feinheiten beim Einrichten der Infrastruktur.
Service Mesh kombiniert und abstrahiert nur sehr erfolgreich Entwickler wie:
- Serviceerkennung
- Verteilte Rückverfolgung;
- Stromkreisunterbrechung / Wiederholungen / Timeouts;
- Monitoring / Telemetrie-Interaktionen und viele andere.
, , 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 .
- — , .
: