Halo kolega.
Hari ini, terjemahan artikel oleh Tugberk Ugurlu, yang mengambil volume yang relatif kecil untuk menjabarkan prinsip-prinsip merancang sistem perangkat lunak modern, diusulkan ke pengadilan Anda. Inilah yang penulis katakan tentang dirinya di baris bawah:
Karena benar-benar mustahil untuk membahas topik kolosal dalam artikel arsitektur sebagai pola arsitektur + pola desain pada tahun 2019, kami merekomendasikan tidak hanya teks Mr. Jika Anda suka, kami akan menerbitkan teks yang lebih khusus tentang desain sistem terdistribusi.
Isaac Smith Ditembak dari UnsplashJika Anda tidak pernah harus menghadapi tantangan seperti merancang sistem perangkat lunak dari awal, maka ketika Anda memulai pekerjaan seperti itu, kadang-kadang bahkan tidak jelas harus mulai dari mana. Saya percaya bahwa pertama-tama Anda perlu menguraikan batas-batas untuk lebih atau kurang percaya diri membayangkan apa yang sebenarnya Anda rancang, dan kemudian menyingsingkan lengan baju Anda dan bekerja tanpa melampaui batas-batas ini. Sebagai titik awal, Anda dapat mengambil beberapa produk atau layanan (idealnya - yang sangat Anda sukai) dan memahami implementasinya. Anda mungkin kagum dengan betapa sederhananya produk ini terlihat, dan betapa rumitnya sebenarnya produk ini disembunyikan. Ingat:
sederhana biasanya rumit , dan itu normal.
Saya pikir saran terbaik yang bisa saya berikan kepada mereka yang mulai merancang sistem adalah ini: jangan membuat asumsi! Sejak awal, perlu untuk mengkonkretkan fakta-fakta yang diketahui tentang sistem ini dan harapan yang terkait dengannya. Berikut adalah beberapa pertanyaan bagus yang dapat membantu Anda memulai mendesain:
- Apa masalah yang kita coba selesaikan?
- Berapa jumlah puncak pengguna yang akan berinteraksi dengan sistem kami?
- Pola menulis dan membaca data apa yang akan digunakan bersama kami?
- Apa kegagalan yang diharapkan, bagaimana kita akan menghadapinya?
- Apa harapan untuk konsistensi dan ketersediaan sistem?
- Apakah Anda harus memperhitungkan persyaratan yang terkait dengan verifikasi dan regulasi eksternal?
- Jenis data rahasia apa yang akan kita simpan?
Ini hanya beberapa pertanyaan yang berguna bagi saya dan bagi tim-tim di mana saya memiliki kesempatan untuk berpartisipasi selama bertahun-tahun dalam kegiatan profesional. Jika Anda tahu jawaban atas pertanyaan-pertanyaan ini (dan bagi orang lain yang relevan dalam konteks di mana Anda harus bekerja), maka Anda dapat secara bertahap mempelajari rincian teknis tugas tersebut.
Atur level awalApa yang saya maksud di sini dengan "baseline"? Sebenarnya, di zaman kita, sebagian besar masalah di industri perangkat lunak dapat "diselesaikan" menggunakan metode dan teknologi yang ada. Oleh karena itu, dengan dipandu dalam lanskap ini, Anda mendapatkan awal yang pasti, dihadapkan dengan tugas-tugas yang harus diselesaikan seseorang sebelum Anda. Jangan lupa bahwa program ditulis untuk memecahkan masalah bisnis dan pengguna, jadi kami berusaha untuk memecahkan masalah dengan cara yang paling mudah dan sederhana (dari sudut pandang pengguna). Mengapa ini perlu diingat? Mungkin dalam sistem koordinat Anda, Anda ingin mencari solusi unik untuk semua tugas, karena Anda berpikir, "Programmer seperti apa saya jika saya mengikuti pola di mana-mana?" Bahkan,
seni di sini adalah membuat keputusan tentang di mana dan apa yang harus dilakukan . Tentu saja, kita masing-masing dari waktu ke waktu harus menghadapi masalah unik, yang masing-masing merupakan tantangan nyata. Namun, jika tingkat awal kita jelas digambarkan, maka kita tahu apa yang harus menghabiskan energi untuk: mencari solusi siap pakai untuk masalah yang diajukan sebelum kita, atau studi lebih lanjut dan pemahaman yang lebih dalam.
Saya pikir saya berhasil meyakinkan Anda bahwa jika seorang spesialis percaya diri memahami apa komponen arsitektur dari beberapa sistem perangkat lunak yang hebat, maka pengetahuan ini akan sangat diperlukan untuk menguasai seni seorang arsitek dan mengembangkan dasar yang kuat di bidang ini.
Oke, jadi dari mana Anda memulai?
Donna Martin memiliki repositori di GitHub yang disebut
system-design-primer , berdasarkan di mana Anda dapat mempelajari cara merancang sistem skala besar, serta mempersiapkan wawancara untuk topik ini. Repositori memiliki bagian dengan contoh-contoh
arsitektur nyata , di mana, khususnya, diperiksa bagaimana
beberapa perusahaan terkenal , seperti Twitter, Uber, dll, mendekati desain sistem mereka.
Namun, sebelum beralih ke materi ini, mari kita lihat lebih dekat tantangan arsitektur terpenting yang harus kita hadapi dalam praktik. Ini penting, karena Anda harus menentukan aspek BANYAK dari masalah yang sulit diselesaikan dan beragam, dan kemudian menyelesaikannya dalam kerangka peraturan yang berlaku dalam sistem ini.
Jackson Gabbard , mantan karyawan Facebook, merekam
video berdurasi 50 menit tentang wawancara perancangan sistem , di mana ia berbagi pengalamannya sendiri dalam meninjau ratusan pencari kerja. Terlepas dari kenyataan bahwa video secara tegas mengacu pada desain sistem besar dan kriteria keberhasilan yang penting ketika mencari kandidat untuk posisi seperti itu, namun video tersebut akan berfungsi sebagai sumber daya lengkap tentang hal-hal apa yang paling penting ketika merancang sistem. Saya juga menawarkan
ringkasan video ini.
Dapatkan pengetahuan tentang penyimpanan dan pengambilan dataSebagai aturan, keputusan Anda tentang bagaimana Anda akan menyimpan dan menampilkan data Anda untuk waktu yang lama sangat mempengaruhi kinerja sistem. Karena itu, Anda harus terlebih dahulu memahami karakteristik yang diharapkan dari menulis dan membaca data di sistem Anda. Maka Anda harus dapat mengevaluasi indikator-indikator ini dan membuat pilihan berdasarkan estimasi yang dibuat. Namun, Anda hanya dapat secara efektif mengatasi pekerjaan ini jika Anda memahami pola penyimpanan data yang ada. Pada prinsipnya, ini menyiratkan pengetahuan yang dapat diandalkan terkait dengan
pemilihan database .
Basis data dapat dianggap sebagai struktur data yang ditandai dengan skalabilitas dan daya tahan yang luar biasa. Oleh karena itu, pengetahuan tentang struktur data harus sangat berguna bagi Anda ketika memilih satu atau lain basis data. Misalnya,
Redis adalah server struktur data yang mendukung berbagai jenis nilai. Ini memungkinkan Anda untuk bekerja dengan struktur data seperti daftar dan set, membaca data menggunakan algoritma terkenal, misalnya,
LRU , mengatur pekerjaan seperti itu dalam gaya yang tahan lama dan sangat mudah diakses.
Cuplikan Samuel Zeller dari UnsplashKetika Anda memiliki pemahaman yang baik tentang berbagai pola penyimpanan data, lanjutkan untuk mempelajari konsistensi dan ketersediaan data. Pertama-tama, Anda perlu mempelajari
teorema CAP, setidaknya secara umum, dan kemudian memoles pengetahuan ini dengan memeriksa secara lebih rinci pola
konsistensi dan
aksesibilitas yang sudah ada . Dengan demikian, Anda akan mengembangkan wawasan Anda di bidang ini dan memahami bahwa membaca dan menulis data sebenarnya adalah dua masalah yang sangat berbeda, dan masing-masing memiliki tantangan tersendiri. Dipersenjatai dengan beberapa pola untuk memastikan konsistensi dan aksesibilitas, Anda dapat secara signifikan meningkatkan kinerja sistem sambil memastikan aliran data yang tidak terputus ke aplikasi Anda.
Akhirnya, menyimpulkan diskusi tentang masalah penyimpanan data, menyebutkan juga harus dibuat caching. Haruskah itu berjalan di klien dan di server? Data apa yang akan ada dalam cache Anda? Dan mengapa? Bagaimana Anda mengatur pembatalan cache? Apakah akan dilakukan secara berkala, secara berkala? Jika ya, seberapa sering? Saya sarankan memulai studi topik ini dengan bagian
selanjutnya dari primer yang disebutkan
di atas pada desain sistem.
Pola komunikasiSistem terdiri dari berbagai komponen; bisa berupa proses berbeda yang berjalan di dalam simpul fisik yang sama, atau mesin yang berbeda yang beroperasi di berbagai bagian jaringan Anda. Beberapa sumber daya ini dalam jaringan Anda mungkin bersifat pribadi, tetapi yang lain harus bersifat publik dan terbuka untuk 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, di sini, sekali lagi, kita dihadapkan dengan serangkaian tantangan unik baru. Kami mencari tahu bagaimana
aliran tugas asinkron dapat berguna, dan
berbagai pola komunikasi apa
yang tersedia .
Cuplikan Tony Stoddard dari UnsplashKetika mengatur komunikasi dengan dunia luar,
keamanan selalu sangat penting, yang juga harus didekati dengan serius dan terlibat aktif.
Distribusi KoneksiSaya tidak yakin bahwa menempatkan topik ini di bagian independen tampaknya dibenarkan untuk semua orang. Namun demikian, saya akan menguraikan konsep ini di sini, dan saya percaya bahwa materi dalam bagian ini paling akurat dijelaskan oleh istilah "distribusi koneksi".
Sistem dibentuk dengan menghubungkan banyak komponen dengan benar, dan komunikasinya dengan satu sama lain sering diatur berdasarkan protokol yang sudah ada, misalnya, TCP dan UDP. Namun, protokol ini seringkali tidak cukup untuk memenuhi semua kebutuhan sistem modern, yang sering dioperasikan di bawah beban tinggi, dan juga sangat tergantung pada kebutuhan pengguna. Sering kali perlu menemukan cara untuk mendistribusikan senyawa untuk mengatasi beban sistem yang demikian tinggi.
Distribusi ini didasarkan pada
sistem nama domain (DNS) yang terkenal. Sistem seperti ini memungkinkan Anda untuk mengonversi nama domain, misalnya, round robin tertimbang dan metode berdasarkan penundaan, yang membantu mendistribusikan beban.
Load balancing pada dasarnya penting, dan hampir semua sistem besar di Internet yang harus kita tangani saat ini terletak di belakang satu atau lebih load balancers. Load balancers membantu Anda mendistribusikan permintaan klien di banyak instance yang tersedia. Load balancers dapat berupa perangkat keras atau perangkat lunak, namun dalam praktiknya, Anda sering harus berurusan dengan perangkat lunak, misalnya,
HAProxy dan
ELB .
Proxy terbalik secara konseptual sangat mirip dengan load balancers, meskipun ada sejumlah
perbedaan yang berbeda antara yang pertama dan yang kedua. Perbedaan-perbedaan ini harus diperhitungkan ketika merancang sistem sesuai dengan kebutuhan Anda.
Anda juga harus mengetahui
jaringan pengiriman konten (CDN). CDN adalah jaringan server proxy yang didistribusikan secara global yang memberikan informasi dari node-node yang secara geografis terletak lebih dekat ke pengguna tertentu. CDN lebih disukai jika Anda bekerja dengan file statis yang ditulis dalam JavaScript, CSS, dan HTML. Selain itu, layanan cloud seperti ini sangat populer saat ini yang menyediakan manajer lalu lintas, misalnya,
Manajer Lalu Lintas Azure , yang memberi Anda distribusi global dan pengurangan penundaan saat bekerja dengan konten dinamis. Namun, layanan tersebut biasanya berguna jika Anda harus bekerja dengan layanan web tanpa menyimpan status.
Mari kita bicara tentang logika bisnis. Penataan logika bisnis, alur tugas, dan komponenJadi, kami berhasil membahas berbagai aspek infrastruktur sistem. Kemungkinan besar, pengguna bahkan tidak memikirkan semua elemen dari sistem Anda ini dan, sejujurnya, tidak mengkhawatirkannya sama sekali. Pengguna tertarik pada bagaimana berinteraksi dengan sistem Anda, apa yang dapat dicapai dengan melakukannya, dan bagaimana sistem menjalankan perintah pengguna, apa dan bagaimana melakukan dengan data pengguna.
Seperti yang tersirat dari artikel ini, saya akan menceritakan tentang arsitektur perangkat lunak dan desain sistem di dalamnya. Oleh karena itu, saya tidak berencana untuk membahas pola desain perangkat lunak yang menjelaskan bagaimana komponen perangkat lunak dibuat. Namun, semakin saya memikirkannya, semakin nampak bagi saya bahwa batas antara pola desain perangkat lunak dan pola arsitektur sangat kabur, dan kedua konsep ini saling terkait erat. Ambil, misalnya, sumber acara. Jika Anda mengadopsi pola arsitektur ini, itu akan mempengaruhi hampir semua aspek sistem Anda: penyimpanan data jangka panjang, tingkat konsistensi yang diadopsi dalam sistem Anda, garis besar komponen di dalamnya, dll., Dll. Jadi saya memutuskan untuk menyebutkan beberapa pola arsitektur yang berhubungan langsung dengan logika bisnis. Sekalipun dalam artikel ini Anda harus membatasi diri pada daftar sederhana, saya sarankan Anda membiasakan diri dengannya dan memikirkan ide-ide yang berkaitan dengan pola-pola ini. Anda disini:
Pendekatan kolaboratifSangat tidak mungkin bahwa Anda akan berakhir pada proyek sebagai peserta yang hanya bertanggung jawab atas proses desain sistem. Sebaliknya, kemungkinan besar, Anda harus berinteraksi dengan kolega yang bekerja baik di dalam tugas Anda dan di luar. Dalam hal ini, Anda mungkin perlu mengevaluasi solusi teknologi yang dipilih bersama-sama dengan kolega, mengisolasi kebutuhan bisnis dan memahami bagaimana cara menyejajarkan tugas dengan lebih baik.
Cuplikan Kaleidico dari UnsplashPertama-tama, penting untuk mengembangkan ide yang akurat dan diakui secara universal tentang apa tujuan bisnis yang ingin Anda capai, dan elemen-elemen bergerak apa yang harus Anda tangani. Teknik pemodelan grup, khususnya, event storming, dapat secara signifikan mempercepat proses ini dan meningkatkan peluang keberhasilan Anda. Anda dapat melakukan pekerjaan ini sebelum atau setelah Anda menguraikan
batas -
batas layanan Anda , dan kemudian memperdalamnya saat produk matang. Berdasarkan tingkat konsistensi yang akan dicapai di sini, Anda juga dapat merumuskan
satu bahasa untuk konteks terbatas tempat Anda bekerja. Ketika Anda perlu berbicara tentang arsitektur sistem Anda, Anda dapat menggunakan
model C4 yang diusulkan oleh
Simon Brown untuk ini , terutama ketika Anda perlu memahami berapa banyak Anda harus mempelajari rincian masalah dengan memvisualisasikan hal-hal yang ingin Anda laporkan.
Mungkin, ada teknologi matang lain dalam topik ini, yang tidak kalah bermanfaat dari desain berorientasi subjek. Namun, dengan satu atau lain cara, kami kembali untuk memahami bidang subjek, sehingga pengetahuan dan pengalaman di bidang
desain yang berorientasi pada subjek harus bermanfaat bagi Anda.