Bagikan melalui

Gaya arsitektur

  • Artikel

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. Harap dicatat bahwa daftar tidak lengkap. Baca detail selengkapnya dalam topik terkait.

N-tier

Diagram logis gaya arsitektur N-tingkat.

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

Diagram logis gaya arsitektur 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

Diagram logis gaya arsitektur 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

Diagram gaya arsitektur berbasis 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

Diagram logis gaya arsitektur big data.

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.

Setiap gaya arsitektur memiliki trade-off sendiri. Oleh karena itu, sebelum memilih gaya arsitektur apa pun, 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. Anda perlu lebih memperhatikan mengapa Anda memilih gaya arsitektur tertentu daripada cara mengimplementasikannya. Penting juga untuk bersikap pragmatis. Terkadang lebih baik melonggarkan batasan, daripada bersikeras pada kemurnian arsitektur.

Memilih gaya arsitektur yang sesuai harus dilakukan idealnya dengan konensus pemangku kepentingan beban kerja yang diinformasikan. Tim beban kerja harus terlebih dahulu mengidentifikasi sifat masalah yang coba mereka selesaikan. Kemudian mereka harus mengidentifikasi pendorong bisnis dan karakteristik arsitektur yang sesuai (juga dikenal sebagai persyaratan non-fungsi) kemudian memprioritaskannya. Misalnya, jika membutuhkan waktu yang lebih singkat untuk pasar, mereka mungkin memprioritaskan keberlanjutan, kemampuan pengujian, dan dapat diandalkan oleh kemampuan penyebaran yang cepat. Atau jika tim beban kerja telah membatasi anggaran, mereka mungkin memprioritaskan kelayakan dan kesederhanaan. Memilih dan mempertahankan gaya arsitektur bukanlah aktivitas satu kali tetapi pendekatan berkelanjutan: arsitektur harus terus diukur, divalidasi, dan disempurnakan dari waktu ke waktu. Biasanya ada biaya signifikan yang terlibat dalam beralih gaya arsitektur, sehingga lebih banyak upaya di muka dapat dibenarkan untuk efisiensi tim jangka panjang dan mitigasi risiko.

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-tingkat Tingkatan horizontal dibagi menurut subnet Domain bisnis tradisional. Frekuensi pembaruan rendah.
Web-queue-worker 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 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?