Pada tanggal 26 Februari, kami mengadakan pertemuan Apache Ignite GreenSource, di mana para kontributor proyek sumber terbuka berbicara . Peristiwa penting dalam kehidupan komunitas ini adalah restrukturisasi komponen , yang memungkinkan Anda menerapkan layanan mikro khusus langsung ke kluster Ignite. Dia berbicara tentang proses sulit ini pada pertemuan tersebut , insinyur perangkat lunak dan kontributor Apache Ignite selama lebih dari dua tahun.
Mari kita mulai dengan apa itu Apache Ignite secara umum. Ini adalah database yang merupakan penyimpanan Kunci/Nilai terdistribusi dengan dukungan untuk SQL, transaksionalitas, dan caching. Selain itu, Ignite memungkinkan Anda untuk menyebarkan layanan khusus langsung ke cluster Ignite. Pengembang memiliki akses ke semua alat yang disediakan Ignite - struktur data terdistribusi, Perpesanan, Streaming, Komputasi, dan Grid Data. Misalnya, saat menggunakan Data Grid, masalah pengelolaan infrastruktur terpisah untuk penyimpanan data dan, sebagai konsekuensinya, biaya overhead yang timbul akan hilang.
Dengan menggunakan Service Grid API, Anda dapat menerapkan layanan hanya dengan menentukan skema penerapan dan, karenanya, layanan itu sendiri dalam konfigurasi.
Biasanya, skema penerapan merupakan indikasi jumlah instans yang harus diterapkan pada node cluster. Ada dua skema penerapan yang umum. Yang pertama adalah Cluster Singleton: pada waktu tertentu, satu contoh layanan pengguna dijamin tersedia di cluster. Yang kedua adalah Node Singleton: satu contoh layanan disebarkan pada setiap node cluster.
Pengguna juga dapat menentukan jumlah instans layanan di seluruh cluster dan menentukan predikat untuk memfilter node yang sesuai. Dalam skenario ini, Service Grid sendiri akan menghitung distribusi optimal untuk menyebarkan layanan.
Selain itu, ada fitur seperti Affinity Service. Afinitas adalah fungsi yang mendefinisikan hubungan kunci dengan partisi dan hubungan pihak dengan node dalam topologi. Dengan menggunakan kunci tersebut, Anda dapat menentukan node utama tempat data disimpan. Dengan cara ini Anda dapat mengaitkan layanan Anda sendiri dengan cache kunci dan fungsi afinitas. Jika fungsi afinitas berubah, penempatan ulang otomatis akan terjadi. Dengan cara ini, layanan akan selalu ditempatkan dekat dengan data yang perlu dimanipulasi, dan, karenanya, mengurangi biaya tambahan dalam mengakses informasi. Skema ini bisa disebut semacam komputasi kolokasi.
Sekarang kita telah mengetahui keindahan Service Grid, mari kita bicara tentang sejarah perkembangannya.
Apa yang terjadi sebelumnya
Implementasi Service Grid sebelumnya didasarkan pada cache sistem replikasi transaksional Ignite. Kata "cache" di Ignite mengacu pada penyimpanan. Artinya, ini bukanlah sesuatu yang bersifat sementara, seperti yang mungkin Anda bayangkan. Terlepas dari kenyataan bahwa cache direplikasi dan setiap node berisi seluruh kumpulan data, di dalam cache ia memiliki representasi yang dipartisi. Hal ini disebabkan oleh optimalisasi penyimpanan.
Apa yang terjadi ketika pengguna ingin menerapkan layanan?
- Semua node di cluster berlangganan untuk memperbarui data di penyimpanan menggunakan mekanisme Kueri Berkelanjutan bawaan.
- Node yang memulai, dalam transaksi komitmen baca, membuat catatan dalam database yang berisi konfigurasi layanan, termasuk instance serial.
- Saat diberitahu ada entri baru, koordinator menghitung distribusi berdasarkan konfigurasi. Objek yang dihasilkan ditulis kembali ke database.
- Jika sebuah node merupakan bagian dari distribusi, koordinator harus menyebarkannya.
Apa yang tidak cocok untuk kita
Pada titik tertentu kami sampai pada kesimpulan: ini bukanlah cara bekerja dengan layanan. Ada beberapa alasan.
Jika terjadi kesalahan selama penerapan, maka kesalahan tersebut hanya dapat diketahui dari log node tempat semuanya terjadi. Hanya ada penerapan asinkron, jadi setelah mengembalikan kontrol ke pengguna dari metode penerapan, diperlukan beberapa waktu tambahan untuk memulai layanan - dan selama waktu ini pengguna tidak dapat mengontrol apa pun. Untuk mengembangkan Service Grid lebih lanjut, menciptakan fitur-fitur baru, menarik pengguna baru dan membuat hidup semua orang lebih mudah, ada sesuatu yang perlu diubah.
Saat merancang Service Grid baru, pertama-tama kami ingin memberikan jaminan penerapan yang sinkron: segera setelah pengguna mendapatkan kembali kendali dari API, ia dapat segera menggunakan layanan tersebut. Saya juga ingin memberi pemrakarsa kemampuan untuk menangani kesalahan penerapan.
Selain itu, saya ingin menyederhanakan implementasinya yaitu menjauhi transaksi dan melakukan rebalancing. Meskipun cache direplikasi dan tidak ada penyeimbangan, masalah muncul selama penerapan besar dengan banyak node. Ketika topologi berubah, node perlu bertukar informasi, dan dengan penerapan yang besar, data ini bisa sangat membebani.
Ketika topologi tidak stabil, koordinator perlu menghitung ulang distribusi layanan. Dan secara umum, ketika Anda harus menangani transaksi pada topologi yang tidak stabil, hal ini dapat menyebabkan kesalahan yang sulit diprediksi.
Masalah
Apakah perubahan global yang tidak disertai masalah? Yang pertama adalah perubahan topologi. Anda perlu memahami bahwa kapan saja, bahkan pada saat penerapan layanan, sebuah node dapat masuk atau keluar dari cluster. Selain itu, jika pada saat penerapan node bergabung dengan cluster, semua informasi tentang layanan harus ditransfer secara konsisten ke node baru. Dan kita tidak hanya berbicara tentang apa yang telah diterapkan, tetapi juga tentang penerapan saat ini dan di masa depan.
Ini hanyalah salah satu masalah yang dapat dikumpulkan dalam daftar terpisah:
- Bagaimana cara menyebarkan layanan yang dikonfigurasi secara statis saat startup node?
- Meninggalkan node dari cluster - apa yang harus dilakukan jika node tersebut menghosting layanan?
- Apa yang harus dilakukan jika koordinatornya berubah?
- Apa yang harus dilakukan jika klien terhubung kembali ke cluster?
- Apakah permintaan aktivasi/penonaktifan perlu diproses dan bagaimana caranya?
- Bagaimana jika mereka menyerukan penghancuran cache, dan kita memiliki layanan afinitas yang terkait dengannya?
Dan itu tidak semua.
keputusan
Sebagai sasarannya, kami memilih pendekatan Event Driven dengan penerapan proses komunikasi menggunakan pesan. Ignite sudah mengimplementasikan dua komponen yang memungkinkan node meneruskan pesan satu sama lain - spi komunikasi dan spi penemuan.
Communication-spi memungkinkan node untuk berkomunikasi secara langsung dan meneruskan pesan. Ini sangat cocok untuk mengirim data dalam jumlah besar. Discovery-spi memungkinkan Anda mengirim pesan ke semua node di cluster. Dalam implementasi standar, hal ini dilakukan dengan menggunakan topologi ring. Ada juga integrasi dengan Zookeeper, dalam hal ini digunakan topologi star. Hal penting lainnya yang perlu diperhatikan adalah Discovery-spi memberikan jaminan bahwa pesan pasti akan terkirim dalam urutan yang benar ke semua node.
Mari kita lihat protokol penerapannya. Semua permintaan pengguna untuk penerapan dan pembatalan penerapan dikirim melalui penemuan-spi. Ini memberikan yang berikut ini jaminan:
- Permintaan tersebut akan diterima oleh semua node di cluster. Ini akan memungkinkan permintaan untuk terus diproses ketika koordinator berubah. Ini juga berarti bahwa dalam satu pesan, setiap node akan memiliki semua metadata yang diperlukan, seperti konfigurasi layanan dan instance serialnya.
- Urutan pengiriman pesan yang ketat membantu menyelesaikan konflik konfigurasi dan permintaan yang bersaing.
- Karena entri node ke dalam topologi juga diproses melalui Discovery-spi, node baru akan menerima semua data yang diperlukan untuk bekerja dengan layanan.
Ketika permintaan diterima, node di cluster memvalidasinya dan membuat tugas pemrosesan. Tugas-tugas ini dimasukkan ke dalam antrean dan kemudian diproses di thread lain oleh pekerja terpisah. Hal ini diterapkan dengan cara ini karena penerapan dapat memakan banyak waktu dan menunda aliran penemuan yang mahal.
Semua permintaan dari antrian diproses oleh manajer penerapan. Ia memiliki pekerja khusus yang mengambil tugas dari antrian ini dan menginisialisasinya untuk memulai penerapan. Setelah ini, tindakan berikut terjadi:
- Setiap node secara independen menghitung distribusi berkat fungsi penugasan deterministik baru.
- Node menghasilkan pesan dengan hasil penerapan dan mengirimkannya ke koordinator.
- Koordinator mengumpulkan semua pesan dan menghasilkan hasil dari seluruh proses penerapan, yang dikirim melalui Discovery-spi ke semua node di cluster.
- Ketika hasilnya diterima, proses penerapan berakhir, setelah itu tugas dihapus dari antrian.
Desain berbasis peristiwa baru: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Jika terjadi kesalahan selama penerapan, node segera menyertakan kesalahan ini dalam pesan yang dikirimkan ke koordinator. Setelah agregasi pesan, koordinator akan mendapatkan informasi tentang semua kesalahan selama penerapan dan akan mengirimkan pesan ini melalui penemuan-spi. Informasi kesalahan akan tersedia di node mana pun di cluster.
Semua kejadian penting di Service Grid diproses menggunakan algoritma operasi ini. Misalnya mengubah topologi juga pesan melalui penemuan-spi. Dan secara umum, jika dibandingkan dengan sebelumnya, protokol ini ternyata cukup ringan dan dapat diandalkan. Cukup untuk menangani situasi apa pun selama penerapan.
Apa yang akan terjadi selanjutnya
Sekarang tentang rencananya. Setiap perubahan besar pada proyek Ignite diselesaikan sebagai inisiatif peningkatan Ignite, yang disebut IEP. Desain ulang Service Grid juga memiliki IEP - dengan judul mengejek βGanti Oli di Jaringan Pelayananβ. Namun nyatanya kami tidak mengganti oli mesin, melainkan seluruh mesin.
Kami membagi tugas di IEP menjadi 2 tahap. Yang pertama adalah fase besar, yang terdiri dari pengerjaan ulang protokol penerapan. Sudah termasuk di master, Anda bisa mencoba Service Grid baru yang akan muncul di versi 2.8. Fase kedua mencakup banyak tugas lainnya:
- Penerapan ulang panas
- Versi layanan
- Peningkatan toleransi kesalahan
- Klien tipis
- Alat untuk memantau dan menghitung berbagai metrik
Terakhir, kami dapat memberi saran kepada Anda tentang Service Grid untuk membangun sistem yang toleran terhadap kesalahan dan ketersediaan tinggi. Kami juga mengundang Anda untuk mengunjungi kami di ΠΈ bagikan pengalaman Anda. Pengalaman Anda sangat penting bagi komunitas; ini akan membantu Anda memahami ke mana harus melangkah selanjutnya, bagaimana mengembangkan komponen di masa depan.
Sumber: www.habr.com