Dalam sejumlah besar artikel, layanan mikro sumber, antara lain, disajikan sebagai cara untuk membangun solusi yang skalabel. Mari kita lihat beberapa contoh mengapa tidak demikian. Dan kami juga akan mencoba berkontribusi pada pertanyaan kuno:
Mana yang lebih baik: monolit atau layanan mikro?
Mari kita lihat contohnya.
Misalkan kita memiliki layanan mikro (lambda) A
yang melakukan permintaan otorisasi "apakah pengguna memiliki hak untuk melakukan operasi?"
Karena layanan mikro semacam itu tidak dapat berdiri sendiri, layanan mikro lain (lambda) ada bersama dengannya B
, yang menyimpan daftar korespondensi hak pengguna di penyimpanan.
Diagram perkiraan layanan mikro (lambda) ditunjukkan pada gambar:
Kedua layanan lambda / mikro bersama-sama membentuk layanan mikro Entitas klasik: yang merangkum pekerjaan dengan entitas "pengguna".
Sebagai hasil dari perubahan dalam data pengguna (pendaftaran pengguna baru, pembatasan pada yang sudah ada, dll.), Layanan mikro B
"memantau" relevansi data dalam penyimpanan, yang digunakan layanan mikro A
untuk memenuhi permintaan otorisasi.
Diagram sederhana. Itu hanya diatur, itu bekerja dengan andal.
, , , . "" ?
CPU
A
io-read/select
CPU
B
io-write
CPU . , :
, A
B
?
A
. RO- :
A
, .
: , B
master- , (io-write)?
. , . multi-master:
X
, , - ( - Y
), .
:
. .
, :
CPU
IO
, . , .
. - ( ).
.
:
, , . . , ( ) . , .
? , , ? .
, , , - .
: vs
/FaaS, :
, MVP . - MVP . , , .
- MVP. , , .
? : , :
, ( , )
( )
- " , , ".
Dan, berdasarkan apa yang telah ditulis, energi perselisihan abadi "monolith vs microservice" pada tahap peluncuran proyek harus diarahkan ke pengembangan gudang data dengan fokus awal pada penskalaan. Dan dalam proses pengembangannya, monolith dan microservice akan memiliki arsitektur yang sangat mirip. Begitu mirip sehingga akan sulit membedakannya satu sama lain.