เราจะไม่หารือว่าเป็นสภาพแวดล้อม PHP, JSP หรือ. NET ที่นี่หรือไม่ เราดูปัญหาจากมุมมองของสถาปัตยกรรม การใช้ภาษาไม่ใช่ปัญหา ข้อได้เปรียบของภาษาอยู่ในการนำไปใช้มากกว่าดีหรือไม่ดี ไม่ว่าคุณจะเลือกภาษาใดสถาปัตยกรรมจะต้องเผชิญ
1. การประมวลผลข้อมูลขนาดใหญ่
อย่างที่เราทราบกันดีว่าสำหรับเว็บไซต์ที่ค่อนข้างเล็กจำนวนข้อมูลไม่ใหญ่มาก เลือกและอัปเดตสามารถแก้ปัญหาที่เราเผชิญได้ โหลดตัวเองไม่ใหญ่มากและส่วนใหญ่ดัชนีไม่กี่อย่างสามารถทำได้ สำหรับเว็บไซต์ขนาดใหญ่จำนวนข้อมูลต่อวันอาจเป็นล้าน หากความสัมพันธ์ที่ได้รับการออกแบบมาอย่างไม่ดีหลายต่อหลายครั้งนั้นไม่เป็นปัญหาในระยะแรก แต่เมื่อผู้ใช้เติบโตขึ้นปริมาณข้อมูลจะเพิ่มขึ้นเรขาคณิต ในเวลานี้เมื่อเราเลือกและอัปเดตตาราง (ไม่ต้องพูดถึงการสืบค้นร่วมของหลายตาราง) ค่าใช้จ่ายสูงมาก
2. การประมวลผลข้อมูลพร้อมกัน
ในบางจุด 2.0 CTO มีดาบ Shangfang ซึ่งเป็นแคช สำหรับแคชมันยังเป็นปัญหาใหญ่เมื่อดำเนินการพร้อมกันและการประมวลผลสูง ในแอปพลิเคชันทั้งหมดแคชจะถูกแชร์ทั่วโลก อย่างไรก็ตามเมื่อเราทำการปรับเปลี่ยนหากคำขอสองรายการขึ้นไปต้องการการอัปเดตแคชในเวลาเดียวกันแอปพลิเคชันจะตายโดยตรง ในเวลานี้จำเป็นต้องมีกลยุทธ์การประมวลผลข้อมูลพร้อมกันและกลยุทธ์การแคช
นอกจากนี้ยังเป็นปัญหาการหยุดชะงักของฐานข้อมูล บางทีเราอาจไม่รู้สึกว่าความน่าจะเป็นของการหยุดชะงักที่เกิดขึ้นในการพร้อมกันสูงนั้นสูงมากและการแคชดิสก์เป็นปัญหาใหญ่
3. ปัญหาการจัดเก็บไฟล์
สำหรับบางเว็บไซต์ที่สนับสนุนไฟล์อัปโหลด 2.0 เมื่อเราโชคดีที่ความจุฮาร์ดดิสก์มีขนาดใหญ่ขึ้นเรื่อย ๆ เราควรพิจารณาเพิ่มเติมว่าควรจัดเก็บไฟล์และจัดทำดัชนีอย่างมีประสิทธิภาพอย่างไร โซลูชันทั่วไปคือการจัดเก็บไฟล์ตามวันที่และพิมพ์ อย่างไรก็ตามเมื่อปริมาณไฟล์มีขนาดใหญ่หากฮาร์ดดิสก์เก็บไฟล์เล็กน้อย 500 กรัมแล้ว IO ของดิสก์จะเป็นปัญหาใหญ่ระหว่างการบำรุงรักษาและการใช้งาน แม้ว่าแบนด์วิดท์ของคุณจะเพียงพอ แต่ดิสก์ของคุณอาจไม่ตอบสนอง หากการอัปโหลดมีส่วนร่วมในเวลานี้ดิสก์จะจบลงอย่างง่ายดาย
บางทีการใช้ RAID และเซิร์ฟเวอร์ที่เก็บข้อมูลเฉพาะสามารถแก้ปัญหาปัจจุบันได้ แต่มีปัญหาอีกอย่างหนึ่งที่เป็นปัญหาในการเข้าถึงในสถานที่ต่าง ๆ บางทีเซิร์ฟเวอร์ของเราอยู่ในปักกิ่งบางทีอาจอยู่ในความเร็วในการเข้าถึงของยูนนานหรือซินเทน หากมีการแจกจ่ายดัชนีไฟล์และสถาปัตยกรรมของเราควรได้รับการวางแผนอย่างไร
ดังนั้นเราต้องยอมรับว่าการจัดเก็บไฟล์เป็นปัญหาที่ยากมาก
4. การประมวลผลความสัมพันธ์ข้อมูล
เราสามารถวางแผนฐานข้อมูลที่สอดคล้องกับปกติที่สามซึ่งเต็มไปด้วยความสัมพันธ์แบบหลายต่อหลายครั้งและยังสามารถแทนที่คอลัมน์ Indentify ด้วย GUID อย่างไรก็ตามในยุค 2.0 ที่ความสัมพันธ์หลายต่อหลายครั้งถูกน้ำท่วมปกติสามเป็นคนแรกที่ควรถูกทอดทิ้ง แบบสอบถามข้อต่อหลายโต๊ะจะต้องลดลงอย่างมีประสิทธิภาพ
5. ปัญหาการจัดทำดัชนีข้อมูล
อย่างที่เราทราบกันดีว่าการจัดทำดัชนีเป็นทางออกที่ไม่แพงและง่ายที่สุดในการปรับปรุงการสืบค้นประสิทธิภาพของฐานข้อมูล อย่างไรก็ตามในกรณีที่มีการอัปเดตสูงค่าใช้จ่ายในการอัปเดตและการลบจะสูงและคิดไม่ถึง ผู้เขียนพบสถานการณ์ที่ใช้เวลา 10 นาทีในการดำเนินการเมื่ออัปเดตดัชนีที่มุ่งเน้นดังนั้นสำหรับเว็บไซต์เหล่านี้จะทนไม่ได้
การจัดทำดัชนีและการอัปเดตเป็นคู่ของศัตรูธรรมชาติ คำถาม A, D และ E เป็นปัญหาที่เราต้องพิจารณาเมื่อทำสถาปัตยกรรมและอาจเป็นปัญหาที่ใช้เวลามากที่สุด
6. การประมวลผลแบบกระจาย
สำหรับเว็บไซต์ 2.0 เนื่องจากการโต้ตอบสูงเอฟเฟกต์ที่ CDN ทำได้โดยทั่วไปคือ 0 และเนื้อหาจะได้รับการปรับปรุงแบบเรียลไทม์ซึ่งเป็นการประมวลผลปกติของเรา เพื่อให้แน่ใจว่าความเร็วในการเข้าถึงในสถานที่ต่าง ๆ เราต้องเผชิญกับปัญหาใหญ่นั่นคือวิธีการตระหนักถึงการซิงโครไนซ์ข้อมูลและการปรับปรุงอย่างมีประสิทธิภาพและตระหนักถึงการสื่อสารแบบเรียลไทม์ของเซิร์ฟเวอร์ในสถานที่ต่าง ๆ เป็นปัญหาที่ต้องพิจารณา
7. การวิเคราะห์ข้อดีและข้อเสียของ Ajax
ความสำเร็จคือ Ajax ความล้มเหลวคือ Ajax, Ajax กลายเป็นเทรนด์กระแสหลักและฉันก็พบว่าโพสต์และรับจาก XMLHTTP นั้นง่ายมาก ไคลเอนต์ได้รับหรือโพสต์ข้อมูลไปยังเซิร์ฟเวอร์และเซิร์ฟเวอร์จะส่งคืนหลังจากได้รับคำขอข้อมูล นี่เป็นคำขอ AJAX ปกติมาก อย่างไรก็ตามเมื่อประมวลผล AJAX หากเราใช้เครื่องมือจับแพ็กเก็ตการส่งคืนข้อมูลและการประมวลผลจะชัดเจนอย่างรวดเร็ว สำหรับคำขอ AJAX ที่มีปริมาณการคำนวณสูงเราสามารถสร้างผู้รับเหมาซึ่งสามารถฆ่าเว็บเซิร์ฟเวอร์ได้อย่างง่ายดาย
8. การวิเคราะห์ความปลอดภัยของข้อมูล
สำหรับโปรโตคอล HTTP แพ็คเก็ตข้อมูลจะถูกส่งเป็นข้อความธรรมดา บางทีเราสามารถพูดได้ว่าเราสามารถใช้การเข้ารหัส แต่สำหรับปัญหา G กระบวนการเข้ารหัสอาจเป็นข้อความธรรมดา (ตัวอย่างเช่น QQ ที่เรารู้สามารถตัดสินการเข้ารหัสและเขียนวิธีการเข้ารหัสและถอดรหัสได้อย่างมีประสิทธิภาพ) เมื่อการรับส่งข้อมูลไซต์ของคุณไม่ใหญ่มากไม่มีใครสนใจคุณ แต่เมื่อการรับส่งข้อมูลของคุณเกิดขึ้นปลั๊กอินที่เรียกว่าและการส่งมวลที่เรียกว่าจะตามมาอีกครั้ง (เบาะแสสามารถมองเห็นได้จากมวลที่ส่งที่จุดเริ่มต้นของ QQ) บางทีเราสามารถพูดได้มากว่าเราสามารถใช้การตัดสินระดับสูงหรือแม้กระทั่ง HTTPs เพื่อให้บรรลุเป้าหมายนี้ โปรดทราบว่าเมื่อคุณทำการประมวลผลเหล่านี้คุณจะต้องจ่ายฐานข้อมูลจำนวนมาก IO และ CPU สำหรับการออกอากาศจำนวนมากมันเป็นไปไม่ได้ ผู้เขียนสามารถตระหนักถึงการเผยแพร่จำนวนมากสำหรับพื้นที่ Baidu และพื้นที่ QQ ไม่ใช่เรื่องยากสำหรับทุกคนที่จะลอง
9. ปัญหาการซิงโครไนซ์ข้อมูลและการประมวลผลแบบคลัสเตอร์
เมื่อหนึ่งในฐานข้อมูลของเราถูกครอบงำเราจำเป็นต้องทำการโหลดและกลุ่มฐานข้อมูล นี่อาจเป็นปัญหาที่ลำบากที่สุด ข้อมูลขึ้นอยู่กับการส่งเครือข่าย ความล่าช้าของข้อมูลเป็นปัญหาที่แย่มากและเป็นปัญหาที่หลีกเลี่ยงไม่ได้ ด้วยวิธีนี้เราจำเป็นต้องใช้วิธีการอื่นเพื่อให้แน่ใจว่ามีการโต้ตอบที่มีประสิทธิภาพภายในไม่กี่วินาทีหรือมากกว่านาทีของความล่าช้านี้ ตัวอย่างเช่นการแฮชข้อมูลการแบ่งกลุ่มการประมวลผลเนื้อหาและปัญหาอื่น ๆ
10. ช่องการแชร์ข้อมูลและแนวโน้ม OpenAPI
OpenAPI ได้กลายเป็นเทรนด์ที่หลีกเลี่ยงไม่ได้จาก Google, Facebook, MySpace ไปยังวิทยาเขตที่บ้านปัญหานี้กำลังได้รับการพิจารณา มันสามารถรักษาผู้ใช้และกระตุ้นความสนใจได้อย่างมีประสิทธิภาพมากขึ้นและอนุญาตให้ผู้คนจำนวนมากขึ้นช่วยคุณในการพัฒนาที่มีประสิทธิภาพมากที่สุด ในเวลานี้สำหรับแพลตฟอร์มการแบ่งปันข้อมูลที่มีประสิทธิภาพแพลตฟอร์มการเปิดข้อมูลกลายเป็นวิธีที่ขาดไม่ได้ การรับรองความปลอดภัยของข้อมูลและประสิทธิภาพด้วยอินเทอร์เฟซแบบเปิดเป็นอีกปัญหาหนึ่งที่เราต้องพิจารณาอย่างจริงจัง