Service Mesh adalah pola arsitektur yang terkenal untuk mengintegrasikan layanan-layanan microser dan pindah ke infrastruktur cloud. Saat ini di dunia cloud-container, cukup sulit untuk melakukannya tanpanya. Beberapa implementasi mesh layanan open-source sudah tersedia di pasar, tetapi fungsionalitas, keandalan, dan keamanannya masih jauh dari cukup, terutama ketika menyangkut persyaratan perusahaan keuangan besar di seluruh negeri. Oleh karena itu, kami di Sbertech memutuskan untuk menyesuaikan Service Mesh dan ingin berbicara tentang apa yang keren di Service Mesh, apa yang tidak terlalu dan apa yang akan kami lakukan dengannya.
Popularitas Templat Mesh Layanan tumbuh dengan popularitas teknologi cloud. Ini adalah lapisan infrastruktur khusus yang menyederhanakan interaksi antara berbagai layanan jaringan. Aplikasi cloud modern terdiri dari ratusan bahkan ribuan layanan seperti itu, yang masing-masingnya dapat memiliki ribuan salinan.
Interaksi antara layanan ini dan manajemennya adalah tugas utama dari Service Mesh. Sebenarnya, ini adalah model jaringan dari berbagai proxy, dikelola secara terpusat dan melakukan serangkaian fungsi yang sangat berguna.
Di tingkat proksi (bidang data):- Tetapkan dan sebarkan kebijakan perutean dan penyeimbangan lalu lintas
- Distribusi kunci, sertifikat, token
- Pengumpulan telemetri, pembentukan metrik pemantauan
- Integrasi dengan infrastruktur keamanan dan pemantauan
Di level kontrol pesawat:- Terapkan kebijakan perutean dan perataan lalu lintas
- Manajemen coba ulang dan batas waktu, definisi "mati" node (putus sirkuit), manajemen situasi yang salah (kesalahan penyuntikan) dan pemeliharaan ketahanan layanan melalui mekanisme lain
- Hubungi Otentikasi / Otorisasi
- Membuang metrik (kemampuan observasi)
Lingkaran pengguna yang tertarik pada pengembangan teknologi ini sangat luas - mulai dari perusahaan kecil hingga perusahaan Internet besar, misalnya, PayPal.
Untuk apa Service Mesh di sektor korporasi?
Menggunakan Service Mesh membawa banyak manfaat yang jelas. Pertama-tama, itu hanya nyaman bagi pengembang:
platform teknologi muncul untuk menulis kode yang secara signifikan menyederhanakan integrasi ke dalam infrastruktur cloud karena fakta bahwa lapisan transport sepenuhnya terisolasi dari logika aplikasi.
Selain itu,
Service Mesh menyederhanakan hubungan antara pemasok dan konsumen. Saat ini, jauh lebih mudah bagi pemasok dan konsumen API untuk menyetujui antarmuka dan kontrak sendiri, tanpa melibatkan perantara dan penengah integrasi khusus untuk ini - bus layanan perusahaan. Pendekatan ini secara signifikan mempengaruhi dua indikator. Kecepatan membawa fungsionalitas baru ke pasar (waktu-ke-pasar) meningkat, tetapi pada saat yang sama biaya solusi meningkat, karena integrasi harus dilakukan secara mandiri. Penggunaan Service Mesh oleh tim pengembangan bisnis membantu menjaga keseimbangan di sini. Akibatnya, penyedia API dapat fokus secara eksklusif pada komponen aplikasi layanan mereka dan cukup menerbitkannya di Service Mesh - API akan segera tersedia untuk semua pelanggan, dan kualitas integrasi akan siap produksi dan tidak akan memerlukan satu baris kode tambahan.
Keuntungan lain adalah bahwa
pengembang, menggunakan Service Mesh, hanya berfokus pada fungsionalitas bisnis - pada produk, dan bukan pada komponen teknologi dari layanannya. Misalnya, Anda tidak perlu memikirkan fakta bahwa dalam situasi di mana layanan akan dipanggil melalui jaringan, di suatu tempat koneksi mungkin terputus. Selain itu, Service Mesh membantu menyeimbangkan lalu lintas antara salinan dari layanan yang sama: jika salah satu salinan “mati”, sistem akan mengalihkan semua lalu lintas ke salinan langsung yang tersisa.
Service Mesh adalah
fondasi yang baik untuk membuat aplikasi terdistribusi , yang menyembunyikan dari klien rincian memberikan panggilan ke layanannya baik secara internal maupun eksternal. Semua aplikasi yang menggunakan Service Mesh terisolasi pada lapisan transport baik dari jaringan dan dari satu sama lain: tidak ada koneksi di antara mereka. Dalam hal ini, pengembang mendapat kontrol penuh atas layanan mereka.
Perlu dicatat bahwa
memperbarui aplikasi yang didistribusikan di lingkungan di mana Service Mesh digunakan menjadi lebih mudah. Misalnya, penyebaran biru / hijau, di mana dua lingkungan aplikasi tersedia untuk instalasi, salah satunya tidak diperbarui dan berada dalam mode siaga. Kembalikan ke versi sebelumnya jika perilisan yang gagal dilakukan oleh router khusus, peran yang ditangani oleh Service Mesh dengan sempurna
. Anda dapat menggunakan
rilis kenari untuk berjalan di versi baru - alihkan hanya 10% dari lalu lintas atau permintaan dari kelompok klien percontohan ke versi baru. Lalu lintas utama menuju ke versi lama, tidak ada yang rusak.
Service Mesh juga memberi kami kontrol SLA real-time . Sistem proxy terdistribusi tidak akan memungkinkan untuk membanjiri layanan ketika salah satu klien melebihi kuota yang dikeluarkan untuk itu. Jika bandwidth API terbatas, tidak ada yang akan dapat mencekiknya dengan sejumlah besar transaksi: Service Mesh berada di depan layanan dan tidak memungkinkan lalu lintas tambahan. Itu hanya akan mengalahkan 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 open-source dari produk komersial . Enterprise Service Mesh kami didasarkan pada versi open-source dari Service Mesh.
Keuntungan lain adalah
ketersediaan satu set layanan integrasi penuh . Karena semua integrasi dibangun melalui lapisan perantara ini, kami dapat mengelola semua lalu lintas integrasi dan koneksi antara aplikasi yang membentuk inti bisnis perusahaan. Sangat nyaman.
Akhirnya,
Service Mesh mendorong perusahaan untuk beralih ke infrastruktur yang dinamis. Sekarang banyak yang melihat ke arah peti kemas. Melihat monolith ke dalam layanan mikro, sangat indah untuk mengimplementasikan semuanya - topiknya sedang naik daun. Tetapi ketika Anda mencoba untuk mentransfer ke trek baru sistem yang telah diproduksi selama bertahun-tahun, Anda segera menghadapi sejumlah masalah: memasukkan semuanya ke dalam wadah dan menempatkannya di platform tidak mudah. Dan implementasi, sinkronisasi dan interaksi komponen-komponen yang didistribusikan ini adalah topik sulit lainnya. Bagaimana mereka akan berkomunikasi satu sama lain? Apakah akan ada kegagalan berjenjang? Service Mesh memungkinkan Anda untuk menyelesaikan beberapa masalah ini dan memfasilitasi migrasi dari arsitektur lama ke yang baru karena Anda dapat melupakan logika pertukaran jaringan.
Mengapa menyesuaikan Service Mesh
Di perusahaan kami, ratusan sistem dan modul saling berdampingan, dan runtime sangat sibuk. Jadi pola sederhana, ketika satu sistem memanggil yang lain dan menerima jawaban, tidak cukup, karena dalam produksi kita menginginkan lebih. Apa lagi yang Anda butuhkan dari Service Mesh perusahaan?
Layanan Pemrosesan Acara
Bayangkan bahwa kita perlu membuat pemrosesan peristiwa waktu-nyata - sebuah sistem yang menganalisis tindakan klien secara langsung dan dapat segera membuatnya menjadi penawaran yang relevan. Untuk mengimplementasikan fungsi ini, sebuah
pola arsitektur yang disebut event-driven architecture (EDA) digunakan . Tidak ada satu pun dari Service Mesh yang relevan yang secara alami mendukung pola tersebut, tetapi ini sangat penting, terutama bagi bank!
Sungguh aneh bahwa Remote Procedure Call (RPC) mendukung semua versi Service Mesh, dan mereka tidak berteman dengan EDA. Karena Service Mesh adalah kemiripan integrasi terdistribusi modern, dan EDA adalah pola arsitektur yang sangat relevan yang memungkinkan Anda melakukan hal-hal unik dalam hal pengalaman pelanggan.
Mesh Layanan Perusahaan kami harus menyelesaikan masalah ini. Selain itu, kami ingin melihat di dalamnya implementasi pengiriman yang dijamin, streaming, dan pemrosesan acara terintegrasi menggunakan berbagai filter dan template.
Layanan transfer file
Selain EDA, alangkah baiknya untuk dapat mentransfer file: pada skala Perusahaan, sangat sering hanya integrasi file yang dimungkinkan. Secara khusus, pola arsitektur ETL digunakan (Ekstrak, Transformasi, Muat - “ekstrak, transformasi, muat”). Di dalamnya, sebagai suatu peraturan, setiap orang bertukar file secara eksklusif: mereka menggunakan data besar, yang tidak praktis untuk didorong dalam permintaan terpisah. Kemampuan untuk secara asli mendukung transfer file di Enterprise Service Mesh menyediakan fleksibilitas kebutuhan bisnis.
Layanan Orkestrasi
Dalam organisasi besar, hampir selalu ada tim yang berbeda yang membuat produk yang berbeda. Misalnya, di bank, beberapa tim bekerja dengan deposito, sementara yang lain bekerja dengan produk kredit, dan ada banyak kasus seperti itu. Ini adalah orang-orang yang berbeda, tim yang berbeda yang membuat produk mereka, mengembangkan API mereka dan menyediakannya kepada orang lain. Dan sangat sering ada kebutuhan untuk komposisi layanan ini, serta penerapan logika kompleks panggilan sekuensial dari set API. Untuk mengatasi masalah ini, diperlukan 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 microser berkomunikasi melalui satu lapisan integrasi, Service Mesh, tentu saja, tahu segalanya tentang panggilan masing-masing layanan. Kami mengumpulkan telemetri: siapa yang memanggil siapa, kapan, berapa lama, berapa kali, dan sebagainya. Ketika ada ratusan ribu layanan ini dan miliaran panggilan, semua ini terakumulasi dan membentuk Big Data. Data-data ini dapat dianalisis menggunakan AI, pembelajaran mesin, dll., Dan kemudian melakukan beberapa hal berguna berdasarkan hasil analisis. Ini akan sesuai untuk setidaknya sebagian mentransfer ke kecerdasan buatan manajemen semua lalu lintas jaringan dan panggilan aplikasi yang terintegrasi ke dalam Service Mesh.
Layanan API Gateway
Sebagai aturan, Service Mesh memiliki proksi dan layanan yang saling mengakses di dalam perimeter tepercaya. Tetapi ada juga rekanan eksternal. Persyaratan API untuk grup konsumen ini jauh lebih serius. Kami membagi tugas ini menjadi dua bagian utama.
- Keamanan Masalah yang terkait dengan ddos, kerentanan protokol, aplikasi, sistem operasi dan sebagainya.
- Skalanya . Ketika tagihan API yang perlu diberikan kepada pelanggan mencapai ribuan atau bahkan ratusan ribu, ada kebutuhan untuk beberapa cara untuk mengelola set API ini. Anda harus terus memantau API: apakah berfungsi atau tidak, dalam status apa, lalu lintas apa yang sedang terjadi, statistik apa, dll. Gateway API harus menangani tugas ini, membuat seluruh proses dapat dikelola dan aman. Berkat komponen ini, Enterprise Service Mesh belajar mempublikasikan API internal dan eksternal tanpa kesulitan terlalu banyak.
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 terpotong di tingkat TCP / IP. Enterprise Service Mesh memiliki banyak protokol transfer data yang sangat spesifik. Beberapa sistem dapat menggunakan pialang pesan, yang lain terintegrasi di tingkat basis data. Jika perusahaan memiliki SAP, maka ia juga dapat menggunakan sistem integrasi sendiri. Dan semua ini bekerja dan merupakan bagian penting dari bisnis.
Anda tidak bisa hanya mengatakan: "Mari kita tinggalkan warisan dan membuat sistem baru yang dapat menggunakan Service Mesh." Untuk berteman dari semua sistem lama dengan yang baru (pada arsitektur microservice), sistem yang dapat menggunakan Service Mesh akan membutuhkan semacam adaptor, perantara, dan gateway. Setuju, akan lebih baik jika dikirim dalam kotak bersama dengan layanan. Gateway AS dapat mendukung opsi integrasi apa pun. Bayangkan saja, Anda cukup menginstal Enterprise Service Mesh, dan siap untuk berinteraksi dengan semua protokol yang Anda butuhkan. Bagi kami, pendekatan ini sangat penting.
Ini adalah bagaimana kami menyajikan versi perusahaan Service Mesh (Enterprise Service Mesh). Kustomisasi yang dijelaskan memecahkan sebagian besar masalah yang muncul ketika mencoba menggunakan versi open-source platform integrasi yang sudah jadi. Setelah muncul beberapa tahun yang lalu, arsitektur Service Mesh terus berkembang, dan kami senang bahwa kami dapat berkontribusi untuk pengembangannya. Kami berharap pengalaman kami akan bermanfaat bagi Anda.