Mari kita hadapi itu – jika Anda telah bekerja dengan layanan mikro, Anda mungkin telah mengalami momen teror ini ketika sistem Anda yang dirancang dengan cermat mulai terasa seperti jaringan panggilan API yang rumit. Anda tahu pemandangan: Layanan rusak, dan tiba -tiba, aplikasi Anda terlihat seperti rumah kartu. Apakah itu tampak akrab? Jangan khawatir – Anda tidak sendirian dan ada cara yang lebih baik untuk diikuti.

Membebaskan diri Anda dari mimpi buruk sinkron

Ingat hari -hari ketika kami berpikir bahwa sisa API adalah jawaban untuk segalanya? Saya pasti melakukannya. Kami membangun komunikasi layanan hebat ini dengan layanan, dan semuanya akan bekerja dengan sempurna … sampai ini bukan masalahnya. Pada titik inilah banyak dari kita menemukan arsitektur yang berfokus pada acara (EDA), dan itu seperti menemukan saklar pencahayaan di ruangan gelap.

Solusi nyata untuk masalah nyata

Wahyu pasokan acara

Pertimbangkan pasokan ke acara sebagai sejarah rekening bank Anda. Alih -alih mengetahui saldo Anda saat ini, Anda memiliki file dari setiap setoran dan penarikan. Ini bukan hanya pertanyaan untuk menyimpan data – ini adalah pertanyaan menceritakan kisah kedatangan Anda.

Berikut adalah contoh dari dunia nyata yang dapat menghindari sakit kepala:

public class OrderService {
    private EventStore eventStore;
        public void processRefund(String orderId, RefundRequest refund) {
        // Instead of immediately updating the order status...
        OrderEvent refundEvent = new OrderEvent(
            orderId,
            "REFUND_REQUESTED",
            Map.of(
                "amount", refund.getAmount(),
                "reason", refund.getReason(),
                "requestedBy", refund.getUserId()
            )
        );
                // Store the event first
        eventStore.save(refundEvent);
                // Now even if the next steps fail, we haven't lost the refund request
    }
}

Saya bekerja sekali pada proyek di mana model ini menyelamatkan kami selama kegagalan sistem utama. Kami dapat memutar ulang acara dan memulihkan kondisi yang tepat dari setiap pesanan – cobalah untuk melakukan ini dengan API REST!

CQRS: Bukan hanya akronim fantasi lain

Pemisahan tanggung jawab permintaan pesanan (CQRS) mungkin menyerupai sesuatu dari manual komputer, tetapi itu sebenarnya merupakan solusi praktis untuk masalah umum. Pernahkah Anda mengoptimalkan data menulis dan membaca, untuk berakhir dengan kompromi yang juga tidak hebat? Di sinilah CQRS ikut bermain.

Anggap saja memiliki staf dapur terpisah untuk menyiapkan makanan (kontrol) dan melayani staf untuk menerima pesanan dan mengirimkan makanan (permintaan). Setiap tim dapat mengoptimalkan untuk pekerjaan spesifik mereka tanpa malu.

Wacana Nyata tentang Implementasi

Desain Acara: Tetap Sederhana, Tetap Nyata

Ketika saya mulai dengan acara yang berfokus pada acara, saya membuat kesalahan klasik untuk mencoba membuat acara yang mengangkut semuanya kecuali wastafel dapur. Pelajari dari kesalahan saya: Acara harus seperti tweet yang baik – jelas, terkonsentrasi, dan mengangkut informasi yang cukup untuk berguna.

Acara yang buruk:

{
    "type": "ORDER_PLACED",
    "data": {
        "entireOrderHistory": {...},
        "customerLifetimeValue": ...,
        "predictedNextPurchase": ...,
        // And the kitchen sink
    }
}

Acara bagus:

{
    "type": "ORDER_PLACED",
    "orderId": "12345",
    "timestamp": "2025-01-16T10:30:00Z",
    "items": [
        {"id": "SKU123", "quantity": 2}
    ],
    "totalAmount": 59.98
}

Kelola hal -hal saat mereka salah

Karena mereka akan salah. Percayalah pada yang satu ini. Inilah yang benar -benar Anda butuhkan:

1. File of Dead Letters (DLQ) – Pertimbangkan mereka sebagai jaring pengaman sistem Anda
2. Coba mekanismenya lagi – tetapi jadilah cerdas tentang hal ini (upaya tak terbatas hanya masalah yang tak terbatas)
3. Kapasitas membaca ulang acara – “Mesin dalam waktu” Anda saat semuanya berjalan benar -benar ke samping

Nasihat praktis dari seseorang yang ada di sana

1. Mulai sederhana. Anda tidak membutuhkan kafka segera. Terkadang, antrian antrian sederhana sudah cukup untuk memulai. Saya melihat tim lumpuh saat mencoba membangun acara sempurna yang berfokus pada hari pertama.
2. Perhatikan semuanya. Tapi buatlah itu signifikan. Bukan hanya mengumpulkan langkah -langkah – memahaminya. Konfigurasikan peringatan yang memberi tahu Anda ketika ada sesuatu yang salah, tidak hanya ketika ada sesuatu yang berbeda.
3. Dokumentasikan acara Anda. Masa depan Anda (dan rekan satu tim Anda) akan berterima kasih. Saya menyimpan file penurunan harga sederhana di setoran kami yang menjelaskan setiap jenis peristiwa dan tujuannya. Itu membuat kami menghemat waktu yang tak terhitung waktu gedung pencakar langit.

Kebenaran tentang perangkap umum

Izinkan saya berbagi pelajaran yang disetujui dengan susah payah:

1. Perangkap kompleksitas: Hanya karena Anda dapat mengeluarkan acara yang harus Anda lakukan. Setiap acara menambah kompleksitas. Pastikan dia memenangkan penjara bawah tanahnya.
2. Obsesi dipesan: Ya, pesanan acara bisa menjadi penting, tetapi jangan kehilangan tidur daripada memesan acara yang tidak perlu dipesan. Tanyakan pada diri sendiri: “Apakah sangat penting bahwa kedua acara ini tiba dalam urutan yang berbeda?”
3. Labirin Tes Integrasi: Menguji peristiwa yang difokuskan pada acara bisa menjadi halus. Mulailah dengan tes unit yang baik dan secara bertahap menambahkan tes integrasi. Jangan mencoba menguji semuanya secara bersamaan.

Kemasan

Layanan mikro berorientasi peristiwa bukan hanya solusi teknis lain – ini adalah cara berpikir yang berbeda tentang desain sistem. Mereka tidak akan menyelesaikan semua masalah Anda (tidak ada yang terjadi), tetapi mereka dapat membuat sistem Anda lebih tangguh, dapat diukur dan dapat dipelihara.

Jangan lupa: tujuannya adalah untuk tidak membangun sistem yang sempurna; Ini untuk membangun sistem yang memecahkan masalah nyata dan dapat berkembang ketika masalah ini berubah. Mulailah dari yang kecil, belajar dari kesalahan Anda dan terus meningkatkan diri Anda.

Sudahkah Anda beralih ke arsitektur yang dimotivasi oleh acara? Saya ingin sekali mendengar tentang pengalaman Anda di komentar di bawah. Apa yang berhasil? Apa yang tidak dilakukan? Mari belajar dari satu sama lain.