-
Artikel terakhir dalam seri ini ditulis untuk programmer awam. Jika Anda tidak tertarik, Anda bisa membaca beberapa paragraf terakhir artikel ini.
Sebelum mulai merancang struktur kode, mari kita tinjau apa yang telah kita persiapkan sebelumnya: kita memiliki server WEB dengan beban seimbang, server DB master-slave dan mungkin sharding, cache, dan penyimpanan yang dapat diskalakan. Semua aspek pengorganisasian kode berkaitan erat dengan persiapan ini. Saya akan mencantumkannya satu per satu, dua per tiga, dan masing-masing akan dimulai dengan kalimat klasik "disebutkan di atas" untuk memudahkan perbandingan.
Jangan terburu-buru membaca pola kalimat klasik, pikiran saya melonjak dan saya akan menyisipkan satu paragraf. Dalam pengembangan sebenarnya, kami selalu membuat kompromi antara kinerja dan keanggunan kode. Untuk komputer dan penerjemah bahasa saat ini, pertanyaan tentang berapa banyak lapisan panggilan objek dan berapa banyak lapisan panggilan objek dan apakah akan mendeklarasikan variabel sebagai Map atau HashMap adalah hal terakhir yang perlu dipertimbangkan dari bagian paling lambat. Misalnya, lihat apakah ORM yang Anda gunakan melakukan banyak hal yang tidak Anda perlukan, dan apakah ada panggilan data yang berulang. Apa yang kami lakukan adalah pengembangan aplikasi web, bukan kerangka API yang mendasarinya. Kode yang mudah dibaca dan dimengerti adalah aspek yang sangat penting untuk memastikan kualitas. Untuk apa program Anda dirancang? akan dibahas terpisah. Artikel ini terlalu jauh dari topik. Jika Anda ingin berkomunikasi, Anda dapat mengikuti Weibo saya : http://t.sina.com.cn/liuzhiyi .
Seperti disebutkan sebelumnya, server WEB perlu diseimbangkan bebannya, dan server gambar perlu dipisahkan. Mengenai hal ini, ketika kode menangani status klien, jangan letakkan status pada satu mesin. Misalnya, jangan gunakan sesi file. Jika memungkinkan, yang terbaik adalah mengembangkan antarmuka terpadu untuk otentikasi titik tunggal pengguna dari awal, termasuk cara menentukan status di seluruh domain, cara menentukan status pada halaman statis, dan definisi parameter lompat dan kembali saat masuk . Sediakan antarmuka yang baik di lapisan bawah dan terapkan Lapisan tersebut digunakan secara langsung (lihat layanan pengguna GAE). Desain login harus mempertimbangkan karakteristik perangkat seluler. Misalnya, komputer dapat menggunakan jendela lapisan mengambang, tetapi browser NOKIA atau UCWEB tidak dapat menangani bentuk ekspresi ini. Program harus mampu menangani permintaan Ajax dan langsung melalui URL . bertanya. Server gambar dipisahkan, dan file sumber daya paling baik ditempatkan di server gambar, yaitu server WEB hanya melayani program dinamis. Meskipun agak rumit untuk dikembangkan dan diuji (karena diperlukan URI absolut untuk mengaksesnya), akan lebih mudah untuk mengoptimalkan front-end halaman di masa mendatang, dan optimalisasi IO server WEB Anda juga akan lebih mudah. menjadi jauh lebih mudah. Ketika program mereferensikan file sumber daya, harus ada metode pemrosesan terpadu. Banyak hal yang dapat diselesaikan secara otomatis dalam metode ini, seperti menggabungkan CSS/js ke dalam file, atau secara otomatis menambahkan QUERYSTRING setelah URI yang dihasilkan layanan cache digunakan, menghasilkan QUERYSTRING adalah cara paling sederhana untuk menyegarkan cache server dan cache klien.
Seperti disebutkan sebelumnya, database akan direplikasi, mungkin memiliki banyak master dan banyak budak, dan mungkin dipecah. Dalam proses pemrosesan data dalam program kami, yang terbaik adalah mengabstraksikannya dan meletakkannya di lapisan terpisah. Ambil contoh model MVC yang populer, yaitu meletakkan lapisan data di bawah lapisan M. Lapisan data ini bukanlah JDBC/PDO/ActiveRecord, dll., tetapi lapisan data akses Anda sendiri, yang hanya memaparkan metode ke dalamnya. Sembunyikan detail akses data. Jangan takut dengan tulisan jelek di dalam lapisan data ini, tetapi lapisan ini harus menyediakan semua fungsi penyimpanan data. Alasannya adalah bahwa dalam kasus database relasional tunggal, Anda dapat SELECT...JOIN...atau secara langsung INSERT...INTO..., namun Anda dapat menyimpan beberapa tabel dalam database nilai kunci, atau shardingkan mereka setelah itu, semua pernyataan dan metode asli perlu diubah. Jika terlalu tersebar, banyak usaha yang akan dikeluarkan selama transplantasi, atau Model yang sangat besar akan diperoleh. Dalam hal desain tingkat data, cobalah untuk menghindari kueri GABUNG. Kita dapat melakukan lebih banyak redundansi dan caching. Setiap jenis data hanya memerlukan satu kueri dan kemudian menggabungkannya dalam program Anda. Untuk kombinasi data yang lebih kompleks, ketika persyaratan waktu nyata tidak tinggi, pemrosesan asinkron dapat digunakan, dan pengguna hanya mendapatkan hasil yang diproses saat mengakses. Saat menangani kunci utama, hindari penggunaan ID yang bertambah secara otomatis dan gunakan nilai unik yang dihasilkan oleh aturan tertentu sebagai kunci utama. Kunci utama ini adalah strategi distribusi sharding yang paling sederhana. Bahkan jika Anda menggunakan ID kenaikan otomatis, yang terbaik adalah menggunakan generator ID kenaikan otomatis. Jika tidak, jika database budak ditulis secara tidak sengaja, kunci utama akan mudah konflik.
Seperti disebutkan sebelumnya, ada beberapa cache yang memblokir bagian depan database kami. Jangan perlakukan cache query MySQL sebagai cache. Ketika aplikasinya sedikit rumit, QUERY CACHE akan menjadi beban. Caching terintegrasi erat dengan database dan bisnis. Karena terkait erat dengan bisnis, tidak ada pendekatan yang bisa diterapkan untuk semua. Namun kami masih memiliki beberapa aturan yang harus dipatuhi. Aturan 1: Semakin dekat ke ujung depan, semakin besar perincian cache. Misalnya, seluruh halaman di-cache di ujung depan WEB, sebagian halaman di-cache di tingkat berikutnya, dan satu catatan di area tersebut di-cache di tingkat berikutnya. Karena semakin dekat kita dengan backend, semakin fleksibel pengoperasiannya, dan kode front-end yang paling banyak berubah akan lebih mudah untuk ditulis. Dalam praktiknya, karena persyaratan produk berubah dengan sangat cepat dan siklus iterasi semakin pendek, terkadang sulit untuk membedakan dengan jelas Pengontrol dan Model. Caching parsial tidak dapat dihindari di tingkat Pengontrol, tetapi hal ini perlu dipastikan terjadi, Pengendali Cache yang dioperasikan tidak boleh mempengaruhi pihak lain yang meminta data, yaitu harus dipastikan bahwa data cache ini hanya digunakan oleh Pengendali ini. Aturan 2: Program tidak dapat membuat kesalahan tanpa melakukan cache. Jika tidak mempertimbangkan efek longsoran salju yang disebabkan oleh pembatalan cache, program Anda harus memiliki cache dan sama seperti tanpa cache. Tidak bisa seperti Sina Weibo. Setelah cache gagal, kipas weibo akan kosong dan seluruh aplikasi akan kosong kacau. Ketika caching sangat penting, memberikan pesan kesalahan kepada pengguna lebih baik daripada memberikan pesan yang menyesatkan. Aturan 3: Pembaruan cache harus bersifat atomik atau thread-safe. Terutama ketika caching pasif digunakan, kemungkinan besar cache yang sama akan diperbarui ketika dua pengguna mengaksesnya setelah habis masa berlakunya. Ini mungkin salah satu penyebab reaksi berantai. Aturan 4: Caching juga memerlukan biaya. Bukan hanya biaya teknologi, tapi juga biaya waktu tenaga kerja. Jika suatu fungsi menggunakan caching dan tidak menggunakannya, perbedaan volume akses yang dapat diperkirakan kecil, namun menggunakan caching akan meningkatkan kompleksitas, maka kita tidak perlu menambahkan tanda TODO dan menambahkan pemrosesan caching pada iterasi berikutnya.
Seperti disebutkan sebelumnya, penyimpanan file bersifat independen, sehingga semua operasi file merupakan panggilan jarak jauh. Anda dapat menyediakan antarmuka RESTful yang sangat sederhana di server file, atau Anda dapat menyediakan layanan xmlrpc atau json. Semua file yang dihasilkan dan diproses oleh server WEB diberitahukan ke server file melalui antarmuka untuk diproses untuk menyediakan penyimpanan file apa pun. Anda akan menemukan bahwa mengunggah gambar dan menyimpan artikel di banyak situs besar diselesaikan dalam dua langkah, karena alasan ini.
Hal "yang disebutkan sebelumnya" di atas sebenarnya telah dikatakan oleh banyak orang. Saya hanya mengulanginya dengan kata-kata saya sendiri berdasarkan artikel sebelumnya. Inti dari analisis sebenarnya sangat sederhana - selain lapisan logika fungsional yang baik, kita juga memerlukan Desain antarmuka terpisah untuk panggilan sumber daya eksternal seperti penyimpanan basis data, caching, antrian, dan layanan file. Anda dapat membayangkan program Anda berjalan di Amazon EC2 dan menggunakan semua layanan webnya. Basis data Anda adalah SimpleDB-nya penyimpanannya adalah S3 miliknya. Satu-satunya perbedaan adalah antarmuka Amazon adalah panggilan jarak jauh, dan antarmuka Anda adalah panggilan internal.
Antarmuka layanan dukungan berarti mengganti MySQL dengan PostgreSQL tidak memerlukan perubahan pada program pemrosesan bisnis, dan tim migrasi bahkan tidak perlu terlalu banyak berkomunikasi dengan tim pengembangan bisnis, yang berarti tim pengembangan bisnislah yang memprogram antarmuka; daripada memprogram database; itu berarti Kinerja tidak akan melambat karena kesalahan pengembang bisnis.
Jika Anda tidak tertarik dengan literasi program, lihat saja di sini—
Setelah desain produk selesai dan kerangka program dibangun, konflik mungkin timbul pada saat ini. Ada keluhan terus-menerus dari desainer produk bahwa ide mereka tidak mencapai hasil yang diinginkan, dan pemrogram mengeluh bahwa desain produk tidak realistis. Keluhan seperti ini sebagian besar disebabkan karena personel produk tidak memahami teknologi dan personel teknis tidak memahami produk. Dalam arti luas, produk mencakup strategi pasar, metode pemasaran, dan desain fungsional. Ketika berdebat tentang produk dan teknologi, fokusnya sering kali pada fungsi, namun fokus sebenarnya adalah pada biaya untuk mewujudkan fungsi ini dan manfaat dari fungsi tersebut. dapat membawa. Apakah dapat dikonversi dan apakah dapat dijadikan pertimbangan. Jika memungkinkan, selesaikan perselisihan tersebut. Jika tidak, lempar koin dan lihat keberuntungan. Ada banyak contoh indikator meledak karena peningkatan suatu fungsi, atau penundaan pertempuran karena penundaan proyek. Pengambil keputusan yang radikal fokus pada keuntungan, pengambil keputusan yang konservatif fokus pada kerugian, dan pengambil keputusan yang cerdas akan mempertimbangkan apakah masalahnya benar-benar serius.
Tidak ada yang bisa memprediksi apa yang akan terjadi di masa depan. Kalau tidak, separuh dari memulai bisnis bergantung pada keberuntungan. Namun selalu ada hal yang dapat diungkapkan secara akurat, dan Anda harus mengandalkan data untuk menjelaskannya sendiri.
Tidak 100%, tetapi 99,9% situs web telah memasang kode statistik akses, bahkan http://zhiyi.us saya tidak terkecuali, dan Jaringan Xinwen selalu berbicara tentang pengambilan keputusan ilmiah dan pengembangan ilmiah. Dengan statistik, banyak hal yang bisa ditentukan. Misalnya, Anda dapat menganalisis saluran mana yang memiliki biaya akuisisi per kapita terendah berdasarkan rasio konversi target sumber, menebak alasan rasio pentalan pengguna berdasarkan akses konten sumber, dan menentukan apakah posisi tautan masuk akal berdasarkan klik pengguna perilaku. Gabungkan data dengan berbagai cara untuk menemukan hubungan internal, menganalisis faktor internal dan eksternal, merumuskan strategi yang sesuai, dan mengurangi keputusan yang tidak tepat sasaran. Mengandalkan data untuk mendukung operasi adalah hal yang sangat profesional. Meskipun saya tidak memahami model matematika yang mendalam dan perhitungan rumus yang rumit, lambat laun saya mengetahui bahwa B karena A, dan C karena A dan B. Itu masih relatif sederhana. .
Penulis artikel: Liu Zhiyi (harap sebutkan tautan sumber dan penulisnya saat mencetak ulang)
Sumber artikel: http://zhiyi.us/