Kursus Asas Temu Duga Reka Bentuk Sistem

Temu duga reka bentuk sistem menguji cara anda mengubah idea produk yang luas menjadi pelan teknikal yang jelas. Penemuduga mahu melihat struktur, komunikasi, dan kesedaran tentang pertukaran, bukan seni bina yang dihafal. Mulakan setiap jawapan dengan mengulangi masalah dan bertanya tentang pengguna, skala, dan kekangan.

Pertama, jelaskan keperluan: siapa pengguna sistem, berapa banyak baca dan tulis setiap saat, latensi yang penting, berapa banyak data perlu disimpan, dan dari kawasan mana pengguna berasal. Catat angka ini kerana ia menentukan setiap keputusan seterusnya.

Seterusnya buat anggaran kapasiti yang mudah. Anggarkan pengguna aktif harian, permintaan sesaat, pertumbuhan storan, dan lebar jalur. Pengiraan kasar seperti QPS = DAU x tindakan sehari / saat cukup untuk memilih antara reka bentuk kecil dan besar.

Kemudian lukis reka bentuk aras tinggi: klien, pengimbang beban, perkhidmatan aplikasi, cache, baris gilir, dan pangkalan data. Labelkan setiap komponen dan terangkan aliran permintaan utama sebelum menambah butiran.

Pilih satu atau dua bidang untuk penerokaan mendalam, seperti model data, reka bentuk API, strategi pembahagian shard, atau pengendalian kegagalan. Nyatakan pertukaran yang anda optimumkan dan bandingkan sekurang-kurangnya satu alternatif sebelum membuat keputusan.

Akhiri dengan ringkasan pendek: komponen utama, risiko utama, dan perkara yang akan anda pantau. Penutup yang jelas membantu penemuduga mengikuti penaakulan anda dan menjadikan jawapan anda diingati.

Tip latihan Peta Jalan Temu Duga Reka Bentuk Sistem: Ulang kaji pelajaran ini dalam sesi pendek setiap hari. Selepas setiap latihan, sebutkan peraturan atau langkah yang anda gunakan; jika tidak dapat, ulang kaji topik itu sebelum meneruskan. Konsistensi lebih baik daripada sesi panjang.

Penskalaan ialah perkara pertama yang diuji oleh penemuduga kerana ia menghubungkan setiap komponen. Penskalaan menegak menambah kuasa pada satu mesin; penskalaan mendatar menambah lebih banyak mesin dan merupakan pilihan biasa untuk sistem web.

Pengimbang beban berada di hadapan perkhidmatan, menyemak kesihatan, dan mengarahkan trafik dengan strategi seperti round-robin atau sambungan paling sedikit. Pengimbang lapisan 7 juga boleh mengarahkan berdasarkan laluan URL dan pengepala.

Cache menyimpan data yang kerap dibaca berhampiran pemanggil. Gunakan cache-aside untuk bacaan pangkalan data: semak cache, muat dari pangkalan data jika tiada, tulis semula, dan tetapkan TTL. Pilih pengusiran LRU dan tentukan masa untuk menyahaktifkan.

CDN menghidangkan aset statik dari lokasi pinggir dan mengurangkan latensi untuk pengguna di seluruh dunia. Ia paling sesuai untuk imej, JavaScript, CSS, dan kandungan tak berubah lain.

Untuk kunci panas, satu item popular boleh membebankan satu shard cache. Sebarkan kunci ke beberapa shard atau tambah rawak pada kunci cache, dan cache tahap agregasi berbeza secara berasingan.

Contoh: suapan yang banyak dibaca boleh meletakkan API di belakang pengimbang beban, cache suapan popular dalam Redis, dan hidangkan fail statik melalui CDN. Ini mengekalkan bacaan pangkalan data rendah dan masa tindak balas stabil.

Tip latihan Kebolehskalaan, Pengimbangan Beban, dan Cache: Ulang kaji pelajaran ini dalam sesi pendek setiap hari. Selepas setiap latihan, sebutkan peraturan atau langkah yang anda gunakan; jika tidak dapat, ulang kaji topik itu sebelum meneruskan. Konsistensi lebih baik daripada sesi panjang.

Pilihan pangkalan data bergantung pada corak akses. Pangkalan data hubungan sesuai untuk transaksi berstruktur dan gabungan; stor NoSQL membantu dengan skema fleksibel, volum tulis tinggi, atau set data teragih yang besar.

Tambahkan indeks untuk laluan pertanyaan biasa dan denormalisasi model baca apabila gabungan menjadi mahal. Replika baca memindahkan trafik SELECT daripada utama, dan failover mengekalkan tulis tersedia apabila utama gagal.

Sharding membahagikan baris dengan kunci menggunakan pemisahan julat atau hash. Sharding hash mengagihkan beban secara sekata tetapi menyukarkan pertanyaan julat; sharding julat membantu lokaliti tetapi boleh mewujudkan shard panas.

Teorem CAP menyatakan sistem teragih mesti memilih antara konsistensi dan ketersediaan semasa partition. Konsistensi kuat lebih mudah dinalar, manakala konsistensi akhir berskala lebih baik dan memerlukan rekonsiliasi.

Transaksi teragih mahal. Gunakan operasi idempoten, jadual outbox, atau aliran kerja berpandukan peristiwa dan bukannya cuba menjadikan setiap tulis atomik merentas perkhidmatan.

Untuk temu duga, sebut pangkalan data, kunci shard, strategi replika, dan model konsistensi. Empat keputusan ini menunjukkan anda memahami data pada skala besar.

Tip latihan Pangkalan Data, Pembahagian Shard, dan Konsistensi: Ulang kaji pelajaran ini dalam sesi pendek setiap hari. Selepas setiap latihan, sebutkan peraturan atau langkah yang anda gunakan; jika tidak dapat, ulang kaji topik itu sebelum meneruskan. Konsistensi lebih baik daripada sesi panjang.

Reka bentuk API yang bersih menjadikan sistem lebih mudah dibina dan diselenggara. REST menggunakan sumber dan kata kerja HTTP: GET membaca, POST mencipta, PUT menggantikan, PATCH mengemas kini, dan DELETE memadam. Gunakan kod status seperti 201 untuk dicipta dan 429 untuk dihadkan kadar.

Gunakan pagination untuk koleksi besar. Pagination kursor lebih stabil apabila data berubah; pagination offset lebih ringkas tetapi boleh melangkau atau menduplikasi baris.

Had kadar melindungi API daripada penyalahgunaan. Token bucket dan gelongsor tetingkap ialah algoritma biasa, dan had sering digunakan setiap pengguna atau setiap kunci API.

Perkhidmatan mikro memecah produk kepada perkhidmatan boleh digunakan secara bebas dengan sempadan yang jelas. Elakkan berkongsi satu pangkalan data dan gunakan API gateway untuk memusatkan pengesahan, penghalaan, dan had.

Baris gilir mesej menyahgandingkan penerbit dan pengguna. Penghantaran sekurang-kurangnya sekali boleh mewujudkan pendua, jadi pengguna perlu idempoten; baris gilir mesej mati menangkap mesej yang gagal berulang kali.

Contoh: perkhidmatan pesanan menulis peristiwa ke baris gilir, perkhidmatan pembayaran memakannya, dan perkhidmatan pemberitahuan berasingan mendengar hasilnya. Setiap perkhidmatan berskala dan digunakan secara bebas.

Tip latihan REST API, Perkhidmatan Mikro, dan Baris Gilir Mesej: Ulang kaji pelajaran ini dalam sesi pendek setiap hari. Selepas setiap latihan, sebutkan peraturan atau langkah yang anda gunakan; jika tidak dapat, ulang kaji topik itu sebelum meneruskan. Konsistensi lebih baik daripada sesi panjang.

Sistem yang boleh dipercayai gagal dengan anggun. Gunakan cuba semula dengan backoff eksponen dan jitter untuk ralat sementara, dan tambah pemutus litar untuk menghentikan panggilan ke perkhidmatan yang gagal sebelum ia menghabiskan sumber.

Bulkheads mengasingkan kolam sumber supaya satu perkhidmatan perlahan tidak boleh menggunakan semua sambungan. Tetapkan masa tamat dan takrifkan tingkah laku gantian untuk ciri bukan kritikal.

Kebolehcerapan menggabungkan metrik, log, dan jejak. Metrik menunjukkan kesihatan, log menerangkan peristiwa, dan jejak teragih mengikuti satu permintaan merentas perkhidmatan. Takrifkan SLI dan SLO supaya pasukan tahu bila tindakan diperlukan.

Keselamatan harus menjadi sebahagian daripada reka bentuk: TLS untuk data dalam transit, pengesahan di gateway, akses keistimewaan paling rendah, pengurusan rahsia, dan had kadar untuk titik akhir awam.

Juga bincangkan kos dan kapasiti: saizkan contoh dengan betul, gunakan autoskala, pindahkan data sejuk ke storan lebih murah, dan elakkan sumber terbiar.

Gunakan bank 50 soalan yang dipautkan sebagai ulasan simulasi: jawab di bawah tekanan masa, kelaskan kesilapan, dan ulangi selepas 24 jam, 3 hari, dan 7 hari.

Tip latihan Kebolehpercayaan, Kebolehcerapan, dan Keselamatan: Ulang kaji pelajaran ini dalam sesi pendek setiap hari. Selepas setiap latihan, sebutkan peraturan atau langkah yang anda gunakan; jika tidak dapat, ulang kaji topik itu sebelum meneruskan. Konsistensi lebih baik daripada sesi panjang.