Banyak aplikasi modern perlu dibangun di seluruh perusahaan, terkadang bahkan di Internet. Setiap aplikasi harus memenuhi persyaratan skalabilitas, ketersediaan, keamanan, keandalan, dan ketahanan.
Pada artikel ini, saya akan memperkenalkan beberapa pola desain yang dapat dengan mudah membantu Anda mencapai kemampuan di atas. Saya akan membahas setiap pola, bagaimana menggunakan pola ini di awan, dan kapan menggunakannya dan kapan tidak.
Beberapa dari pola ini tidak semuanya baru, tetapi sangat berguna di dunia cloud Internet saat ini.
Berikut daftar pola yang akan saya bahas dalam artikel ini:
- Pemutus arus
- Command and Query Responsibility Segregation (CQRS)
- Sumber Acara
- Sespan
- Backend-untuk-Frontend
- Pencekik
Jadi mari kita mulai.
1. Pemutus Sirkuit
Sistem terdistribusi harus dirancang dengan mempertimbangkan kegagalan. Layanan mikro saat ini diadopsi di dunia dan layanan ini terutama bergantung pada layanan jarak jauh lainnya. Layanan jarak jauh ini mungkin tidak merespons tepat waktu karena berbagai alasan seperti jaringan, mengunduh aplikasi, dll. Dalam kebanyakan kasus, penerapan percobaan ulang seharusnya dapat menyelesaikan masalah.
Namun terkadang ada masalah serius seperti degradasi layanan atau kegagalan layanan dengan sendirinya. Tidak masuk akal untuk terus mencoba lagi dalam kasus seperti itu. Dalam hal ini, model pemutus sirkuit dapat berguna.
Diagram di atas menunjukkan implementasi skema pemutus sirkuit di mana ketika layanan 1 menyadari bahwa layanan panggilan 2 memiliki kegagalan / batas waktu terus menerus alih-alih mencoba ulang, layanan 1 memutuskan panggilan ke layanan 2 dan mengembalikan respons jika terjadi kegagalan.
Ada pustaka sumber terbuka populer seperti Netflix Hystrix
atau Reselience4J yang dapat digunakan untuk menerapkan pola ini dengan sangat mudah.
Jika Anda menggunakan gerbang API atau proxy
seperti Envoy , ini dapat dicapai di tingkat proxy itu sendiri.
catatan:Sangat penting bahwa log dan peringatan yang cukup diterapkan saat rantai terbuka untuk melacak permintaan yang diterima selama waktu ini dan agar tim operasi menyadari hal ini.
Anda juga dapat menerapkan pemutus arus setengah untuk terus melayani pelanggan layanan yang mengalami gangguan.
Kapan menggunakan pola ini
- Ketika sebuah layanan bergantung pada layanan jarak jauh lain, dan dalam beberapa skenario, kemungkinan besar akan gagal.
- Ketika layanan memiliki ketergantungan yang sangat kuat (seperti layanan data master).
Kapan tidak menggunakan pola ini
- Saat menangani dependensi lokal, pemutus sirkuit dapat menimbulkan overhead.
2. Command and Query Responsibility Segregation (CQRS) ( (CQRS))
CQRS adalah model yang sangat berguna untuk aplikasi gudang data modern. Ini didasarkan pada prinsip pemisahan operasi baca (kueri) dan tulis / perbarui (perintah) di penyimpanan data.
Katakanlah Anda sedang membangun aplikasi yang membutuhkan penyimpanan data dalam database seperti MySQL / PostgreSQL, dll. Seperti yang diketahui semua orang, saat menulis data ke penyimpanan, sebuah operasi harus melalui beberapa tahap - misalnya, validasi, pemodelan, dan persistensi - dan oleh karena itu operasi tulis / perbarui biasanya membutuhkan waktu lebih lama daripada operasi baca sederhana.
Saat Anda menggunakan satu datastore untuk melakukan operasi baca dan tulis pada waktu dan skala yang sama, Anda bisa mulai melihat masalah kinerja.
Dalam kasus seperti itu, template CQRS dapat berguna. Pola CQRS menyarankan penggunaan model data yang berbeda untuk operasi baca dan tulis. Beberapa variasi juga menyarankan penggunaan penyimpanan data terpisah untuk model ini.
Catatan: Sebagian besar database PaaS saat ini menyediakan kemampuan untuk membuat replika yang dapat dibaca ( Google Cloud SQL , Azure SQL DB , Amazon RDS
, dll.) Dari penyimpanan data, yang membuatnya lebih mudah untuk mencapai replikasi data.
Banyak database perusahaan juga menyediakan kemampuan ini jika Anda berurusan dengan database lokal.
Catatan: Beberapa orang akhir-akhir ini juga memilih untuk mengimplementasikan replika yang dapat dibaca sebagai database NoSQL yang cepat dan berkinerja baik seperti MongoDB dan Elasticsearch.
Kapan menggunakan pola ini
- Saat Anda melihat penskalaan aplikasi yang mengharapkan sejumlah besar pembacaan dan penulisan
- Saat Anda ingin menyiapkan operasi baca dan tulis secara terpisah.
- Saat operasi baca Anda mendekati nyata atau pada akhirnya konsisten.
Kapan tidak menggunakan pola ini
- Saat Anda membangun aplikasi CRUD biasa yang tidak mengharapkan banyak membaca dan menulis sekaligus.
3. Sumber Acara
Sumber peristiwa adalah pola desain yang menarik di mana urutan peristiwa domain disimpan sebagai log, dan tampilan log teragregasi memberikan status aplikasi saat ini.
Pola ini biasanya digunakan untuk sistem yang tidak mampu membeli kunci penyimpanan data dan yang perlu mempertahankan audit dan riwayat acara - misalnya, aplikasi seperti hotel / konferensi / tempat duduk.
Diberikan sistem reservasi kamar hotel dimana pengguna diharapkan untuk memesan atau membatalkan reservasi. Di sini Anda perlu menyimpan reservasi dan pembatalan Anda sebagai rangkaian acara Kamar yang tersedia ditampilkan dalam ringkasan sebelum setiap pemesanan dengan meninjau log acara.
catatan:Sebagian besar penyedia layanan cloud mendukung layanan perpesanan seperti Google Pub / Sub, Azure Service Bus, AWS SQS, dan sebagainya. Layanan ini, dikombinasikan dengan penyimpanan data yang konsisten dan kuat, dapat digunakan untuk menerapkan skema ini.
Kapan menggunakan pola ini
- Saat operasi CRUD normal tidak cukup baik untuk memenuhi persyaratan
- Biasanya cocok untuk sistem reservasi kursi seperti bus, kereta api, konferensi, bioskop, dll. - atau untuk sistem e-niaga, yang terdiri dari aktivitas seperti keranjang belanja, pembayaran, dll.
- Ketika ada kebutuhan untuk audit yang kuat dan pemutaran ulang acara untuk membuat status aplikasi saat ini dan sebelumnya.
Kapan tidak menggunakan pola ini
- Ketika operasi CRUD normal cukup baik untuk memenuhi kebutuhan pengguna.
4. Sidecar (Pola Desain Sidecar)
Pola Sidecar menjadi populer dengan munculnya layanan mikro. Dalam skema ini, komponen aplikasi disebarkan ke dalam proses atau wadah terpisah. Ini membantu mencapai abstraksi dan enkapsulasi.
Envoy Proxy adalah salah satu proxy bantuan paling populer dan banyak digunakan. Ini membantu Anda memisahkan fungsionalitas utama aplikasi dengan menggunakan mesin samping untuk mengisolasi fungsi umum seperti jaringan, observabilitas, dan keamanan.
Jenis sidecar ini dapat membantu jenis komunikasi L4 / L7 abstrak. Sidecars seperti Envoy Proxies bahkan membantu mencapai keamanan yang lebih tinggi dengan menerapkan TLS bersama.
Anda dapat menggunakan ini dalam kombinasi dengan kisi layanan untuk mencapai konektivitas dan keamanan yang lebih baik antara layanan mikro yang berbeda. Anda dapat membaca lebih lanjut tentang ini di artikel saya sebelumnya .
Kapan menggunakan pola ini
- Saat Anda berurusan dengan layanan mikro yang banyak dan heterogen dalam portofolio produk.
- Saat berhadapan dengan aplikasi legacy yang cenderung gagal menangani interoperabilitas dan tantangan keamanan era baru.
Kapan tidak menggunakan pola ini
- Ketika Anda berurusan dengan sejumlah layanan yang perlu berkomunikasi satu sama lain.
- Aplikasi kecil di mana penggunaan kursi roda samping mungkin tidak ekonomis atau tidak nyaman untuk dioperasikan
5. Backend-for-Front (BFF)
Dalam siklus pengembangan produk yang khas, teknisi back-end bertanggung jawab untuk membuat layanan yang berinteraksi dengan gudang data, sementara teknisi front-end menangani pembuatan antarmuka pengguna. Aplikasi saat ini harus dibuat dengan mempertimbangkan seluler dan desktop.
Sementara kesenjangan antara perangkat seluler dan desktop semakin dekat dalam hal perangkat keras, konektivitas dan penggunaan masih menjadi tantangan bagi perangkat seluler.
Dalam skenario seperti itu, templat BFF menjadi sangat berguna. Di sini, Anda diharapkan untuk membangun / mengkonfigurasi layanan internal untuk front-end tertentu.
Untuk mengoptimalkan kinerja klien seluler, Anda mungkin ingin membuat layanan back-end terpisah yang merespons dengan respons ringan dan paginasi.
Anda mungkin juga ingin menggunakan pola ini untuk menggabungkan berbagai layanan untuk mengurangi komunikasi data antara back-end dan front-end.
Catatan: Saat ini, jika Anda menggunakan gateway API, pola BFF dapat dengan mudah diterapkan di gateway itu sendiri, dan Anda tidak perlu menyediakan layanan terpisah.
Kapan menggunakan pola ini
- Ketika Anda ingin menyediakan produk / layanan untuk berbagai klien seperti klien desktop dan seluler.
- Saat Anda ingin mengoptimalkan respons Anda untuk jenis pelanggan tertentu.
- Ketika Anda ingin mengurangi obrolan antara klien seluler dan layanan yang berbeda.
- , .
- , .
6. Strangler ( )
Jika Anda bekerja untuk organisasi yang sedang menuju modernisasi aplikasi, maka Pola Desain Pencekik adalah suatu keharusan. Pencekik pendukung pola membangun fasad overlay di atas warisan dan aplikasi baru, memberikan konsumen kemampuan untuk melihat hal-hal secara objektif.
Pola ini memisahkan klien dari aktivitas migrasi antara bagian lama dan baru aplikasi.
Catatan: Dalam organisasi TI pada umumnya, jika Anda bermigrasi dari satu sistem ERP ke sistem ERP lainnya, jenis skema ini akan sangat berguna. Jika Anda menggunakan API gateway, akan lebih mudah untuk menerapkannya di gateway proxy itu sendiri.
Anda perlu memutuskan apakah Anda ingin mempertahankan add-in (fasad) di akhir migrasi atau menghapusnya.
Kapan menggunakan pola ini
- Saat Anda memigrasi atau meningkatkan aplikasi yang kompleks dan sangat bergantung seperti migrasi ERP
Kapan tidak menggunakan pola ini
- Ketika migrasi mudah dan penggantian langsung adalah pilihan terbaik.