Hai Habr!
Kami mengingatkan anda bahawa mengikuti buku tentang kami telah menerbitkan karya yang sama menarik tentang perpustakaan .
Buat masa ini, komuniti hanya mempelajari had alat berkuasa ini. Oleh itu, satu artikel telah diterbitkan baru-baru ini, terjemahan yang kami ingin perkenalkan kepada anda. Dari pengalamannya sendiri, penulis memberitahu cara menukar Kafka Streams menjadi storan data teragih. Selamat membaca!
perpustakaan Apache digunakan di seluruh dunia dalam perusahaan untuk pemprosesan strim teragih di atas Apache Kafka. Salah satu aspek yang kurang dihargai dalam rangka kerja ini ialah ia membolehkan anda menyimpan keadaan tempatan yang dihasilkan berdasarkan pemprosesan benang.
Dalam artikel ini, saya akan memberitahu anda bagaimana syarikat kami berjaya menggunakan peluang ini dengan menguntungkan apabila membangunkan produk untuk keselamatan aplikasi awan. Menggunakan Kafka Streams, kami mencipta perkhidmatan mikro negeri yang dikongsi, yang setiap satunya berfungsi sebagai sumber maklumat yang boleh dipercayai dan boleh dipercayai tentang keadaan objek dalam sistem yang tahan terhadap kesalahan dan sangat tersedia. Bagi kami, ini adalah satu langkah ke hadapan dari segi kebolehpercayaan dan kemudahan sokongan.
Jika anda berminat dengan pendekatan alternatif yang membolehkan anda menggunakan pangkalan data pusat tunggal untuk menyokong keadaan formal objek anda, bacalah, ia akan menjadi menarik...
Sebab kami fikir sudah tiba masanya untuk mengubah cara kami bekerja dengan keadaan kongsi
Kami perlu mengekalkan keadaan pelbagai objek berdasarkan laporan ejen (contohnya: adakah tapak diserang)? Sebelum berhijrah ke Kafka Streams, kami sering bergantung pada satu pangkalan data pusat (+ perkhidmatan API) untuk pengurusan negeri. Pendekatan ini mempunyai kelemahannya: mengekalkan konsistensi dan penyegerakan menjadi cabaran sebenar. Pangkalan data mungkin menjadi halangan atau berakhir dan mengalami ketidakpastian.
Rajah 1: Senario keadaan berpecah yang biasa dilihat sebelum peralihan kepada
Aliran Kafka dan Kafka: ejen menyampaikan pandangan mereka melalui API, keadaan dikemas kini dikira melalui pangkalan data pusat
Temui Kafka Streams, menjadikannya mudah untuk mencipta perkhidmatan mikro negeri yang dikongsi
Kira-kira setahun yang lalu, kami memutuskan untuk melihat dengan teliti senario negeri kami yang dikongsi untuk menangani isu ini. Kami segera memutuskan untuk mencuba Kafka Streams - kami tahu betapa berskala, sangat tersedia dan bertolak ansur terhadap kesalahan, fungsi penstriman yang kaya yang dimilikinya (transformasi, termasuk yang berstatus). Hanya apa yang kami perlukan, apatah lagi betapa matang dan boleh dipercayai sistem pemesejan di Kafka.
Setiap perkhidmatan mikro stateful yang kami cipta telah dibina di atas contoh Kafka Streams dengan topologi yang agak mudah. Ia terdiri daripada 1) sumber 2) pemproses dengan stor nilai kunci yang berterusan 3) sinki:
Rajah 2: Topologi lalai kejadian penstriman kami untuk perkhidmatan mikro stateful. Ambil perhatian bahawa terdapat juga repositori di sini yang mengandungi metadata perancangan.
Dalam pendekatan baharu ini, ejen mengarang mesej yang dimasukkan ke dalam topik sumber dan pengguna—katakan, perkhidmatan pemberitahuan mel—menerima keadaan kongsi yang dikira melalui sinki (topik output).
Rajah 3: Aliran tugas contoh baharu untuk senario dengan perkhidmatan mikro dikongsi: 1) ejen menjana mesej yang tiba di topik sumber Kafka; 2) perkhidmatan mikro dengan keadaan dikongsi (menggunakan Kafka Streams) memprosesnya dan menulis keadaan yang dikira ke topik Kafka terakhir; selepas itu 3) pengguna menerima keadaan baharu
Hei, kedai nilai kunci terbina dalam ini sebenarnya sangat berguna!
Seperti yang dinyatakan di atas, topologi keadaan kongsi kami mengandungi stor nilai kunci. Kami menemui beberapa pilihan untuk menggunakannya, dan dua daripadanya diterangkan di bawah.
Pilihan #1: Gunakan stor nilai kunci untuk pengiraan
Simpanan nilai kunci pertama kami mengandungi data tambahan yang kami perlukan untuk pengiraan. Sebagai contoh, dalam beberapa kes, negeri bersama ditentukan oleh prinsip "undi majoriti". Repositori boleh menyimpan semua laporan ejen terkini tentang status beberapa objek. Kemudian, apabila kami menerima laporan baharu daripada satu ejen atau yang lain, kami boleh menyimpannya, mendapatkan semula laporan daripada semua ejen lain tentang keadaan objek yang sama daripada storan dan mengulangi pengiraan.
Rajah 4 di bawah menunjukkan cara kami mendedahkan simpanan kunci/nilai kepada kaedah pemprosesan pemproses supaya mesej baharu kemudiannya boleh diproses.
Ilustrasi 4: Kami membuka akses kepada stor nilai kunci untuk kaedah pemprosesan pemproses (selepas ini, setiap skrip yang berfungsi dengan keadaan kongsi mesti melaksanakan kaedah tersebut doProcess)
Pilihan #2: Mencipta API CRUD di atas Strim Kafka
Setelah menetapkan aliran tugas asas kami, kami mula cuba menulis API CRUD RESTful untuk perkhidmatan mikro negeri kongsi kami. Kami mahu dapat mendapatkan semula keadaan beberapa atau semua objek, serta menetapkan atau mengalih keluar keadaan objek (berguna untuk sokongan bahagian belakang).
Untuk menyokong semua Get State API, apabila kami perlu mengira semula keadaan semasa pemprosesan, kami menyimpannya dalam stor nilai kunci terbina dalam untuk masa yang lama. Dalam kes ini, agak mudah untuk melaksanakan API sedemikian menggunakan satu contoh Kafka Streams, seperti yang ditunjukkan dalam penyenaraian di bawah:
Rajah 5: Menggunakan stor nilai kunci terbina dalam untuk mendapatkan keadaan objek yang diprakira
Mengemas kini keadaan objek melalui API juga mudah dilaksanakan. Pada asasnya, semua yang anda perlu lakukan ialah mencipta pengeluar Kafka dan menggunakannya untuk membuat rekod yang mengandungi keadaan baharu. Ini memastikan bahawa semua mesej yang dijana melalui API akan diproses dengan cara yang sama seperti yang diterima daripada pengeluar lain (cth ejen).
Rajah 6: Anda boleh menetapkan keadaan objek menggunakan pengeluar Kafka
Komplikasi kecil: Kafka mempunyai banyak partition
Seterusnya, kami ingin mengagihkan beban pemprosesan dan meningkatkan ketersediaan dengan menyediakan kluster perkhidmatan mikro keadaan kongsi bagi setiap senario. Persediaan adalah mudah: sebaik sahaja kami mengkonfigurasi semua kejadian untuk dijalankan di bawah ID aplikasi yang sama (dan pelayan bootstrap yang sama), hampir semua yang lain dilakukan secara automatik. Kami juga menyatakan bahawa setiap topik sumber akan terdiri daripada beberapa partition, supaya setiap kejadian boleh diberikan subset partition tersebut.
Saya juga akan menyebut bahawa adalah amalan biasa untuk membuat salinan sandaran stor negeri supaya, sebagai contoh, dalam kes pemulihan selepas kegagalan, pindahkan salinan ini ke contoh lain. Untuk setiap kedai negeri dalam Kafka Streams, topik yang direplikasi dibuat dengan log perubahan (yang menjejaki kemas kini setempat). Oleh itu, Kafka sentiasa menyokong kedai negeri. Oleh itu, sekiranya berlaku kegagalan satu atau satu contoh Aliran Kafka yang lain, stor keadaan boleh dipulihkan dengan cepat pada contoh lain, di mana partition yang sepadan akan pergi. Ujian kami telah menunjukkan bahawa ini dilakukan dalam beberapa saat, walaupun terdapat berjuta-juta rekod dalam kedai.
Beralih daripada perkhidmatan mikro tunggal dengan keadaan dikongsi kepada sekumpulan perkhidmatan mikro, ia menjadi kurang penting untuk melaksanakan API Get State. Dalam situasi baharu, stor keadaan setiap perkhidmatan mikro hanya mengandungi sebahagian daripada gambar keseluruhan (objek yang kuncinya dipetakan pada partition tertentu). Kami terpaksa menentukan contoh yang mengandungi keadaan objek yang kami perlukan, dan kami melakukan ini berdasarkan metadata benang, seperti yang ditunjukkan di bawah:
Rajah 7: Menggunakan metadata aliran, kami menentukan dari contoh mana untuk menanyakan keadaan objek yang dikehendaki; pendekatan yang sama telah digunakan dengan GET ALL API
Penemuan Utama
Kedai negeri di Kafka Streams boleh berfungsi sebagai pangkalan data yang diedarkan secara de facto,
- sentiasa direplikasi dalam Kafka
- API CRUD boleh dibina dengan mudah di atas sistem sedemikian
- Mengendalikan berbilang partition adalah sedikit lebih rumit
- Ia juga mungkin untuk menambah satu atau lebih stor negeri pada topologi penstriman untuk menyimpan data tambahan. Pilihan ini boleh digunakan untuk:
- Penyimpanan jangka panjang data yang diperlukan untuk pengiraan semasa pemprosesan strim
- Penyimpanan data jangka panjang yang mungkin berguna apabila tika penstriman diperuntukkan seterusnya
- banyak lagi...
Kelebihan ini dan lain-lain menjadikan Kafka Streams sangat sesuai untuk mengekalkan keadaan global dalam sistem teragih seperti kami. Kafka Streams telah terbukti sangat dipercayai dalam pengeluaran (kami hampir tidak mengalami kehilangan mesej sejak menggunakannya), dan kami yakin keupayaannya tidak akan berhenti di situ!
Sumber: www.habr.com