Sebagai seorang insinyur web, saya paling fokus pada kinerja dan arsitektur. Untungnya, saya berpartisipasi dalam konferensi sd2.0 kali ini dan dapat berkomunikasi secara luas dengan rekan-rekan saya pengalaman desain arsitektur kepada saya sendiri. Dibagikan oleh teman-teman, artikel ini adalah pengalaman mengikuti konferensi ini dan berkomunikasi dengan orang lain.
Beberapa pemikiran tentang desain arsitektur:
1. Jangan pernah berlebihan dalam mendesain: jangan pernah berlebihan dalam mendesain
Ini adalah topik yang sering disebutkan, tetapi selama Anda memikirkan berapa banyak fungsi dalam arsitektur Anda yang tidak digunakan sama sekali, atau akhirnya ditinggalkan, Anda dapat memahami pentingnya fungsi tersebut saat pertama kali terlibat dalam desain arsitektur cenderung merancang desain berskala besar. Sedangkan untuk arsitektur Huayi, kami berharap dapat merancang arsitektur tambahan yang sangat terukur dan dapat beradaptasi dengan semua kebutuhan. Bidang pengembangan web adalah proses yang sangat dinamis perubahan minggu depan, dan kita perlu merespons perubahan tersebut secepat mungkin.
Insinyur eBay mengatakan bahwa desain arsitektur mereka tidak pernah mampu memenuhi pertumbuhan sistem, sehingga sistem mereka selalu dibalik dan diperbaiki. Perlu diketahui bahwa tidak ada masalah dengan kemampuan arsitek eBay. Arsitektur yang mereka rancang selalu dibangun di atas hambatan versi lama, dengan harapan arsitektur baru akan membawa terobosan dalam waktu singkat. Karena kewalahan dengan tuntutan baru, mereka harus menggunakan arsitektur baru
Pengembangan web adalah proses yang sangat cepat. Perubahan terjadi kapan saja. Kebutuhan pengguna selalu berubah. Dalam banyak aspek, kontingensi sangat tinggi. Dibandingkan dengan pengembangan perangkat lunak, tidak realistis untuk berharap menggunakan satu arsitektur untuk merencanakan semua desain di masa depan.
2. siklus hidup arsitektur web: siklus hidup arsitektur web
Karena kita perlu menghilangkan desain yang berlebihan dan memastikan tingkat pandangan ke depan tertentu, bagaimana kita bisa menemukan keseimbangan? Saya harap siklus hidup arsitektur web berikut dapat membantu Anda.
Arsitektur yang dirancang harus mampu menangani pertumbuhan 1-10 kali lipat hanya dengan meningkatkan kapasitas perangkat keras. Selama periode pertumbuhan 5-10 kali lipat, silakan mulai merancang versi arsitektur berikutnya agar dapat bertahan 10 kali lipat berikutnya. pertumbuhan ganda
Alasan mengapa Google bisa mendominasi tidak sepenuhnya karena canggihnya teknologi pencarian dan teknologi penyortiran. Faktanya, termasuk Baidu dan Yahoo, teknologi yang digunakan kini serupa. Namun, Google bisa mencapainya dengan menambahkan puluhan ribu server di dalamnya per bulan. Kemampuan kapasitas sistem yang memadai memang sulit untuk ditiru
3. Tembolok: Tembolok
Ruang ditukar dengan waktu. Cache selalu menjadi prioritas utama dalam desain komputer. Dari CPU hingga IO, cache dapat dilihat di mana saja. Desain arsitektur web itu penting, dan desain cache itu penting jbosscache Pendiri Taobao mengatakan ini: Faktanya, desain cache web dan cache tingkat perusahaan sangat berbeda. Cache tingkat perusahaan berfokus pada logika, sedangkan cache web sederhana dan cepat. .
Apa masalah yang disebabkan oleh caching? Ini adalah peningkatan kompleksitas program. Karena data tersebar di beberapa proses, sinkronisasi adalah masalah yang menyusahkan. Dengan penambahan cluster, kompleksitasnya akan semakin meningkat digunakan? Strategi seringkali harus dikaitkan dengan bisnis
Laoqian merancang cache daftar tertaut untuk postingan yang dirancang oleh Sohu, yang tidak hanya dapat memenuhi kebutuhan penyisipan yang fleksibel, tetapi juga memungkinkan pembacaan cepat. Beberapa komunitas besar lainnya sering menggunakan struktur serupa untuk mengoptimalkan daftar postingan. alat
Tautan: Video Qian Hongwu tentang desain arsitektur http://211.100.26.82/CSDN_Live/140/qhw.flv
Strategi umum Cache adalah menyimpan data di memori, bukan di disk yang lebih memakan waktu. Dari perspektif ini, mesin heap (metode penyimpanan) yang disediakan oleh MySQL juga merupakan metode yang patut dipertimbangkan. Metode penyimpanan ini dapat menyimpan data dalam memori dan mempertahankan kemampuan kueri SQL yang kuat.
Kami hanya berbicara tentang read caching di sini. Faktanya, ada juga write cache, yang jarang digunakan di komunitas berorientasi konten, karena masalah utama yang perlu diselesaikan oleh komunitas tersebut adalah masalah baca, tetapi ketika kapasitas pemrosesan lebih rendah. daripada kapasitas permintaan Ketika, atau ketika satu permintaan di-cache untuk membentuk blok dan kemudian diproses dalam batch, cache tulis muncul. Kita dapat dengan mudah menemukan cache seperti itu dalam desain komunitas yang sangat interaktif.
Keempat, modul inti harus dikembangkan sendiri: Buat sendiri modul inti Anda
Kami sangat menyadari hal ini. Qian Hongwu dan Yunfeng juga menyebutkan bahwa kami sering cenderung menggunakan beberapa modul open source. Jika modul inti tidak terlibat, itu memang mungkin Ketika jumlah kunjungan mencapai tingkat tertentu, modul-modul ini sering kali memiliki masalah dalam satu atau lain bentuk. Tentu saja, kita dapat mengaitkan masalah tersebut dengan ketidaktahuan dengan modul sumber terbuka, tetapi bagaimanapun juga, ketika ada masalah dengan intinya, itu akan terjadi. sangat menakutkan untuk tidak sepenuhnya memahami kodenya.
5. Penyimpanan data yang wajar: penyimpanan data yang wajar
Apakah kita harus menggunakan database? Belum tentu. Lei Ming memberi tahu kita bahwa pencarian tidak selalu memerlukan database. Yunfeng memberi tahu kita bahwa game tidak selalu memerlukan database menggantinya?
Pertama-tama, kita perlu mengakui bahwa database juga beroperasi pada file. Kita memerlukan database, terutama untuk menggunakan fungsi-fungsi berikut, yang pertama adalah penyimpanan data, dan yang lainnya adalah pengambilan data. Dalam database relasional, kami sebenarnya sangat memperhatikan kemampuan pencarian database yang kompleks. Tidak perlu membaca dengan seksama, cukup meliriknya saja)
pilih c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(pilih count(Id) dari review dimana Reviewid=a.Id) sebagai countNum dari Creativity sebagai a,User_info sebagai b,class sebagai c,class2 sebagai d dimana a.user_id=b.id dan a.Creativity_Class=c.Id dan a.Creativity_Class_2=d.Id
pilih a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum dari Kreativitas sebagai a,User_info sebagai b ,kelas sebagai c,kelas2 sebagai d,review sebagai e dimana a.user_id=b.id dan a.Creativity_Class=c.Id dan a.Creativity_Class_2=d.Id dan a.Id=e.Reviewid dikelompokkan berdasarkan a.Id … ………………………………….