Pada artikel ini, kami akan menjelaskan bagaimana kami menggunakan Service Mesh, memecahkan beberapa masalah dalam arsitektur layanan mikro, dan mengurangi beban pada pengembang dan insinyur infrastruktur.
Mengapa kami membutuhkan Service Mesh
Service Mesh mendapatkan popularitas. Saya pikir tidak masuk akal sekali lagi untuk mendefinisikan dan menjelaskan segala sesuatu mengapa ini mungkin berguna. Jika Anda tidak tahu tentang apa itu, tetapi perusahaan Anda memiliki banyak tim, layanan, atau Anda akan berbagi monolit, maka Anda harus membiasakan diri dengan subjek tersebut. Anda bisa mulai dengan menerjemahkan artikel yang ditulis oleh pencipta proyek Service Mesh pertama, William Morgan.
Selama setahun terakhir, jumlah tim produk di perusahaan telah meningkat 1,5 kali. Pada saat penulisan ini, kami memiliki lebih dari 20 tim, hampir setiap orang memiliki pengembang. Dengan bertambahnya jumlah mereka, pengembangan monolith tidak menjadi lebih mudah, oleh karena itu, kami mulai bergerak lebih aktif menuju arsitektur layanan-mikro. Meskipun kami agak berada di awal perjalanan kami, namun, sudah 3-4 tahun yang lalu, layanan untuk berbagai keperluan mulai bertambah banyak dengan kecepatan yang layak.
Tentu saja, semakin banyak layanan, semakin sulit untuk melacaknya, semakin sulit untuk mengelolanya dan konfigurasi infrastruktur. Ini akan sangat sulit dalam sistem tradisional di mana ada dinding antara pengembang dan admin. Oleh karena itu, bersamaan dengan pembuatan layanan mikro, kami mulai memberikan sebagian besar tanggung jawab untuk peluncuran dan pengoperasian layanan kepada pengembang, menyediakan pemeriksaan Ops sebagai layanan. Namun, pengembang, tentu saja, tidak tahu semua seluk-beluk pengaturan infrastruktur.
Service Mesh hanya berhasil menggabungkan dan abstrak dari pengembang hal-hal seperti:
- Penemuan Layanan
- Pelacakan terdistribusi;
- Circuit Breaking / Retries / Timeout;
- Pemantauan / interaksi telemetri dan banyak lainnya.
, , 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 .
- — , .
: