Arsitektur logis versus arsitektur fisik

Tip

Konten ini adalah kutipan dari eBook, .NET Microservices Architecture for Containerized .NET Applications, tersedia di .NET Docs atau sebagai PDF yang dapat diunduh gratis dan dapat dibaca secara offline.

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Pada titik ini Anda perlu berhenti dan membahas perbedaan antara arsitektur logis dan arsitektur fisik, dan bagaimana arsitektur ini diterapkan pada rancangan aplikasi berbasis layanan mikro.

Untuk memulai, membangun layanan mikro tidak memerlukan penggunaan teknologi tertentu. Misalnya, kontainer Docker tidak diharuskan 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 (untuk kesederhanaan, hal tersebut merupakan pendekatan yang diambil pada versi awal eShopOnContainers), paritas antara layanan mikro bisnis dan layanan fisik atau kontainer ini tidak selalu diperlukan dalam semua kasus ketika Anda membangun aplikasi yang besar dan kompleks yang terdiri dari puluhan atau bahkan ratusan layanan.

Di sinilah letak perbedaan antara arsitektur logis dan arsitektur fisik aplikasi. Arsitektur logis dan batas logis sistem tidak selalu memetakan satu-ke-satu ke arsitektur fisik atau penyebaran. Hal tersebut bisa terjadi, tetapi sering kali tidak.

Meskipun Anda mungkin telah mengidentifikasi layanan mikro bisnis atau Konteks Terikat tertentu, 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 bahwa setiap layanan mikro bisnis harus diimplementasikan menggunakan satu layanan atau kontainer sifatnya 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 bersifat otonom dengan mengizinkan kode dan status dibuat versinya, disebarkan, dan diskalakan secara independen.

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

Diagram of the Catalog business microservice with physical servers.

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

Layanan dalam contoh memiliki model data yang sama karena layanan Web API menargetkan data yang sama dengan layanan Pencarian. Jadi, dalam implementasi fisik layanan mikro bisnis, Anda membagi fungsionalitas tersebut sehingga Anda dapat menaikkan maupun menurunkan skala masing-masing layanan internal tersebut sesuai kebutuhan. Mungkin layanan Web API biasanya membutuhkan lebih banyak instans dibandingkan dengan 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, yang kami maksud adalah layanan mikro bisnis atau logis yang dapat memetakan ke satu atau beberapa layanan (fisik). Dalam kebanyakan kasus, mungkin berarti satu layanan, tetapi mungkin lebih.