Hello, Habr! Saya membentangkan kepada anda terjemahan artikel "Satah data mesh perkhidmatan vs satah kawalan" pengarang Matt Klein.

Kali ini, saya "ingin dan menterjemah" perihalan kedua-dua komponen jaringan perkhidmatan, satah data dan satah kawalan. Penerangan ini bagi saya nampaknya paling mudah difahami dan menarik, dan yang paling penting membawa kepada pemahaman "Adakah perlu sama sekali?"

Memandangkan idea "Mesh Perkhidmatan" telah menjadi semakin popular sejak dua tahun kebelakangan ini (Artikel asal 10 Oktober 2017) dan bilangan peserta dalam ruang telah meningkat, saya telah melihat peningkatan yang setimpal dalam kekeliruan di kalangan seluruh komuniti teknologi berkenaan cara membandingkan dan membezakan penyelesaian yang berbeza.

Situasi ini paling baik diringkaskan oleh siri tweet berikut yang saya tulis pada bulan Julai:

Kekeliruan jaringan perkhidmatan #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Utusan. Tiada satu pun daripada mereka yang sama dengan Istio. Istio adalah sesuatu yang sama sekali berbeza. 1 /

Yang pertama hanyalah satah data. Dengan sendirinya mereka tidak melakukan apa-apa. Mereka mesti berada dalam mood untuk sesuatu yang lebih. 2/

Istio ialah contoh satah kawalan yang mengikat bahagian bersama. Ini adalah lapisan lain. /akhir

Tweet sebelum ini menyebut beberapa projek berbeza (Linkerd, NGINX, HAProxy, Envoy, dan Istio), tetapi yang lebih penting memperkenalkan konsep umum satah data, jaringan perkhidmatan dan satah kawalan. Dalam siaran ini, saya akan mengambil langkah ke belakang dan bercakap tentang apa yang saya maksudkan dengan istilah "satah data" dan "satah kawalan" pada tahap yang sangat tinggi, dan kemudian bercakap tentang cara istilah itu digunakan untuk projek yang disebut dalam tweet.

Apakah mesh perkhidmatan, sebenarnya?

Rajah 1: Gambaran keseluruhan jaringan perkhidmatan

Rajah 1 menggambarkan konsep jaringan perkhidmatan pada tahap paling asasnya. Terdapat empat kluster perkhidmatan (AD). Setiap contoh perkhidmatan dikaitkan dengan pelayan proksi tempatan. Semua trafik rangkaian (HTTP, REST, gRPC, Redis, dsb.) daripada satu contoh aplikasi dihantar melalui proksi tempatan kepada kluster perkhidmatan luaran yang sesuai. Dengan cara ini, contoh aplikasi tidak mengetahui rangkaian secara keseluruhan dan hanya mengetahui proksi setempatnya. Sebenarnya, rangkaian sistem yang diedarkan telah dialih keluar daripada perkhidmatan.

Pesawat data

Dalam jaringan perkhidmatan, pelayan proksi yang terletak secara setempat untuk aplikasi melaksanakan tugas berikut:

• Penemuan perkhidmatan. Apakah perkhidmatan/aplikasi yang tersedia untuk permohonan anda?
• Pemeriksaan kesihatan. Adakah contoh perkhidmatan yang dikembalikan oleh penemuan perkhidmatan sihat dan bersedia untuk menerima trafik rangkaian? Ini boleh termasuk pemeriksaan kesihatan aktif (cth tindak balas/pemeriksaan kesihatan) dan pasif (cth menggunakan 3 ralat 5xx berturut-turut sebagai petunjuk keadaan perkhidmatan yang tidak sihat).
• Penghalaan. Apabila menerima permintaan untuk "/foo" daripada perkhidmatan REST, kluster perkhidmatan yang manakah permintaan itu harus dihantar?
• Pengimbangan beban. Sebaik sahaja kluster perkhidmatan telah dipilih semasa penghalaan, kepada contoh perkhidmatan manakah permintaan itu harus dihantar? Dengan tamat masa apa? Dengan tetapan pemutus litar apa? Sekiranya permintaan itu gagal, adakah ia patut dicuba semula?
• Pengesahan dan kebenaran. Untuk permintaan masuk, bolehkah perkhidmatan panggilan dikenal pasti/diizinkan secara kriptografi menggunakan mTLS atau beberapa mekanisme lain? Jika ia diiktiraf/dibenarkan, adakah ia dibenarkan untuk memanggil operasi yang diminta (titik akhir) pada perkhidmatan atau patutkah respons yang tidak disahkan dikembalikan?
• Kebolehlihatan. Statistik terperinci, log/log dan data surih teragih hendaklah dijana untuk setiap permintaan supaya pengendali dapat memahami aliran trafik teragih dan isu penyahpepijatan apabila ia timbul.

Pesawat data bertanggungjawab untuk semua titik sebelumnya dalam jaringan perkhidmatan. Malah, proksi setempat kepada perkhidmatan (kereta sampingan) ialah satah data. Dalam erti kata lain, pesawat data bertanggungjawab untuk penyiaran bersyarat, pemajuan dan pemantauan setiap paket rangkaian yang dihantar ke atau dari perkhidmatan.

Pesawat kawalan

Abstraksi rangkaian yang disediakan oleh proksi tempatan dalam satah data adalah ajaib(?). Walau bagaimanapun, bagaimanakah proksi sebenarnya mengetahui tentang laluan "/foo" ke perkhidmatan B? Bagaimanakah data penemuan perkhidmatan yang diisi oleh permintaan proksi boleh digunakan? Bagaimanakah parameter dikonfigurasikan untuk pengimbangan beban, tamat masa, pemutus litar, dsb.? Bagaimanakah anda menggunakan aplikasi menggunakan kaedah biru/hijau atau kaedah peralihan trafik yang anggun? Siapa yang mengkonfigurasi tetapan pengesahan dan kebenaran seluruh sistem?

Semua item di atas adalah di bawah kawalan satah kawalan jaringan perkhidmatan. Pesawat kawalan mengambil satu set proksi tanpa kewarganegaraan terpencil dan mengubahnya menjadi sistem teragih.

Saya rasa sebab ramai ahli teknologi mendapati konsep berasingan satah data dan satah kawalan mengelirukan adalah kerana bagi kebanyakan orang satah data biasa manakala satah kawalan asing/tidak difahami. Kami telah bekerja dengan penghala rangkaian fizikal dan suis untuk masa yang lama. Kami faham bahawa paket/permintaan perlu pergi dari titik A ke titik B dan kami boleh menggunakan perkakasan dan perisian untuk melakukan ini. Proksi perisian generasi baharu hanyalah versi mewah bagi alatan yang telah kami gunakan sejak sekian lama.

Rajah 2: Pesawat kawalan manusia

Walau bagaimanapun, kami telah lama menggunakan pesawat kawalan, walaupun kebanyakan pengendali rangkaian mungkin tidak mengaitkan bahagian sistem ini dengan mana-mana komponen teknologi. Sebabnya mudah sahaja:
Kebanyakan pesawat kawalan yang digunakan hari ini ialah... kita.

Pada Rajah 2 menunjukkan apa yang saya panggil "Satah kawalan manusia." Dalam jenis penggunaan ini, yang masih sangat biasa, pengendali manusia yang mungkin pemarah mencipta konfigurasi statik - berpotensi melalui skrip - dan menggunakan mereka melalui beberapa proses khas kepada semua proksi. Proksi kemudian mula menggunakan konfigurasi ini dan mula memproses satah data menggunakan tetapan yang dikemas kini.

Rajah 3: Satah kawalan mesh perkhidmatan lanjutan

Pada Rajah 3 menunjukkan satah kawalan "dilanjutkan" jaringan perkhidmatan. Ia terdiri daripada bahagian berikut:

• Manusia: Masih ada orang (mudah-mudahan kurang marah) yang membuat keputusan peringkat tinggi mengenai keseluruhan sistem secara keseluruhan.
• UI satah kawalan: Seseorang berinteraksi dengan beberapa jenis antara muka pengguna untuk mengawal sistem. Ini boleh menjadi portal web, aplikasi baris arahan (CLI), atau antara muka lain. Menggunakan antara muka pengguna, pengendali mempunyai akses kepada parameter konfigurasi sistem global seperti:
  • Kawalan penempatan, peralihan trafik biru/hijau dan/atau beransur-ansur
  • Pilihan Pengesahan dan Kebenaran
  • Spesifikasi jadual penghalaan, contohnya apabila aplikasi A meminta maklumat tentang "/foo" apa yang berlaku
  • Tetapan pengimbang beban, seperti tamat masa, percubaan semula, tetapan pemutus litar, dsb.
• Penjadual beban kerja: Perkhidmatan dijalankan pada infrastruktur melalui beberapa jenis sistem penjadualan/orkestra, seperti Kubernetes atau Nomad. Penjadual bertanggungjawab untuk memuatkan perkhidmatan bersama-sama dengan proksi setempatnya.
• Penemuan perkhidmatan. Apabila penjadual memulakan dan menghentikan contoh perkhidmatan, ia melaporkan status kesihatan kepada sistem penemuan perkhidmatan.
• API konfigurasi proksi kereta sampingan : Proksi tempatan mengekstrak keadaan secara dinamik daripada pelbagai komponen sistem menggunakan model yang akhirnya konsisten tanpa campur tangan pengendali. Keseluruhan sistem, yang terdiri daripada semua contoh perkhidmatan yang sedang berjalan dan pelayan proksi tempatan, akhirnya menumpu kepada satu ekosistem. API satah data universal Envoy ialah satu contoh cara ini berfungsi dalam amalan.

Pada asasnya, tujuan pesawat kawalan adalah untuk menetapkan dasar yang akhirnya akan diterima oleh pesawat data. Pesawat kawalan yang lebih maju akan mengalih keluar lebih banyak bahagian sesetengah sistem daripada operator dan memerlukan kurang operasi manual, dengan syarat ia berfungsi dengan betul!...

Satah data dan satah kawalan. Ringkasan satah data lwn. satah kawalan

• Pesawat data jaringan perkhidmatan: Mempengaruhi setiap paket/permintaan dalam sistem. Bertanggungjawab untuk penemuan aplikasi/perkhidmatan, pemeriksaan kesihatan, penghalaan, pengimbangan beban, pengesahan/keizinan dan pemerhatian.
• Pesawat kawalan mesh servis: Menyediakan dasar dan konfigurasi untuk semua satah data yang sedang berjalan dalam rangkaian perkhidmatan. Tidak menyentuh sebarang pakej/permintaan pada sistem. Satah kawalan menukar semua satah data menjadi sistem teragih.

Landskap projek semasa

Setelah memahami penjelasan di atas, mari kita lihat keadaan semasa projek mesh perkhidmatan.

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

Daripada pergi ke analisis mendalam bagi setiap penyelesaian di atas, saya akan membincangkan secara ringkas beberapa perkara yang saya percaya menyebabkan banyak kekeliruan dalam ekosistem sekarang.

Linkerd ialah salah satu pelayan proksi satah data pertama untuk mesh perkhidmatan pada awal 2016 dan telah melakukan tugas yang hebat dalam meningkatkan kesedaran dan perhatian kepada model reka bentuk jaringan perkhidmatan. Kira-kira 6 bulan selepas itu, Envoy menyertai Linkerd (walaupun dia telah bersama Lyft sejak lewat 2015). Linkerd dan Envoy ialah dua projek yang paling kerap disebut apabila membincangkan jaringan perkhidmatan.

Istio diumumkan pada Mei 2017. Matlamat projek Istio sangat serupa dengan satah kawalan lanjutan yang ditunjukkan dalam Rajah 3. Utusan untuk Istio ialah proksi lalai. Oleh itu, Istio ialah satah kawalan, dan Utusan ialah satah data. Dalam masa yang singkat, Istio menjana banyak keseronokan, dan pesawat data lain mula disepadukan sebagai pengganti Envoy (kedua-dua Linkerd dan NGINX menunjukkan penyepaduan dengan Istio). Hakikat bahawa satah data yang berbeza boleh digunakan dalam satah kawalan yang sama bermakna satah kawalan dan satah data tidak semestinya berganding rapat. API seperti API satah data generik Envoy boleh membentuk jambatan antara dua bahagian sistem.

Nelson dan SmartStack membantu menggambarkan lagi pemisahan satah kawalan dan satah data. Nelson menggunakan Envoy sebagai proksinya dan membina satah kawalan yang boleh dipercayai untuk jaringan perkhidmatan berdasarkan timbunan HashiCorp, i.e. Nomad, dsb. SmartStack mungkin yang pertama daripada gelombang baru jejaring perkhidmatan. SmartStack membina satah kawalan di sekeliling HAProxy atau NGINX, menunjukkan keupayaan untuk memisahkan satah kawalan daripada jaringan perkhidmatan daripada satah data.

Seni bina perkhidmatan mikro dengan jaringan perkhidmatan semakin mendapat perhatian (betul!), dan semakin banyak projek serta vendor mula berfungsi ke arah ini. Dalam beberapa tahun akan datang kita akan melihat banyak inovasi dalam kedua-dua satah data dan satah kawalan, serta mencampurkan lagi komponen yang berbeza. Akhirnya, seni bina perkhidmatan mikro harus menjadi lebih telus dan ajaib (?) untuk pengendali.
Harap-harap makin kurang rasa meragam.

Pengambilan utama

• Jaringan perkhidmatan terdiri daripada dua bahagian berbeza: satah data dan satah kawalan. Kedua-dua komponen diperlukan, dan tanpa mereka sistem tidak akan berfungsi.
• Semua orang sudah biasa dengan pesawat kawalan, dan pada ketika ini, pesawat kawalan mungkin anda!
• Semua pesawat data bersaing antara satu sama lain pada ciri, prestasi, kebolehkonfigurasian dan kebolehlanjutan.
• Semua pesawat kawalan bersaing antara satu sama lain dalam ciri, kebolehkonfigurasian, kebolehlanjutan dan kemudahan penggunaan.
• Satu satah kawalan boleh mengandungi abstraksi dan API yang betul supaya berbilang satah data boleh digunakan.

Sumber: www.habr.com