Gaya arsitektur

Gaya arsitektur adalah keluarga arsitektur yang memiliki karakteristik tertentu. Misalnya, N-tier adalah gaya arsitektur yang umum. Baru-baru ini, arsitektur layanan mikro mulai disukai. Gaya arsitektur tidak memerlukan penggunaan teknologi tertentu, tetapi beberapa teknologi sangat cocok untuk arsitektur tertentu. Misalnya, kontainer sangat cocok untuk layanan mikro.

Kami telah mengidentifikasi serangkaian gaya arsitektur yang umum ditemukan pada aplikasi cloud. Artikel untuk setiap gaya meliputi:

• Deskripsi dan diagram logis dari gaya.
• Rekomendasi kapan harus memilih gaya ini.
• Keuntungan, tantangan, dan praktik terbaik.
• Penyebaran yang disarankan menggunakan layanan Azure yang relevan.

Tur singkat tentang gaya

Bagian ini memberikan tur singkat seputar gaya arsitektur yang telah kami identifikasi, bersama dengan beberapa pertimbangan tingkat tinggi untuk penggunaannya. Baca detail selengkapnya dalam topik terkait.

N-tier

N-tier adalah arsitektur tradisional untuk aplikasi perusahaan. Dependensi dikelola dengan membagi aplikasi menjadi beberapa lapisan yang melakukan fungsi logis, seperti presentasi, logika bisnis, dan akses data. Sebuah lapisan hanya dapat memanggil lapisan yang berada di bawahnya. Namun, lapisan horizontal ini bisa menjadi sebuah kewajiban. Mungkin sulit untuk memperkenalkan perubahan di satu bagian aplikasi tanpa menyentuh bagian aplikasi lainnya. Hal tersebut membuat pembaruan sering menjadi tantangan, membatasi seberapa cepat fitur baru dapat ditambahkan.

N-tier sangat cocok untuk memigrasikan aplikasi yang ada, yang sudah menggunakan arsitektur berlapis. Oleh karena itu, N-tier paling sering terlihat pada solusi infrastruktur sebagai layanan (IaaS), atau aplikasi yang menggunakan gabungan IaaS dan layanan terkelola.

Web-Queue-Worker

Untuk solusi PaaS murni, pertimbangkan arsitektur Web-Queue-Worker. Dalam gaya ini, aplikasi memiliki front end web yang menangani permintaan HTTP dan worker back-end yang melakukan tugas intensif CPU atau operasi yang berjalan lama. Front end berkomunikasi dengan worker melalui antrean pesan asinkron.

Web-queue-worker cocok untuk domain yang relatif sederhana dengan beberapa tugas intensif sumber daya. Seperti N-tier, arsitekturnya mudah dipahami. Penggunaan layanan terkelola menyederhanakan penyebaran dan operasi. Tetapi dengan domain yang kompleks, mungkin sulit untuk mengelola dependensi. Front end dan worker dapat dengan mudah menjadi komponen monolitik besar yang sulit dipelihara dan diperbarui. Seperti halnya N-tier, ini dapat mengurangi frekuensi pembaruan dan membatasi inovasi.

Layanan mikro

Jika aplikasi Anda memiliki domain yang lebih kompleks, pertimbangkan untuk beralih ke arsitektur Microservices. Aplikasi layanan mikro terdiri dari banyak layanan kecil dan independen. Setiap layanan menerapkan kemampuan bisnis tunggal. Layanan digabungkan secara longgar, berkomunikasi melalui kontrak API.

Setiap layanan dapat dibangun oleh tim pengembangan kecil yang terfokus. Layanan individual dapat disebarkan tanpa banyak koordinasi antartim, yang mendorong pembaruan yang sering terjadi. Arsitektur layanan mikro lebih kompleks untuk dibangun dan dikelola daripada N-tier atau web-queue-worker. Hal ini membutuhkan pengembangan yang matang dan budaya DevOps. Tetapi jika dilakukan dengan benar, gaya ini dapat menghasilkan kecepatan rilis yang lebih tinggi, inovasi yang lebih cepat, dan arsitektur yang lebih tangguh.

Arsitektur yang didorong oleh peristiwa

Arsitektur yang Didorong oleh Peristiwa menggunakan model terbitkan-langganan (pub-sub), yaitu produsen menerbitkan peristiwa, dan konsumen berlangganan. Produsen adalah independen dari konsumen, dan konsumen adalah independen satu sama lain.

Pertimbangkan arsitektur yang didorong oleh peristiwa untuk aplikasi yang menyerap dan memproses volume data besar dengan latensi yang sangat rendah, seperti solusi IoT. Gaya ini juga berguna ketika subsistem yang berbeda harus melakukan jenis pemrosesan yang berbeda pada data peristiwa yang sama.

Big Data, Komputasi Skala Besar

Big Data dan Komputasi Skala Besar merupakan gaya arsitektur khusus untuk beban kerja yang sesuai dengan profil tertentu. Big data membagi himpunan data yang sangat besar menjadi gugus, melakukan pemrosesan paralel di seluruh himpunan, untuk analisis dan pelaporan. Komputasi skala besar, juga disebut komputasi kinerja tinggi (HPC), membuat komputasi paralel di sejumlah besar (ribuan) core. Domain termasuk simulasi, pemodelan, dan penyajian 3-D.

Gaya arsitektur sebagai batasan

Gaya arsitektur menempatkan batasan pada desain, termasuk seperangkat elemen yang dapat muncul dan hubungan yang diizinkan antara elemen-elemen tersebut. Batasan memandu "bentuk" arsitektur dengan membatasi cakupan pilihan. Ketika arsitektur sesuai dengan batasan gaya tertentu, properti tertentu yang diinginkan akan muncul.

Misalnya, batasan dalam layanan mikro meliputi:

• Sebuah layanan mewakili satu tanggung jawab.
• Setiap layanan adalah independen dari yang lain.
• Data bersifat privat untuk layanan yang memilikinya. Layanan tidak berbagi data.

Dengan mematuhi batasan ini, yang muncul adalah sistem yang layanannya dapat digunakan secara independen, kesalahan diisolasi, pembaruan sering dapat dilakukan, dan memperkenalkan teknologi baru ke dalam aplikasi mudah dilakukan.

Sebelum memilih gaya arsitektur, pastikan Anda memahami prinsip dan batasan yang mendasari gaya tersebut. Jika tidak, Anda bisa mendapatkan desain yang sesuai dengan gaya pada tingkat dangkal, tetapi tidak mencapai potensi penuh gaya tersebut. Penting juga untuk bersikap pragmatis. Terkadang lebih baik melonggarkan batasan, daripada bersikeras pada kemurnian arsitektur.

Tabel berikut merangkum cara setiap gaya mengelola dependensi, dan jenis domain yang paling cocok untuk masing-masing gaya.

Gaya arsitektur	Manajemen dependensi	Jenis domain
N-tier	Tingkatan horizontal dibagi menurut subnet	Domain bisnis tradisional. Frekuensi pembaruan rendah.
Pekerja antrean web	Pekerjaan front dan backend, dipisahkan oleh olahpesan asinkron.	Domain yang relatif sederhana dengan beberapa tugas intensif sumber daya.
Layanan mikro	Secara vertikal (secara fungsional) menguraikan layanan yang saling memanggil melalui API.	Domain yang rumit. Pembaruan yang sering.
Arsitektur berbasis peristiwa	Producer/consumer. Tampilan independen per sub-sistem.	IoT dan sistem real-time.
Big data	Bagi himpunan data besar ke dalam gugus kecil. Pemrosesan paralel pada himpunan data lokal.	Analisis data real time dan batch. Analisis prediktif menggunakan ML.
Komputasi skala besar	Alokasi data untuk ribuan core.	Menghitung domain intensif seperti simulasi.

Mempertimbangkan tantangan dan keuntungan

Batasan juga menciptakan tantangan, sehingga penting untuk memahami trade-off saat mengadopsi salah satu gaya ini. Apakah keuntungan dari gaya arsitektur lebih besar daripada tantangannya, untuk subdomain ini dan konteks terbatas.

Berikut adalah beberapa jenis tantangan yang perlu dipertimbangkan ketika memilih gaya arsitektur:

• Kompleksitas. Apakah kompleksitas arsitektur dibenarkan untuk domain Anda? Sebaliknya, apakah gaya terlalu sederhana untuk domain Anda? Dalam hal ini, Anda berisiko mendapatkan"bola lumpur besar", karena arsitekturnya tidak membantu Anda mengelola dependensi dengan bersih.

• Olahpesan asinkron dan konsistensi akhirnya. Olahpesan asinkron dapat digunakan untuk memisahkan layanan, dan meningkatkan keandalan (karena pesan dapat dicoba ulang) dan skalabilitas. Namun, ini juga menciptakan tantangan dalam menangani konsistensi akhirnya, serta kemungkinan pesan duplikat.

• Komunikasi antarlayanan. Ketika Anda menguraikan aplikasi menjadi layanan terpisah, ada risiko bahwa komunikasi antarlayanan akan menyebabkan latensi yang tidak dapat diterima atau menciptakan kemacetan jaringan (misalnya, dalam arsitektur layanan mikro).

• Pengelolaan. Seberapa sulit mengelola aplikasi, pemantauan, menyebarkan pembaruan, dan sebagainya?

Sumber daya terkait

• Sepuluh prinsip desain untuk aplikasi Azure
• Membangun aplikasi di Microsoft Cloud
• Praktik terbaik dalam aplikasi cloud
• Pola Desain Cloud
• Pengujian performa dan antipattern untuk aplikasi cloud
• Merancang solusi multipenyewa di Azure
• Arsitektur beban kerja misi penting di Azure
• Arsitektur untuk startup