Apakah Teorema CAP berlaku untuk Layanan Mikro?

Layanan mikro adalah sistem terdistribusi sehingga Teorema CAP harus diterapkan bukan? Yah, itu tergantung pada bagaimana Anda mendefinisikan layanan mikro dan sistem terdistribusi! Layanan mikro didefinisikan sebagai “arsitektur berorientasi layanan yang digabungkan secara longgar dengan konteks terbatas”. SOA menyiratkan Event Driven Architecture. Jika layanan mikro Anda digabungkan secara longgar, mereka tidak membuat panggilan RPC langsung satu sama lain. Jika ini masalahnya, maka tidak ada partisi yang dapat terjadi di antara layanan. Jika layanan adalah konteks yang dibatasi dan memiliki datanya sendiri, maka tidak ada konsistensi antar layanan.

CAP melakukannya tidak berlaku untuk Layanan Mikro jika digabungkan secara longgar dan merupakan konteks yang dibatasi.

Berikut rinciannya dan untuk menjelaskan lebih lanjut mengapa pertanyaan “Apakah Teorema CAP berlaku untuk Layanan Mikro?” bahkan tidak masuk akal dan tidak ada hubungannya dengan Microservices.

Youtube

Lihat saluran YouTube saya tempat saya memposting semua jenis konten yang menyertai posting saya termasuk video ini yang menampilkan semua yang ada di posting ini.

Teorema CAP

Dalam ilmu komputer teoretis, teorema CAP, juga dinamai teorema Brewer setelah ilmuwan komputer Eric Brewer, menyatakan bahwa tidak mungkin penyimpanan data terdistribusi secara bersamaan menyediakan lebih dari dua dari tiga jaminan berikut:

Konsistensi: Setiap pembacaan menerima penulisan terbaru atau kesalahan
Ketersediaan: Setiap permintaan menerima respons (non-kesalahan), tanpa jaminan bahwa itu berisi tulisan terbaru
Toleransi partisi: Sistem terus beroperasi meskipun ada sejumlah pesan yang dibatalkan (atau ditunda) oleh jaringan antar node
Ketika terjadi kegagalan partisi jaringan, sebaiknya kita memutuskan untuk

Batalkan operasi dan dengan demikian kurangi ketersediaan tetapi pastikan konsistensi
Lanjutkan dengan operasi dan dengan demikian memberikan ketersediaan tetapi risiko inkonsistensi
Teorema CAP menyiratkan bahwa dengan adanya partisi jaringan, seseorang harus memilih antara konsistensi dan ketersediaan.

https://en.wikipedia.org/wiki/CAP_theorem

Contoh yang sering saya lihat yang menjelaskan CAP dengan cukup baik adalah kasus penggunaan ATM. Katakanlah ada 2 ATM yang berkomunikasi melalui jaringan. Setiap kali Anda pergi untuk menyetor uang ke ATM, itu menegaskan ATM lain sedang online dan tersedia.

Jika kedua ATM online dan tersedia dan Anda melakukan deposit $100, kedua ATM akan mencatat deposit tersebut. Jika Anda pergi ke ATM lain dan memeriksa saldo Anda, itu akan menjadi $100. Kedua ATM konsisten.

Ketika partisi jaringan terjadi, kita harus memilih konsistensi atau ketersediaan.

Apakah Teorema CAP berlaku untuk Layanan Mikro?

Jika kita memilih konsistensi, maka jika kita tidak dapat berkomunikasi antar ATM, maka kita tidak dapat mengizinkan deposit di satu ATM karena tidak akan konsisten dengan ATM yang lain.

Jika kami memilih ketersediaan, maka kami akan mengizinkan setoran terjadi, namun jika kami pergi ke ATM lain, itu tidak akan mengetahui setoran $ 100 kami. Sistem kami harus mendamaikan perbedaan antara ATM ketika mereka dapat berkomunikasi.

Jadi kembali ke pertanyaan: Apakah Teorema CAP berlaku untuk Layanan Mikro? Nah, apa definisi dari Microservices?

Layanan mikro

Adrian Cockcroft mendefinisikan Microservices sebagai:

arsitektur berorientasi layanan yang digabungkan secara longgar dengan konteks terbatas

https://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices

Ini sangat berbeda dari sistem terdistribusi dimana setiap node menyediakan kemampuan dan data yang sama. Layanan mikro adalah tentang penguraian sistem yang lebih besar. Setiap layanan mikro memiliki perilaku dan datanya sendiri. Membandingkan kedua sistem itu seperti membandingkan apel dan jeruk.

Tapi ada dua poin penting yang ingin saya bicarakan dalam definisi Adrian yang benar-benar mendorong ini pulang. Konteks yang digabungkan dan dibatasi secara longgar.

Konteks Terikat

Konsep konteks terikat dari Desain Berbasis Domain adalah tentang membuat batas. Adrian berkata:

Jika Anda harus tahu terlalu banyak tentang layanan di sekitarnya, Anda tidak memiliki konteks yang terbatas.

Ini karena konsep harus dimiliki oleh konteks terbatas tertentu dalam subdomain. Satu layanan tidak harus tahu secara eksplisit tentang detail layanan lain. Layanan adalah tentang mendefinisikan kemampuan bisnis dan data di balik kemampuan tersebut.

Ini sangat berbeda dengan contoh ATM karena sekali lagi, setiap layanan mendefinisikan kapabilitas (fungsionalitas) sendiri. Dengan kemampuan tersebut adalah kepemilikan data. Data tidak dimiliki oleh beberapa konteks yang dibatasi. Membangun layanan dengan kohesi fungsional yang tinggi adalah kunci dalam menentukan batasan layanan.

Hubungan renggang

Kopling dapat dipikirkan dalam dua cara. Kopling Aferen dan Eferen.

Jika Anda berpikir tentang modul/kelas/proyek:

Kopling Aferen (Ca) adalah modul lain yang bergantung padanya.
Kopling Eferen (Ce) adalah modul lain yang bergantung padanya.

Apakah Teorema CAP berlaku untuk Layanan Mikro?

Dalam contoh ini, modul Katalog memiliki Afferent Coupling (Ca) sebesar 3 karena Gudang, Penjualan, dan Penagihan bergantung padanya. Modul Katalog memiliki Efferent Couling (Ce) 0 karena tidak bergantung pada modul lain. Gudang, Penjualan, dan Penagihan semuanya memiliki Kopling Aferen 0 karena tidak ada modul lain yang bergantung padanya dan Kopling Eferen 1 karena semuanya bergantung pada Katalog.

Jika modul Anda berkomunikasi dalam proses (monolit) melalui jaringan melalui HTTP, modul-modul tersebut masih terikat erat. Sekali lagi, berkomunikasi melalui REST HTTP API tidak membuat layanan Anda kurang digabungkan atau digabungkan secara longgar. Ini hanya membuat sistem Anda menjadi monolit terdistribusi.

Apa itu kopling longgar?

Dalam komputasi dan desain sistem, sistem yang digabungkan secara longgar adalah sistem di mana masing-masing komponennya memiliki, atau menggunakan, sedikit atau tidak ada pengetahuan tentang definisi komponen terpisah lainnya separate. Subarea termasuk kopling kelas, antarmuka, data, dan layanan. Kopling longgar adalah kebalikan dari kopling ketat.

https://en.wikipedia.org/wiki/Loose_coupling

Jika Anda memikirkan kembali komentar Adrian tentang konteks yang terbatas, tentang mengetahui terlalu banyak, inilah yang dia maksud. Cara untuk mencapai kopling longgar adalah melalui Pesan atau Arsitektur Berbasis Peristiwa.

Apakah Teorema CAP berlaku untuk Layanan Mikro?

Alih-alih layanan kami berkomunikasi langsung dengan layanan lain, kami mengirim dan menerbitkan acara ke broker pesan. Setiap modul mengkonsumsi Acara dan bereaksi terhadapnya. Penerbit acara sama sekali tidak mengetahui siapa konsumennya atau apakah ada konsumen sama sekali.

Sebagai contoh dalam proses yang berjalan lama dari situs e-commerce dari pesanan yang ditempatkan, Koreografi Acara digunakan.

Langkah pertama adalah ketika pesanan ditempatkan di layanan Penjualan, Acara Pemesanan diterbitkan ke broker pesan.

Layanan Penagihan akan menggunakan pesan itu dan membuat Faktur atau Mengisi pelanggan.

Setelah Faktur atau Pelanggan telah ditagih, layanan Penagihan akan menerbitkan acara Tagihan Pesanan.

Layanan Warehouse akan menggunakan event Order Billed untuk mengalokasikan produk di Warehouse.

Setelah produk telah dialokasikan dan label pengiriman telah dibuat, ia menerbitkan Acara Pembuatan Label Pengiriman.

Layanan Penjualan menggunakan peristiwa Pembuatan Label Pengiriman untuk memperbarui Status Pesanannya.

Semua alur kerja ini dilakukan dengan menggunakan Event Choregraphy. Tidak ada layanan yang tahu tentang layanan lain yang menggunakan pesan yang diterbitkannya. Mereka digabungkan secara longgar.

Ini berarti bahwa Event Driven Architecture adalah karakteristik arsitektur Microservices.

Untuk lebih lanjut tentang bagaimana ini bekerja untuk proses bisnis yang berjalan lama yang mencakup layanan dapat dikelola, lihat posting saya di Koreografi Acara atau Orkestrasi.

Apakah Teorema CAP berlaku untuk Layanan Mikro?

Tidak. Sama sekali tidak.

Layanan adalah tentang mendefinisikan satu set kemampuan bisnis. Layanan tidak berbagi kepemilikan atas data. Layanan digabungkan secara longgar melalui Arsitektur Pesan dan/atau Event Driven.

Tidak ada perhatian untuk konsistensi karena tidak ada data yang perlu konsisten antar layanan.
Tidak ada perhatian untuk ketersediaan karena setiap layanan bersifat otonom.
Tidak ada masalah toleransi partisi karena setiap layanan bersifat otonom dan digabungkan secara longgar.

Layanan mikro adalah tentang penguraian sistem besar.

posting terkait

Ikuti @CodeOpinion di Twitter