Bagikan melalui

Menerapkan komunikasi berbasis peristiwa antara layanan mikro (peristiwa integrasi)

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Arsitektur Layanan Mikro .NET untuk Aplikasi .NET Kontainer, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Arsitektur Layanan Mikro .NET untuk Aplikasi .NET Dalam Kontainer: gambar kecil sampul eBook.

Seperti yang dijelaskan sebelumnya, saat Anda menggunakan komunikasi berbasis peristiwa, layanan mikro menerbitkan peristiwa ketika sesuatu yang penting terjadi, seperti ketika memperbarui entitas bisnis. Layanan mikro lainnya berlangganan peristiwa tersebut. Ketika layanan mikro menerima peristiwa, layanan mikro dapat memperbarui entitas bisnisnya sendiri, yang mungkin menyebabkan lebih banyak peristiwa diterbitkan. Ini adalah esensi dari konsep konsistensi akhirnya. Sistem penerbitan/berlangganan ini biasanya dilakukan dengan menggunakan implementasi bus peristiwa. Bus acara dapat dirancang sebagai antarmuka dengan API yang diperlukan untuk mendaftar dan membatalkan pendaftaran acara serta untuk memublikasikan acara. Ini juga dapat memiliki satu atau beberapa implementasi berdasarkan komunikasi antar proses atau olahpesan apa pun, seperti antrean olahpesan atau bus layanan yang mendukung komunikasi asinkron dan model publikasi/berlangganan.

Anda dapat menggunakan peristiwa untuk menerapkan transaksi bisnis yang mencakup beberapa layanan, yang memberi Anda konsistensi akhir antara layanan tersebut. Transaksi yang akhirnya konsisten terdiri dari serangkaian tindakan terdistribusi. Pada setiap tindakan, layanan mikro memperbarui entitas bisnis dan menerbitkan peristiwa yang memicu tindakan berikutnya. Ketahuilah bahwa transaksi tidak mencakupi persistensi dasar dan bus peristiwa, sehingga penanganan idempotensi diperlukan. Gambar 6-18 di bawah ini menunjukkan peristiwa PriceUpdated yang diterbitkan melalui bus peristiwa, sehingga pembaruan harga disebarkan ke Keranjang dan layanan mikro lainnya.

Diagram komunikasi berbasis peristiwa asinkron dengan bus peristiwa.

Gambar 6-18. Komunikasi berbasis peristiwa menggunakan bus acara

Bagian ini menjelaskan bagaimana Anda dapat menerapkan jenis komunikasi ini dengan .NET dengan menggunakan antarmuka bus peristiwa generik, seperti yang ditunjukkan pada Gambar 6-18. Ada beberapa implementasi potensial, masing-masing menggunakan teknologi atau infrastruktur yang berbeda seperti RabbitMQ, Azure Service Bus, atau bus layanan terbuka atau komersial pihak ketiga lainnya.

Memanfaatkan broker pesan dan bus layanan dalam sistem produksi

Seperti yang disebutkan di bagian arsitektur, Anda dapat memilih dari beberapa teknologi olahpesan untuk mengimplementasikan bus peristiwa abstrak Anda. Tetapi teknologi ini berada pada tingkat yang berbeda. Misalnya, RabbitMQ, sebagai sistem transpor perantara pesan, berada pada tingkat teknis yang lebih dasar dibandingkan dengan produk komersial seperti Azure Service Bus, NServiceBus, MassTransit, atau Brighter. Sebagian besar produk ini dapat bekerja di atas RabbitMQ atau Azure Service Bus. Pilihan produk Anda tergantung pada berapa banyak fitur dan berapa banyak skalabilitas out-of-the-box yang Anda butuhkan untuk aplikasi Anda.

Untuk menerapkan konsep dasar bus peristiwa untuk lingkungan pengembangan Anda, seperti dalam contoh eShopOnContainers, implementasi sederhana di atas RabbitMQ yang dijalankan dalam bentuk kontainer mungkin sudah cukup. Tetapi untuk sistem misi penting dan produksi yang membutuhkan skalabilitas tinggi, Anda mungkin ingin mengevaluasi dan menggunakan Azure Service Bus.

Jika Anda memerlukan abstraksi tingkat tinggi dan fitur yang lebih kaya seperti Sagas untuk proses jangka panjang yang membuat pengembangan terdistribusi lebih mudah, bus layanan komersial dan sumber terbuka lainnya seperti NServiceBus, MassTransit, dan Brighter layak dievaluasi. Dalam hal ini, abstraksi dan API yang digunakan biasanya akan langsung berasal dari bus layanan tingkat tinggi yang disediakan, bukan dari abstraksi Anda sendiri (seperti abstraksi bus peristiwa sederhana yang disediakan di eShopOnContainers). Untuk itu, Anda dapat meneliti eShopOnContainers yang telah terfork menggunakan NServiceBus (contoh turunan tambahan yang diterapkan oleh Particular Software).

Tentu saja, Anda selalu dapat membangun fitur bus layanan Anda sendiri di atas teknologi tingkat bawah seperti RabbitMQ dan Docker, tetapi pekerjaan yang diperlukan untuk "menciptakan kembali roda" mungkin terlalu mahal untuk aplikasi perusahaan kustom.

Untuk menegaskan kembali: contoh abstraksi dan implementasi bus peristiwa yang ditampilkan dalam sampel eShopOnContainers dimaksudkan untuk digunakan hanya sebagai bukti konsep. Setelah Anda memutuskan bahwa Anda ingin memiliki komunikasi asinkron dan berbasis peristiwa, seperti yang dijelaskan di bagian saat ini, Anda harus memilih produk bus layanan yang paling sesuai dengan kebutuhan Anda untuk produksi.

Peristiwa integrasi

Peristiwa integrasi digunakan untuk menyinkronkan status domain di beberapa layanan mikro atau sistem eksternal. Fungsionalitas ini dilakukan dengan menerbitkan peristiwa integrasi di luar layanan mikro. Ketika sebuah event diterbitkan ke beberapa layanan mikro penerima (kepada sebanyak layanan mikro yang berlangganan event integrasi), penangan event yang tepat di setiap layanan mikro penerima menangani event tersebut.

Peristiwa integrasi pada dasarnya adalah kelas penyimpanan data, seperti dalam contoh berikut:

public class ProductPriceChangedIntegrationEvent : IntegrationEvent
{
    public int ProductId { get; private set; }
    public decimal NewPrice { get; private set; }
    public decimal OldPrice { get; private set; }

    public ProductPriceChangedIntegrationEvent(int productId, decimal newPrice,
        decimal oldPrice)
    {
        ProductId = productId;
        NewPrice = newPrice;
        OldPrice = oldPrice;
    }
}

Peristiwa integrasi dapat didefinisikan pada tingkat aplikasi setiap layanan mikro, sehingga dipisahkan dari layanan mikro lainnya, dengan cara yang sebanding dengan bagaimana ViewModels didefinisikan di server dan klien. Yang tidak disarankan adalah berbagi pustaka peristiwa integrasi umum di berbagai layanan mikro; tindakan tersebut akan menghubungkan layanan mikro tersebut dengan satu pustaka data definisi peristiwa. Anda tidak ingin melakukannya karena alasan yang sama bahwa Anda tidak ingin berbagi model domain umum di beberapa layanan mikro: layanan mikro harus sepenuhnya otonom. Untuk informasi selengkapnya, lihat posting blog ini tentang jumlah data yang akan dimasukkan ke dalam peristiwa. Berhati-hatilah untuk tidak mengambil ini terlalu jauh, karena posting blog lain ini menjelaskan masalah yang dapat dihasilkan oleh pesan kekurangan data. Desain acara Anda harus bertujuan "tepat" untuk kebutuhan konsumen mereka.

Hanya ada beberapa jenis pustaka yang harus Anda bagikan di seluruh layanan mikro. Salah satunya adalah pustaka yang merupakan blok aplikasi akhir, seperti API klien Azure Event Bus, seperti di eShopOnContainers. Lainnya adalah pustaka yang merupakan alat yang juga dapat dibagikan sebagai komponen NuGet, seperti serializer JSON.

Bus acara

Bus acara memungkinkan komunikasi gaya terbit/berlangganan antara layanan mikro tanpa mengharuskan komponen untuk secara eksplisit mengetahui satu sama lain, seperti yang ditunjukkan pada Gambar 6-19.

Diagram yang memperlihatkan pola publikasi/berlangganan dasar.

Gambar 6-19. Dasar-dasar publikasi/berlangganan dengan bus peristiwa

Diagram di atas menunjukkan bahwa mikrolayanan A menerbitkan ke Event Bus, yang mendistribusikan ke mikrolayanan yang berlangganan, yaitu B dan C, tanpa penerbit perlu mengetahui siapa pelanggannya. Bus peristiwa terkait dengan pola Pengamat dan pola terbitkan-berlangganan.

Pola pengamat

Dalam pola Pengamat, objek utama Anda (dikenal sebagai Dapat Diamati) memberi tahu objek lain yang tertarik (dikenal sebagai Pengamat) dengan informasi (peristiwa) yang relevan.

Pola Terbitkan/Berlangganan (Pub/Sub)

Tujuan pola Terbitkan/Berlangganan sama dengan pola Pengamat: Anda ingin memberi tahu layanan lain ketika peristiwa tertentu terjadi. Tetapi ada perbedaan penting antara pola Observer dan Pub/Sub. Dalam pola pengamat, siaran dilakukan langsung dari yang dapat diamati kepada pengamat, itulah sebabnya mereka 'saling mengenal'. Tetapi saat menggunakan pola Pub/Sub, ada komponen ketiga, yang disebut broker, atau broker pesan atau bus peristiwa, yang dikenal oleh penerbit dan pelanggan. Oleh karena itu, saat menggunakan pola Pub/Sub, penerbit dan pelanggan terpisah secara tepat berkat keberadaan event bus atau broker pesan yang telah disebutkan.

Perantara atau bus acara

Bagaimana Anda mencapai anonimitas antara penerbit dan pelanggan? Cara mudah adalah membiarkan perantara mengurus semua komunikasi. Bus acara adalah salah satu perantara seperti itu.

Bus event biasanya terdiri dari dua bagian:

  • Abstraksi atau antarmuka.

  • Satu atau beberapa implementasi.

Di Gambar 6-19 Anda dapat melihat bagaimana, dari sudut pandang aplikasi, bus acara tidak lebih dari sekedar saluran Pub/Sub. Cara Anda menerapkan komunikasi asinkron ini dapat bervariasi. Ini dapat memiliki beberapa implementasi sehingga Anda dapat bertukar di antara mereka, tergantung pada persyaratan lingkungan (misalnya, produksi versus lingkungan pengembangan).

Pada Gambar 6-20, Anda dapat melihat abstraksi bus peristiwa dengan beberapa implementasi berdasarkan teknologi olahpesan infrastruktur seperti RabbitMQ, Azure Service Bus, atau broker peristiwa/pesan lainnya.

Diagram memperlihatkan penambahan lapisan abstraksi bus peristiwa.

Gambar 6- 20. Beberapa implementasi bus peristiwa

Ada baiknya memiliki bus peristiwa yang ditentukan melalui antarmuka sehingga dapat diimplementasikan dengan beberapa teknologi, seperti RabbitMQ, Azure Service bus atau yang lain. Namun, dan seperti disebutkan sebelumnya, menggunakan abstraksi Anda sendiri (antarmuka bus peristiwa) hanya baik jika Anda memerlukan fitur bus peristiwa dasar yang didukung oleh abstraksi Anda. Jika Anda membutuhkan fitur bus layanan yang lebih kaya, Anda mungkin harus menggunakan API dan abstraksi yang disediakan oleh bus layanan komersial pilihan Anda alih-alih abstraksi Anda sendiri.

Menentukan antarmuka event bus

Mari kita mulai dengan beberapa kode implementasi untuk antarmuka bus peristiwa dan kemungkinan implementasi untuk tujuan eksplorasi. Antarmuka harus generik dan mudah, seperti pada antarmuka berikut.

public interface IEventBus
{
    void Publish(IntegrationEvent @event);

    void Subscribe<T, TH>()
        where T : IntegrationEvent
        where TH : IIntegrationEventHandler<T>;

    void SubscribeDynamic<TH>(string eventName)
        where TH : IDynamicIntegrationEventHandler;

    void UnsubscribeDynamic<TH>(string eventName)
        where TH : IDynamicIntegrationEventHandler;

    void Unsubscribe<T, TH>()
        where TH : IIntegrationEventHandler<T>
        where T : IntegrationEvent;
}

Metode Publish ini mudah. Bus acara akan menyiarkan peristiwa integrasi yang diterima ke layanan mikro atau aplikasi eksternal mana pun yang berlangganan acara tersebut. Metode ini digunakan oleh layanan mikro yang menerbitkan peristiwa.

Metode Subscribe (Anda dapat memiliki beberapa implementasi tergantung pada argumen) digunakan oleh layanan mikro yang ingin menerima peristiwa. Metode ini memiliki dua argumen. Yang pertama adalah peristiwa integrasi untuk berlangganan (IntegrationEvent). Argumen kedua adalah penanganan aktivitas integrasi (atau metode panggilan balik), bernama IIntegrationEventHandler<T>, untuk dijalankan ketika layanan mikro penerima mendapatkan pesan peristiwa integrasi tersebut.

Sumber daya tambahan

Beberapa solusi olahpesan siap produksi:

SebelumnyaBerikutnya