Kami adalah departemen pengembangan teknologi ritel. Suatu ketika, manajemen mengatur tugas mempercepat perhitungan volumetrik dengan menggunakan Apache Ignite bersama dengan MSSQL, dan menunjukkan situs dengan ilustrasi yang indah dan contoh kode Java. Situs ini langsung menyukai Zero Deployment , deskripsi yang menjanjikan keajaiban: Anda tidak harus menggunakan kode Java atau Scala secara manual di setiap node di grid dan menyebarkan kembali setiap kali berubah. Dalam perjalanan kerja, ternyata Zero Deployment memiliki penggunaan khusus, fitur yang ingin saya bagikan. Di bawah refleksi kucing dan detail implementasi.
1. Pernyataan masalah
Inti dari masalah adalah sebagai berikut. Ada direktori titik penjualan untuk SalesPoint dan direktori produk Sku (Stock Keeping Unit). Titik penjualan memiliki atribut "tipe toko" dengan nilai "kecil" dan "besar". Bermacam-macam (daftar barang dari titik penjualan) terhubung (dimuat dari DBMS) ke setiap titik penjualan dan informasi disediakan bahwa produk yang ditentukan telah tanggal
dikecualikan dari bermacam-macam atau ditambahkan ke bermacam-macam.
Diperlukan untuk mengatur cache titik penjualan dan menyimpan informasi tentang barang yang terhubung selama sebulan di muka. Kompatibilitas dengan sistem pertempuran memerlukan simpul klien Ignite untuk mengunduh data, menghitung agregat jenis (tipe Toko, kode Produk, hari, jumlah titik penjualan) dan mengunggahnya kembali ke DBMS.
2. Studi literatur
Belum ada pengalaman, jadi saya mulai menari dari kompor. Yaitu, dengan ulasan publikasi.
Artikel 2016 Memperkenalkan Apache Ignite: Langkah-langkah pertama menyediakan tautan ke dokumentasi proyek Apache Ignite dan pada saat yang sama mencela untuk slurring. Saya membacanya beberapa kali, kejelasan tidak datang. Beralih ke tutorial memulai resmi, yang
optimis menjanjikan "Anda akan bangun dan berjalan dalam sekejap!". Saya mengerti pengaturan variabel lingkungan, menonton dua video Apache Ignite Essentials, ternyata tidak terlalu berguna untuk tugas spesifik saya. Saya berhasil meluncurkan Ignite dari baris perintah dengan file standar "example-ignite.xml", saya membangun Aplikasi Compute pertama menggunakan Maven. Aplikasi ini bekerja dan menggunakan Zero Deployment, sungguh indah!
Saya membaca lebih lanjut, dan di sana contohnya segera menggunakan affinityKey (dibuat sebelumnya melalui query SQL), dan bahkan BinaryObject misterius diterapkan:
IgniteCache<BinaryObject, BinaryObject> people = ignite.cache("Person").withKeepBinary();
Saya membaca sedikit : format biner sedikit refleksi, akses ke bidang objek dengan nama. Itu dapat membaca nilai dari suatu bidang tanpa benar-benar deserializing objek (menyimpan memori). Tetapi mengapa BinaryObject digunakan sebagai ganti Person, karena ada Zero Deployment? Mengapa IgniteCache <Key, Person> diterjemahkan ke dalam IgniteCache <BinaryObject, BinaryObject>? Belum jelas.
Saya membuat kembali Aplikasi Hitung untuk kasus saya. Kunci utama dari titik penjualan direktori di MSSQL didefinisikan sebagai [id] [int] BUKAN NULL, saya membuat cache dengan analogi
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")
Dalam xml-config saya menunjukkan bahwa cache dipartisi
<bean class="org.apache.ignite.configuration.CacheConfiguration"> <property name="name" value="spCache"/> <property name="cacheMode" value="PARTITIONED"/> </bean>
Pemisahan dengan titik penjualan mengasumsikan bahwa agregat yang diperlukan akan dibangun pada setiap node cluster untuk catatan salesPointCache di sana, setelah itu node klien akan melakukan penjumlahan akhir.
Saya membaca tutorial Aplikasi Ignite Compute Pertama , saya melakukannya dengan analogi. Pada setiap node cluster saya menjalankan IgniteRunnable (), sesuatu seperti ini:
@Override public void run() { SalesPoint sp=salesPointCache.get(spId); sp.calculateSalesPointCount(); .. }
Saya menambahkan agregasi dan mengunggah logika, dijalankan pada set data uji. Secara lokal, semuanya berfungsi di server pengembangan.
Saya meluncurkan dua server pengujian CentOs, tentukan alamat ip di default-config.xml, jalankan pada masing-masing
./bin/ignite.sh config/default-config.xml
Kedua node Ignite mulai dan saling bertemu. Saya menentukan alamat yang diperlukan dalam xml-config dari aplikasi klien, dimulai, menambahkan node ketiga ke topologi dan segera ada dua node lagi. Log berbunyi "ClassNotFoundException: model.SalesPoint" di baris
SalesPoint sp=salesPointCache.get(spId);
StackOverflow mengatakan penyebab kesalahan adalah bahwa server CentOs tidak memiliki kelas SalesPoint kustom. Tiba Jadi bagaimana Anda tidak perlu menyebarkan kode Java secara manual pada setiap node dan seterusnya? Atau apakah kode Java Anda bukan tentang SalesPoint?
Saya mungkin melewatkan sesuatu - lagi saya mulai mencari, membaca dan mencari lagi. Seiring waktu, ada perasaan bahwa saya membaca segala sesuatu tentang topik itu, tidak ada yang baru. Saat mencari, saya menemukan beberapa komentar menarik.
Valentin Kulichenko , Arsitek Utama di GridGain Systems, menanggapi StackOverflow, April 2016:
Model classes are not peer deployed, but you can use withKeepBinary() flag on the cache and query BinaryObjects. This way you will avoid deserialization on the server side and will not get ClassNotFoundException.
Pendapat otoritatif lainnya: Denis Magda , Direktur manajemen produk, GridGain Systems.
Sebuah artikel tentang Habré tentang microservices merujuk pada tiga artikel Denis Magda: Microservices Bagian I , Microservices Bagian II , Microservices Bagian III 2016-2017. Dalam artikel kedua, Denis menyarankan memulai simpul kluster melalui MaintenanceServiceNodeStartup.jar. Anda juga dapat menggunakan peluncuran dengan konfigurasi xml dan baris perintah, tetapi kemudian Anda perlu secara manual menempatkan kelas khusus pada setiap node gugus yang digunakan:
That's it. Start (..) node using MaintenanceServiceNodeStartup file or pass maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts. If you prefer the latter then make sure to build a jar file that will contain all the classes from java/app/common and java/services/maintenance directories. The jar has to be added to the classpath of every node where the service might be deployed.
Memang itu saja. Di sini ternyata, mengapa, format biner misterius ini!
3. SingleJar
Denis mengambil tempat pertama di peringkat pribadi saya, IMHO tutorial yang paling berguna dari semua yang tersedia. MicroServicesExample github- nya berisi contoh konfigurasi cluster node yang sudah jadi, yang dikompilasi tanpa squat tambahan.
Saya melakukannya dalam gambar dan rupa, saya mendapatkan file jar tunggal yang menjalankan "data node" atau "client node" tergantung pada argumen baris perintah. Perakitan dimulai dan dijalankan. Zero Deployment dikalahkan.
Transisi dari megabita data uji ke puluhan gigabita data pertempuran menunjukkan bahwa format biner ada karena alasan yang bagus. Itu diperlukan untuk mengoptimalkan konsumsi memori pada node, dan di sini BinaryObject sangat berguna.
4. Kesimpulan
Teguran pertama yang kami temui tentang dokumentasi cadel dari proyek Apache Ignite ternyata adil, itu telah berubah sedikit sejak 2016. Tidak mudah bagi pemula untuk membangun prototipe yang berfungsi berdasarkan situs dan / atau repositori.
Sebagai hasil dari pekerjaan yang dilakukan, tampaknya Zero Deployment berfungsi, tetapi hanya pada level sistem. Sesuatu seperti ini: BinaryObject digunakan untuk mengajarkan node cluster jarak jauh bagaimana bekerja dengan kelas kustom; Zero Deployment - Mekanisme Internal
Apache Menyalakan dirinya sendiri dan mendistribusikan objek sistem di seluruh cluster.
Saya harap pengalaman saya akan bermanfaat bagi pengguna baru Apache Ignite.