Arsitektur logis versus arsitektur fisik

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

Hal ini berguna pada saat ini untuk menghentikan dan mendiskusikan perbedaan antara arsitektur logis dan arsitektur fisik, dan bagaimana hal ini berlaku untuk desain aplikasi berbasis layanan mikro.

Untuk memulai, membangun layanan mikro tidak memerlukan penggunaan teknologi tertentu. Misalnya, kontainer Docker tidak wajib untuk membuat arsitektur berbasis layanan mikro. Layanan mikro tersebut juga dapat dijalankan sebagai proses biasa. Layanan mikro adalah arsitektur logis.

Selain itu, bahkan ketika layanan mikro dapat diimplementasikan secara fisik sebagai layanan tunggal, proses, atau kontainer (demi kesederhanaan, itu adalah pendekatan yang diambil dalam versi awal eShopOnContainers), paritas ini antara layanan mikro bisnis dan layanan fisik atau kontainer tidak selalu diperlukan dalam semua kasus ketika Anda membangun aplikasi besar dan kompleks yang terdiri dari banyak lusinan atau bahkan ratusan layanan.

Di sinilah ada perbedaan antara arsitektur logis aplikasi dan arsitektur fisik. Arsitektur logis dan batas logis sistem tidak selalu memetakan satu-dengan-satu dengan arsitektur fisik atau arsitektur penyebaran. Itu bisa terjadi, tetapi sering tidak.

Meskipun Anda mungkin telah mengidentifikasi layanan mikro bisnis tertentu atau Konteks Terikat, itu tidak berarti bahwa cara terbaik untuk mengimplementasikannya selalu dengan membuat satu layanan (seperti ASP.NET Web API) atau kontainer Docker tunggal untuk setiap layanan mikro bisnis. Memiliki aturan yang mengatakan setiap layanan mikro bisnis harus diimplementasikan menggunakan satu layanan atau kontainer terlalu kaku.

Oleh karena itu, layanan mikro bisnis atau Konteks Terikat adalah arsitektur logis yang mungkin bertepatan (atau tidak) dengan arsitektur fisik. Poin pentingnya adalah bahwa layanan mikro bisnis atau Konteks Terikat harus otonom dengan memungkinkan kode dan status di-versi, disebarkan, dan diskalakan secara independen.

Seperti yang ditunjukkan Gambar 4-8, layanan mikro bisnis katalog dapat terdiri dari beberapa layanan atau proses. Ini bisa berupa beberapa layanan ASP.NET Web API atau jenis layanan lainnya menggunakan HTTP atau protokol lainnya. Lebih penting lagi, layanan dapat berbagi data yang sama, selama layanan ini kohesif sehubungan dengan domain bisnis yang sama.

Gambar 4-8. Layanan mikro bisnis dengan beberapa layanan fisik

Layanan dalam contoh berbagi model data yang sama karena layanan API Web menargetkan data yang sama dengan layanan Pencarian. Jadi, dalam implementasi fisik layanan mikro bisnis, Anda membagi fungsionalitas tersebut sehingga Anda dapat menskalakan masing-masing layanan internal tersebut ke atas atau ke bawah sesuai kebutuhan. Mungkin layanan API Web biasanya membutuhkan lebih banyak instans daripada layanan Pencarian, atau sebaliknya.

Singkatnya, arsitektur logis layanan mikro tidak selalu harus bertepatan dengan arsitektur penyebaran fisik. Dalam panduan ini, setiap kali kami menyebutkan layanan mikro, kami berarti layanan mikro bisnis atau logis yang dapat memetakan ke satu atau beberapa layanan (fisik). Dalam kebanyakan kasus, ini akan menjadi satu layanan, tetapi mungkin lebih.

SebelumnyaBerikutnya