Meskipun saya telah menemukan Kafka sebelumnya, saya baru-baru ini menyadari Kafka mungkin dapat digunakan sebagai (dasar) CQRS , eventstore .

Salah satu poin utama yang didukung Kafka:

• Acara menangkap / menyimpan, semua HA tentu saja.
• Arsitektur pub / sub
• Kemampuan untuk memutar ulang eventlog yang memungkinkan kemampuan bagi pelanggan baru untuk mendaftar dengan sistem setelah fakta.

Memang saya tidak 100% berpengalaman dalam CQRS / Sumber acara tetapi ini tampaknya cukup dekat dengan apa yang seharusnya menjadi toko acara. Lucunya adalah: Saya benar-benar tidak dapat menemukan banyak tentang Kafka yang digunakan sebagai toko acara, jadi mungkin saya kehilangan sesuatu.

Jadi, ada yang hilang dari Kafka untuk itu menjadi toko acara yang bagus? Apakah ini akan berhasil? Menggunakannya produksi? Tertarik pada wawasan, tautan, dll.

Pada dasarnya keadaan sistem disimpan berdasarkan pada transaksi / peristiwa yang pernah diterima sistem, bukan hanya menyimpan keadaan saat ini / snapshot dari sistem yang biasanya dilakukan. (Anggap saja sebagai Buku Besar Akuntansi: semua transaksi pada akhirnya mencapai kondisi akhir) Hal ini memungkinkan semua jenis hal keren, tetapi baca saja tautan yang disediakan.

Kafka dimaksudkan untuk menjadi sistem pengiriman pesan yang memiliki banyak kemiripan dengan toko peristiwa namun mengutip intro mereka:

Cluster Kafka mempertahankan semua pesan yang dipublikasikan — baik dikonsumsi atau tidak — untuk jangka waktu yang dapat dikonfigurasi . Misalnya, jika retensi diatur selama dua hari, maka selama dua hari setelah pesan diterbitkan, itu tersedia untuk konsumsi, setelah itu akan dibuang untuk membebaskan ruang. Kinerja Kafka secara konstan konstan sehubungan dengan ukuran data sehingga mempertahankan banyak data tidak menjadi masalah.

Jadi, sementara pesan dapat berpotensi dipertahankan tanpa batas waktu, harapannya adalah bahwa pesan itu akan dihapus. Ini tidak berarti Anda tidak dapat menggunakan ini sebagai toko acara, tetapi mungkin lebih baik menggunakan sesuatu yang lain. Lihatlah EventStore untuk alternatifnya.

MEMPERBARUI

Dokumentasi Kafka :

Sumber acara adalah gaya desain aplikasi di mana perubahan negara dicatat sebagai urutan catatan yang terurut waktu. Dukungan Kafka untuk data log tersimpan sangat besar menjadikannya backend yang sangat baik untuk aplikasi yang dibangun dengan gaya ini.

PEMBARUAN 2

Salah satu perhatian dengan menggunakan Kafka untuk sumber acara adalah sejumlah topik yang diperlukan. Biasanya dalam sumber acara, ada aliran (topik) acara per entitas (seperti pengguna, produk, dll). Dengan cara ini, keadaan saat ini dari entitas dapat disusun kembali dengan menerapkan kembali semua peristiwa di aliran. Setiap topik Kafka terdiri dari satu atau lebih partisi dan setiap partisi disimpan sebagai direktori pada sistem file. Juga akan ada tekanan dari ZooKeeper karena jumlah znode meningkat.

Saya adalah salah satu penulis asli Kafka. Kafka akan bekerja dengan sangat baik sebagai log untuk sumber acara. Ini toleran terhadap kesalahan, skala untuk ukuran data yang sangat besar, dan memiliki model partisi yang dibangun.

Kami menggunakannya untuk beberapa kasus penggunaan formulir ini di LinkedIn. Misalnya sistem pemrosesan sumber terbuka kami, Apache Samza, dilengkapi dengan dukungan bawaan untuk sumber acara.

Saya pikir Anda tidak mendengar banyak tentang menggunakan Kafka untuk sumber acara terutama karena terminologi sumber acara tampaknya tidak terlalu lazim di ruang web konsumen di mana Kafka paling populer.

Saya telah menulis sedikit tentang gaya penggunaan Kafka di sini .

Saya terus kembali ke QA ini. Dan saya tidak menemukan jawaban yang ada cukup bernuansa, jadi saya menambahkan jawaban ini.

TL; DR. Ya atau Tidak, tergantung pada penggunaan sumber acara Anda.

Ada dua jenis utama sistem sumber acara yang saya sadari.

Prosesor acara hilir = Ya

Dalam sistem semacam ini, peristiwa terjadi di dunia nyata dan dicatat sebagai fakta. Seperti sistem gudang untuk melacak palet produk. Pada dasarnya tidak ada peristiwa yang saling bertentangan. Semuanya sudah terjadi, walaupun itu salah. (Yaitu palet 123456 memakai truk A, tetapi dijadwalkan untuk truk B.) Kemudian fakta diperiksa untuk pengecualian melalui mekanisme pelaporan. Kafka tampaknya sangat cocok untuk aplikasi pemrosesan acara seperti ini.

Dalam konteks ini, dapat dimengerti mengapa orang Kafka mengadvokasi itu sebagai solusi Event Sourcing. Karena sangat mirip dengan cara penggunaannya, misalnya, klik aliran. Namun, orang yang menggunakan istilah Pengadaan Acara (yang bertentangan dengan Pemrosesan Streaming) cenderung merujuk pada penggunaan kedua ...

Sumber kebenaran yang dikendalikan aplikasi = Tidak

Aplikasi semacam ini menyatakan acara sendiri sebagai hasil dari permintaan pengguna yang melewati logika bisnis. Kafka tidak berfungsi dengan baik dalam hal ini karena dua alasan utama.

Kurangnya isolasi entitas

Skenario ini membutuhkan kemampuan untuk memuat aliran acara untuk entitas tertentu. Alasan umum untuk ini adalah untuk membangun model tulis sementara untuk logika bisnis untuk digunakan untuk memproses permintaan. Melakukan ini tidak praktis di Kafka. Menggunakan topik per entitas dapat memungkinkan hal ini, kecuali ini bukan permulaan ketika mungkin ada ribuan atau jutaan entitas. Ini karena batasan teknis di Kafka / Zookeeper.

Salah satu alasan utama untuk menggunakan model tulis sementara dengan cara ini adalah untuk membuat perubahan logika bisnis murah dan mudah digunakan.

Disarankan menggunakan topik per jenis untuk Kafka, tetapi ini membutuhkan pemuatan acara untuk setiap entitas dari tipe itu hanya untuk mendapatkan acara untuk satu entitas. Karena Anda tidak dapat mengetahui posisi log peristiwa mana yang dimiliki entitas mana. Bahkan menggunakan Snapshots untuk memulai dari posisi log yang diketahui, ini bisa menjadi sejumlah besar peristiwa yang harus dilalui.

Kurangnya deteksi konflik

Kedua, pengguna dapat membuat kondisi balapan karena permintaan bersamaan terhadap entitas yang sama. Mungkin sangat tidak diinginkan untuk menyimpan peristiwa yang saling bertentangan dan menyelesaikannya setelah fakta. Jadi penting untuk bisa mencegah peristiwa yang saling bertentangan. Untuk skala pemuatan permintaan, adalah umum untuk menggunakan layanan stateless sambil mencegah konflik penulisan menggunakan penulisan bersyarat (hanya menulis jika peristiwa entitas terakhir adalah #x). Aka Optimis Concurrency. Kafka tidak mendukung konkurensi optimis. Bahkan jika itu mendukungnya di tingkat topik, itu akan perlu sampai ke tingkat entitas untuk menjadi efektif. Untuk menggunakan Kafka dan mencegah peristiwa yang saling bertentangan, Anda harus menggunakan penulis berseri, berseri di tingkat aplikasi. Ini adalah persyaratan / batasan arsitektur yang signifikan.

Informasi lebih lanjut

Perbarui per komentar

Komentar telah dihapus, tetapi pertanyaannya adalah seperti: apa yang digunakan orang untuk penyimpanan acara?

Tampaknya sebagian besar orang menggelar implementasi penyimpanan acara mereka sendiri di atas basis data yang ada. Untuk skenario yang tidak terdistribusi, seperti back-end internal atau produk yang berdiri sendiri, terdokumentasi dengan baik bagaimana membuat event store berbasis SQL. Dan ada perpustakaan yang tersedia di atas berbagai macam basis data. Ada juga EventStore , yang dibangun untuk tujuan ini.

Dalam skenario terdistribusi, saya telah melihat beberapa implementasi yang berbeda. Proyek Jet's Panther menggunakan Azure CosmosDB , dengan fitur Change Feed untuk memberi tahu pendengar. Implementasi serupa lainnya yang pernah saya dengar di AWS adalah menggunakan DynamoDB dengan fitur Streams untuk memberi tahu pendengar. Kunci partisi mungkin harus menjadi id aliran untuk distribusi data terbaik (untuk mengurangi jumlah penyediaan berlebihan). Namun, replay penuh lintas sungai di Dynamo mahal (baca dan hemat biaya). Jadi impl ini juga disiapkan untuk Dynamo Streams untuk membuang acara ke S3. Ketika pendengar baru daring, atau pendengar yang ada ingin ulangan penuh, ia akan membaca S3 untuk mengejar ketinggalan terlebih dahulu.

Proyek saya saat ini adalah skenario multi-tenant, dan saya menggulirkan sendiri di atas Postgres. Sesuatu seperti Citus tampaknya sesuai untuk skalabilitas, dipartisi oleh aliran + tentant.

Kafka masih sangat berguna dalam skenario terdistribusi. Merupakan masalah non-sepele untuk mengekspos acara masing-masing layanan ke layanan lain. Sebuah toko acara tidak dibangun untuk itu biasanya, tapi justru itulah yang dilakukan Kafka dengan baik. Setiap layanan memiliki sumber kebenaran internal sendiri (dapat berupa penyimpanan acara atau lainnya), tetapi mendengarkan Kafka untuk mengetahui apa yang terjadi "di luar". Layanan ini juga dapat memposting acara ke Kafka untuk menginformasikan "luar" hal-hal menarik yang dilakukan layanan.

Anda dapat menggunakan Kafka sebagai toko acara, tetapi saya tidak merekomendasikan melakukannya, meskipun ini mungkin pilihan yang bagus:

• Kafka hanya menjamin setidaknya sekali pengiriman dan ada duplikat di toko acara yang tidak dapat dihapus. Pembaruan: Di sini Anda dapat membaca mengapa begitu sulit dengan Kafka dan beberapa berita terbaru tentang bagaimana akhirnya mencapai perilaku ini: https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how -apache-kafka-do-it /
• Karena kekekalan, tidak ada cara untuk memanipulasi event store ketika aplikasi berkembang dan acara perlu diubah (tentu saja ada metode seperti upcasting, tapi ...). Sekali mungkin mengatakan Anda tidak perlu mengubah peristiwa, tetapi itu bukan asumsi yang benar, mungkin ada situasi di mana Anda membuat cadangan asli, tetapi Anda meng-upgrade mereka ke versi terbaru. Itulah persyaratan yang valid dalam arsitektur yang digerakkan oleh peristiwa.
• Tidak ada tempat untuk menyimpan snapshot entitas / agregat dan pemutaran ulang akan menjadi lebih lambat dan lebih lambat. Membuat snapshot adalah fitur untuk penyimpanan acara dari perspektif jangka panjang.
• Mengingat partisi Kafka didistribusikan dan mereka sulit untuk mengelola dan membuat cadangan dibandingkan dengan database. Basis data lebih sederhana :-)

Jadi, sebelum Anda membuat pilihan, Anda berpikir dua kali. Event store sebagai kombinasi antarmuka lapisan aplikasi (pemantauan dan manajemen), toko SQL / NoSQL dan Kafka sebagai broker adalah pilihan yang lebih baik daripada meninggalkan Kafka menangani kedua peran untuk membuat fitur lengkap solusi lengkap.

Event store adalah layanan kompleks yang membutuhkan lebih dari apa yang dapat ditawarkan Kafka jika Anda serius menerapkan sumber acara, CQRS, Sagas, dan pola lainnya dalam arsitektur yang digerakkan oleh acara dan tetap berkinerja tinggi.

Jangan ragu untuk menantang jawaban saya! Anda mungkin tidak menyukai apa yang saya katakan tentang broker favorit Anda dengan banyak kemampuan yang tumpang tindih, tetapi tetap saja, Kafka tidak dirancang sebagai event store, tetapi lebih sebagai broker dan buffer berkinerja tinggi pada saat yang sama untuk menangani produsen cepat versus skenario konsumen yang lambat, sebagai contoh.

Silakan lihat framework open source eventuate.io microservices untuk menemukan lebih banyak tentang masalah potensial: http://eventuate.io/

Pembaruan pada 8 Februari 2018

Saya tidak memasukkan info baru dari komentar, tetapi menyetujui beberapa aspek tersebut. Pembaruan ini lebih lanjut tentang beberapa rekomendasi untuk platform yang didorong oleh acara microservice. Jika Anda serius tentang desain microservice yang tangguh dan kinerja setinggi mungkin secara umum, saya akan memberikan beberapa petunjuk yang mungkin menarik bagi Anda.

1. Jangan gunakan Spring - itu hebat (saya sering menggunakannya sendiri), tetapi berat dan lambat pada saat yang sama. Dan itu bukan platform microservice sama sekali. Ini "hanya" kerangka kerja untuk membantu Anda menerapkannya (banyak pekerjaan di balik ini ..). Kerangka kerja lainnya adalah "hanya" REST ringan atau JPA atau kerangka kerja yang berbeda fokus. Saya merekomendasikan mungkin platform microservice lengkap open source terbaik di kelasnya yang tersedia yang kembali ke akar Java murni: https://github.com/networknt

Jika Anda bertanya-tanya tentang kinerja, Anda dapat membandingkan diri Anda dengan benchmark benchmark yang ada. https://github.com/networknt/microservices-framework-benchmark

2. Jangan gunakan Kafka sama sekali :-)) Ini setengah bercanda. Maksud saya sementara Kafka hebat, itu adalah sistem sentris broker lain. Saya pikir masa depan adalah dalam sistem pesan tanpa perantara. Anda mungkin terkejut tetapi ada yang lebih cepat daripada sistem Kafka :-), tentu saja Anda harus turun ke level yang lebih rendah. Lihatlah Chronicle.

3. Untuk Event store, saya merekomendasikan ekstensi Postgresql superior yang disebut TimescaleDB, yang berfokus pada pemrosesan data deret waktu kinerja tinggi (peristiwa adalah deret waktu) dalam volume besar. Tentu saja CQRS, Event sourcing (fitur replay, dll.) Dibangun dalam kerangka light4j di luar kotak yang menggunakan Postgres sebagai penyimpanan rendah.

4. Untuk olahpesan coba lihat Chronicle Queue, Map, Engine, Network. Maksud saya menyingkirkan solusi sentris broker kuno dan pergi dengan sistem pesan mikro (tertanam satu). Antrian Chronicle sebenarnya bahkan lebih cepat dari Kafka. Tapi saya setuju itu tidak semua dalam satu solusi dan Anda perlu melakukan pengembangan jika tidak Anda pergi dan membeli versi Perusahaan (berbayar). Pada akhirnya, upaya untuk membangun dari Chronicle, lapisan pesan Anda sendiri akan dibayar dengan menghilangkan beban mempertahankan cluster Kafka.

Ya, Anda dapat menggunakan Kafka sebagai toko acara. Ini bekerja cukup baik, terutama dengan pengenalan Kafka Streams , yang menyediakan cara asli Kafka untuk memproses acara Anda menjadi keadaan terakumulasi yang dapat Anda tanyakan .

Mengenai:

Kemampuan untuk memutar ulang eventlog yang memungkinkan kemampuan bagi pelanggan baru untuk mendaftar dengan sistem setelah fakta.

Ini bisa rumit. Saya membahasnya secara rinci di sini: https://stackoverflow.com/a/48482974/741970

Ya, Kafka bekerja dengan baik dalam model sumber acara khusus CQRS, namun Anda harus berhati-hati saat menetapkan TTL untuk topik dan selalu ingat bahwa Kafka tidak dirancang untuk model ini, namun kami dapat menggunakannya dengan sangat baik.

Saya pikir Anda harus melihat kerangka akson bersama dengan dukungan mereka untuk Kafka