Hei Habr! Untuk perhatian Anda, saya persembahkan terjemahan artikel tersebut penulis Matt Klein.
Kali ini, saya “menginginkan dan menerjemahkan” deskripsi komponen mesh layanan, bidang data, dan bidang kontrol. Deskripsi ini menurut saya paling mudah dimengerti dan menarik, dan yang paling penting mengarah pada pemahaman tentang “Apakah perlu?”
Ketika gagasan "Jaringan Layanan" menjadi semakin populer selama dua tahun terakhir (Artikel asli 10 Oktober 2017) dan jumlah peserta dalam ruang tersebut meningkat, saya telah melihat peningkatan kebingungan yang sepadan di antara seluruh komunitas teknologi tentang cara membandingkan dan membedakan solusi yang berbeda.
Situasi ini dapat diringkas dengan baik melalui rangkaian tweet berikut yang saya tulis pada bulan Juli:
Kebingungan mesh layanan #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Tak satu pun dari mereka yang setara dengan Istio. Istio adalah sesuatu yang sangat berbeda. 1 /
Yang pertama hanyalah bidang data. Sendirian mereka tidak melakukan apa pun. Mereka pasti sedang berminat untuk sesuatu yang lebih. 2/
Istio adalah contoh bidang kendali yang mengikat bagian-bagiannya menjadi satu. Ini adalah lapisan lain. /akhir
Tweet sebelumnya menyebutkan beberapa proyek berbeda (Linkerd, NGINX, HAProxy, Envoy, dan Istio), namun yang lebih penting memperkenalkan konsep umum bidang data, mesh layanan, dan bidang kendali. Dalam posting ini, saya akan mengambil langkah mundur dan berbicara tentang apa yang saya maksud dengan istilah "data plane" dan "control plane" pada tingkat yang sangat tinggi, dan kemudian berbicara tentang bagaimana istilah tersebut berlaku untuk proyek yang disebutkan dalam tweet.
Apa sebenarnya jaring layanan itu?
Gambar 1: Ikhtisar mesh layanan
Gambar 1 mengilustrasikan konsep jaring layanan pada tingkat paling dasar. Ada empat cluster layanan (AD). Setiap contoh layanan dikaitkan dengan server proksi lokal. Semua lalu lintas jaringan (HTTP, REST, gRPC, Redis, dll.) dari satu instance aplikasi diteruskan melalui proksi lokal ke cluster layanan eksternal yang sesuai. Dengan cara ini, instance aplikasi tidak mengetahui jaringan secara keseluruhan dan hanya mengetahui proksi lokalnya. Akibatnya, jaringan sistem terdistribusi telah dihapus dari layanan.
Pesawat data
Dalam mesh layanan, server proksi yang terletak secara lokal untuk aplikasi melakukan tugas-tugas berikut:
- Penemuan layanan. Layanan/aplikasi apa yang tersedia untuk aplikasi Anda?
- Pemeriksaan kesehatan. Apakah instans layanan yang dikembalikan oleh penemuan layanan sehat dan siap menerima lalu lintas jaringan? Hal ini dapat mencakup pemeriksaan kesehatan aktif (misalnya respons/pemeriksaan kesehatan) dan pasif (misalnya menggunakan 3 kesalahan 5xx berturut-turut sebagai indikasi status layanan tidak sehat).
- Rute. Saat menerima permintaan ke "/foo" dari layanan REST, ke cluster layanan mana permintaan tersebut harus dikirim?
- Penyeimbang beban. Setelah kluster layanan dipilih selama perutean, ke instans layanan mana permintaan harus dikirim? Dengan batas waktu berapa? Dengan pengaturan pemutusan sirkuit apa? Jika permintaan gagal, apakah harus dicoba lagi?
- Otentikasi dan otorisasi. Untuk permintaan masuk, dapatkah layanan panggilan diidentifikasi/diotorisasi secara kriptografis menggunakan mTLS atau mekanisme lainnya? Jika dikenali/diotorisasi, apakah diperbolehkan memanggil operasi yang diminta (titik akhir) pada layanan atau haruskah respons yang tidak diautentikasi dikembalikan?
- Observabilitas. Statistik terperinci, log/log, dan data jejak terdistribusi harus dihasilkan untuk setiap permintaan sehingga operator dapat memahami arus lalu lintas terdistribusi dan masalah debug yang muncul.
Bidang data bertanggung jawab atas semua titik sebelumnya dalam mesh layanan. Faktanya, proksi lokal ke layanan (sespan) adalah bidang data. Dengan kata lain, bidang data bertanggung jawab untuk menyiarkan, meneruskan, dan memantau secara kondisional setiap paket jaringan yang dikirim ke atau dari suatu layanan.
Pesawat kendali
Abstraksi jaringan yang disediakan oleh proxy lokal di bidang data bersifat ajaib (?). Namun, bagaimana sebenarnya proxy mengetahui tentang rute "/ foo" ke layanan B? Bagaimana data penemuan layanan yang diisi oleh permintaan proksi dapat digunakan? Bagaimana parameter dikonfigurasi untuk penyeimbangan beban, batas waktu, pemutusan sirkuit, dll.? Bagaimana Anda menerapkan aplikasi menggunakan metode biru/hijau atau metode transisi lalu lintas yang anggun? Siapa yang mengonfigurasi pengaturan autentikasi dan otorisasi seluruh sistem?
Semua item di atas berada di bawah kendali bidang kendali mesh layanan. Bidang kontrol mengambil sekumpulan proxy tanpa kewarganegaraan yang terisolasi dan mengubahnya menjadi sistem terdistribusi.
Saya pikir alasan banyak ahli teknologi menganggap konsep terpisah antara bidang data dan bidang kendali membingungkan adalah karena bagi kebanyakan orang bidang data sudah familiar sedangkan bidang kendali asing/tidak dipahami. Kami telah lama bekerja dengan router dan switch jaringan fisik. Kami memahami bahwa paket/permintaan harus berpindah dari titik A ke titik B dan kami dapat menggunakan perangkat keras dan perangkat lunak untuk melakukan hal ini. Proksi perangkat lunak generasi baru hanyalah versi mewah dari alat yang telah kami gunakan sejak lama.
Gambar 2: Bidang kendali manusia
Namun, kami telah menggunakan bidang kendali sejak lama, meskipun sebagian besar operator jaringan mungkin tidak mengaitkan bagian sistem ini dengan komponen teknologi apa pun. Alasannya sederhana:
Kebanyakan pesawat kendali yang digunakan saat ini adalah... kita.
Pada Gambar 2 menunjukkan apa yang saya sebut sebagai “bidang kendali manusia”. Dalam jenis penerapan ini, yang masih sangat umum, operator manusia yang mungkin pemarah membuat konfigurasi statis - kemungkinan melalui skrip - dan menyebarkannya melalui beberapa proses khusus ke semua proxy. Proksi kemudian mulai menggunakan konfigurasi ini dan mulai memproses bidang data menggunakan pengaturan yang diperbarui.
Gambar 3: Bidang kontrol mesh layanan lanjutan
Pada Gambar 3 menunjukkan bidang kontrol “diperluas” dari mesh layanan. Ini terdiri dari bagian-bagian berikut:
- Manusia: Masih ada orang (semoga tidak terlalu marah) yang membuat keputusan tingkat tinggi mengenai keseluruhan sistem secara keseluruhan.
- Kontrol UI bidang: Seseorang berinteraksi dengan beberapa jenis antarmuka pengguna untuk mengontrol sistem. Ini bisa berupa portal web, aplikasi baris perintah (CLI), atau antarmuka lainnya. Dengan menggunakan antarmuka pengguna, operator memiliki akses ke parameter konfigurasi sistem global seperti:
- Kontrol penerapan, transisi lalu lintas biru/hijau dan/atau bertahap
- Opsi Otentikasi dan Otorisasi
- Spesifikasi tabel routing, misalnya ketika aplikasi A meminta informasi tentang "/foo" apa yang terjadi
- Pengaturan penyeimbang beban, seperti batas waktu, percobaan ulang, pengaturan pemutusan sirkuit, dll.
- Penjadwal beban kerja: Layanan dijalankan pada infrastruktur melalui beberapa jenis sistem penjadwalan/orkestrasi, seperti Kubernetes atau Nomad. Penjadwal bertanggung jawab untuk memuat layanan bersama dengan proxy lokalnya.
- Penemuan layanan. Ketika penjadwal memulai dan menghentikan instans layanan, ia melaporkan status kesehatan ke sistem penemuan layanan.
- API konfigurasi proksi sidecar : Proksi lokal secara dinamis mengekstraksi status dari berbagai komponen sistem menggunakan model yang pada akhirnya konsisten tanpa campur tangan operator. Seluruh sistem, yang terdiri dari semua layanan yang sedang berjalan dan server proxy lokal, pada akhirnya menyatu menjadi satu ekosistem. API bidang data universal Envoy adalah salah satu contoh cara kerjanya dalam praktik.
Pada dasarnya, tujuan dari bidang kendali adalah untuk menetapkan kebijakan yang pada akhirnya akan diterima oleh bidang data. Bidang kendali yang lebih canggih akan menghilangkan lebih banyak bagian dari beberapa sistem dari operator dan memerlukan lebih sedikit pengoperasian manual, asalkan berfungsi dengan benar!...
Bidang data dan bidang kontrol. Ringkasan bidang data vs. bidang kontrol
- Bidang data mesh layanan: Mempengaruhi setiap paket/permintaan di sistem. Bertanggung jawab atas penemuan aplikasi/layanan, pemeriksaan kesehatan, perutean, penyeimbangan beban, autentikasi/otorisasi, dan kemampuan observasi.
- Bidang kontrol jaring layanan: Memberikan kebijakan dan konfigurasi untuk semua bidang data yang berjalan dalam jaringan layanan. Tidak menyentuh paket/permintaan apa pun di sistem. Bidang kendali mengubah semua bidang data menjadi sistem terdistribusi.
Lanskap proyek saat ini
Setelah memahami penjelasan di atas, mari kita lihat keadaan proyek service mesh saat ini.
- Pesawat data: Linkerd, NGINX, HAProxy, Utusan, Traefik
- Kendalikan pesawat: Istio, Nelson, SmartStack
Daripada membahas secara mendalam analisis masing-masing solusi di atas, saya akan membahas secara singkat beberapa poin yang saya yakini menyebabkan banyak kebingungan dalam ekosistem saat ini.
Linkerd adalah salah satu server proksi bidang data pertama untuk mesh layanan pada awal tahun 2016 dan telah melakukan pekerjaan luar biasa dalam meningkatkan kesadaran dan perhatian terhadap model desain mesh layanan. Sekitar 6 bulan setelah itu, Envoy bergabung dengan Linkerd (meskipun dia telah bergabung dengan Lyft sejak akhir tahun 2015). Linkerd dan Envoy adalah dua proyek yang paling sering disebutkan ketika membahas jerat layanan.
Istio diumumkan pada Mei 2017. Tujuan dari proyek Istio sangat mirip dengan bidang kendali yang diperluas yang ditunjukkan pada gambar Gambar 3. Utusan untuk Istio adalah proxy default. Jadi, Istio adalah bidang kendali, dan Utusan adalah bidang data. Dalam waktu singkat, Istio menghasilkan banyak kegembiraan, dan bidang data lainnya mulai berintegrasi sebagai pengganti Envoy (Linkerd dan NGINX mendemonstrasikan integrasi dengan Istio). Fakta bahwa bidang data yang berbeda dapat digunakan dalam bidang kendali yang sama berarti bahwa bidang kendali dan bidang data belum tentu digabungkan secara erat. API seperti API bidang data generik Envoy dapat membentuk jembatan antara dua bagian sistem.
Nelson dan SmartStack membantu mengilustrasikan lebih jauh pemisahan bidang kendali dan bidang data. Nelson menggunakan Envoy sebagai proksinya dan membangun bidang kendali yang andal untuk mesh layanan berdasarkan tumpukan HashiCorp, yaitu. Pengembara, dll. SmartStack mungkin yang pertama dari gelombang layanan baru. SmartStack membangun bidang kendali di sekitar HAProxy atau NGINX, menunjukkan kemampuan untuk memisahkan bidang kendali dari mesh layanan dan bidang data.
Arsitektur layanan mikro dengan jaring layanan semakin mendapat perhatian (benar!), dan semakin banyak proyek serta vendor mulai bekerja ke arah ini. Selama beberapa tahun ke depan kita akan melihat banyak inovasi baik pada bidang data maupun bidang kontrol, serta pencampuran lebih lanjut berbagai komponen. Pada akhirnya, arsitektur layanan mikro harus menjadi lebih transparan dan ajaib (?) bagi operator.
Semoga semakin berkurang rasa jengkelnya.
Poin-poin penting
- Jaring layanan terdiri dari dua bagian berbeda: bidang data dan bidang kontrol. Kedua komponen tersebut diperlukan, dan tanpanya sistem tidak akan berfungsi.
- Semua orang sudah familiar dengan bidang kendali, dan pada titik ini, bidang kendalinya bisa jadi adalah Anda!
- Semua bidang data bersaing satu sama lain dalam hal fitur, kinerja, kemampuan konfigurasi, dan ekstensibilitas.
- Semua bidang kontrol bersaing satu sama lain dalam hal fitur, kemampuan konfigurasi, ekstensibilitas, dan kemudahan penggunaan.
- Satu bidang kendali dapat berisi abstraksi dan API yang tepat sehingga beberapa bidang data dapat digunakan.
Sumber: www.habr.com