Arsitektur Berbasis Acara Python: Menguasai Komunikasi Berbasis Pesan

Dalam lanskap digital yang terus berkembang pesat saat ini, membangun sistem perangkat lunak yang tidak hanya fungsional tetapi juga skalabel, tangguh, dan adaptif adalah hal yang utama. Arsitektur Berbasis Acara (Event-Driven Architecture - EDA) telah muncul sebagai paradigma ampuh untuk mencapai tujuan ini. Intinya, EDA berkisar pada produksi, deteksi, konsumsi, dan reaksi terhadap acara. Dalam panduan komprehensif ini, kita akan menyelami seluk-beluk implementasi Arsitektur Berbasis Acara menggunakan Python, dengan fokus khusus pada komunikasi berbasis pesan. Kita akan mengeksplorasi konsep fundamental, alat populer, pola desain, dan pertimbangan praktis yang akan memberdayakan Anda untuk membangun sistem yang canggih dan terpisah.

Apa itu Arsitektur Berbasis Acara (EDA)?

Arsitektur Berbasis Acara adalah pola desain perangkat lunak yang mempromosikan produksi, deteksi, konsumsi, dan reaksi terhadap acara. Acara adalah perubahan signifikan dalam keadaan. Misalnya, pelanggan melakukan pemesanan, sensor mendeteksi ambang batas suhu, atau pengguna mengklik tombol, semuanya dapat dianggap sebagai acara.

Dalam EDA, komponen sistem berkomunikasi dengan memproduksi dan mengonsumsi acara. Ini berbeda dengan arsitektur permintaan-respons tradisional di mana komponen secara langsung memanggil satu sama lain. Karakteristik utama EDA meliputi:

• Komunikasi Asinkron: Acara biasanya diproses secara asinkron, yang berarti produsen tidak menunggu konsumen untuk mengakui atau memproses acara sebelum melanjutkan pekerjaannya sendiri.
• Pemisahan: Komponen terpisah satu sama lain. Produsen tidak perlu tahu siapa konsumennya, dan konsumen tidak perlu tahu siapa produsernya. Mereka hanya perlu menyepakati format acara dan saluran komunikasi.
• Responsif: Sistem dapat bereaksi cepat terhadap perubahan keadaan saat acara disebarkan melalui sistem.
• Skalabilitas dan Ketahanan: Dengan memisahkan komponen, layanan individu dapat diskalakan secara independen, dan kegagalan satu komponen cenderung tidak akan merusak seluruh sistem.

Peran Komunikasi Berbasis Pesan dalam EDA

Komunikasi berbasis pesan adalah tulang punggung sebagian besar Arsitektur Berbasis Acara. Ini menyediakan infrastruktur agar acara dapat dikirimkan dari produsen ke konsumen secara andal dan efisien. Sederhananya, pesan adalah sepotong data yang mewakili suatu acara.

Komponen kunci dalam komunikasi berbasis pesan meliputi:

• Produsen Acara: Aplikasi atau layanan yang menghasilkan acara dan mempublikasikannya sebagai pesan.
• Konsumen Acara: Aplikasi atau layanan yang berlangganan jenis acara tertentu dan bereaksi ketika mereka menerima pesan yang sesuai.
• Broker/Antrean Pesan: Layanan perantara yang menerima pesan dari produsen dan mengirimkannya ke konsumen. Komponen ini sangat penting untuk pemisahan dan pengelolaan aliran acara.

Broker pesan bertindak sebagai pusat utama, menampung pesan, memastikan pengiriman, dan memungkinkan banyak konsumen memproses acara yang sama. Pemisahan kekhawatiran ini adalah fundamental untuk membangun sistem terdistribusi yang kuat.

Mengapa Python untuk Arsitektur Berbasis Acara?

Popularitas Python dan ekosistemnya yang kaya menjadikannya pilihan yang sangat baik untuk membangun sistem berbasis acara. Beberapa faktor berkontribusi pada kesesuaiannya:

• Keterbacaan dan Kesederhanaan: Sintaks Python yang jelas dan kemudahan penggunaan mempercepat pengembangan dan membuat kode lebih mudah dikelola, terutama di lingkungan terdistribusi yang kompleks.
• Pustaka dan Kerangka Kerja yang Luas: Python memiliki koleksi pustaka yang luas untuk jaringan, pemrograman asinkron, dan integrasi dengan broker pesan.
• Dukungan Pemrograman Asinkron: Dukungan bawaan Python untuk asyncio, bersama dengan pustaka seperti aiohttp dan httpx, membuatnya mudah untuk menulis kode non-blocking dan asinkron, yang penting untuk EDA.
• Komunitas dan Dokumentasi yang Kuat: Komunitas yang besar dan aktif berarti sumber daya yang melimpah, tutorial, dan dukungan yang tersedia.
• Kemampuan Integrasi: Python mudah diintegrasikan dengan berbagai teknologi, termasuk basis data, layanan cloud, dan sistem perusahaan yang ada.

Konsep Inti dalam EDA Python dengan Komunikasi Berbasis Pesan

1. Acara dan Pesan

Dalam EDA, acara adalah pernyataan faktual tentang sesuatu yang telah terjadi. Pesan adalah struktur data konkret yang membawa informasi acara ini. Pesan biasanya berisi:

• Tipe Acara: Pengenal yang jelas tentang apa yang terjadi (misalnya, 'OrderPlaced', 'UserLoggedIn', 'PaymentProcessed').
• Data Acara: Muatan yang berisi detail relevan tentang acara (misalnya, ID pesanan, ID pengguna, jumlah pembayaran).
• Stempel Waktu: Kapan acara itu terjadi.
• Sumber: Sistem atau komponen yang menghasilkan acara.

Python dictionary atau kelas kustom umum digunakan untuk merepresentasikan data acara. Format serialisasi seperti JSON atau Protocol Buffers sering digunakan untuk menyusun pesan untuk transmisi.

2. Broker dan Antrean Pesan

Broker pesan adalah sistem saraf pusat dari banyak EDA. Mereka memisahkan produsen dari konsumen dan mengelola aliran pesan.

Pola perpesanan umum meliputi:

• Point-to-Point (Antrean): Sebuah pesan dikirimkan ke satu konsumen. Berguna untuk distribusi tugas.
• Publish/Subscribe (Topik): Sebuah pesan yang dipublikasikan ke suatu topik dapat diterima oleh banyak pelanggan yang tertarik pada topik tersebut. Ideal untuk menyiarkan acara.

Broker pesan populer yang terintegrasi dengan baik dengan Python meliputi:

• RabbitMQ: Broker pesan sumber terbuka yang kuat yang mendukung berbagai protokol perpesanan (AMQP, MQTT, STOMP) dan menawarkan kemampuan perutean yang fleksibel.
• Apache Kafka: Platform streaming acara terdistribusi yang dirancang untuk throughput tinggi, toleransi kesalahan, dan umpan data waktu nyata. Sangat baik untuk pemrosesan aliran dan sumber acara.
• Redis Streams: Struktur data di Redis yang memungkinkan log append-only, berfungsi sebagai broker pesan ringan untuk kasus penggunaan tertentu.
• AWS SQS (Simple Queue Service) dan SNS (Simple Notification Service): Layanan terkelola asli cloud yang menawarkan kemampuan antrean dan publikasi/berlangganan.
• Google Cloud Pub/Sub: Layanan perpesanan asinkron terkelola yang memungkinkan Anda mengirim dan menerima pesan antara aplikasi independen.

3. Pemrograman Asinkron dengan `asyncio`

Pustaka `asyncio` Python sangat penting dalam membangun aplikasi berbasis acara yang efisien. Ini memungkinkan penulisan kode konkuren menggunakan sintaks async/await, yang non-blocking dan berkinerja tinggi untuk operasi terikat I/O seperti komunikasi jaringan dengan broker pesan.

Produsen `asyncio` tipikal mungkin terlihat seperti ini:

            
import asyncio
import aio_pika # Contoh untuk RabbitMQ

async def send_event(queue_name, message_data):
    connection = await aio_pika.connect_robust("amqp://guest:guest@localhost/")
    async with connection:
        channel = await connection.channel()
        await channel.declare_queue(queue_name)
        message = aio_pika.Message(body=message_data.encode())
        await channel.default_exchange.publish(message, routing_key=queue_name)
        print(f"Sent message: {message_data}")

async def main():
    await send_event("my_queue", '{"event_type": "UserCreated", "user_id": 123}')

if __name__ == "__main__":
    asyncio.run(main())

            

              
                Copy
              
            
          

Dan seorang konsumen:

            
import asyncio
import aio_pika

async def consume_events(queue_name):
    connection = await aio_pika.connect_robust("amqp://guest:guest@localhost/")
    async with connection:
        channel = await connection.channel()
        queue = await channel.declare_queue(queue_name)
        async with queue.iterator() as queue_iter:
            async for message in queue_iter:
                async with message.process():
                    print(f"Received message: {message.body.decode()}")
                    # Process the event here

async def main():
    await consume_events("my_queue")

if __name__ == "__main__":
    asyncio.run(main())

            

              
                Copy
              
            
          

4. Pemisahan dan Skalabilitas dengan Microservices

EDA sangat cocok untuk arsitektur microservices. Setiap microservice dapat bertindak sebagai produsen dan/atau konsumen acara, berkomunikasi dengan layanan lain melalui broker pesan. Ini memungkinkan:

• Pengembangan dan Penerapan Independen: Tim dapat mengerjakan dan menerapkan layanan secara independen.
• Keragaman Teknologi: Layanan yang berbeda dapat ditulis dalam bahasa yang berbeda, meskipun format pesan yang umum masih diperlukan.
• Penskalaan Granular: Layanan yang mengalami beban tinggi dapat ditingkatkan skalanya tanpa mempengaruhi yang lain.
• Isolasi Kegagalan: Kegagalan satu microservice cenderung tidak akan merambat dan mempengaruhi seluruh sistem.

Misalnya, platform e-niaga mungkin memiliki layanan untuk 'Manajemen Pesanan', 'Inventaris', 'Pemrosesan Pembayaran', dan 'Pengiriman'. Ketika pesanan dilakukan (acara 'OrderPlaced'), layanan Manajemen Pesanan menerbitkan acara ini. Layanan Inventaris mengonsumsinya untuk memperbarui stok, layanan Pembayaran untuk memulai pembayaran, dan layanan Pengiriman untuk mempersiapkan pengiriman.

Pustaka Python Populer untuk Broker Pesan

Mari kita jelajahi beberapa pustaka Python yang paling banyak digunakan untuk berinteraksi dengan broker pesan:

1. `pika` dan `aio-pika` untuk RabbitMQ

pika adalah klien sinkron resmi untuk RabbitMQ. Untuk aplikasi asinkron yang dibangun dengan `asyncio`, aio-pika adalah pilihan yang disukai. Ini menyediakan API asinkron untuk mempublikasikan dan mengonsumsi pesan.

Kasus Penggunaan: Antrean tugas, pemrosesan tugas terdistribusi, notifikasi waktu nyata, perutean aliran pesan yang kompleks.

2. `kafka-python` dan `confluent-kafka-python` untuk Apache Kafka

kafka-python adalah klien Python murni yang banyak digunakan untuk Kafka. confluent-kafka-python, yang dibangun di atas `librdkafka`, menawarkan kinerja lebih tinggi dan seperangkat fitur yang lebih komprehensif, seringkali disukai untuk lingkungan produksi.

Kasus Penggunaan: Pipeline data waktu nyata, agregasi log, sumber acara, pemrosesan aliran, penyerapan data skala besar.

3. `redis-py` untuk Redis Streams

Meskipun terutama merupakan penyimpanan key-value, Redis menawarkan tipe Streams yang kuat yang dapat digunakan sebagai broker pesan ringan. Pustaka redis-py menyediakan akses ke kemampuan ini.

Kasus Penggunaan: Pub/sub sederhana, analitik waktu nyata, caching dengan notifikasi acara, distribusi tugas ringan di mana broker penuh mungkin berlebihan.

4. SDK Khusus Cloud (Boto3 untuk AWS, Pustaka Klien Google Cloud)

Untuk penerapan asli cloud, menggunakan SDK yang disediakan oleh penyedia cloud seringkali merupakan pendekatan yang paling mudah:

• Boto3 (AWS): Berinteraksi dengan AWS SQS, SNS, Kinesis, dll.
• Pustaka Klien Google Cloud untuk Python: Berinteraksi dengan Google Cloud Pub/Sub.

Kasus Penggunaan: Memanfaatkan layanan cloud terkelola untuk skalabilitas, keandalan, dan pengurangan overhead operasional di lingkungan cloud.

Pola Desain EDA Umum dalam Python

Menerapkan pola desain yang mapan sangat penting untuk membangun sistem berbasis acara yang dapat dikelola dan diskalakan. Berikut adalah beberapa pola kunci yang umum diterapkan dalam Python:

1. Notifikasi Acara

Dalam pola ini, produsen acara menerbitkan acara untuk memberi tahu layanan lain bahwa sesuatu telah terjadi. Pesan acara itu sendiri mungkin berisi data minimal, secukupnya untuk mengidentifikasi kejadian tersebut. Konsumen yang tertarik pada acara tersebut kemudian dapat meminta produsen atau toko data bersama untuk detail lebih lanjut.

Contoh: Acara 'ProductUpdated' dipublikasikan. Layanan 'Search Indexer' mengonsumsi acara ini dan kemudian mengambil detail produk lengkap untuk memperbarui indeks pencariannya.

Implementasi Python: Gunakan sistem Pub/Sub (seperti topik Kafka atau SNS) untuk menyiarkan acara. Konsumen menggunakan filter pesan atau melakukan pencarian berdasarkan ID acara.

2. Transfer Keadaan Dibawa Acara (Event-Carried State Transfer)

Di sini, pesan acara berisi semua data yang diperlukan bagi konsumen untuk melakukan tindakannya, tanpa perlu meminta produsen. Ini meningkatkan pemisahan dan mengurangi latensi.

Contoh: Acara 'OrderPlaced' berisi detail pesanan lengkap (item, kuantitas, alamat pelanggan, informasi pembayaran). Layanan 'Shipping Service' dapat langsung menggunakan informasi ini untuk membuat label pengiriman.

Implementasi Python: Pastikan muatan acara komprehensif. Gunakan format serialisasi yang efisien (seperti Protocol Buffers untuk efisiensi biner) dan pertimbangkan implikasi konsistensi data.

3. Sumber Acara (Event Sourcing)

Dalam Event Sourcing, semua perubahan pada keadaan aplikasi disimpan sebagai urutan acara yang tidak dapat diubah. Alih-alih menyimpan keadaan entitas saat ini, Anda menyimpan riwayat acara yang mengarah ke keadaan tersebut. Keadaan saat ini dapat dibangun kembali dengan memutar ulang acara-acara ini.

Contoh: Untuk entitas 'BankAccount', alih-alih menyimpan saldo saat ini, Anda menyimpan acara seperti 'AccountCreated', 'MoneyDeposited', 'MoneyWithdrawn'. Saldo dihitung dengan menjumlahkan acara-acara ini.

Implementasi Python: Membutuhkan toko acara yang kuat (seringkali basis data khusus atau topik Kafka). Konsumen acara dapat membuat proyeksi (model baca) dengan memproses aliran acara.

4. CQRS (Command Query Responsibility Segregation)

CQRS memisahkan model yang digunakan untuk memperbarui keadaan (Perintah) dari model yang digunakan untuk membaca keadaan (Kueri). Sering digunakan bersama dengan Event Sourcing.

Contoh: Pengguna mengirimkan perintah 'CreateOrder'. Perintah ini diproses, dan acara 'OrderCreated' dipublikasikan. Layanan 'OrderReadModel' yang terpisah mengonsumsi acara ini dan memperbarui basis data yang dioptimalkan untuk baca untuk menanyakan status pesanan secara efisien.

Implementasi Python: Gunakan layanan atau modul terpisah untuk penanganan perintah dan penanganan kueri. Penangan acara bertanggung jawab untuk memperbarui model baca dari acara.

5. Pola Saga

Untuk transaksi yang mencakup banyak microservice, pola Saga mengelola transaksi terdistribusi. Ini adalah urutan transaksi lokal di mana setiap transaksi memperbarui basis data dan menerbitkan pesan atau acara untuk memicu transaksi lokal berikutnya dalam saga. Jika transaksi lokal gagal, saga mengeksekusi serangkaian transaksi kompensasi untuk membatalkan operasi sebelumnya.

Contoh: Proses 'Pesanan' yang melibatkan layanan 'Pembayaran', 'Inventaris', dan 'Pengiriman'. Jika 'Pengiriman' gagal, saga memicu kompensasi untuk mengembalikan pembayaran dan melepaskan inventaris.

Implementasi Python: Dapat diimplementasikan melalui koreografi (layanan bereaksi terhadap acara satu sama lain) atau orkestrasi (layanan orkestrator pusat mengelola langkah-langkah saga).

Pertimbangan Praktis untuk EDA Python

Meskipun EDA menawarkan keuntungan yang signifikan, implementasi yang sukses memerlukan perencanaan yang matang dan pertimbangan beberapa faktor:

1. Desain dan Versi Skema Acara

Pentingnya: Saat sistem Anda berkembang, skema acara akan berubah. Mengelola perubahan ini tanpa merusak konsumen yang ada sangat penting.

Strategi:

• Gunakan Pendaftar Skema: Alat seperti Confluent Schema Registry (untuk Kafka) atau solusi kustom memungkinkan Anda mengelola skema acara dan menegakkan aturan kompatibilitas.
• Kompatibilitas Mundur dan Maju: Rancang acara agar versi yang lebih baru dapat dipahami oleh konsumen lama (kompatibilitas mundur) dan versi lama dapat diproses oleh konsumen baru (kompatibilitas maju).
• Hindari Perubahan yang Merusak: Tambahkan bidang baru alih-alih menghapus atau mengganti nama bidang yang ada sebisa mungkin.
• Versioning Jelas: Sertakan nomor versi dalam skema acara atau metadata pesan Anda.

2. Penanganan Kesalahan dan Percobaan Ulang

Pentingnya: Dalam sistem terdistribusi dan asinkron, kegagalan tidak dapat dihindari. Penanganan kesalahan yang kuat adalah hal terpenting.

Strategi:

• Idempotensi: Rancang konsumen agar idempoten, yang berarti memproses pesan yang sama berkali-kali memiliki efek yang sama seperti memprosesnya sekali. Ini sangat penting untuk mekanisme percobaan ulang.
• Antrean Surat Mati (Dead-Letter Queues - DLQs): Konfigurasikan broker pesan Anda untuk mengirim pesan yang berulang kali gagal diproses ke DLQ terpisah untuk penyelidikan.
• Kebijakan Percobaan Ulang: Terapkan backoff eksponensial untuk percobaan ulang agar tidak membebani layanan hilir.
• Pemantauan dan Peringatan: Siapkan peringatan untuk tingkat DLQ yang tinggi atau kegagalan pemrosesan yang persisten.

3. Pemantauan dan Keterlihatan (Observability)

Pentingnya: Memahami aliran acara, mengidentifikasi hambatan, dan mendiagnosis masalah dalam sistem terdistribusi adalah tantangan tanpa observabilitas yang tepat.

Alat dan Praktik:

• Pelacakan Terdistribusi: Gunakan alat seperti Jaeger, Zipkin, atau OpenTelemetry untuk melacak permintaan dan acara di berbagai layanan.
• Pencatatan (Logging): Pencatatan terpusat (misalnya, tumpukan ELK, Splunk) sangat penting untuk mengumpulkan log dari semua layanan. Sertakan ID korelasi dalam log untuk menghubungkan acara.
• Metrik: Lacak metrik utama seperti throughput pesan, latensi, tingkat kesalahan, dan panjang antrean. Prometheus dan Grafana adalah pilihan populer.
• Pemeriksaan Kesehatan (Health Checks): Terapkan titik akhir pemeriksaan kesehatan untuk semua layanan.

4. Kinerja dan Throughput

Pentingnya: Untuk aplikasi bervolume tinggi, mengoptimalkan kinerja pemrosesan pesan sangat penting.

Strategi:

• Operasi Asinkron: Manfaatkan `asyncio` Python untuk I/O non-blocking.
• Batching: Proses pesan dalam batch jika memungkinkan untuk mengurangi overhead.
• Serialisasi Efisien: Pilih format serialisasi dengan bijak (misalnya, JSON untuk keterbacaan manusia, Protocol Buffers atau Avro untuk kinerja dan penegakan skema).
• Penskalaan Konsumen: Tingkatkan jumlah instance konsumen berdasarkan backlog pesan dan kapasitas pemrosesan.
• Penyesuaian Broker: Konfigurasikan broker pesan Anda untuk kinerja optimal berdasarkan beban kerja Anda.

5. Keamanan

Pentingnya: Mengamankan saluran komunikasi dan data itu sendiri sangat penting.

Praktik:

• Autentikasi dan Otorisasi: Amankan akses ke broker pesan Anda menggunakan kredensial, sertifikat, atau autentikasi berbasis token.
• Enkripsi: Gunakan TLS/SSL untuk mengenkripsi komunikasi antara produsen, konsumen, dan broker.
• Validasi Data: Validasi pesan masuk untuk konten berbahaya atau data yang rusak.
• Daftar Kontrol Akses (ACL): Tentukan klien mana yang dapat mempublikasikan atau berlangganan dari topik atau antrean tertentu.

Pertimbangan Global untuk EDA

Saat menerapkan EDA dalam skala global, beberapa tantangan dan peluang unik muncul:

• Zona Waktu: Acara sering membawa stempel waktu. Pastikan konsistensi dan penanganan zona waktu yang tepat untuk pengurutan dan pemrosesan yang akurat. Pertimbangkan untuk menggunakan Waktu Universal Terkoordinasi (UTC) sebagai standar.
• Latensi: Latensi jaringan antara layanan yang terdistribusi secara geografis dapat memengaruhi waktu pengiriman dan pemrosesan pesan. Pilih broker pesan dengan ketersediaan regional atau pertimbangkan penerapan multi-regional.
• Kedaulatan Data dan Peraturan: Negara yang berbeda memiliki undang-undang perlindungan data yang bervariasi (misalnya, GDPR, CCPA). Pastikan penanganan data acara Anda mematuhi peraturan ini, terutama yang berkaitan dengan Informasi Identitas Pribadi (PII). Anda mungkin perlu menyimpan atau memproses data dalam batas geografis tertentu.
• Mata Uang dan Lokalisasi: Jika acara melibatkan transaksi keuangan atau konten yang dilokalkan, pastikan muatan pesan Anda mengakomodasi mata uang, bahasa, dan format regional yang berbeda.
• Pemulihan Bencana dan Kelangsungan Bisnis: Rancang EDA Anda agar tangguh terhadap pemadaman regional. Ini mungkin melibatkan broker pesan multi-regional dan penerapan layanan redundan.

Contoh: Alur Pesanan E-niaga Internasional

Mari kita visualisasikan alur pesanan e-niaga internasional yang disederhanakan menggunakan EDA dengan Python:

1. Pengguna Melakukan Pesanan (Aplikasi Frontend): Seorang pengguna di Tokyo melakukan pemesanan. Aplikasi frontend mengirimkan permintaan HTTP ke 'Layanan Pesanan' (kemungkinan microservice Python).
2. Layanan Pesanan Membuat Pesanan: 'Layanan Pesanan' memvalidasi permintaan, membuat pesanan baru dalam basis datanya, dan menerbitkan acara OrderCreated ke topik Kafka bernama orders.

   Cuplikan Kode Python (Layanan Pesanan):

               
   from confluent_kafka import Producer
   import json
   
   p = Producer({'bootstrap.servers': 'kafka-broker-address'})
   
   def delivery_report(err, msg):
       if err is not None:
           print(f"Message delivery failed: {err}")
       else:
           print(f"Message delivered to {msg.topic()} [{msg.partition()}] @ {msg.offset()}")
   
   def publish_order_created(order_data):
       message_json = json.dumps(order_data)
       p.produce('orders', key=str(order_data['order_id']), value=message_json, callback=delivery_report)
       p.poll(0) # Trigger delivery reports
       print(f"Published OrderCreated event for order {order_data['order_id']}")
   
   # Asumsikan order_data adalah dict seperti {'order_id': 12345, 'user_id': 987, 'items': [...], 'total': 150.00, 'currency': 'JPY', 'shipping_address': {...}}
   # publish_order_created(order_data)
   
               
   
                 
                   Copy
                 
               
             

3. Layanan Inventaris Memperbarui Stok: 'Layanan Inventaris' (juga Python, mengonsumsi dari topik orders) menerima acara OrderCreated. Ia memeriksa apakah item tersedia dan menerbitkan acara InventoryUpdated.

   Cuplikan Kode Python (Konsumen Inventaris):

               
   from confluent_kafka import Consumer, KafkaException
   import json
   
   c = Consumer({
       'bootstrap.servers': 'kafka-broker-address',
       'group.id': 'inventory_group',
       'auto.offset.reset': 'earliest',
   })
   
   c.subscribe(['orders'])
   
   def process_order_created_for_inventory(order_event):
       print(f"Inventory Service: Processing OrderCreated event for order {order_event['order_id']}")
       # Logic to check stock and reserve items
       # Publish InventoryUpdated event or handle insufficient stock scenario
       print(f"Inventory Service: Stock updated for order {order_event['order_id']}")
   
   while True:
       msg = c.poll(1.0)
       if msg is None:
           continue
       if msg.error():
           if msg.error().code() == KafkaException._PARTITION_EOF:
               # End of partition event, not an error
               print('%% Aborted')
               break
           elif msg.error():
               raise msg.error()
       else:
           try:
               order_data = json.loads(msg.value().decode('utf-8'))
               process_order_created_for_inventory(order_data)
           except Exception as e:
               print(f"Error processing message: {e}")
   
   c.close()
   
               
   
                 
                   Copy
                 
               
             

4. Layanan Pembayaran Memproses Pembayaran: 'Layanan Pembayaran' (Python) mengonsumsi acara OrderCreated. Ia menggunakan total dan mata uang pesanan (misalnya, JPY) untuk memulai pembayaran dengan gateway pembayaran. Ia kemudian menerbitkan acara PaymentProcessed atau acara PaymentFailed.

   Catatan: Untuk kesederhanaan, mari kita asumsikan pembayaran berhasil untuk saat ini.

5. Layanan Pengiriman Menyiapkan Pengiriman: 'Layanan Pengiriman' (Python) mengonsumsi acara PaymentProcessed. Ia menggunakan alamat pengiriman dan item dari pesanan asli (mungkin diambil jika tidak sepenuhnya ada dalam acara) untuk menyiapkan pengiriman. Ia menerbitkan acara ShipmentPrepared.

   Penanganan pengiriman internasional melibatkan kerumitan seperti formulir bea cukai dan pemilihan kurir, yang akan menjadi bagian dari logika Layanan Pengiriman.

6. Layanan Notifikasi Memberi Tahu Pengguna: 'Layanan Notifikasi' (Python) mengonsumsi acara ShipmentPrepared. Ia memformat pesan notifikasi (misalnya, "Pesanan Anda #{order_id} telah dikirim!") dan mengirimkannya ke pengguna melalui email atau notifikasi push, mempertimbangkan lokal pengguna dan bahasa pilihan.

Alur sederhana ini menggambarkan bagaimana komunikasi berbasis pesan dan EDA memungkinkan berbagai bagian sistem untuk bekerja sama secara asinkron, independen, dan reaktif.

Kesimpulan

Arsitektur Berbasis Acara, yang didukung oleh komunikasi berbasis pesan yang kuat, menawarkan pendekatan yang menarik untuk membangun sistem perangkat lunak modern dan kompleks. Python, dengan ekosistem pustakanya yang kaya dan dukungan bawaannya untuk pemrograman asinkron, sangat cocok untuk mengimplementasikan EDA.

Dengan merangkul konsep-konsep seperti broker pesan, pola asinkron, dan pola desain yang terdefinisi dengan baik, Anda dapat membangun aplikasi yang:

• Terpisah: Layanan beroperasi secara independen, mengurangi ketergantungan antar layanan.
• Skalabel: Komponen individu dapat diskalakan berdasarkan permintaan.
• Tangguh: Kegagalan terisolasi, dan sistem dapat pulih dengan lebih mudah.
• Responsif: Aplikasi dapat bereaksi cepat terhadap perubahan waktu nyata.

Saat Anda memulai membangun sistem berbasis acara Anda sendiri dengan Python, ingatlah untuk memprioritaskan desain skema acara yang jelas, penanganan kesalahan yang kuat, pemantauan yang komprehensif, dan pendekatan yang bijaksana terhadap pertimbangan global. Perjalanan ke EDA adalah perjalanan pembelajaran dan adaptasi yang berkelanjutan, tetapi imbalannya dalam hal ketangguhan dan kelincahan sistem sangat besar.

Siap membangun aplikasi skalabel Anda berikutnya? Jelajahi pustaka antrean pesan Python dan mulailah merancang masa depan berbasis acara Anda hari ini!