Catatan. terjemahan: Service mesh adalah fenomena yang belum memiliki terjemahan stabil ke dalam bahasa Rusia (lebih dari 2 tahun yang lalu kami menawarkan opsi “mesh untuk layanan”, dan beberapa saat kemudian, beberapa rekan mulai secara aktif mempromosikan kombinasi “service strain”) . Pembicaraan terus-menerus tentang teknologi ini telah menyebabkan situasi di mana komponen pemasaran dan teknis saling terkait erat. Materi luar biasa dari salah satu penulis istilah asli ini dimaksudkan untuk memberikan kejelasan bagi para insinyur dan tidak hanya.
Komik dari
pengenalan
Jika Anda seorang insinyur perangkat lunak yang bekerja di bidang sistem backend, istilah “jaringan layanan” mungkin sudah tertanam kuat di benak Anda selama beberapa tahun terakhir. Berkat kebetulan yang aneh, frasa ini semakin mengambil alih industri, dan hype serta tawaran promosi terkait tumbuh seperti bola salju, terbang menuruni bukit dan tidak menunjukkan tanda-tanda melambat.
Jaringan layanan lahir di perairan ekosistem cloud native yang keruh dan tendensius. Sayangnya, hal ini berarti banyak kontroversi seputar hal ini berkisar dari “obrolan rendah kalori” hingga—dalam istilah teknisnya—omong kosong yang terang-terangan. Namun jika Anda menyaring semua kebisingan, Anda akan menemukan bahwa jaring layanan memiliki fungsi yang sangat nyata, pasti, dan penting.
Dalam posting ini, saya akan mencoba melakukan hal itu: memberikan panduan yang jujur, mendalam, dan berorientasi pada insinyur tentang mesh layanan. Saya akan menjawab lebih dari sekedar pertanyaan: "Apa itu?", - tetapi juga "Mengapa?"Dan "Kenapa sekarang?". Terakhir, saya akan mencoba menjelaskan mengapa (menurut saya) teknologi khusus ini menimbulkan sensasi yang begitu gila, yang dengan sendirinya merupakan cerita yang menarik.
Siapa saya
Halo semua! Nama saya adalah . Saya salah satu penciptanya - proyek mesh layanan pertama dan proyek yang harus disalahkan atas munculnya istilah tersebut jaring layanan seperti itu (maaf teman-teman!). (Catatan terjemahan.: Omong-omong, pada awal kemunculan istilah ini, lebih dari 2,5 tahun yang lalu, kami telah menerjemahkan materi awal dari penulis yang sama berjudul "".) Saya juga memimpin adalah startup yang membangun layanan mesh keren seperti Linkerd dan .
Anda mungkin dapat menebak bahwa saya memiliki pendapat yang sangat bias dan subjektif mengenai masalah ini. Namun, saya akan mencoba meminimalkan bias (dengan pengecualian satu bagian: “Mengapa ada begitu banyak pembicaraan tentang jaringan layanan?”, - di mana saya akan membagikan ide-ide saya yang sudah terbentuk sebelumnya). Saya juga akan melakukan yang terbaik untuk membuat panduan ini seobjektif mungkin. Dalam contoh spesifik, saya terutama akan mengandalkan pengalaman Linkerd, sambil menunjukkan perbedaan (jika ada) yang saya ketahui dalam penerapan jenis mesh layanan lainnya.
Oke, saatnya beralih ke suguhannya.
Apa itu jaring layanan?
Terlepas dari semua hype, jaringan layanan secara struktural cukup sederhana. Ini hanyalah sekumpulan proxy ruang pengguna yang terletak "di sebelah" layanan (kita akan membicarakan sedikit tentang "dekat" nanti), ditambah serangkaian proses kontrol. Proksi secara kolektif disebut pesawat data, dan proses kontrol disebut kontrol pesawat. Bidang data mencegat panggilan antar layanan dan melakukan "sesuatu yang berbeda" dengannya; bidang kontrol, masing-masing, mengoordinasikan perilaku proxy dan menyediakan akses untuk Anda, mis. operator, ke API, memungkinkan jaringan untuk dimanipulasi dan diukur secara keseluruhan.
Apa proksi ini? Ini adalah proksi TCP dari kategori "Layer 7-aware". (yaitu "memperhitungkan" lapisan ke-7 model OSI) seperti HAProxy dan NGINX. Anda dapat memilih proxy sesuai keinginan Anda; Linkerd menggunakan proxy Rust, yang namanya tidak rumit . Kami telah menyusunnya khusus untuk mesh layanan. Jejaring lain lebih memilih proxy lain (Utusan adalah pilihan umum). Namun, memilih proxy hanyalah masalah implementasi.
Apa yang dilakukan server proxy ini? Tentu saja, mereka memproksi panggilan ke dan dari layanan (sebenarnya, mereka bertindak sebagai proksi dan membalikkan proksi, menangani panggilan masuk dan keluar). Dan mereka menerapkan serangkaian fitur yang berfokus pada panggilan antara jasa. Fokus pada lalu lintas antar layanan inilah yang membedakan proksi mesh layanan dari, katakanlah, gateway API atau proksi ingress (yang terakhir berfokus pada panggilan yang masuk ke dalam klaster dari dunia luar). (Catatan. terjemahan: Untuk perbandingan pengontrol Kubernetes Ingress yang ada, banyak di antaranya menggunakan Envoy yang telah disebutkan, lihat .)
Jadi, kami menemukan bidang datanya. Bidang kendali lebih sederhana: merupakan sekumpulan komponen yang menyediakan semua mekanisme yang dibutuhkan bidang data untuk bekerja secara terkoordinasi, termasuk penemuan layanan, penerbitan sertifikat TLS, agregasi metrik, dll. Bidang data memberi tahu bidang kendali tentang perilakunya; pada gilirannya, bidang kendali menyediakan API yang memungkinkan Anda mengubah dan melacak perilaku bidang data secara keseluruhan.
Di bawah ini adalah diagram bidang kendali dan bidang data di Linkerd. Seperti yang Anda lihat, bidang kendali mencakup beberapa komponen berbeda, termasuk instans Prometheus yang mengumpulkan metrik dari server proksi, serta komponen lain seperti destination (penemuan layanan), identity (otoritas sertifikat, CA) dan public-api (titik akhir untuk web dan CLI). Sebaliknya, bidang data adalah proxy linkerd sederhana di sebelah instance aplikasi. Ini hanyalah diagram logika; dalam penerapan dunia nyata, Anda mungkin memiliki tiga replika dari setiap komponen bidang kendali dan ratusan atau ribuan proxy di bidang data.
(Kotak biru pada diagram ini mewakili batas pod Kubernetes. Anda dapat melihat bahwa container dengan linkerd-proxy berada di pod yang sama dengan container aplikasi. Skema ini dikenal sebagai wadah sespan.)
Arsitektur layanan mesh memiliki beberapa implikasi penting. Pertama, karena tugas proxy adalah mencegat panggilan antar layanan, mesh layanan hanya masuk akal jika aplikasi Anda dibuat untuk sekumpulan layanan. jaring satu bisa digunakan dengan monolit, tapi ini jelas mubazir demi satu proxy, dan fungsinya sepertinya tidak akan dibutuhkan.
Konsekuensi penting lainnya adalah kebutuhan jaringan layanan sangat besar jumlah proxy. Faktanya, Linkerd merangkai proxy-linkerd ke setiap instance dari setiap layanan (implementasi lain menambahkan proxy ke setiap host/host/VM. Lagipula itu banyak sekali). Penggunaan proxy yang aktif itu sendiri membawa sejumlah komplikasi tambahan:
- Proksi di bidang data seharusnya cepat, karena untuk setiap panggilan ada beberapa panggilan ke proxy: satu di sisi klien, satu di sisi server.
- Juga, proxy harus kecil и ringan. Masing-masing akan menggunakan memori dan sumber daya CPU, dan konsumsi ini akan tumbuh secara linier seiring dengan aplikasi.
- Anda memerlukan mekanisme untuk menyebarkan dan memperbarui proxy dalam jumlah besar. Melakukannya secara manual bukanlah suatu pilihan.
Secara umum, mesh layanan terlihat seperti ini (setidaknya dari pandangan sekilas): Anda menyebarkan sekelompok proxy ruang pengguna yang "melakukan sesuatu" dengan lalu lintas internal antar layanan, dan menggunakan bidang kontrol untuk memantau dan mengelolanya.
Sudah waktunya untuk pertanyaan "Mengapa?"
Untuk apa jaring layanan?
Bagi mereka yang pertama kali menemukan ide service mesh, boleh dimaafkan jika merasa sedikit kagum. Desain mesh layanan berarti tidak hanya akan meningkatkan latensi aplikasi, tetapi juga akan meningkatkan mengkonsumsi sumber daya dan akan ditambahkan sekelompok mekanisme baru dalam infrastruktur. Pertama, Anda menyiapkan mesh layanan, dan kemudian Anda tiba-tiba merasa perlu melayani ratusan (jika tidak ribuan) proxy. Pertanyaannya adalah, siapa yang akan menjadi sukarelawan untuk hal ini?
Jawaban atas pertanyaan ini memiliki dua bagian. Pertama, biaya transaksi yang terkait dengan penerapan proxy ini dapat dikurangi secara signifikan karena beberapa perubahan yang terjadi di ekosistem (lebih lanjut tentang ini nanti).
Kedua, perangkat semacam itu sebenarnya merupakan cara yang bagus untuk memasukkan logika tambahan ke dalam sistem. Dan bukan hanya karena banyak fitur baru yang dapat ditambahkan menggunakan mesh layanan, tetapi juga karena hal tersebut dapat dilakukan tanpa mengganggu ekosistem. Faktanya, seluruh model jaringan layanan didasarkan pada postulat ini: dalam sistem multilayanan, apa pun yang terjadi lakukan layanan individu, lalu lintas diantara mereka adalah titik ideal untuk menambahkan fungsionalitas.
Misalnya, di Linkerd (seperti di sebagian besar mesh) fungsionalitas difokuskan terutama pada panggilan HTTP, termasuk HTTP/2 dan gRPC*. Fungsionalitasnya cukup kaya - dapat dibagi menjadi tiga kelas:
- Fitur terkait keandalan. Permintaan percobaan ulang, batas waktu, pendekatan canary (pembagian/pengalihan lalu lintas), dll.
- Fitur terkait pemantauan. Agregasi tingkat keberhasilan, penundaan, dan volume permintaan untuk setiap layanan atau tujuan individual; membangun peta topologi layanan, dll.
- Fitur terkait keamanan. Saling TLS, kontrol akses, dll.
* Dari sudut pandang Linkerd, gRPC secara praktis tidak berbeda dengan HTTP/2: ia hanya menggunakan protobuf di payloadnya. Dari sudut pandang pengembang, kedua hal ini tentu saja berbeda.
Banyak dari mekanisme ini beroperasi pada tingkat permintaan (karenanya disebut "proxy L7"). Misalnya, jika layanan Foo membuat panggilan HTTP ke layanan Bar, proxy-linkerd di sisi Foo dapat dengan cerdas melakukan penyeimbangan beban dan merutekan panggilan dari instans Foo ke Bar berdasarkan latensi yang diamati; ia dapat mengulangi permintaan tersebut jika perlu (dan jika idempoten); dia dapat mencatat kode respons dan batas waktu, dan seterusnya. Demikian pula, proxy-linkerd di sisi Bar dapat menolak permintaan jika tidak diizinkan atau jika batas permintaan terlampaui; dapat memperbaiki penundaan di pihaknya, dll.
Proxy juga dapat “melakukan sesuatu” pada tingkat koneksi. Misalnya, proxy-linkerd di sisi Foo dapat memulai koneksi TLS, dan proxy-linkerd di sisi Bar dapat menghentikannya, dan kedua belah pihak dapat saling memverifikasi sertifikat TLS*. Hal ini tidak hanya memberikan enkripsi antar layanan, tetapi juga cara yang aman secara kriptografis untuk mengidentifikasi layanan: Foo dan Bar dapat "membuktikan" bahwa layanan tersebut memang sesuai dengan apa yang mereka katakan.
* "Teman dari teman" berarti sertifikat klien juga terverifikasi (saling TLS). Dalam TLS "klasik", misalnya, antara browser dan server, sertifikat hanya satu sisi (server) biasanya diverifikasi.
Apakah mereka beroperasi pada tingkat permintaan atau koneksi, penting untuk menekankan bahwa semua fitur mesh layanan beroperasi operasional karakter. Linkerd tidak dapat mengubah semantik payload, seperti menambahkan bidang ke fragmen JSON atau membuat perubahan pada protobuf. Kita akan membicarakan fitur penting ini nanti ketika kita berbicara tentang ESB dan middleware.
Ini adalah serangkaian fitur yang ditawarkan oleh jaring layanan. Timbul pertanyaan: mengapa tidak menerapkannya langsung di aplikasi? Dan mengapa harus mengacaukan proxy?
Mengapa jaring layanan adalah ide yang bagus
Meskipun kemampuan jaringan layanan sangat menawan, nilai utamanya tidak terletak pada fiturnya. Pada akhirnya kita Bisa mengimplementasikannya secara langsung dalam aplikasi (nanti kita akan melihat bahwa ini adalah asal usul mesh layanan). Singkatnya, nilai dari jaring layanan adalah: ini menyediakan fungsionalitas yang penting untuk menjalankan perangkat lunak server modern dengan cara yang konsisten, luas tumpukan, dan agnostik kode aplikasi.
Mari kita analisis proposal ini.
«Fungsi Penting untuk Menjalankan Perangkat Lunak Server Modern". Jika Anda sedang membangun aplikasi server transaksional yang terhubung ke internet publik yang menerima permintaan dari dunia luar dan meresponsnya dalam waktu singkat - misalnya, aplikasi web, server API, dan sebagian besar aplikasi modern lainnya - dan jika Anda mengimplementasikannya sebagai sekumpulan layanan yang berinteraksi secara sinkron satu sama lain, dan jika Anda terus meningkatkan perangkat lunak ini, menambahkan fitur baru, dan jika Anda terpaksa menjaga sistem ini tetap berfungsi selama proses modifikasi - dalam hal ini, selamat, Anda membuat perangkat lunak server modern. Dan semua fitur hebat yang tercantum di atas ternyata sangat penting bagi Anda. Aplikasi tersebut harus dapat diandalkan, aman, dan Anda harus dapat melihat apa yang dilakukannya. Pertanyaan-pertanyaan inilah yang dibantu oleh jaringan layanan untuk dipecahkan.
(Oke, keyakinan saya bahwa pendekatan ini adalah cara modern untuk membangun perangkat lunak server telah muncul di paragraf sebelumnya. Yang lain lebih suka mengembangkan monolit, "layanan mikro reaktif" dan hal-hal lain yang tidak termasuk dalam definisi yang diberikan di atas. Orang-orang ini mungkin punya pendapat yang berbeda dengan pendapat saya, dan pada gilirannya, saya yakin mereka "salah" - meskipun bagaimanapun juga, jaringan layanan tidak terlalu berguna bagi mereka).
«Seragam untuk seluruh tumpukan". Fitur-fitur yang disediakan oleh jaring layanan tidak hanya penting. Aturan ini berlaku untuk semua layanan dalam aplikasi, apa pun bahasa penulisannya, kerangka apa yang digunakan, siapa yang menulisnya, bagaimana penerapannya, dan semua seluk-beluk pengembangan dan penggunaannya.
«Kode aplikasi independen". Terakhir, mesh layanan tidak hanya menyediakan fungsionalitas yang konsisten di seluruh tumpukan, tetapi juga menyediakannya dengan cara yang tidak memerlukan pengeditan aplikasi. Dasar fundamental dari fungsionalitas mesh layanan, termasuk tugas konfigurasi, pembaruan, pengoperasian, pemeliharaan, dll., murni pada tingkat platform dan tidak bergantung pada aplikasi. Aplikasi dapat berubah tanpa mempengaruhi mesh layanan. Pada gilirannya, mesh layanan dapat berubah tanpa intervensi aplikasi apa pun.
Singkatnya, mesh layanan tidak hanya menyediakan fungsionalitas penting, namun juga melakukannya secara global, seragam, dan tidak bergantung pada aplikasi. Jadi, meskipun fungsionalitas mesh layanan dapat diimplementasikan dalam kode layanan (misalnya, sebagai perpustakaan yang disertakan dengan setiap layanan), pendekatan ini tidak akan memberikan keseragaman dan independensi yang sangat berharga dalam kasus mesh layanan. .
Dan yang perlu Anda lakukan hanyalah menambahkan banyak proxy! Saya berjanji, kami akan segera mempertimbangkan biaya operasional yang terkait dengan penambahan proxy ini. Namun pertama-tama, mari kita berhenti dan melihat gagasan kemerdekaan ini dari sudut pandang berbagai pihak orang-orang.
Siapa yang dibantu oleh jaring layanan?
Meskipun mungkin sulit, agar suatu teknologi menjadi bagian penting dari ekosistem, teknologi tersebut harus diterima oleh masyarakat. Jadi siapa yang tertarik dengan jaringan layanan? Siapa yang diuntungkan dari penggunaannya?
Jika Anda mengembangkan perangkat lunak server modern, secara kasar Anda dapat membayangkan tim Anda sebagai sebuah kelompok pemilik layananyang bersama-sama mengembangkan dan menerapkan logika bisnis, dan pemilik platformterlibat dalam pengembangan platform internal tempat layanan ini dijalankan. Dalam organisasi kecil, mereka bisa saja terdiri dari orang-orang yang sama, namun seiring pertumbuhan perusahaan, peran-peran ini cenderung menjadi lebih jelas dan bahkan terbagi menjadi beberapa sub-peran... (Ada banyak hal yang bisa dikatakan di sini tentang perubahan sifat devops, dampak organisasi dari layanan mikro, dll.) n. Namun untuk saat ini, anggap saja uraian ini sebagai hal yang wajar).
Dari sudut pandang ini, penerima manfaat yang jelas dari jaringan layanan adalah pemilik platform. Lagi pula, tujuan akhir dari tim platform adalah untuk menciptakan platform internal di mana pemilik layanan dapat menerapkan logika bisnis dan melakukannya dengan cara yang menjamin independensi maksimum mereka dari detail operasinya yang suram. Jaring layanan tidak hanya menawarkan kemampuan penting untuk mencapai tujuan ini, namun juga memberikannya sedemikian rupa sehingga, pada gilirannya, tidak menimbulkan ketergantungan pada pemilik layanan.
Pemilik layanan juga mendapatkan keuntungan, meskipun secara tidak langsung. Tujuan dari pemilik layanan adalah menjadi seproduktif mungkin dalam menerapkan logika proses bisnis, dan semakin sedikit ia khawatir tentang masalah operasional, semakin baik. Daripada menerapkan, katakanlah, kebijakan percobaan ulang atau TLS, mereka dapat fokus hanya pada bisnis dan berharap platform akan menangani sisanya. Bagi mereka, ini merupakan keuntungan besar.
Nilai organisasi dari pembagian antara pemilik platform dan layanan tidak dapat ditaksir terlalu tinggi. Saya pikir dia berkontribusi utama kontribusi terhadap nilai jaring layanan.
Kami mempelajari pelajaran ini ketika seorang penggemar awal Linkerd memberi tahu kami mengapa mereka memilih jaringan layanan: karena hal ini memungkinkan mereka untuk “terus berbicara seminimal mungkin.” Berikut beberapa detailnya: orang-orang dari satu perusahaan besar memigrasikan platform mereka ke Kubernetes. Karena aplikasi bekerja dengan informasi sensitif, mereka ingin mengenkripsi semua komunikasi di cluster. Namun situasi menjadi rumit dengan kehadiran ratusan layanan dan ratusan tim pengembangan. Prospek untuk menghubungi semua orang dan meyakinkan mereka untuk memasukkan dukungan untuk TLS dalam rencana mereka sama sekali tidak menyenangkan mereka. Dengan menginstal Linkerd, mereka bermigrasi tanggung jawab dari pengembang (yang dari sudut pandangnya hal ini merupakan masalah yang tidak perlu) hingga platformer, yang menganggap hal ini sebagai prioritas tingkat atas. Dengan kata lain, Linkerd memecahkan masalah teknis bagi mereka, bukan masalah organisasi.
Singkatnya, jaringan layanan bukanlah solusi teknis, melainkan solusi teknis sosio-teknis Masalah. (Terima kasih untuk memperkenalkan istilah ini.
Akankah jaringan layanan menyelesaikan semua masalah saya?
Ya. Maksudku, tidak!
Melihat tiga kelas fitur yang diuraikan di atas - keandalan, keamanan, dan kemampuan observasi - menjadi jelas bahwa mesh layanan bukanlah solusi lengkap untuk semua masalah ini. Meskipun Linkerd dapat mengirimkan permintaan berulang (jika diketahui bahwa permintaan tersebut idempoten), Linkerd tidak dalam posisi untuk membuat keputusan tentang apa yang akan dikembalikan kepada pengguna jika layanan akhirnya mati - keputusan seperti itu harus dibuat oleh aplikasi. Linkerd dapat menyimpan statistik permintaan yang berhasil, namun tidak dapat melihat layanan dan menyediakan metrik internalnya - aplikasi harus memiliki perangkat seperti itu. Meskipun Linkerd mampu menghosting mTLS, solusi keamanan lengkap memerlukan lebih banyak hal.
Sebagian fitur di area ini yang ditawarkan oleh jaringan layanan terkait dengan fitur platform. Maksud saya fungsi yang:
- Independen dari logika bisnis. Cara pembuatan histogram panggilan antara Foo dan Bar sepenuhnya tidak bergantung pada apakah mengapa Foo memanggil Bar.
- Sulit untuk diterapkan dengan benar. Di Linkerd, percobaan ulang diparameterisasi dengan segala macam hal mewah seperti anggaran percobaan ulang. (coba lagi anggaran), karena pendekatan yang sederhana terhadap pelaksanaan hal-hal seperti itu pasti akan menyebabkan munculnya apa yang disebut "longsoran permintaan" (coba lagi badai) dan masalah lain khusus untuk sistem terdistribusi.
- Paling efektif bila diterapkan secara konsisten. Mekanisme TLS hanya masuk akal jika diterapkan di mana saja.
Karena fitur-fitur ini diimplementasikan pada lapisan proxy (dan bukan pada lapisan aplikasi), mesh layanan memaparkannya pada platform, bukan aplikasi. Oleh karena itu, tidak menjadi masalah dalam bahasa apa layanan tersebut ditulis, kerangka apa yang digunakan, siapa yang menulisnya, dan mengapa. Proxy bekerja melampaui semua detail ini, dan dasar fundamental dari fungsi ini, termasuk tugas mengonfigurasi, memperbarui, mengoperasikan, memelihara, dll., hanya terletak pada tingkat platform.
Contoh kemampuan jaringan layanan
Singkatnya, mesh layanan bukanlah solusi lengkap untuk keandalan, observasi, atau keamanan. Cakupan area ini menyiratkan partisipasi wajib dari pemilik layanan, tim Ops/SRE, dan pemangku kepentingan perusahaan lainnya. Jaring layanan hanya menyediakan "potongan" pada tingkat platform untuk masing-masing area ini.
Mengapa jaringan layanan menjadi populer saat ini?
Anda mungkin bertanya-tanya saat ini: Oke, jika jaringan layanannya sangat bagus, mengapa kita tidak mulai menerapkan jutaan proxy di tumpukan sepuluh tahun yang lalu?
Ada jawaban yang dangkal untuk pertanyaan ini: sepuluh tahun yang lalu semua orang membangun monolit, dan tidak ada yang membutuhkan jaringan layanan. Ini benar, tetapi menurut saya, jawaban ini melenceng. Sepuluh tahun yang lalu, konsep layanan mikro sebagai cara yang menjanjikan untuk menciptakan sistem berskala besar telah banyak dibahas dan diterapkan di perusahaan seperti Twitter, Facebook, Google, dan Netflix. Persepsi umum - setidaknya di bagian industri yang pernah saya hubungi - adalah bahwa layanan mikro adalah "cara yang tepat" untuk membangun sistem besar, meskipun itu sangat sulit.
Tentu saja, meskipun ada perusahaan yang mengeksploitasi layanan mikro sepuluh tahun yang lalu, mereka tidak menempelkan proxy di mana pun mereka bisa untuk membentuk jaringan layanan. Namun, jika Anda perhatikan lebih dekat, mereka melakukan hal serupa: banyak dari perusahaan ini mewajibkan penggunaan perpustakaan internal khusus untuk jaringan (terkadang disebut perpustakaan klien gemuk, perpustakaan klien yang gemuk).
Netflix punya Hysterix, Google punya Stubby, Twitter punya perpustakaan Finagle. Finagle, misalnya, telah diwajibkan untuk setiap layanan baru di Twitter. Ini menangani koneksi sisi klien dan server, memungkinkan permintaan berulang, mendukung perutean permintaan, penyeimbangan beban, dan pengukuran. Ini memberikan lapisan keandalan dan kemampuan observasi yang konsisten di seluruh tumpukan Twitter, apa pun yang dilakukan layanan tersebut. Tentu saja, ini hanya berfungsi untuk bahasa JVM dan didasarkan pada model pemrograman yang harus digunakan untuk keseluruhan aplikasi. Namun, fungsinya hampir sama dengan jaringan layanan. (Sebenarnya, versi pertama Linkerd hanyalah Finagle yang dibungkus dalam bentuk proxy.)
Jadi, sepuluh tahun yang lalu tidak hanya ada layanan mikro, tetapi juga perpustakaan mesh layanan proto khusus yang memecahkan masalah yang sama dengan yang dipecahkan oleh mesh layanan saat ini. Namun, jaringan layanan itu sendiri belum ada pada saat itu. Harus ada perubahan lain sebelum dia muncul.
Dan di sinilah letak jawaban yang lebih mendalam, yang tersembunyi dalam perubahan lain yang terjadi selama 10 tahun terakhir: telah terjadi penurunan tajam dalam biaya penerapan layanan mikro. Perusahaan-perusahaan yang disebutkan di atas yang menggunakan layanan mikro satu dekade lalu—Twitter, Netflix, Facebook, Google—adalah perusahaan dengan skala besar dan sumber daya besar. Mereka tidak hanya memiliki kebutuhan, namun juga kemampuan untuk membangun, menyebarkan, dan mengoperasikan aplikasi besar berdasarkan layanan mikro. Energi dan upaya yang dilakukan para insinyur Twitter untuk beralih dari pendekatan monolitik ke pendekatan layanan mikro sungguh luar biasa. (Sejujurnya, faktanya itu berhasil.) Manuver infrastruktur semacam ini tidak mungkin dilakukan oleh perusahaan kecil.
Mari kita beralih ke masa kini. Saat ini ada startup yang rasio layanan mikro dan pengembangnya adalah 5:1 (atau bahkan ), dan terlebih lagi, mereka berhasil mengatasinya! Jika sebuah startup yang terdiri dari 5 orang mampu mengoperasikan 50 layanan mikro tanpa melelahkan, maka sesuatu jelas mengurangi biaya implementasinya.
1500 layanan mikro di Monzo; setiap baris adalah aturan jaringan yang ditentukan yang memungkinkan lalu lintas
Pengurangan dramatis dalam biaya pengoperasian layanan mikro adalah hasil dari satu proses: semakin populernya kontainer и orkestra. Inilah jawaban mendalam terhadap pertanyaan tentang apa yang berkontribusi terhadap munculnya jaringan jasa. Teknologi yang sama membuat layanan mesh dan layanan mikro menjadi menarik: Kubernetes dan Docker.
Mengapa? Nah, Docker memecahkan satu masalah besar - masalah pengemasan. Dengan mengemas aplikasi dan dependensi runtime (non-jaringan) dalam sebuah container, Docker mengubah aplikasi menjadi unit sepadan yang dapat dihosting dan dijalankan di mana saja. Pada saat yang sama, ini sangat menyederhanakan pengoperasian. multibahasa tumpukan: Karena sebuah container adalah unit eksekusi atom, tidak peduli apa yang ada di dalamnya, apakah itu aplikasi JVM, Node, Go, Python, atau Ruby, untuk tujuan penerapan dan operasional. Anda tinggal menjalankannya dan hanya itu.
Kubernetes membawa segalanya ke level berikutnya. Sekarang, karena terdapat banyak "hal yang dapat dieksekusi" dan banyak mesin untuk menjalankannya, diperlukan suatu alat yang dapat mencocokkannya satu sama lain. Dalam arti luas, Anda memberi Kubernetes banyak container dan banyak mesin, dan Kubernetes mencocokkannya satu sama lain (tentu saja, ini adalah proses yang dinamis dan terus berubah: container baru bergerak di sekitar sistem, mesin mulai dan berhenti, dll. Namun, Kubernetes memperhitungkan semua ini).
Setelah Kubernetes disiapkan, waktu yang diperlukan untuk menerapkan dan mengoperasikan satu layanan tidak jauh berbeda dengan biaya untuk menerapkan dan mengoperasikan sepuluh layanan (bahkan hampir sama untuk 100 layanan). Tambahkan ke container ini sebagai mekanisme pengemasan yang mendorong implementasi multibahasa, dan Anda akan memiliki banyak sekali aplikasi baru yang diimplementasikan sebagai layanan mikro yang ditulis dalam berbagai bahasa, jenis lingkungan yang sangat cocok untuk mesh layanan.
Jadi, kita sampai pada jawaban atas pertanyaan mengapa gagasan service mesh menjadi populer saat ini: keseragaman yang disediakan Kubernetes untuk layanan dapat diterapkan secara langsung pada tugas operasional yang dihadapi service mesh. Anda mengemas proxy dalam container, memberi Kubernetes tugas untuk menempelkannya sedapat mungkin, dan voila! Pada outputnya, Anda mendapatkan mesh layanan, sementara Kubernetes mengontrol semua mekanisme penerapannya. (Setidaknya dari pandangan sekilas. Tentu saja, ada banyak perbedaan dalam proses ini.)
Singkatnya: alasan mengapa layanan mesh menjadi populer sekarang dan bukan sepuluh tahun yang lalu adalah karena Kubernetes dan Docker tidak hanya meningkat secara signifikan membutuhkan di dalamnya, menyederhanakan implementasi aplikasi sebagai kumpulan layanan mikro multibahasa, namun juga berkurang secara signifikan biaya untuk pengoperasiannya dengan menyediakan mekanisme untuk menyebarkan dan memelihara taman proksi sespan.
Mengapa ada begitu banyak pembicaraan tentang jaringan layanan?
Peringatan: Di bagian ini, saya menggunakan segala macam asumsi, dugaan, rekayasa, dan informasi orang dalam.
Menelusuri "jaringan layanan" akan menghasilkan sekumpulan konten daur ulang, rendah kalori, proyek aneh, dan kaleidoskop distorsi yang layak untuk ruang gema. Setiap teknologi baru yang trendi memiliki hal ini, namun dalam kasus jaringan layanan, masalahnya sangat akut. Mengapa?
Yah, itu sebagian salahku. Saya telah melakukan yang terbaik untuk mempromosikan Linkerd dan layanannya di setiap kesempatan, melalui postingan blog dan artikel seperti ini yang tak terhitung jumlahnya. Tapi aku tidak sekuat itu. Untuk benar-benar menjawab pertanyaan ini, kita perlu membicarakan sedikit tentang situasi umum. Dan tidak mungkin membicarakan hal ini tanpa menyebutkan satu proyek: adalah jaringan layanan sumber terbuka yang dikembangkan bersama oleh Google, IBM, dan Lyft.
(Ketiga perusahaan tersebut memiliki peran yang sangat berbeda: keterlibatan Lyft tampaknya hanya sebatas nama saja; mereka membuat Envoy tetapi tidak menggunakan atau terlibat dalam pengembangan Istio. IBM terlibat dalam pengembangan Istio dan menggunakannya. Google sangat terlibat dalam pengembangan Istio. terlibat dalam pengembangan Istio, tapi sejauh yang saya tahu, sebenarnya tidak menggunakannya.)
Proyek Istio terkenal karena dua hal. Pertama, upaya pemasaran besar-besaran yang dilakukan Google, khususnya, dalam promosinya. Saya memperkirakan sebagian besar orang yang saat ini mengetahui konsep mesh layanan pertama kali mempelajarinya berkat Istio. Fitur kedua adalah seberapa buruk Istio diterima. Dalam hal ini, saya jelas merupakan pihak yang berkepentingan, tetapi berusaha untuk tetap seobjektif mungkin, saya tetap tidak bisa berbuat apa-apa , tidak terlalu spesifik (meskipun tidak unik: systemd terlintas dalam pikiran, ...) untuk proyek Sumber Terbuka.
(Dalam praktiknya, Istio tampaknya memiliki masalah tidak hanya pada kompleksitas dan UX, tetapi juga pada performa. Misalnya, selama dilakukan oleh pihak ketiga, para ahli menemukan situasi di mana latensi ekor Istio 100 kali lebih tinggi daripada latensi Linkerd, serta situasi dengan kekurangan sumber daya, ketika Linkerd terus berfungsi dengan sukses, dan Istio benar-benar berhenti bekerja.)
Mengesampingkan teori saya tentang mengapa hal ini terjadi, saya percaya bahwa hype yang luar biasa seputar jaringan layanan disebabkan oleh keterlibatan Google. Yakni kombinasi tiga faktor berikut:
- promosi obsesif Istio oleh Google;
- sikap tidak setuju dan kritis terhadap proyek;
- popularitas Kubernetes yang meroket baru-baru ini, yang ingatannya masih segar.
Bersama-sama, faktor-faktor ini menyatu menjadi suatu lingkungan yang memabukkan dan anoxic di mana kapasitas untuk melakukan penilaian rasional semakin berkurang, sehingga hanya menyisakan variasi yang aneh. .
Dari sudut pandang Linkerd, ini… Saya akan menggambarkannya sebagai berkah yang campur aduk. Maksud saya, sangat bagus bahwa jaringan layanan telah memasuki arus utama - yang tidak terjadi pada tahun 2016 ketika Linkerd pertama kali muncul dan sangat sulit untuk menarik perhatian orang pada proyek tersebut. Sekarang tidak ada masalah seperti itu! Namun kabar buruknya adalah situasi mesh layanan saat ini sangat membingungkan sehingga hampir tidak mungkin untuk mengetahui proyek mana yang benar-benar termasuk dalam kategori mesh layanan (apalagi mencari tahu mana yang terbaik untuk kasus penggunaan tertentu). Hal ini tentu saja menghalangi semua orang (dan tentunya dalam beberapa kasus Istio atau proyek lain lebih baik daripada Linkerd, karena Linkerd bukanlah solusi universal).
Dari sisi Linkerd, strategi kami adalah mengabaikan kebisingan, tetap fokus pada penyelesaian masalah nyata di masyarakat, dan pada dasarnya menunggu hingga hype tersebut mereda. Pada akhirnya, hype ini akan mereda dan kami dapat terus bekerja dengan damai.
Sampai saat itu tiba, kita semua harus bersabar.
Akankah jaring layanan bermanfaat bagi saya, seorang insinyur perangkat lunak sederhana?
Kuesioner berikut akan membantu menjawab pertanyaan ini:
Apakah Anda hanya menangani penerapan logika bisnis? Dalam hal ini, jaring layanan tidak akan berguna bagi Anda. Tentu saja, Anda mungkin tertarik dengannya, tetapi idealnya, mesh layanan tidak secara langsung memengaruhi apa pun di lingkungan Anda. Teruslah bekerja sesuai dengan bayaran Anda.
Apakah Anda mengelola platform di perusahaan yang menggunakan Kubernetes? Ya, dalam hal ini Anda memerlukan mesh layanan (tentu saja, jika Anda tidak menggunakan K8 hanya untuk menjalankan monolit atau pemrosesan batch - tetapi saya ingin bertanya mengapa Anda memerlukan K8). Kemungkinan besar, Anda akan menemukan diri Anda berada dalam situasi dengan banyak layanan mikro yang ditulis oleh orang berbeda. Mereka semua berinteraksi satu sama lain dan terikat dalam jalinan ketergantungan runtime, dan Anda perlu menemukan cara untuk mengatasi semua ini. Penggunaan Kubernetes memungkinkan Anda memilih mesh layanan "untuk Anda sendiri". Untuk melakukan ini, biasakan diri Anda dengan kemampuan dan fiturnya dan jawab pertanyaan apakah proyek yang tersedia cocok untuk Anda (saya sarankan memulai penelitian Anda dengan Linkerd).
Apakah Anda menjalankan platform untuk perusahaan yang TIDAK menggunakan Kubernetes tetapi menggunakan layanan mikro? Dalam hal ini, jaring layanan akan berguna bagi Anda, tetapi penggunaannya tidak sepele. Tentu saja Anda bisa meniru layanan mesh dengan menghosting banyak proxy, namun keunggulan penting Kubernetes justru terletak pada model penerapannya: memelihara proxy ini secara manual akan memerlukan lebih banyak waktu, tenaga, dan biaya.
Apakah Anda bertanggung jawab atas platform di perusahaan yang menangani monolit? Dalam hal ini, Anda mungkin tidak memerlukan jaring layanan. Jika Anda bekerja dengan monolit (atau bahkan kumpulan monolit) yang memiliki pola interaksi yang terdefinisi dengan baik dan jarang berubah, maka jaringan layanan tidak menawarkan banyak hal kepada Anda. Jadi kamu bisa mengabaikannya saja dan berharap itu hilang seperti mimpi buruk...
Kesimpulan
Mungkin, jaringan layanan masih belum bisa disebut sebagai “teknologi paling canggih di dunia” - kehormatan yang meragukan ini mungkin milik bitcoin atau AI. Mungkin dia masuk lima besar. Namun jika Anda menerobos lapisan kebisingan dan hiruk pikuk, menjadi jelas bahwa jaringan layanan membawa manfaat nyata bagi mereka yang membuat aplikasi di Kubernetes.
Saya ingin Anda mencoba Linkerd - menginstalnya di cluster Kubernetes (atau bahkan Minikube di laptop) dan Anda dapat melihat sendiri apa yang saya bicarakan.
FAQ
- Jika saya mengabaikan jaring layanan, apakah akan hilang?
- Saya pasti mengecewakan Anda: jaringan layanan sudah ada bersama kami untuk waktu yang lama.
— Tapi SAYA TIDAK INGIN menggunakan jaring layanan!
- Yah, itu tidak perlu! Baca saja kuesioner saya di atas untuk mengetahui apakah Anda setidaknya harus memahami dasar-dasarnya.
— Bukankah ESB/middleware lama yang bagus dengan saus baru?
- Jala layanan berhubungan dengan logika operasional, bukan semantik. bus layanan perusahaan (). Menjaga pemisahan ini membantu jaringan layanan menghindari nasib yang sama.
- Apa perbedaan mesh layanan dengan gateway API?
Ada sejuta artikel mengenai hal ini. Hanya Google.
Apakah Utusan merupakan jaringan layanan?
- Tidak, Utusan bukanlah jaring layanan, ini adalah server proxy. Ini dapat digunakan untuk mengatur mesh layanan (dan banyak lagi - ini adalah proxy tujuan umum). Namun dengan sendirinya, ini bukanlah jaringan layanan.
- Network Service Mesh - apakah ini mesh layanan?
- TIDAK. Terlepas dari namanya, ini bukanlah jaringan layanan (bagaimana Anda menyukai keajaiban pemasaran?).
- Akankah mesh layanan membantu sistem asinkron reaktif saya berdasarkan antrian pesan?
- Tidak, jaringan layanan tidak akan membantu Anda.
- Jaring layanan mana yang harus saya gunakan?
- , tidak perlu khawatir.
- Artikelnya jelek! / Penulis - di sabun!
— Silakan bagikan tautannya dengan semua teman Anda sehingga mereka dapat yakin akan hal ini!
Ucapan Terima Kasih
Seperti yang bisa Anda tebak dari judulnya, artikel ini terinspirasi oleh risalah fantastis Jay Kreps "". Saya bertemu Jay sepuluh tahun lalu saat melakukan wawancara di Linked In dan dia telah menjadi inspirasi bagi saya sejak saat itu.
Meskipun saya suka menyebut diri saya "pengembang Linkerd", kenyataannya saya lebih merupakan pengelola file README.md dalam sebuah proyek. Bekerja di Linkerd hari ini , , orang-orang, dan proyek ini tidak akan mungkin terwujud tanpa komunitas kontributor dan pengguna yang luar biasa.
Dan terakhir, terima kasih khusus kepada pencipta Linkerd, (primus antar pares), yang, bersama saya bertahun-tahun yang lalu, terjun langsung ke dalam semua keributan dengan jaringan layanan ini.
PS dari penerjemah
Baca juga di blog kami:
- «»;
- «»;
- «»;
- «»;
- «'.
Sumber: www.habr.com