Arsitektur Perangkat Lunak dan Desain Sistem: Gambaran Besar dan Panduan Sumber Daya

Halo rekan-rekan.

Hari ini kami menawarkan untuk pertimbangan Anda terjemahan artikel oleh Tugberk Ugurlu, yang berupaya menguraikan dalam volume yang relatif kecil prinsip-prinsip merancang sistem perangkat lunak modern. Inilah yang penulis katakan tentang dirinya secara ringkas:

Arsitektur Perangkat Lunak dan Desain Sistem: Gambaran Besar dan Panduan Sumber Daya
Karena sangat tidak mungkin untuk meliput dalam artikel habro topik kolosal seperti pola arsitektur + pola desain pada tahun 2019, kami merekomendasikan tidak hanya teks Pak Uruglu sendiri, tetapi juga banyak tautan yang dengan baik hati ia sertakan di dalamnya. Jika Anda menyukainya, kami akan menerbitkan teks yang lebih khusus tentang desain sistem terdistribusi.

Arsitektur Perangkat Lunak dan Desain Sistem: Gambaran Besar dan Panduan Sumber Daya

Foto Isaac Smith dari Unsplash

Jika Anda belum pernah menghadapi tantangan seperti merancang sistem perangkat lunak dari awal, maka ketika memulai pekerjaan tersebut, terkadang tidak jelas harus mulai dari mana. Saya percaya bahwa pertama-tama Anda perlu menarik batasan sehingga Anda memiliki gagasan yang lebih atau kurang yakin tentang apa sebenarnya yang akan Anda desain, dan kemudian menyingsingkan lengan baju Anda dan bekerja dalam batasan tersebut. Sebagai titik awal, Anda dapat mengambil produk atau layanan (idealnya produk atau layanan yang benar-benar Anda sukai) dan mencari cara untuk menerapkannya. Anda mungkin akan takjub melihat betapa sederhananya tampilan produk ini, dan betapa rumitnya kandungan di dalamnya. Jangan lupa: sederhana - biasanya rumit, dan tidak apa-apa.

Saya pikir saran terbaik yang bisa saya berikan kepada siapa pun yang mulai merancang sistem adalah: jangan membuat asumsi apa pun! Sejak awal, Anda perlu menentukan fakta yang diketahui tentang sistem ini dan ekspektasi yang terkait dengannya. Berikut adalah beberapa pertanyaan bagus untuk ditanyakan guna membantu Anda memulai desain Anda:

  • Masalah apa yang ingin kita selesaikan?
  • Berapa jumlah puncak pengguna yang akan berinteraksi dengan sistem kami?
  • Pola penulisan dan pembacaan data apa yang akan kita gunakan?
  • Kasus kegagalan apa saja yang mungkin terjadi, bagaimana kita akan menanganinya?
  • Apa yang diharapkan dari konsistensi dan ketersediaan sistem?
  • Apakah Anda harus mempertimbangkan persyaratan terkait verifikasi dan regulasi eksternal saat bekerja?
  • Jenis data sensitif apa yang akan kami simpan?

Ini hanyalah beberapa pertanyaan yang berguna bagi saya dan tim tempat saya berpartisipasi selama bertahun-tahun dalam aktivitas profesional. Jika Anda mengetahui jawaban atas pertanyaan-pertanyaan ini (dan pertanyaan lain yang relevan dengan konteks di mana Anda harus bekerja), maka Anda dapat secara bertahap mempelajari rincian teknis masalahnya.

Tetapkan level awal

Apa yang saya maksud dengan β€œdasar” di sini? Sebenarnya, di zaman kita, sebagian besar masalah dalam industri perangkat lunak β€œdapat” diselesaikan dengan menggunakan metode dan teknologi yang ada. Oleh karena itu, dengan menavigasi lanskap ini, Anda memiliki keunggulan tertentu ketika menghadapi masalah yang harus diselesaikan oleh orang lain sebelum Anda. Jangan lupa bahwa program ditulis untuk menyelesaikan masalah bisnis dan pengguna, jadi kami berusaha menyelesaikan masalah tersebut dengan cara yang paling mudah dan sederhana (dari sudut pandang pengguna). Mengapa hal ini penting untuk diingat? Mungkin dalam sistem koordinat Anda, Anda suka mencari solusi unik untuk semua masalah, karena Anda berpikir, β€œprogrammer macam apa saya ini jika saya mengikuti pola di mana pun”? Nyatanya, seni di sini adalah membuat keputusan tentang di mana dan apa yang harus dilakukan. Tentu saja, masing-masing dari kita harus menghadapi masalah unik dari waktu ke waktu, yang masing-masing merupakan tantangan nyata. Namun, jika tingkat awal kita terdefinisi dengan jelas, maka kita tahu apa yang harus kita habiskan energinya: mencari pilihan yang sudah jadi untuk memecahkan masalah yang ada di hadapan kita, atau mempelajarinya lebih lanjut dan mendapatkan pemahaman yang lebih dalam.

Saya rasa saya dapat meyakinkan Anda bahwa jika seorang spesialis dengan percaya diri memahami apa itu komponen arsitektur dari beberapa sistem perangkat lunak yang luar biasa, maka pengetahuan ini akan sangat diperlukan untuk menguasai seni seorang arsitek dan mengembangkan dasar yang kokoh di bidang ini.

Oke, jadi harus mulai dari mana? kamu Donna Martina Ada repositori di GitHub bernama primer desain sistem, dari sana Anda dapat mempelajari cara merancang sistem berskala besar, serta mempersiapkan wawancara mengenai topik ini. Repositori memiliki bagian dengan contoh arsitektur nyata, yang secara khusus mempertimbangkan pendekatan mereka dalam merancang sistem mereka beberapa perusahaan terkenalmisalnya Twitter, Uber, dll.

Namun, sebelum beralih ke materi ini, mari kita lihat lebih dekat tantangan arsitektur terpenting yang kita hadapi dalam praktiknya. Hal ini penting karena Anda harus menentukan BANYAK aspek dari suatu masalah yang membandel dan memiliki banyak segi, dan kemudian menyelesaikannya dalam kerangka peraturan yang berlaku dalam sistem tertentu. Jackson Gabbard, seorang mantan karyawan Facebook, menulis Video berdurasi 50 menit tentang wawancara desain sistem, di mana dia berbagi pengalamannya menyaring ratusan pelamar. Meskipun video ini sangat berfokus pada desain sistem yang besar dan kriteria keberhasilan yang penting ketika mencari kandidat untuk posisi tersebut, video ini tetap berfungsi sebagai sumber daya komprehensif tentang hal-hal yang paling penting ketika merancang sistem. Saya juga menyarankan ringkasan video ini.

Membangun pengetahuan tentang menyimpan dan mengambil data

Biasanya, keputusan Anda tentang cara menyimpan dan mengambil data dalam jangka panjang memiliki dampak penting pada kinerja sistem. Oleh karena itu, Anda harus terlebih dahulu memahami karakteristik tulis dan baca yang diharapkan dari sistem Anda. Kemudian Anda harus bisa mengevaluasi indikator-indikator tersebut dan menentukan pilihan berdasarkan penilaian yang dilakukan. Namun, Anda dapat mengatasi pekerjaan ini secara efektif hanya jika Anda memahami pola penyimpanan data yang ada. Pada prinsipnya, ini menyiratkan pengetahuan yang kuat terkait dengan pemilihan basis data.

Basis data dapat dianggap sebagai struktur data yang sangat terukur dan tahan lama. Oleh karena itu, pengetahuan tentang struktur data akan sangat berguna bagi Anda ketika memilih database tertentu. Misalnya, Redis adalah server struktur data yang mendukung berbagai jenis nilai. Ini memungkinkan Anda untuk bekerja dengan struktur data seperti daftar dan kumpulan, dan membaca data menggunakan algoritma terkenal, misalnya, LRU, mengatur pekerjaan semacam itu dengan gaya yang tahan lama dan sangat mudah diakses.

Arsitektur Perangkat Lunak dan Desain Sistem: Gambaran Besar dan Panduan Sumber Daya

Foto Samuel Zeller dari Unsplash

Setelah Anda memiliki pemahaman yang memadai tentang berbagai pola penyimpanan data, lanjutkan mempelajari konsistensi dan ketersediaan data. Pertama-tama, Anda perlu memahaminya teorema CAP setidaknya secara umum, dan kemudian memoles pengetahuan ini dengan mencermati pola-pola yang sudah ada konsistensi ΠΈ aksesibilitas. Dengan cara ini, Anda akan mengembangkan pemahaman lapangan dan memahami bahwa membaca dan menulis data sebenarnya adalah dua masalah yang sangat berbeda, masing-masing memiliki tantangan uniknya sendiri. Berbekal beberapa pola konsistensi dan ketersediaan, Anda dapat meningkatkan kinerja sistem secara signifikan sekaligus memastikan kelancaran aliran data ke aplikasi Anda.

Terakhir, sebagai penutup pembicaraan tentang masalah penyimpanan data, kami juga harus menyebutkan caching. Haruskah ini dijalankan secara bersamaan di klien dan server? Data apa yang akan ada di cache Anda? Dan mengapa? Bagaimana Anda mengatur pembatalan cache? Apakah akan dilakukan secara rutin, dengan interval tertentu? Jika ya, seberapa sering? Saya sarankan mulai mempelajari topik-topik ini dengan bagian berikutnya primer desain sistem yang disebutkan di atas.

Pola Komunikasi

Sistem terdiri dari berbagai komponen; ini bisa berupa proses berbeda yang berjalan dalam node fisik yang sama, atau mesin berbeda yang berjalan di bagian berbeda jaringan Anda. Beberapa sumber daya dalam jaringan Anda mungkin bersifat pribadi, namun sumber daya lainnya harus bersifat publik dan terbuka bagi konsumen yang mengaksesnya dari luar.

Penting untuk memastikan komunikasi sumber daya ini satu sama lain, serta pertukaran informasi antara seluruh sistem dan dunia luar. Dalam konteks desain sistem, sekali lagi kita dihadapkan pada serangkaian tantangan baru dan unik. Mari kita lihat bagaimana manfaatnya aliran tugas asinkron, dan apa halBerbagai pola komunikasi tersedia.

Arsitektur Perangkat Lunak dan Desain Sistem: Gambaran Besar dan Panduan Sumber Daya

Foto Tony Stoddard dari Unsplash

Saat mengatur komunikasi dengan dunia luar, ini selalu sangat penting Keamanan, yang penyediaannya juga perlu ditanggapi dengan serius dan diupayakan secara aktif.

Distribusi koneksi

Saya tidak yakin bahwa menempatkan topik ini di bagian terpisah akan tampak dibenarkan bagi semua orang. Namun demikian, saya akan menyajikan konsep ini secara rinci di sini, dan saya yakin materi di bagian ini paling tepat dijelaskan dengan istilah β€œdistribusi koneksi”.

Sistem dibentuk dengan menghubungkan banyak komponen dengan benar, dan komunikasinya satu sama lain sering kali diatur berdasarkan protokol yang sudah ada, misalnya TCP dan UDP. Namun, protokol-protokol ini seringkali tidak cukup untuk memenuhi semua kebutuhan sistem modern, yang sering kali dioperasikan di bawah beban tinggi dan juga sangat bergantung pada kebutuhan pengguna. Seringkali perlu menemukan cara untuk mendistribusikan koneksi untuk mengatasi beban tinggi pada sistem.

Distribusi ini didasarkan pada yang terkenal sistem nama domain (DNS). Sistem seperti ini memungkinkan transformasi nama domain seperti round robin berbobot dan metode berbasis latensi untuk membantu mendistribusikan beban.

Penyeimbang beban pada dasarnya penting, dan hampir setiap sistem Internet besar yang kita gunakan saat ini terletak di belakang satu atau lebih penyeimbang beban. Penyeimbang beban membantu mendistribusikan permintaan klien ke beberapa instans yang tersedia. Penyeimbang beban hadir dalam perangkat keras dan perangkat lunak, namun, dalam praktiknya, Anda lebih sering harus berurusan dengan perangkat lunak, misalnya HAProxy ΠΈ ELB. Membalikkan proxy secara konseptual juga sangat mirip dengan penyeimbang beban, meskipun ada rentang antara yang pertama dan kedua perbedaan yang nyata. Perbedaan-perbedaan ini harus diperhitungkan ketika merancang sistem berdasarkan kebutuhan Anda.

Anda juga harus tahu tentang jaringan pengiriman konten (CDN). CDN adalah jaringan server proxy terdistribusi global yang mengirimkan informasi dari node yang secara geografis terletak lebih dekat dengan pengguna tertentu. CDN lebih baik digunakan jika Anda bekerja dengan file statis yang ditulis dalam JavaScript, CSS, dan HTML. Selain itu, layanan cloud yang menyediakan pengelola lalu lintas sudah umum saat ini, misalnya, Manajer Lalu Lintas Azure, memberi Anda distribusi global dan mengurangi latensi saat bekerja dengan konten dinamis. Namun, layanan seperti itu biasanya berguna jika Anda harus bekerja dengan layanan web tanpa kewarganegaraan.

Mari kita bicara tentang logika bisnis. Penataan logika bisnis, alur tugas dan komponen

Jadi, kami berhasil mendiskusikan berbagai aspek infrastruktur sistem. Kemungkinan besar, pengguna bahkan tidak memikirkan semua elemen sistem Anda ini dan, sejujurnya, tidak mempedulikannya sama sekali. Pengguna tertarik dengan bagaimana rasanya berinteraksi dengan sistem Anda, apa yang dapat dicapai dengan melakukan hal ini, dan juga bagaimana sistem menjalankan perintah pengguna, apa dan bagaimana fungsinya dengan data pengguna.

Sesuai dengan judul artikel ini, saya akan berbicara tentang arsitektur perangkat lunak dan desain sistem. Oleh karena itu, saya tidak berencana untuk membahas pola desain perangkat lunak yang menggambarkan bagaimana komponen perangkat lunak dibuat. Namun, semakin saya memikirkannya, semakin saya merasa bahwa garis antara pola desain perangkat lunak dan pola arsitektur sangat kabur, dan kedua konsep tersebut terkait erat. Mari kita ambil contoh pendaftaran acara (sumber acara). Setelah Anda mengadopsi pola arsitektur ini, hal itu akan memengaruhi hampir setiap aspek sistem Anda: penyimpanan data jangka panjang, tingkat konsistensi yang diterapkan dalam sistem Anda, bentuk komponen di dalamnya, dll., dll. Oleh karena itu, saya memutuskan untuk menyebutkan beberapa pola arsitektur yang berhubungan langsung dengan logika bisnis. Meskipun artikel ini harus dibatasi pada daftar sederhana, saya mendorong Anda untuk mengenalnya dan memikirkan ide-ide yang terkait dengan pola-pola ini. Ini dia:

Pendekatan kolaboratif

Sangat kecil kemungkinannya Anda akan terlibat dalam suatu proyek sebagai peserta yang bertanggung jawab penuh atas proses desain sistem. Sebaliknya, kemungkinan besar Anda harus berinteraksi dengan rekan kerja yang bekerja di dalam dan di luar tugas Anda. Dalam hal ini, Anda mungkin perlu mengevaluasi solusi teknologi yang dipilih bersama rekan kerja, mengidentifikasi kebutuhan bisnis, dan memahami cara terbaik untuk memparalelkan tugas.

Arsitektur Perangkat Lunak dan Desain Sistem: Gambaran Besar dan Panduan Sumber Daya

Foto kaleidico dari Unsplash

Langkah pertama adalah mengembangkan pemahaman yang akurat dan bersama tentang tujuan bisnis yang ingin Anda capai dan bagian penting apa yang harus Anda tangani. Teknik pemodelan kelompok, khususnya peristiwa badai (event storming) membantu mempercepat proses ini secara signifikan dan meningkatkan peluang kesuksesan Anda. Pekerjaan ini dapat dilakukan sebelum atau sesudah Anda membuat kerangka batasan layanan Anda, dan kemudian memperdalamnya saat produk matang. Berdasarkan tingkat konsistensi yang ingin dicapai di sini, Anda juga bisa merumuskannya bahasa umum untuk konteks terbatas tempat Anda bekerja. Saat Anda perlu berbicara tentang arsitektur sistem Anda, mungkin ini berguna model C4, diajukan Simon Brown, terutama ketika Anda perlu memahami seberapa jauh Anda harus menjelaskan secara detail masalahnya, memvisualisasikan hal-hal yang ingin Anda komunikasikan.

Mungkin ada teknologi matang lainnya dalam topik ini yang tidak kalah bermanfaatnya dengan Desain Berbasis Domain. Namun, entah bagaimana kita kembali pada pemahaman bidang studi, jadi pengetahuan dan pengalaman di lapangan Desain Berbasis Domain seharusnya berguna bagi Anda.

Sumber: www.habr.com

Tambah komentar