🥇Service Mesh: perkara yang perlu diketahui oleh setiap Jurutera Perisian tentang teknologi terhangat

Catatan. terjemah: Jaringan perkhidmatan adalah fenomena yang belum mempunyai terjemahan yang stabil ke dalam bahasa Rusia (lebih daripada 2 tahun yang lalu kami mencadangkan pilihan "mesh untuk perkhidmatan", dan tidak lama kemudian beberapa rakan sekerja mula aktif mempromosikan gabungan "ayak perkhidmatan"). Perbincangan berterusan tentang teknologi ini telah membawa kepada situasi di mana komponen pemasaran dan teknikal terlalu berkait rapat. Bahan hebat dari salah seorang pengarang istilah asal ini bertujuan untuk memberikan kejelasan kepada jurutera dan lain-lain.

Komik dari Sebastian Caceres

Pengenalan

Jika anda seorang jurutera perisian yang bekerja di suatu tempat di ruang sistem bahagian belakang, istilah "jaringan perkhidmatan" mungkin telah tertanam kuat dalam fikiran anda sejak beberapa tahun yang lalu. Terima kasih kepada satu kebetulan yang aneh, frasa ini semakin banyak mengambil alih industri, dan gembar-gembur serta tawaran promosi yang dikaitkan dengannya semakin berkembang seperti bola salji yang terbang menuruni bukit dan tidak menunjukkan tanda-tanda akan perlahan.

Jaringan perkhidmatan dilahirkan di perairan yang keruh dan berat sebelah ekosistem asli awan. Malangnya, ini bermakna bahawa banyak kontroversi yang mengelilinginya berkisar daripada "percakapan rendah kalori" hingga—menggunakan istilah teknikal—karut langsung. Tetapi jika anda memotong semua bunyi, anda akan mendapati bahawa jaringan perkhidmatan mempunyai fungsi yang sangat nyata, jelas dan penting.

Dalam siaran ini, saya akan cuba melakukan perkara itu sahaja: menyediakan panduan yang jujur, mendalam, tertumpu kepada jurutera untuk mesh servis. Saya bukan sahaja akan menjawab soalan: "Apa ini?", - tetapi juga "Kenapa?"Dan "Kenapa sekarang?". Akhir sekali, saya akan cuba menggariskan mengapa (pada pendapat saya) teknologi tertentu ini telah menyebabkan kekecohan gila, yang merupakan cerita yang menarik itu sendiri.

Siapakah saya?

Hai semua! Nama saya ialah William Morgan. Saya salah seorang pencipta Linkerd — projek jaringan perkhidmatan yang pertama dan projek yang harus dipersalahkan untuk kemunculan istilah itu jaringan perkhidmatan demikian (maaf kawan-kawan!). (Nota transl.: By the way, pada awal kemunculan istilah ini, lebih daripada 2,5 tahun yang lalu, kami telah menterjemah bahan awal pengarang yang sama bertajuk "Apakah mesh perkhidmatan dan mengapa saya memerlukannya [untuk aplikasi awan dengan perkhidmatan mikro]?".) Saya juga kepala Pelampung ialah permulaan yang mencipta perkara mesh perkhidmatan yang hebat seperti Linkerd dan Menyelam.

Anda mungkin boleh mengagak bahawa saya mempunyai pendapat yang sangat berat sebelah dan subjektif mengenai isu ini. Walau bagaimanapun, saya akan cuba mengekalkan berat sebelah pada tahap minimum (kecuali satu bahagian: “Mengapa terdapat begitu banyak perbincangan mengenai jaringan perkhidmatan?”, - di mana saya masih akan berkongsi idea-idea prasangka saya). Saya juga akan melakukan yang terbaik untuk menjadikan panduan ini seobjektif mungkin. Untuk contoh khusus, saya akan bergantung terutamanya pada pengalaman Linkerd, sambil menunjukkan perbezaan (jika ada) yang saya ketahui dalam pelaksanaan jenis jaringan perkhidmatan lain.

Okey, masa untuk beralih kepada kebaikan.

Apakah jaringan perkhidmatan?

Walaupun semua gembar-gembur, struktur jaringan perkhidmatan agak mudah. Ini hanyalah sekumpulan proksi ruang pengguna yang terletak "bersebelahan" perkhidmatan (kita akan bercakap sedikit tentang perkara "seterusnya" kemudian), serta satu set proses kawalan. Proksi dipanggil secara kolektif satah data, dan proses kawalan dipanggil Pesawat kawalan. Pesawat data memintas panggilan antara perkhidmatan dan melakukan "segala jenis perkara yang berbeza" dengan mereka; Pesawat kawalan, sewajarnya, menyelaraskan kelakuan proksi dan menyediakan akses untuk anda, i.e. operator, kepada API, membolehkan rangkaian dimanipulasi dan diukur secara keseluruhan.

Apakah jenis proksi ini? Ini ialah proksi TCP yang sedar Lapisan 7 (iaitu "mengambil kira" lapisan 7 model OSI) seperti HAProxy dan NGINX. Anda boleh memilih proksi mengikut keinginan anda; Linkerd menggunakan proksi Rust, hanya dinamakan linkerd-proxy. Kami menyusunnya khusus untuk mesh perkhidmatan. Mesh lain lebih suka proksi lain (Utusan adalah pilihan biasa). Walau bagaimanapun, memilih proksi hanyalah soal pelaksanaan.

Apakah yang dilakukan oleh pelayan proksi ini? Jelas sekali, mereka membuat panggilan proksi ke dan dari perkhidmatan (secara tegasnya, mereka bertindak sebagai proksi dan proksi terbalik, mengendalikan kedua-dua panggilan masuk dan keluar). Dan mereka melaksanakan set ciri yang memfokuskan pada panggilan antara perkhidmatan. Tumpuan pada trafik antara perkhidmatan inilah yang membezakan proksi mesh perkhidmatan daripada, katakan, get laluan API atau proksi masuk (yang terakhir memfokuskan pada panggilan yang masuk ke kluster dari dunia luar). (Catatan. terjemah: Untuk perbandingan pengawal Ingress sedia ada untuk Kubernetes, kebanyakannya menggunakan Utusan yang telah disebutkan, lihat artikel ini.)

Jadi, kami telah menyusun satah data. Satah kawalan adalah lebih mudah: ia ialah satu set komponen yang menyediakan semua mekanik yang diperlukan oleh satah data untuk beroperasi dengan cara yang diselaraskan, termasuk penemuan perkhidmatan, mengeluarkan sijil TLS, pengagregatan metrik, dsb. Satah data memberitahu satah kawalan tentang tingkah lakunya; seterusnya, satah kawalan menyediakan API yang membolehkan anda mengubah dan memantau kelakuan satah data secara keseluruhan.

Di bawah ialah gambar rajah satah kawalan dan satah data dalam Linkerd. Seperti yang anda lihat, satah kawalan termasuk beberapa komponen berbeza, termasuk tika Prometheus yang mengumpulkan metrik daripada pelayan proksi, serta komponen lain seperti destination (penemuan perkhidmatan), identity (pihak berkuasa sijil, CA) dan public-api (titik akhir untuk web dan CLI). Sebaliknya, satah data ialah proksi penghubung mudah di sebelah contoh aplikasi. Ini hanyalah gambar rajah logik; Dalam penggunaan dunia sebenar, anda mungkin mempunyai tiga replika setiap komponen satah kawalan dan ratusan atau beribu-ribu proksi dalam satah data.

(Segi empat tepat biru dalam rajah ini melambangkan sempadan pod Kubernetes. Anda boleh melihat bahawa bekas dengan linkerd-proxy berada dalam pod yang sama dengan bekas aplikasi. Skim ini dikenali sebagai bekas kereta sampingan.)

Seni bina mesh perkhidmatan mempunyai beberapa implikasi penting. Pertama, kerana tugas proksi adalah untuk memintas panggilan antara perkhidmatan, jaringan perkhidmatan hanya masuk akal jika aplikasi anda dibuat untuk set perkhidmatan tertentu. mesh seseorang boleh gunakan dengan monolit, tetapi ini jelas berlebihan demi satu proksi tunggal, dan fungsinya tidak mungkin diperlukan.

Satu lagi akibat penting ialah mesh perkhidmatan memerlukan besar bilangan proksi. Malah, Linkerd melampirkan linkerd-proxy pada setiap contoh setiap perkhidmatan (pelaksanaan lain menambah proksi pada setiap nod/hos/mesin maya. Itu pun banyak). Penggunaan aktif proksi itu sendiri membawa beberapa komplikasi tambahan:

Proksi dalam satah data mestilah cepat, kerana untuk setiap panggilan terdapat beberapa panggilan kepada proksi: satu di bahagian klien, satu di bahagian pelayan.
Juga proksi sepatutnya kecil и ringan. Masing-masing akan menggunakan memori dan sumber CPU, dan penggunaan ini akan berkembang secara linear dengan aplikasi.
Anda memerlukan mekanisme untuk menggunakan dan mengemas kini sejumlah besar proksi. Melakukannya secara manual bukan pilihan.

Secara umum, jaringan perkhidmatan kelihatan seperti ini (sekurang-kurangnya dari pandangan mata): anda menggunakan sekumpulan proksi ruang pengguna yang "melakukan sesuatu" dengan trafik dalaman, antara perkhidmatan dan menggunakan satah kawalan untuk memantau dan mengurusnya.

Kini tiba masanya untuk bertanya soalan "Mengapa?"

Untuk apa mesh perkhidmatan?

Mereka yang pertama kali menemui idea mesh perkhidmatan boleh dimaafkan kerana berasa sedikit gementar. Reka bentuk mesh perkhidmatan bermakna ia bukan sahaja akan meningkatkan kependaman dalam aplikasi, tetapi juga akan memakan sumber dan akan menambah sekumpulan mekanisme baharu dalam infrastruktur. Mula-mula anda menyediakan jaringan perkhidmatan, dan kemudian tiba-tiba anda mendapati diri anda perlu menyediakan ratusan (jika tidak beribu-ribu) proksi. Persoalannya, siapa yang secara sukarela akan melakukan ini?

Jawapan kepada soalan ini mempunyai dua bahagian. Pertama, kos urus niaga yang berkaitan dengan menggunakan proksi ini boleh dikurangkan dengan ketara terima kasih kepada beberapa perubahan yang berlaku dalam ekosistem (lebih lanjut mengenai perkara ini kemudian).

Kedua, peranti seperti ini sebenarnya adalah cara terbaik untuk memperkenalkan logik tambahan ke dalam sistem. Bukan sahaja kerana jaringan perkhidmatan boleh menambah banyak fungsi baharu, tetapi juga kerana ia boleh dilakukan tanpa mengganggu ekosistem. Malah, keseluruhan model mesh perkhidmatan adalah berdasarkan premis ini: dalam sistem berbilang perkhidmatan, tidak kira apa membuat perkhidmatan individu, lalu lintas antara mereka adalah titik ideal untuk menambah fungsi.

Sebagai contoh, dalam Linkerd (seperti dalam kebanyakan jejaring) fungsi tertumpu terutamanya pada panggilan HTTP, termasuk HTTP/2 dan gRPC*. Fungsinya agak kaya - ia boleh dibahagikan kepada tiga kelas:

Ciri-ciri yang berkaitan dengan kebolehpercayaan. Permintaan berulang, tamat masa, pendekatan kenari (pemisahan/pengalihan lalu lintas), dsb.
Ciri-ciri yang berkaitan dengan pemantauan. Pengagregatan kadar kejayaan, kelewatan dan volum permintaan untuk setiap perkhidmatan atau arahan individu; pembinaan peta topologi perkhidmatan, dsb.
Ciri-ciri yang berkaitan dengan keselamatan. TLS bersama, kawalan akses, dsb.

* Dari sudut pandangan Linkerd, gRPC boleh dikatakan tidak berbeza daripada HTTP/2: ia hanya menggunakan protobuf dalam muatan. Dari sudut pandangan pemaju, kedua-dua perkara itu, sudah tentu, berbeza.

Kebanyakan mekanisme ini beroperasi pada tahap permintaan (oleh itu "proksi L7"). Contohnya, jika perkhidmatan Foo membuat panggilan HTTP ke perkhidmatan Bar, proksi penghubung di sebelah Foo boleh melakukan pengimbangan beban pintar dan panggilan laluan daripada tika Foo ke Bar berdasarkan kependaman yang diperhatikan; ia boleh mengulangi permintaan jika perlu (dan jika ia adalah idempoten); ia boleh merekodkan kod respons dan tamat masa, dsb. Begitu juga, linkerd-proxy di sebelah Bar boleh menolak permintaan jika ia tidak dibenarkan atau melebihi had permintaan; boleh merekodkan kelewatan di pihaknya, dsb.

Proksi boleh "melakukan sesuatu" pada tahap sambungan juga. Sebagai contoh, linkerd-proxy di sebelah Foo boleh memulakan sambungan TLS dan linkerd-proxy di sebelah Bar boleh menamatkannya dan kedua-dua pihak boleh mengesahkan sijil TLS masing-masing*. Ini menyediakan bukan sahaja penyulitan antara perkhidmatan, tetapi juga cara yang selamat dari segi kriptografi untuk mengenal pasti perkhidmatan: Foo dan Bar boleh "membuktikan" bahawa mereka adalah siapa yang mereka katakan.

* "Mutual of a friend" bermakna sijil pelanggan juga disahkan (mutual TLS). Dalam TLS "klasik", contohnya antara penyemak imbas dan pelayan, sijil hanya sebelah pihak (pelayan) biasanya disahkan.

Tidak kira sama ada ia beroperasi pada tahap permintaan atau sambungan, adalah penting untuk menekankan bahawa semua fungsi mesh perkhidmatan adalah operasi watak. Linkerd tidak dapat mengubah semantik muatan - contohnya, menambahkan medan pada serpihan JSON atau membuat perubahan pada protobuf. Kami akan bercakap tentang ciri penting ini kemudian apabila kita bercakap tentang ESB dan perisian tengah.

Ini ialah set ciri yang ditawarkan oleh rangkaian perkhidmatan. Persoalannya timbul: mengapa tidak melaksanakannya secara langsung dalam aplikasi? Dan mengapa bersusah payah dengan proksi sama sekali?

Mengapa mesh perkhidmatan adalah idea yang baik

Walaupun keupayaan jaringan perkhidmatan menarik, nilai terasnya sebenarnya tidak terletak pada cirinya. Akhirnya kita Boleh melaksanakannya secara langsung dalam aplikasi (kita akan melihat kemudian bahawa ini adalah asal-usul mesh perkhidmatan). Untuk mencuba dan merumuskannya dalam satu ayat, nilai jaringan perkhidmatan ialah: ia menyediakan ciri penting untuk menjalankan perisian pelayan moden dengan cara yang konsisten merentas keseluruhan timbunan dan bebas daripada kod aplikasi.

Mari kita analisa cadangan ini.

«Ciri penting untuk menjalankan perisian pelayan moden" Jika anda mencipta aplikasi pelayan transaksi yang disambungkan ke Internet awam, menerima permintaan daripada dunia luar dan membalasnya dalam masa yang singkat - contohnya, aplikasi web, pelayan API dan sebahagian besar aplikasi moden yang lain - dan jika anda melaksanakannya sebagai satu set perkhidmatan yang berinteraksi secara serentak antara satu sama lain, dan jika anda sentiasa menaik taraf perisian ini, menambah ciri baharu, dan jika anda terpaksa mengekalkan sistem ini dalam keadaan berfungsi semasa proses pengubahsuaian - dalam ini kes, tahniah, anda sedang mencipta perisian pelayan moden . Dan semua ciri hebat yang disenaraikan di atas sebenarnya menjadi kritikal untuk anda. Aplikasi itu mestilah boleh dipercayai, selamat dan anda mesti dapat memerhatikan apa yang dilakukannya. Ini betul-betul soalan yang dibantu oleh mesh perkhidmatan.

(OK, perenggan sebelumnya masih menyertakan kepercayaan saya bahawa pendekatan ini adalah cara moden untuk mencipta perisian pelayan. Orang lain lebih suka membangunkan monolit, "perkhidmatan mikro reaktif" dan perkara lain yang tidak termasuk dalam definisi yang diberikan di atas. Orang ini mungkin mempunyai pendapat berbeza daripada saya. Sebaliknya, saya berpendapat bahawa mereka "salah" - walaupun dalam apa jua keadaan jaringan perkhidmatan tidak begitu berguna untuk mereka).

«Seragam untuk keseluruhan timbunan" Fungsi yang disediakan oleh jaringan perkhidmatan bukan sahaja kritikal misi. Ia digunakan untuk semua perkhidmatan dalam aplikasi, tanpa mengira bahasa apa yang mereka gunakan, rangka kerja yang mereka gunakan, siapa yang menulisnya, cara ia digunakan, dan apa-apa kehalusan lain dalam pembangunan dan penggunaannya.

«Bebas daripada kod aplikasi" Akhir sekali, jaringan perkhidmatan bukan sahaja menyediakan fungsi yang konsisten merentas keseluruhan timbunan, ia melakukannya dengan cara yang tidak memerlukan aplikasi diedit. Asas asas kefungsian jaringan perkhidmatan, termasuk tugas untuk konfigurasi, pengemaskinian, operasi, penyelenggaraan, dsb., terletak sepenuhnya pada peringkat platform dan bebas daripada aplikasi. Aplikasi boleh berubah tanpa menjejaskan jaringan perkhidmatan. Sebaliknya, jaringan perkhidmatan boleh berubah tanpa sebarang penyertaan daripada aplikasi.

Ringkasnya, jaringan perkhidmatan bukan sahaja menyediakan fungsi penting, tetapi juga melakukannya secara global, seragam dan bebas aplikasi. Oleh itu, sementara fungsi jaringan perkhidmatan boleh dilaksanakan dalam kod perkhidmatan (contohnya, sebagai perpustakaan yang disertakan dengan setiap perkhidmatan), pendekatan ini tidak akan memberikan keseragaman dan kebebasan yang sangat berharga dalam kes jaringan perkhidmatan.

Dan apa yang anda perlu lakukan ialah menambah sekumpulan proksi! Saya berjanji kita akan melihat kos operasi yang berkaitan dengan penambahan proksi ini tidak lama lagi. Tetapi pertama-tama mari kita berhenti dan melihat idea kemerdekaan ini dari perspektif yang berbeza. daripada orang.

Siapa yang membantu mesh perkhidmatan?

Walaupun menyusahkan, untuk teknologi menjadi bahagian penting dalam ekosistem, ia mesti diterima oleh orang ramai. Jadi siapa yang berminat dengan mesh perkhidmatan? Siapa yang mendapat manfaat daripada penggunaannya?

Jika anda sedang membangunkan perisian pelayan moden, anda boleh menganggap pasukan anda sebagai satu kumpulan pemilik perkhidmatanyang bersama-sama membangunkan dan melaksanakan logik perniagaan, dan pemilik platform, membangunkan platform dalaman di mana perkhidmatan ini beroperasi. Dalam organisasi kecil, ini mungkin orang yang sama, tetapi apabila syarikat berkembang, peranan ini cenderung menjadi lebih ketara malah dibahagikan kepada sub-peranan... (Terdapat banyak yang boleh diperkatakan di sini tentang perubahan sifat devops, kesan organisasi perkhidmatan mikro, dsb.) n. Tetapi buat masa ini mari kita ambil penerangan ini seperti yang diberikan).

Dari sudut pandangan ini, penerima manfaat yang jelas bagi mesh perkhidmatan adalah pemilik platform. Lagipun, akhirnya matlamat pasukan platform adalah untuk mencipta platform dalaman di mana pemilik perkhidmatan boleh melaksanakan logik perniagaan dan melakukannya dengan cara yang memastikan mereka bebas daripada butiran operasinya yang keruh. Jaringan perkhidmatan bukan sahaja menawarkan keupayaan yang penting untuk mencapai matlamat ini, ia melakukannya dengan cara yang seterusnya tidak mengenakan pergantungan kepada pemilik perkhidmatan.

Pemilik perkhidmatan juga mendapat manfaat, walaupun dengan cara yang lebih tidak langsung. Matlamat pemilik perkhidmatan adalah untuk menjadi produktif yang mungkin dalam melaksanakan logik proses perniagaan, dan semakin kurang dia perlu bimbang tentang isu operasi, semakin baik. Daripada perlu berurusan dengan melaksanakan, katakan, mencuba semula dasar atau TLS, mereka boleh menumpukan pada objektif perniagaan semata-mata dan berharap platform mengurus yang lain. Ini adalah kelebihan besar bagi mereka.

Nilai organisasi pembahagian sedemikian antara pemilik platform dan perkhidmatan tidak boleh dianggarkan terlalu tinggi. Saya rasa dia menyumbang asas sumbangan kepada nilai jaringan perkhidmatan.

Kami mempelajari pelajaran ini apabila peminat Linkerd awal memberitahu kami sebab mereka memilih rangkaian perkhidmatan: kerana ia membolehkan mereka "memastikan kedai bercakap pada tahap minimum." Berikut ialah beberapa butiran: lelaki dari sebuah syarikat besar memindahkan platform mereka ke Kubernetes. Memandangkan aplikasi itu mengendalikan maklumat sensitif, mereka mahu menyulitkan semua komunikasi merentas kluster. Bagaimanapun, keadaan menjadi rumit dengan kehadiran ratusan perkhidmatan dan ratusan pasukan pembangunan. Prospek untuk menghubungi semua orang dan meyakinkan mereka untuk memasukkan sokongan TLS dalam rancangan mereka tidak menggembirakan mereka sama sekali. Selepas memasang Linkerd, mereka memindahkan tanggungjawab daripada pembangun (dari sudut pandangan yang mana ini adalah masalah yang tidak perlu) kepada platformer, yang mana ini adalah keutamaan peringkat atasan. Dalam erti kata lain, Linkerd menyelesaikan untuk mereka bukan masalah teknikal tetapi masalah organisasi.

Pendek kata, jaringan perkhidmatan lebih merupakan penyelesaian, bukan teknikal, tetapi sosio-teknikal Masalah. (Terima kasih Cindy Sridharan kerana memperkenalkan istilah ini.)

Adakah rangkaian perkhidmatan menyelesaikan semua masalah saya?

ya. Maksud saya, tidak!

Jika anda melihat pada tiga kelas ciri yang digariskan di atas—kebolehpercayaan, keselamatan dan kebolehmerhatian—menjadi jelas bahawa jaringan perkhidmatan bukanlah penyelesaian lengkap kepada mana-mana masalah ini. Walaupun Linkerd boleh mengeluarkan semula permintaan (jika ia tahu ia adalah idempoten), ia tidak dapat membuat keputusan tentang perkara yang perlu dikembalikan kepada pengguna jika perkhidmatan tersebut gagal secara kekal—keputusan tersebut mesti dibuat oleh aplikasi. Linkerd boleh menyimpan statistik permintaan yang berjaya, tetapi ia tidak dapat melihat ke dalam perkhidmatan dan menyediakan metrik dalamannya - aplikasi mesti mempunyai alat sedemikian. Dan walaupun Linkerd mampu mengatur mTLS, penyelesaian keselamatan yang lengkap memerlukan lebih banyak lagi.

Subset ciri dalam kawasan ini yang ditawarkan oleh jaringan perkhidmatan berkaitan dengan ciri platform. Dengan ini yang saya maksudkan berfungsi bahawa:

Bebas daripada logik perniagaan. Cara histogram panggilan antara Foo dan Bar dibina adalah bebas sepenuhnya mengapa Foo memanggil Bar.
Sukar untuk dilaksanakan dengan betul. Dalam Linkerd, cubaan semula diparameterkan dengan pelbagai perkara mewah seperti belanjawan cuba semula (cuba semula belanjawan), memandangkan pendekatan yang tidak canggih dan terarah untuk melaksanakan perkara sedemikian pastinya akan membawa kepada kemunculan apa yang dipanggil "permintaan longsoran" (cuba semula ribut) dan masalah lain ciri sistem teragih.
Paling berkesan apabila digunakan secara seragam. Mekanisme TLS hanya masuk akal jika ia digunakan di mana-mana sahaja.

Memandangkan fungsi ini dilaksanakan pada peringkat proksi (dan bukan pada peringkat aplikasi), mesh perkhidmatan menyediakannya di platform, bukan aplikasi. Oleh itu, tidak kira bahasa apa perkhidmatan itu ditulis, rangka kerja yang mereka gunakan, siapa yang menulisnya dan mengapa. Proksi beroperasi di luar semua butiran ini, dan asas asas kefungsian ini, termasuk tugas untuk konfigurasi, pengemaskinian, operasi, penyelenggaraan, dll., terletak semata-mata pada peringkat platform.

Contoh keupayaan jaringan perkhidmatan

Untuk meringkaskan, jaringan perkhidmatan bukanlah penyelesaian lengkap untuk kebolehpercayaan, pemerhatian atau keselamatan. Skop bidang ini memerlukan penyertaan pemilik perkhidmatan, pasukan Ops/SRE dan entiti syarikat lain. Jaringan perkhidmatan hanya menyediakan "kepingan" peringkat platform untuk setiap kawasan ini.

Mengapakah jaringan perkhidmatan menjadi popular sekarang?

Sekarang anda mungkin tertanya-tanya: ok, jika jaringan perkhidmatan sangat baik, mengapa kami tidak mula menggunakan berjuta-juta proksi dalam tindanan sepuluh tahun yang lalu?

Terdapat jawapan cetek untuk soalan ini: sepuluh tahun yang lalu semua orang membina monolit, dan tiada siapa yang memerlukan jaringan perkhidmatan. Ini benar, tetapi pada pendapat saya jawapan ini meleset. Malah sepuluh tahun yang lalu, konsep perkhidmatan mikro sebagai cara yang menjanjikan untuk membina sistem berskala besar telah dibincangkan dan digunakan secara meluas di syarikat seperti Twitter, Facebook, Google dan Netflix. Pandangan umum—sekurang-kurangnya dalam bahagian industri yang saya temui—adalah perkhidmatan mikro ialah "cara yang betul" untuk membina sistem yang besar, walaupun ia sangat sukar.

Sudah tentu, walaupun sepuluh tahun yang lalu terdapat syarikat yang mengendalikan perkhidmatan mikro, mereka tidak meletakkan proksi di mana-mana yang mereka boleh untuk membentuk jaringan perkhidmatan. Walau bagaimanapun, jika anda melihat dengan teliti, mereka melakukan sesuatu yang serupa: kebanyakan syarikat ini memerlukan penggunaan perpustakaan dalaman khas untuk komunikasi rangkaian (kadangkala dipanggil perpustakaan pelanggan tebal, perpustakaan pelanggan gemuk).

Netflix mempunyai Hysterix, Google mempunyai Stubby, Twitter mempunyai perpustakaan Finagle. Finagle, sebagai contoh, adalah wajib untuk setiap perkhidmatan baharu di Twitter. Ia mengendalikan kedua-dua bahagian sambungan klien dan pelayan, dibenarkan untuk permintaan berulang, penghalaan permintaan yang disokong, pengimbangan beban dan pengukuran. Ia memberikan lapisan kebolehpercayaan dan pemerhatian yang konsisten di seluruh timbunan Twitter, tanpa mengira apa yang dilakukan oleh perkhidmatan itu. Sudah tentu, ia hanya berfungsi untuk bahasa JVM dan berdasarkan model pengaturcaraan yang perlu digunakan untuk keseluruhan aplikasi. Walau bagaimanapun, fungsinya hampir sama dengan jaringan perkhidmatan. (Malah, versi pertama Linkerd hanyalah Finagle yang dibungkus dalam bentuk proksi.)

Oleh itu, sepuluh tahun yang lalu bukan sahaja terdapat perkhidmatan mikro, tetapi juga perpustakaan proto-service-mesh khas yang menyelesaikan masalah yang sama yang diselesaikan oleh mesh perkhidmatan hari ini. Walau bagaimanapun, jaringan perkhidmatan itu sendiri tidak wujud ketika itu. Perlu ada satu syif lagi sebelum dia muncul.

Dan di sinilah letaknya jawapan yang lebih mendalam, tersembunyi dalam satu lagi perubahan yang telah berlaku sepanjang 10 tahun yang lalu: kos untuk menggunakan perkhidmatan mikro telah menurun secara mendadak. Syarikat-syarikat yang disebutkan di atas yang menggunakan perkhidmatan mikro sepuluh tahun lalu—Twitter, Netflix, Facebook, Google—adalah syarikat berskala besar dan sumber yang besar. Mereka bukan sahaja mempunyai keperluan, tetapi juga keupayaan untuk membina, menggunakan dan mengendalikan aplikasi berasaskan perkhidmatan mikro yang besar. Tenaga dan usaha yang dilakukan oleh jurutera Twitter untuk beralih daripada pendekatan monolitik kepada perkhidmatan mikro adalah menakjubkan. (Untuk bersikap adil, begitu juga hakikat bahawa ia berjaya.) Gerakan infrastruktur seperti ini kemudiannya mustahil untuk syarikat yang lebih kecil.

Cepat ke masa kini. Terdapat syarikat permulaan hari ini di mana nisbah perkhidmatan mikro kepada pembangun ialah 5:1 (atau malah 10:1), dan lebih-lebih lagi, mereka berjaya mengatasinya! Jika permulaan 5 orang boleh mengendalikan 50 perkhidmatan mikro dengan mudah, maka sesuatu telah mengurangkan kos pelaksanaannya dengan jelas.

1500 perkhidmatan mikro di Monzo; setiap baris ialah peraturan rangkaian yang ditetapkan yang membenarkan trafik

Pengurangan dramatik dalam kos pengendalian perkhidmatan mikro adalah hasil daripada satu proses: populariti kontena yang semakin meningkat и orkestra. Ini adalah jawapan yang mendalam kepada soalan tentang apa yang menyumbang kepada kemunculan jaringan perkhidmatan. Teknologi yang sama menjadikan kedua-dua jaringan perkhidmatan dan perkhidmatan mikro menarik: Kubernetes dan Docker.

kenapa? Nah, Docker menyelesaikan satu masalah besar - masalah pembungkusan. Dengan membungkus aplikasi dan kebergantungan masa jalannya (bukan rangkaian) ke dalam bekas, Docker menukar aplikasi menjadi unit boleh tukar ganti yang boleh dihoskan dan dijalankan di mana-mana sahaja. Pada masa yang sama, ia sangat memudahkan operasi berbilang bahasa Tindanan: Oleh kerana bekas ialah unit pelaksanaan atom, untuk penggunaan dan tujuan operasi, tidak kira apa yang ada di dalamnya, sama ada aplikasi JVM, Node, Go, Python atau Ruby. Anda hanya melancarkannya dan itu sahaja.

Kubernetes membawa segala-galanya ke peringkat seterusnya. Memandangkan terdapat banyak "perkara untuk dijalankan" dan banyak mesin untuk menjalankannya, terdapat keperluan untuk alat yang boleh mengaitkannya antara satu sama lain. Dalam erti kata yang luas, anda memberi Kubernetes banyak bekas dan banyak mesin, dan ia memetakannya antara satu sama lain (sudah tentu, ini adalah proses yang dinamik dan sentiasa berubah: bekas baharu bergerak di sekeliling sistem, mesin bermula dan berhenti , dsb. Walau bagaimanapun, Kubernetes mengambil kira semua ini ).

Setelah Kubernetes dikonfigurasikan, kos masa untuk menggunakan dan mengendalikan satu perkhidmatan adalah sedikit berbeza daripada kos untuk menggunakan dan mengendalikan sepuluh perkhidmatan (sebenarnya, ia hampir sama untuk 100 perkhidmatan). Tambahkan pada bekas ini sebagai mekanisme pembungkusan yang menggalakkan pelaksanaan berbilang bahasa, dan anda mempunyai pelbagai aplikasi baharu yang dilaksanakan dalam bentuk perkhidmatan mikro yang ditulis dalam bahasa yang berbeza - persis jenis persekitaran yang sangat sesuai untuk rangkaian perkhidmatan.

Jadi, kami sampai kepada jawapan kepada persoalan mengapa idea jaringan perkhidmatan telah menjadi popular sekarang: kehomogenan yang disediakan oleh Kubernetes untuk perkhidmatan secara langsung terpakai kepada cabaran operasi yang dihadapi oleh jaringan perkhidmatan. Anda membungkus proksi ke dalam bekas, berikan Kubernetes tugas untuk melekatkannya di mana-mana sahaja, dan voila! Akibatnya, anda mendapat jaringan perkhidmatan, manakala semua mekanik penggunaannya diuruskan oleh Kubernetes. (Sekurang-kurangnya dari pandangan mata burung. Sudah tentu, terdapat banyak nuansa untuk proses ini.)

Kesimpulannya: sebab jejaring perkhidmatan telah menjadi popular sekarang, dan bukan sepuluh tahun yang lalu, ialah Kubernetes dan Docker bukan sahaja telah meningkat dengan ketara perlukan di dalamnya, setelah memudahkan pelaksanaan aplikasi sebagai set perkhidmatan mikro berbilang bahasa, tetapi juga berkurangan dengan ketara kos untuk operasinya, menyediakan mekanisme untuk menempatkan dan menyokong armada proksi kereta sampingan.

Mengapa terdapat banyak perbincangan mengenai jaringan perkhidmatan?

Awas: Dalam bahagian ini saya menggunakan semua jenis andaian, andaian, rekaan dan maklumat dalaman.

Lakukan carian untuk "jaringan perkhidmatan" dan anda akan menemui satu tan kandungan rendah kalori yang dikitar semula, projek pelik dan kaleidoskop herotan yang layak untuk ruang gema. Mana-mana teknologi baharu yang mewah melakukan ini, tetapi dalam kes jaringan perkhidmatan, masalahnya amat meruncing. kenapa?

Nah, sebahagian daripadanya adalah salah saya. Saya telah bekerja keras untuk mempromosikan Linkerd dan rangkaian perkhidmatan setiap peluang yang saya dapat melalui catatan blog dan artikel yang tidak terkira banyaknya seperti ini. Tetapi saya tidak begitu berkuasa. Untuk benar-benar menjawab soalan ini, kita perlu bercakap sedikit tentang keadaan keseluruhan. Dan mustahil untuk membincangkannya tanpa menyebut satu projek: Istio ialah rangkaian perkhidmatan sumber terbuka yang dibangunkan bersama oleh Google, IBM dan Lyft.

(Tiga syarikat mempunyai peranan yang sangat berbeza: Penglibatan Lyft nampaknya hanya dalam nama; mereka adalah pengarang Envoy, tetapi tidak menggunakan atau mengambil bahagian dalam pembangunan Istio. IBM terlibat dalam dan menggunakan pembangunan Istio. Google terlibat secara aktif dalam Istio's development , tetapi sebenarnya tidak menggunakannya sejauh yang saya tahu.)

Projek Istio terkenal untuk dua perkara. Pertama, terdapat usaha pemasaran yang besar yang Google, khususnya, lakukan untuk mempromosikannya. Saya akan menganggarkan bahawa kebanyakan orang yang mengetahui konsep mesh perkhidmatan hari ini mula-mula mengetahui tentangnya melalui Istio. Perkara kedua ialah betapa buruknya penerimaan Istio. Dalam perkara ini, saya jelas seorang yang berminat, tetapi cuba untuk kekal seobjektif mungkin, saya masih tidak dapat membantu Mark весьма negatif sikap, tidak begitu tersendiri (walaupun tidak unik: systemd terlintas di fikiran, perbandingan telah dijalankan sudah berulang kali...) untuk projek Sumber Terbuka.

(Dalam amalan, Istio nampaknya mempunyai masalah bukan sahaja dengan kerumitan dan UX, tetapi juga dengan prestasi. Contohnya, semasa Penilaian prestasi LinkerdDalam kajian pihak ketiga, penyelidik menemui situasi di mana kependaman ekor Istio adalah 100 kali lebih tinggi daripada Linkerd, serta situasi kekurangan sumber di mana Linkerd terus berfungsi dengan jayanya manakala Istio berhenti berfungsi sepenuhnya.)

Mengetepikan teori saya tentang sebab ini berlaku, saya percaya bahawa keterujaan yang luar biasa di sekeliling rangkaian perkhidmatan dijelaskan oleh penyertaan Google. Iaitu gabungan tiga faktor berikut:

Promosi Istio yang mengganggu Google;
sikap tidak bersetuju dan kritikal yang sepadan terhadap projek;
peningkatan mendadak dalam populariti Kubernetes baru-baru ini, yang kenangannya masih segar.

Bersama-sama faktor-faktor ini bergabung untuk mewujudkan persekitaran yang menakjubkan, bebas oksigen di mana kapasiti untuk pertimbangan rasional menjadi lemah, dan hanya kepelbagaian aneh yang kekal. mania tulip.

Dari perspektif Linkerd, inilah...apa yang saya akan gambarkan sebagai rahmat yang bercampur-campur. Maksud saya, adalah bagus bahawa jaringan perkhidmatan telah memasuki arus perdana dengan cara yang tidak berlaku pada tahun 2016 apabila Linkerd mula-mula bermula dan amat sukar untuk menarik perhatian orang ramai kepada projek itu. Sekarang tiada masalah seperti itu! Tetapi berita buruknya ialah landskap jaringan perkhidmatan sangat mengelirukan hari ini sehingga hampir mustahil untuk memahami projek yang sebenarnya tergolong dalam kategori jaringan perkhidmatan (apatah lagi memahami mana yang paling sesuai untuk kes penggunaan tertentu). Ini pastinya pemecah perjanjian untuk semua orang (dan pasti ada beberapa kes di mana Istio atau projek lain lebih sesuai daripada Linkerd, kerana yang terakhir masih bukan penyelesaian universal).

Di pihak Linkerd, strategi kami adalah untuk mengabaikan bunyi bising, terus menumpukan pada menyelesaikan masalah komuniti sebenar dan pada dasarnya menunggu gembar-gembur itu reda. Akhirnya, gembar-gembur akan reda dan kita boleh terus bekerja dengan tenang.

Sementara itu, kita semua perlu bersabar sedikit.

Adakah jaringan perkhidmatan berguna kepada saya, seorang jurutera perisian yang rendah hati?

Soal selidik berikut akan membantu anda menjawab soalan ini:

Adakah anda hanya terlibat dalam melaksanakan logik perniagaan? Dalam kes ini, jaringan perkhidmatan tidak akan berguna kepada anda. Iaitu, sudah tentu, anda mungkin berminat dengannya, tetapi idealnya jaringan perkhidmatan tidak boleh menjejaskan apa-apa dalam persekitaran anda secara langsung. Teruskan bekerja pada apa yang anda dibayar untuk lakukan.

Adakah anda menyokong platform di syarikat yang menggunakan Kubernetes? Ya, dalam kes ini, anda memerlukan jaringan perkhidmatan (melainkan, sudah tentu, anda menggunakan K8 hanya untuk menjalankan pemprosesan monolit atau kelompok - tetapi kemudian saya ingin bertanya mengapa anda memerlukan K8). Anda mungkin akan mendapat banyak perkhidmatan mikro yang ditulis oleh orang yang berbeza. Mereka semua berinteraksi antara satu sama lain dan diikat ke dalam kusut kebergantungan masa jalan, dan anda perlu mencari cara untuk menangani semuanya. Menggunakan Kubernetes membolehkan anda memilih rangkaian perkhidmatan "untuk diri sendiri." Untuk melakukan ini, biasakan diri anda dengan keupayaan dan ciri mereka dan jawab soalan sama ada mana-mana projek yang tersedia sesuai untuk anda (saya cadangkan memulakan penyelidikan anda dengan Linkerd).

Adakah anda syarikat platform di syarikat yang TIDAK menggunakan Kubernetes tetapi menggunakan perkhidmatan mikro? Dalam kes ini, jaringan perkhidmatan akan berguna kepada anda, tetapi penggunaannya akan menjadi tidak penting. Sudah tentu boleh meniru mesh perkhidmatan kerja dengan meletakkan sekumpulan proksi, tetapi kelebihan penting Kubernetes ialah model penggunaan: menyelenggara proksi ini secara manual akan memerlukan lebih banyak masa, usaha dan perbelanjaan.

Adakah anda bertanggungjawab untuk platform dalam syarikat yang berfungsi dengan monolit? Dalam kes ini, anda mungkin tidak memerlukan jaringan perkhidmatan. Jika anda bekerja dengan monolit (atau bahkan koleksi monolit) yang mempunyai corak interaksi yang jelas dan jarang berubah, maka jaringan perkhidmatan akan mempunyai sedikit tawaran kepada anda. Jadi anda boleh mengabaikannya dan berharap ia akan hilang seperti mimpi buruk...

Kesimpulan

Mungkin, jaringan perkhidmatan masih tidak boleh dipanggil "teknologi paling digembar-gemburkan di dunia" - penghormatan yang meragukan ini mungkin milik Bitcoin atau AI. Dia mungkin dalam lima teratas. Tetapi jika anda memotong lapisan hingar, menjadi jelas bahawa jaringan perkhidmatan membawa faedah sebenar kepada mereka yang membina aplikasi pada Kubernetes.

Saya ingin anda mencuba Linkerd - memasangnya pada kelompok Kubernetes (atau bahkan Minikube pada komputer riba) mengambil masa kira-kira 60 saat, dan anda boleh lihat sendiri apa yang saya bincangkan.

Soalan Lazim

— Jika saya mengabaikan jaringan perkhidmatan, adakah ia akan hilang?
— Saya mesti mengecewakan anda: rangkaian perkhidmatan ada bersama kami untuk masa yang lama.

- Tetapi saya TIDAK MAHU menggunakan mesh perkhidmatan!
- Nah, ia tidak perlu! Baca sahaja soal selidik saya di atas untuk memahami sama ada anda sekurang-kurangnya harus membiasakan diri dengan asasnya.

— Bukankah ESB/perkakas tengah lama yang bagus ini dengan sos baharu?
— Jaringan perkhidmatan memperkatakan logik operasi, bukan logik semantik. Ini adalah kelemahan utama bas perkhidmatan perusahaan (IALAH B). Mengekalkan pemisahan ini membantu jaringan perkhidmatan mengelakkan nasib yang sama.

— Bagaimanakah jaringan perkhidmatan berbeza daripada get laluan API?
— Terdapat sejuta artikel mengenai topik ini. Google sahaja.

— Utusan adalah jaringan perkhidmatan?
- Tidak, Utusan bukan jaringan perkhidmatan, ia adalah pelayan proksi. Ia boleh digunakan untuk mengatur jaringan perkhidmatan (dan banyak lagi - ia adalah proksi tujuan umum). Tetapi dengan sendirinya ia bukan jaringan perkhidmatan.

— Jaringan Perkhidmatan Rangkaian ialah jaringan perkhidmatan?
- Tidak. Walaupun namanya, ini bukan jaringan perkhidmatan (bagaimana anda suka keajaiban pemasaran?).

— Adakah jaringan perkhidmatan membantu dengan sistem tak segerak reaktif berasaskan baris gilir mesej saya?
- Tidak, jaringan perkhidmatan tidak akan membantu anda.

— Jaringan perkhidmatan manakah yang patut saya gunakan?
- Linkerd, tak payahlah.

- Artikel itu menyebalkan! / Penulis dialu-alukan!
— Sila kongsikan pautan kepadanya dengan semua rakan anda supaya mereka dapat melihatnya!

Ucapan terima kasih

Seperti yang mungkin anda duga dari tajuknya, artikel ini diilhamkan oleh risalah hebat Jay Kreps "Log: Perkara yang perlu diketahui oleh setiap jurutera perisian tentang abstraksi penyatuan data masa nyata" Saya bertemu Jay sepuluh tahun yang lalu apabila saya menemu bualnya di Linked In dan dia telah menjadi inspirasi kepada saya sejak itu.

Walaupun saya suka memanggil diri saya sebagai "pembangun Linkerd", realitinya ialah saya lebih kepada penyelenggara fail README.md pada projek. Linkerd sedang diusahakan hari ini очень, очень, очень много orang, dan projek ini tidak akan berlaku tanpa penyertaan komuniti penyumbang dan pengguna yang hebat.

Dan akhirnya, terima kasih khas kepada pencipta Linkerd, Oliver Gould (primus inter pares), yang, bersama saya bertahun-tahun yang lalu, menyelami semua kekecohan ini dengan jaringan perkhidmatan.

Mesh Servis: Perkara yang Perlu Tahu Setiap Jurutera Perisian Mengenai Teknologi Terhangat