Artikel tentang satu keputusan buruk yang umum terjadi saat bermigrasi ke layanan mikro. Sementara Microsoft dan perusahaan lain sedang mempertimbangkan untuk membuat Layanan Entitas dalam tutorial mereka, ada banyak alasan untuk menganggapnya sebagai anti-pola. Selanjutnya, kita akan berbicara tentang apa itu Entity Service dan properti apa yang dimilikinya untuk sistem akhir secara keseluruhan.
Entity Service - apa itu? Dan bagaimana ide untuk membuatnya muncul?
Setiap orang telah mendengar bahwa membagi monolit menjadi layanan mikro memberikan banyak keuntungan. Meningkatkan fleksibilitas, kesederhanaan, skalabilitas, toleransi kesalahan, dll. Namun, orang juga dapat mendengar kritik terhadap pendekatan layanan mikro untuk kerumitan dalam memastikan konsistensi data, karena tidak mungkin untuk berbagi transaksi antara beberapa layanan mikro - mereka berkomunikasi melalui http. Dan sistem itu sendiri secara keseluruhan menjadi kompleks - jauh lebih mudah untuk menghapus panggilan http dan menggabungkan semuanya kembali menjadi satu monolit dengan panggilan biasa dari kode.
Ini menunjukkan bahwa tidak cukup hanya memecah monolit menjadi beberapa bagian komponen. Anda harus melakukannya dengan benar. Monolit tipikal berfungsi dengan database dan berisi banyak contoh untuk meningkatkan kinerja dan toleransi kesalahan.
Anggap saja monolit kita adalah toko online. Ini berisi daftar produk, Anda dapat mendaftar sebagai pengguna, memesan, membayarnya, dan mengatur pengiriman. Sebuah ide muncul untuk memotong monolit menjadi layanan mikro. Sudah ada entitas di dalam kode monolit - pesanan, produk, pengguna, pengiriman, dll. Paling mudah untuk mengisolasi mereka sebagai layanan mikro terpisah. Cukup mengganti panggilan dalam kode dengan panggilan melalui http, menyalin kode entitas ke layanan baru, membuat fasad API, dll. Alhasil, kita akan mendapatkan layanan untuk pesanan, pengguna, barang, pengiriman, dll.
Pada gambar, registrasi pesanan dan perencanaan pengiriman tetap berada di dalam fasad, tetapi dapat dipindahkan ke layanan terpisah - dalam contoh kita, ini bukanlah hal yang paling penting.
- Entity Service. , CRUD .
, ( ) entity . . .
:
. , ( ). , .
. - , . , . , - , - .
. , . Jaeger Jaeger: open source, end-to-end distributed tracing.
. , .
Microsoft : Creating a simple data-driven CRUD microservice
Entity Service?
entity service . ( ). :
;
, ;
, . , - ;
( , );
;
.
Entity Service :
API , . , - . , . . , .
entity service. , . , -, - :
- . - . - . , . , . . , , , . . .
. . , , . , , - - . . .
, , . - (immutability). - , . :
.
-.
-.
, .. .
(eventual consistency).
. , .
:
.
.
- . . , .
Opsi lain yang masuk akal untuk diperhatikan adalah alokasi layanan mikro menurut subdomain. Pola: Dekomposisi menurut subdomain Ada lebih banyak opsi untuk membagi menjadi layanan mikro sesuai dengan tautan di atas, tetapi masuk akal untuk mempertimbangkan dua hal di atas terlebih dahulu.
Kedua opsi berjalan dengan baik bersama - Anda dapat dengan mudah menggabungkannya. Hal utama adalah untuk menghindari semua kerugian dari Layanan Entitas .
Pernahkah Anda menemukan anti-pola ini dalam latihan Anda? Bagaimana Anda menyarankan sistem refactoring jika sudah ada? Ajukan pertanyaan, ungkapkan pemikiran Anda di komentar. Pendapat Anda menarik!