Service Mesh adalah pola arsitektur terkenal untuk mengintegrasikan layanan mikro dan bermigrasi ke infrastruktur cloud. Saat ini di dunia cloud-container cukup sulit untuk dilakukan tanpanya. Beberapa implementasi mesh layanan sumber terbuka sudah tersedia di pasar, namun fungsionalitas, keandalan, dan keamanannya tidak selalu memadai, terutama jika menyangkut kebutuhan perusahaan keuangan besar di seluruh negeri. Itu sebabnya kami di Sbertech memutuskan untuk menyesuaikan Service Mesh dan ingin berbicara tentang apa yang keren tentang Service Mesh, apa yang tidak begitu keren, dan apa yang akan kami lakukan untuk mengatasinya.
Popularitas pola Service Mesh semakin meningkat seiring dengan popularitas teknologi cloud. Ini adalah lapisan infrastruktur khusus yang menyederhanakan interaksi antara berbagai layanan jaringan. Aplikasi cloud modern terdiri dari ratusan atau bahkan ribuan layanan serupa, yang masing-masing dapat memiliki ribuan salinan.
Interaksi antara dan pengelolaan layanan ini merupakan tugas utama Service Mesh. Faktanya, ini adalah model jaringan dari banyak proxy, dikelola secara terpusat dan menjalankan serangkaian fungsi yang sangat berguna.
Di tingkat proxy (data plane):
- Menetapkan dan mendistribusikan kebijakan perutean dan penyeimbangan lalu lintas
- Distribusi kunci, sertifikat, token
- Pengumpulan telemetri, pembuatan metrik pemantauan
- Integrasi dengan infrastruktur keamanan dan pemantauan
Di tingkat bidang kendali:
- Menerapkan kebijakan perutean dan penyeimbangan lalu lintas
- Mengelola percobaan ulang dan batas waktu, mendeteksi node βmatiβ (pemutus sirkuit), mengelola kesalahan yang disuntikkan, dan memastikan ketahanan layanan melalui mekanisme lain
- Otentikasi/otorisasi panggilan
- Menghapus metrik (observabilitas)
Kisaran pengguna yang tertarik dengan pengembangan teknologi ini sangat luas - mulai dari startup kecil hingga perusahaan Internet besar, misalnya PayPal.
Mengapa Service Mesh dibutuhkan di sektor korporasi?
Ada banyak manfaat yang jelas menggunakan Service Mesh. Pertama-tama, ini nyaman bagi pengembang: untuk menulis kode sebuah platform teknologi muncul, yang secara signifikan menyederhanakan integrasi ke dalam infrastruktur cloud karena lapisan transport sepenuhnya terisolasi dari logika aplikasi.
Selain itu, Service Mesh menyederhanakan hubungan antara pemasok dan konsumen. Saat ini, jauh lebih mudah bagi penyedia API dan konsumen untuk menyetujui antarmuka dan kontrak mereka sendiri, tanpa melibatkan perantara dan penengah integrasi khusus - bus layanan perusahaan. Pendekatan ini secara signifikan mempengaruhi dua indikator. Kecepatan menghadirkan fungsionalitas baru ke pasar (time-to-market) meningkat, namun pada saat yang sama biaya solusi meningkat, karena integrasi harus dilakukan secara mandiri. Penggunaan Service Mesh oleh tim pengembangan fungsionalitas bisnis membantu menjaga keseimbangan di sini. Hasilnya, penyedia API dapat fokus secara eksklusif pada komponen aplikasi layanan mereka dan cukup mempublikasikannya di Service Mesh - API akan segera tersedia untuk semua klien, dan kualitas integrasi akan siap produksi dan tidak memerlukan satu pun baris kode tambahan.
Keuntungan berikutnya adalah itu pengembang, menggunakan Service Mesh, hanya berfokus pada fungsionalitas bisnis β pada produk dan bukan pada komponen teknologi dari layanannya. Misalnya, Anda tidak perlu lagi memikirkan fakta bahwa dalam situasi di mana layanan dipanggil melalui jaringan, kegagalan koneksi mungkin terjadi di suatu tempat. Selain itu, Service Mesh membantu menyeimbangkan lalu lintas antar salinan layanan yang sama: jika salah satu salinan βmatiβ, sistem akan mengalihkan semua lalu lintas ke salinan aktif yang tersisa.
Jaring Layanan - ini adalah dasar yang baik untuk membuat aplikasi terdistribusi, yang menyembunyikan dari klien rincian penyediaan panggilan ke layanannya baik secara internal maupun eksternal. Semua aplikasi yang menggunakan Service Mesh diisolasi pada tingkat transport baik dari jaringan maupun satu sama lain: tidak ada komunikasi di antara aplikasi tersebut. Dalam hal ini, pengembang menerima kendali penuh atas layanannya.
Perlu dicatat bahwa Memperbarui aplikasi terdistribusi di lingkungan mesh layanan menjadi lebih mudah. Misalnya, penerapan biru/hijau, yang mana dua lingkungan aplikasi tersedia untuk instalasi, salah satunya tidak diperbarui dan berada dalam mode siaga. Mengembalikan ke versi sebelumnya jika rilis gagal dilakukan oleh router khusus, yang perannya dapat diatasi dengan baik oleh Service Mesh. Untuk menguji versi baru, Anda dapat menggunakan pelepasan kenari β beralih ke versi baru hanya 10% lalu lintas atau permintaan dari grup klien percontohan. Lalu lintas utama menuju ke versi lama, tidak ada yang rusak.
Juga Service Mesh memberi kita kontrol SLA waktu nyata. Sistem proxy terdistribusi tidak akan membiarkan layanan gagal ketika salah satu klien melebihi kuota yang ditetapkan padanya. Jika throughput API terbatas, tidak ada yang bisa membanjirinya dengan sejumlah besar transaksi: Service Mesh berdiri di depan layanan dan tidak mengizinkan lalu lintas yang tidak perlu. Itu hanya akan melawan di lapisan integrasi, dan layanan itu sendiri akan terus bekerja tanpa menyadarinya.
Jika perusahaan ingin mengurangi biaya pengembangan solusi integrasi, Service Mesh juga membantu: Anda dapat beralih ke versi sumber terbuka dari produk komersial. Enterprise Service Mesh kami didasarkan pada Service Mesh versi sumber terbuka.
Keuntungan lain - ketersediaan satu set layanan integrasi yang lengkap. Karena seluruh integrasi dibangun melalui middleware ini, kita dapat mengatur semua lalu lintas integrasi dan koneksi antar aplikasi yang menjadi inti bisnis perusahaan. Sangat nyaman.
Dan akhirnya Service Mesh mendorong perusahaan untuk beralih ke infrastruktur yang dinamis. Sekarang banyak yang beralih ke containerisasi. Memotong monolit menjadi layanan mikro, mengimplementasikan semua ini dengan indah - topiknya sedang naik daun. Namun ketika Anda mencoba mentransfer sistem yang telah diproduksi selama bertahun-tahun ke platform baru, Anda langsung menemui sejumlah masalah: memasukkan semuanya ke dalam container dan menerapkannya pada platform tidaklah mudah. Dan implementasi, sinkronisasi, dan interaksi komponen terdistribusi ini merupakan topik lain yang sangat kompleks. Bagaimana mereka berkomunikasi satu sama lain? Apakah akan terjadi kegagalan berjenjang? Service Mesh memungkinkan Anda memecahkan beberapa masalah ini dan memfasilitasi migrasi dari arsitektur lama ke arsitektur baru karena Anda dapat melupakan logika pertukaran jaringan.
Mengapa Anda memerlukan kustomisasi Service Mesh?
Di perusahaan kami, ratusan sistem dan modul hidup berdampingan, dan runtimenya sangat padat. Jadi pola sederhana dari satu sistem memanggil sistem lain dan menerima respons tidaklah cukup, karena dalam produksi kita menginginkan lebih. Apa lagi yang Anda perlukan dari jaringan layanan perusahaan?
Layanan pemrosesan acara
Bayangkan kita perlu membuat pemrosesan peristiwa secara real-time - sebuah sistem yang menganalisis tindakan klien secara real-time dan dapat segera memberikan penawaran yang relevan kepadanya. Untuk mengimplementasikan fungsi serupa, gunakan pola arsitektur yang disebut arsitektur berbasis peristiwa (EDA). Tak satu pun dari Service Mesh saat ini yang secara asli mendukung pola seperti itu, namun ini sangat penting, terutama bagi bank!
Cukup aneh bahwa Panggilan Prosedur Jarak Jauh (RPC) didukung oleh semua versi Service Mesh, tetapi tidak bersahabat dengan EDA. Karena Service Mesh adalah semacam integrasi terdistribusi modern, dan EDA adalah pola arsitektur yang sangat relevan yang memungkinkan Anda melakukan hal-hal unik dalam hal pengalaman pelanggan.
Enterprise Service Mesh kami seharusnya mengatasi masalah ini. Selain itu, kami ingin melihat di dalamnya penerapan jaminan pengiriman, streaming, dan pemrosesan acara yang kompleks menggunakan berbagai filter dan templat.
Layanan transfer file
Selain EDA, alangkah baiknya jika dapat mentransfer file: pada skala Perusahaan, seringkali hanya integrasi file yang dapat dilakukan. Secara khusus, pola arsitektur ETL (Extract, Transform, Load) digunakan. Di dalamnya, sebagai suatu peraturan, setiap orang bertukar file secara eksklusif: data besar digunakan, yang tidak praktis untuk dimasukkan dalam permintaan terpisah. Kemampuan untuk mendukung transfer file secara native di Enterprise Service Mesh memberi Anda fleksibilitas yang dibutuhkan bisnis Anda.
Layanan orkestrasi
Organisasi besar hampir selalu memiliki tim berbeda yang membuat produk berbeda. Misalnya, di bank, beberapa tim menangani simpanan, sementara yang lain menangani produk pinjaman, dan kasus seperti itu cukup banyak. Ini adalah orang-orang yang berbeda, tim yang berbeda yang membuat produk mereka, mengembangkan API mereka dan memberikannya kepada orang lain. Dan seringkali ada kebutuhan untuk membuat layanan ini, serta mengimplementasikan logika kompleks untuk memanggil sekumpulan API secara berurutan. Untuk mengatasi masalah ini, Anda memerlukan solusi di lapisan integrasi yang akan menyederhanakan semua logika komposit ini (memanggil beberapa API, menjelaskan rute permintaan, dll.). Ini adalah layanan orkestrasi di Enterprise Service Mesh.
AI dan ML
Ketika layanan mikro berkomunikasi melalui satu lapisan integrasi, Service Mesh secara alami mengetahui segala sesuatu tentang setiap panggilan layanan. Kami mengumpulkan telemetri: siapa yang menelepon siapa, kapan, berapa lama, berapa kali, dan seterusnya. Ketika ada ratusan ribu layanan ini, dan miliaran panggilan, maka semua ini terakumulasi dan membentuk Big Data. Data ini dapat dianalisis menggunakan AI, pembelajaran mesin, dll., dan kemudian beberapa hal berguna dapat dilakukan berdasarkan hasil analisis tersebut. Sebaiknya setidaknya sebagian kendali atas semua lalu lintas jaringan dan panggilan aplikasi yang terintegrasi ke dalam Service Mesh ini diserahkan kepada kecerdasan buatan.
Layanan Gerbang API
Biasanya, Service Mesh memiliki proksi dan layanan yang berkomunikasi satu sama lain dalam batas tepercaya. Namun ada juga pihak eksternal. Persyaratan API yang diterapkan pada kelompok konsumen ini jauh lebih ketat. Kami membagi tugas ini menjadi dua bagian utama.
- keamanan. Masalah terkait ddos, kerentanan protokol, aplikasi, sistem operasi, dan sebagainya.
- Skala. Ketika jumlah API yang perlu dilayani ke klien mencapai ribuan atau bahkan ratusan ribu, diperlukan semacam alat manajemen untuk kumpulan API ini. Anda perlu terus memantau API: apakah berfungsi atau tidak, bagaimana statusnya, lalu lintas apa yang mengalir, statistik apa, dll. Gateway API harus menangani tugas ini sekaligus membuat seluruh proses dapat dikelola dan aman. Berkat komponen ini, Enterprise Service Mesh belajar mempublikasikan API internal dan eksternal dengan mudah.
Layanan dukungan untuk protokol dan format data tertentu (AS gateway)
Saat ini, sebagian besar solusi Service Mesh hanya dapat bekerja secara asli dengan lalu lintas HTTP dan HTTP2 atau dalam mode yang dikurangi di tingkat TCP/IP. Enterprise Service Mesh muncul dengan banyak protokol transfer data lain yang sangat spesifik. Beberapa sistem mungkin menggunakan perantara pesan, yang lain terintegrasi pada tingkat basis data. Jika perusahaan memiliki SAP, maka dapat juga menggunakan sistem integrasinya sendiri. Selain itu, semua ini berhasil dan merupakan bagian penting dari bisnis.
Anda tidak bisa hanya mengatakan: βMari kita tinggalkan sistem lama dan buat sistem baru yang dapat menggunakan Service Mesh.β Untuk menghubungkan semua sistem lama dengan yang baru (pada arsitektur layanan mikro), sistem yang dapat menggunakan Service Mesh memerlukan semacam adaptor, perantara, gateway. Setuju, alangkah baiknya jika disertakan dalam kotak beserta pelayanannya. Gerbang AC dapat mendukung opsi integrasi apa pun. Bayangkan saja, Anda baru saja menginstal Enterprise Service Mesh dan siap berinteraksi dengan semua protokol yang Anda perlukan. Pendekatan ini sangat penting bagi kami.
Ini kira-kira bagaimana kita membayangkan versi korporat dari Service Mesh (Enterprise Service Mesh). Kustomisasi yang dijelaskan memecahkan sebagian besar masalah yang muncul saat mencoba menggunakan versi platform integrasi sumber terbuka yang sudah jadi. Diperkenalkan beberapa tahun yang lalu, arsitektur Service Mesh terus berkembang, dan kami sangat senang dapat berkontribusi terhadap pengembangannya. Semoga pengalaman kami bermanfaat bagi Anda.
Sumber: www.habr.com