Halo, Habr! Saya hadir untuk Anda terjemahan artikel "Pesawat data layanan mesh vs pesawat kontrol" oleh Matt Klein .



Kali ini saya ingin dan menerjemahkan deskripsi dari kedua komponen service mesh, data plane, dan control plane. Deskripsi ini bagi saya tampaknya yang paling dapat dimengerti dan menarik, dan yang paling penting mengarah pada pemahaman "Apakah itu perlu?"

Ketika ide "Service mesh" telah menjadi semakin populer selama dua tahun terakhir (Artikel asli 10 Oktober 2017) dan jumlah peserta di ruang angkasa telah meningkat, saya telah melihat peningkatan yang sepadan dalam kebingungan di antara seluruh komunitas teknis mengenai bagaimana membandingkan dan membandingkan berbagai solusi.

Situasi ini paling baik dijelaskan dalam serangkaian tweet yang saya tulis pada bulan Juli:

Kebingungan dengan service mesh (service mesh) No. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Utusan. Tak satu pun dari mereka yang setara dengan Istio. Istio adalah sesuatu yang sangat berbeda. 1 /

Yang pertama hanya pesawat data. Mereka sendiri tidak melakukan apa pun. Mereka perlu disetel untuk sesuatu yang lebih. 2 /

Istio adalah contoh dari bidang kontrol yang menghubungkan bagian bersama-sama. Ini adalah lapisan yang berbeda. / akhir

Dalam tweet sebelumnya, beberapa proyek berbeda disebutkan (Linkerd, NGINX, HAProxy, Utvoy dan Istio), tetapi, yang lebih penting, konsep umum pesawat data, layanan mesh dan pesawat kontrol diperkenalkan. Dalam posting ini, saya akan mengambil langkah mundur dan memberi tahu apa yang saya maksud dengan istilah "data plane" dan "control plane" pada tingkat yang sangat tinggi, dan kemudian saya akan memberi tahu bagaimana istilah itu terkait dengan proyek yang disebutkan dalam tweet.

Apa yang dimaksud dengan service mesh?

Gambar 1: Ikhtisar jala layanan

Gambar 1 mengilustrasikan konsep service mesh pada level paling dasar. Ada empat kelompok layanan (AD). Setiap instance layanan dikaitkan dengan server proxy lokal. Semua lalu lintas jaringan (HTTP, REST, gRPC, Redis, dll.) Dari satu instance aplikasi ditransmisikan melalui server proxy lokal ke kelompok layanan eksternal yang sesuai. Dengan demikian, contoh aplikasi tidak tahu tentang jaringan secara keseluruhan dan hanya tahu tentang proksi lokalnya. Bahkan, jaringan sistem terdistribusi jauh dari layanan.

Pesawat data

Dalam layanan mesh, server proxy yang terletak secara lokal untuk aplikasi melakukan tugas-tugas berikut:

• Penemuan layanan Layanan / layanan / aplikasi apa yang tersedia untuk aplikasi Anda?
• Pemeriksaan kesehatan Apakah instance layanan dikembalikan oleh penemuan layanan operasional dan siap untuk menerima lalu lintas jaringan? Ini dapat mencakup pemeriksaan kesehatan aktif (mis., Memeriksa / cek kesehatan) atau pasif (mis., Menggunakan 3 kesalahan 5xx berturut-turut sebagai indikasi status layanan yang tidak sehat).
• Routing Setelah menerima permintaan untuk "/ foo" dari layanan REST, ke gugus layanan mana seharusnya permintaan dikirim?
• Load balancing Setelah sebuah kluster layanan telah dipilih selama perutean, ke instance layanan mana seharusnya permintaan dikirim? Batas waktu apa? Pengaturan apa untuk memutuskan sirkuit? Jika permintaan gagal, haruskah itu diulang?
• Otentikasi dan otorisasi Untuk permintaan yang masuk, bisakah layanan panggilan dikenali / disahkan secara kriptografis menggunakan mTLS atau mekanisme lain? Jika teridentifikasi / diotorisasi, apakah diizinkan untuk memanggil operasi yang diminta (titik akhir) dalam layanan atau haruskah respons yang tidak diautentikasi dikembalikan?
• Observabilitas Untuk setiap permintaan, statistik terperinci, log / log, dan data jejak terdistribusi harus dihasilkan sehingga operator dapat memahami arus lalu lintas terdistribusi dan masalah debugging saat mereka muncul.

Untuk semua poin sebelumnya dalam jaringan layanan (service mesh), bidang data bertanggung jawab. Bahkan, proksi lokal ke layanan (sespan) adalah bidang data. Dengan kata lain, pesawat data bertanggung jawab atas penyiaran bersyarat, penerusan dan pemantauan setiap paket jaringan yang dikirim ke atau dikirim dari layanan.

Pesawat kontrol

Abstraksi jaringan yang disediakan oleh proxy lokal di data plane ajaib (?). Namun, bagaimana proksi benar-benar tahu tentang rute "/ foo" ke layanan B? Bagaimana layanan data penemuan yang diisi dengan permintaan proxy dapat digunakan? Bagaimana pengaturan penyeimbangan beban, batas waktu, pemutusan sirkuit, dll.? Bagaimana cara menyebarkan aplikasi menggunakan metode biru / hijau (biru / hijau) atau metode transfer lalu lintas bertahap? Siapa yang mengatur pengaturan otentikasi dan otorisasi seluruh sistem?

Semua item di atas dikelola oleh bidang kontrol jala servis. Pesawat kontrol menerima satu set server proxy terisolasi stateless dan mengubahnya menjadi sistem terdistribusi .

Saya pikir alasan banyak teknolog menemukan konsep yang terpisah dari bidang data dan bidang kontrol menjadi bingung adalah karena bagi kebanyakan orang bidang data sudah dikenal, sedangkan bidang kontrol adalah asing / tidak dapat dipahami. Kami telah bekerja dengan router dan switch jaringan fisik untuk waktu yang lama. Kami memahami bahwa paket / permintaan harus beralih dari titik A ke titik B, dan bahwa kami dapat menggunakan perangkat keras dan perangkat lunak untuk ini. Proksi perangkat lunak generasi baru hanyalah versi trendi dari alat yang telah kami gunakan sejak lama.


Gambar 2: Pesawat kendali manusia

Namun, kami telah lama menggunakan bidang kontrol, meskipun sebagian besar operator jaringan mungkin tidak mengaitkan bagian sistem ini dengan komponen teknologi apa pun. Alasannya sederhana:
Sebagian besar pesawat kontrol yang digunakan saat ini adalah ... kita .

Gambar 2 menunjukkan apa yang saya sebut "Pesawat kendali manusia." Dalam jenis penyebaran ini, yang masih sangat umum, operator manusia, mungkin galak, membuat konfigurasi statis - berpotensi menggunakan skrip - dan menyebarkannya menggunakan semacam proses khusus pada semua proxy. Kemudian proksi mulai menggunakan konfigurasi ini dan mulai memproses data pesawat menggunakan pengaturan yang diperbarui.


Gambar 3: Bidang kontrol mesh layanan lanjutan

Gambar 3 menunjukkan bidang kontrol "extended" dari mesh layanan. Ini terdiri dari bagian-bagian berikut:

• Manusia : Masih ada seseorang (semoga tidak terlalu marah) yang membuat keputusan tingkat tinggi mengenai keseluruhan sistem.
• UI bidang kontrol : Seseorang berinteraksi dengan beberapa jenis antarmuka pengguna untuk mengontrol sistem. Ini bisa berupa portal web, aplikasi baris perintah (CLI), atau antarmuka lain. Menggunakan antarmuka pengguna, operator memiliki akses ke parameter konfigurasi sistem global seperti:
  
  • Manajemen penempatan, biru / hijau dan / atau dengan transfer lalu lintas bertahap
  • Pengaturan Otentikasi dan Otorisasi
  • Spesifikasi tabel perutean, misalnya, ketika aplikasi A meminta informasi tentang "/ foo", apa yang terjadi
  • Memuat pengaturan penyeimbang, seperti batas waktu, coba lagi, parameter pemutus sirkuit, dll.
• Penjadwal beban kerja : Layanan diluncurkan dalam infrastruktur melalui jenis perencanaan / sistem orkestrasi tertentu, seperti Kubernetes atau Nomad. Penjadwal bertanggung jawab untuk memuat layanan bersama dengan server proxy lokalnya.
• Penemuan layanan Ketika penjadwal memulai dan menghentikan instance layanan, ia melaporkan status kesehatan ke sistem penemuan layanan.
• API konfigurasi proxy sespan : Proksi lokal secara dinamis mengekstrak status dari berbagai komponen sistem sesuai dengan model "akhirnya konsisten" tanpa intervensi operator. Seluruh sistem, yang terdiri dari semua instance layanan yang sedang berjalan dan server proxy lokal, pada akhirnya menyatu menjadi satu ekosistem. API bidang data Utusan adalah salah satu contoh cara kerjanya dalam praktik.

Pada dasarnya, tujuan dari bidang kontrol adalah untuk menetapkan kebijakan yang pada akhirnya akan diadopsi oleh bidang data. Pesawat kontrol yang lebih maju akan menghapus lebih banyak bagian dari beberapa sistem dari operator dan memerlukan lebih sedikit kontrol manual, asalkan bekerja dengan benar! ..

Bidang data dan bidang kontrol. Data plane vs ringkasan plane control

• Bidang data layanan mesh : memengaruhi setiap paket / permintaan dalam sistem. Bertanggung jawab untuk penemuan aplikasi / layanan, pemeriksaan kesehatan, perutean, penyeimbangan muatan, otentikasi / otorisasi, dan kemampuan observasi.
• Bidang kendali jala layanan : memberikan kebijakan dan konfigurasi untuk semua pesawat data yang bekerja dalam jaringan layanan. Tidak menyentuh paket / permintaan apa pun dalam sistem. Pesawat kontrol mengubah semua pesawat data menjadi sistem terdistribusi.

Lansekap proyek saat ini

Setelah menemukan penjelasan di atas, mari kita lihat status proyek "service mesh" saat ini.

• Pesawat data : Linkerd, NGINX, HAProxy, Utusan, Traefik
• Pesawat kontrol : Istio, Nelson, SmartStack

Alih-alih melakukan analisis mendalam dari masing-masing solusi di atas, saya akan membahas secara singkat beberapa poin yang, menurut pendapat saya, menyebabkan sebagian besar kebingungan dalam ekosistem saat ini.

Pada awal 2016, Linkerd adalah salah satu server proxy pertama untuk pesawat data untuk layanan mesh dan melakukan pekerjaan yang fantastis untuk meningkatkan kesadaran dan meningkatkan perhatian pada model desain layanan mesh. Sekitar 6 bulan setelah ini, Utusan bergabung dengan Linkerd (meskipun ia telah bersama Lyft sejak akhir 2015). Linkerd dan Utusan adalah dua proyek yang paling sering disebutkan ketika membahas jaringan layanan.

Istio diumumkan pada Mei 2017. Tujuan proyek Istio sangat mirip dengan bidang kontrol yang diperluas yang ditunjukkan pada Gambar 3 . Utusan untuk Istio adalah server proxy standar. Dengan demikian, Istio adalah bidang kontrol, dan Utusan adalah bidang data. Dalam waktu singkat, Istio menyebabkan banyak kerusuhan, dan pesawat data lainnya mulai berintegrasi sebagai pengganti Utusan (baik Linkerd dan NGINX menunjukkan integrasi dengan Istio). Fakta bahwa Anda dapat menggunakan bidang data yang berbeda dalam bidang kontrol yang sama berarti bahwa bidang kontrol dan bidang data tidak selalu terkait erat. API seperti API pesawat data universal Utusan dapat membentuk jembatan antara dua bagian sistem.

Nelson dan SmartStack membantu menggambarkan lebih lanjut pemisahan bidang kontrol dan bidang data. Nelson menggunakan Utusan sebagai proxy dan membangun bidang kontrol yang andal dari service mesh berdasarkan tumpukan HashiCorp, yaitu. Perantau dll SmartStack mungkin adalah yang pertama dari gelombang baru jaringan layanan. SmartStack membentuk bidang kendali di sekitar HAProxy atau NGINX, menunjukkan kemampuan untuk memisahkan bidang kendali dari jala servis dan bidang data.

Arsitektur microservice dengan mesh layanan menarik lebih banyak perhatian (kanan!), Dan semakin banyak proyek dan vendor mulai bekerja ke arah ini. Selama beberapa tahun ke depan, kita akan melihat banyak inovasi di bidang data dan bidang kontrol, serta pencampuran lebih lanjut dari berbagai komponen. Pada akhirnya, arsitektur layanan mikro harus menjadi lebih transparan dan magis (?) Untuk operator.
Harapan semakin tidak terganggu.

Poin-poin penting (Key takeaways)

• Jaring servis (service mesh) terdiri dari dua bagian yang berbeda: bidang data dan bidang kontrol. Kedua komponen diperlukan, dan tanpa mereka sistem tidak akan berfungsi.
• Semua orang akrab dengan bidang kendali, dan saat ini Anda bisa menjadi bidang kendali!
• Semua pesawat data bersaing satu sama lain dalam fungsi, kinerja, konfigurasi, dan ekstensibilitas.
• Semua pesawat kontrol bersaing dalam fungsi, konfigurasi, ekstensibilitas, dan kegunaan.
• Satu bidang kontrol tunggal dapat berisi abstraksi dan API yang benar sehingga beberapa bidang data dapat digunakan.