-
บทความสุดท้ายในชุดนี้เขียนขึ้นสำหรับโปรแกรมเมอร์ทั่วไป หากคุณไม่สนใจ คุณสามารถอ่านสองสามย่อหน้าสุดท้ายของบทความนี้ได้
ก่อนที่จะเริ่มออกแบบโครงสร้างโค้ด เรามาทบทวนสิ่งที่เราได้เตรียมไว้ก่อนหน้านี้: เรามีเว็บเซิร์ฟเวอร์ที่สมดุลโหลด เซิร์ฟเวอร์ DB หลัก-รอง และอาจเป็นการแบ่งส่วน แคช และพื้นที่เก็บข้อมูลที่ปรับขนาดได้ ทุกแง่มุมของการจัดระเบียบโค้ดมีความเกี่ยวข้องอย่างใกล้ชิดกับการเตรียมการเหล่านี้ ฉันจะแสดงรายการทีละรายการ สองคูณสาม และแต่ละส่วนจะเริ่มต้นด้วยประโยคคลาสสิก "ดังที่กล่าวไว้ข้างต้น" เพื่อให้ง่ายต่อการเปรียบเทียบ
อย่าเพิ่งรีบอ่านรูปแบบประโยคคลาสสิก ใจฉันเต้นแรง และจะแทรกย่อหน้าลงไป ในการพัฒนาจริง เรามักจะประนีประนอมระหว่างประสิทธิภาพและความสง่างามของโค้ดเสมอ สำหรับคอมพิวเตอร์และล่ามภาษาในปัจจุบัน คำถามที่ว่ามีการเรียกออบเจ็กต์กี่เลเยอร์และการเรียกออบเจ็กต์กี่เลเยอร์ และจะประกาศตัวแปรเป็น Map หรือ HashMap หรือไม่ ถือเป็นสิ่งสุดท้ายที่ต้องพิจารณาถึงส่วนที่ช้าที่สุดของระบบและแก้ไขมัน จากส่วนที่ช้าที่สุด ตัวอย่างเช่น ดูว่า ORM ที่คุณใช้ทำหลายสิ่งที่คุณไม่ต้องการหรือไม่ และมีการเรียกข้อมูลซ้ำหรือไม่ สิ่งที่เราทำคือการพัฒนาแอปพลิเคชันบนเว็บ ไม่ใช่โค้ดที่อ่านง่ายและเข้าใจได้เป็นสิ่งสำคัญมากในการรับรองคุณภาพ จะพูดคุยแยกกัน บทความนี้อยู่นอกประเด็นเกินไป หากคุณต้องการสื่อสาร คุณสามารถติดตาม Weibo ของฉันได้ : http://t.sina.com.cn/liuzhiyi เรามาต่อกัน
ดังที่ได้กล่าวไว้ก่อนหน้านี้ เว็บเซิร์ฟเวอร์จะต้องมีความสมดุลในการโหลด และเซิร์ฟเวอร์รูปภาพจำเป็นต้องถูกแยกออกจากกัน ในประเด็นนี้ เมื่อโค้ดจัดการสถานะไคลเอ็นต์ อย่าใส่สถานะลงในเครื่องเดียว ตัวอย่างเช่น อย่าใช้เซสชันไฟล์ หากเป็นไปได้ วิธีที่ดีที่สุดคือพัฒนาอินเทอร์เฟซแบบรวมสำหรับการตรวจสอบสิทธิ์ผู้ใช้จุดเดียวตั้งแต่ต้น รวมถึงวิธีการตรวจสอบสถานะข้ามโดเมน วิธีตรวจสอบสถานะบนเพจแบบคงที่ และคำจำกัดความของพารามิเตอร์การข้ามและการส่งคืนเมื่อเข้าสู่ระบบ จัดเตรียมอินเทอร์เฟซที่ดีที่เลเยอร์ด้านล่างและนำไปใช้ เลเยอร์ถูกใช้โดยตรง (อ้างอิงถึงบริการผู้ใช้ของ GAE) การออกแบบการเข้าสู่ระบบควรคำนึงถึงคุณลักษณะของอุปกรณ์เคลื่อนที่ เช่น คอมพิวเตอร์สามารถใช้หน้าต่างแบบเลเยอร์ลอยได้ แต่เบราว์เซอร์ของ NOKIA หรือ UCWEB ไม่สามารถจัดการรูปแบบการแสดงออกนี้ได้ โปรแกรมจะต้องสามารถจัดการทั้งคำขอ Ajax และผ่าน URL ได้โดยตรง . ถาม. เซิร์ฟเวอร์รูปภาพจะถูกแยกออก และไฟล์ทรัพยากรจะถูกวางไว้บนเซิร์ฟเวอร์รูปภาพได้ดีที่สุด นั่นคือ เว็บเซิร์ฟเวอร์ให้บริการเฉพาะโปรแกรมไดนามิกเท่านั้น แม้ว่าการพัฒนาและทดสอบจะซับซ้อนเล็กน้อย (เนื่องจากต้องใช้ URI ที่สมบูรณ์ในการเข้าถึง) แต่จะง่ายกว่ามากในการเพิ่มประสิทธิภาพส่วนหน้าของหน้าในอนาคต และการเพิ่มประสิทธิภาพ IO ของเว็บเซิร์ฟเวอร์ของคุณก็จะง่ายขึ้นเช่นกัน จะง่ายกว่ามาก เมื่อโปรแกรมอ้างอิงไฟล์ทรัพยากร จะต้องมีวิธีการประมวลผลแบบรวมหลายสิ่งหลายอย่างสามารถดำเนินการได้โดยอัตโนมัติภายในวิธีการ เช่น การรวม CSS/js ลงในไฟล์ หรือเพิ่ม QUERYSTRING โดยอัตโนมัติหลังจาก URI ที่สร้างขึ้น หาก มีการใช้บริการแคช การสร้าง QUERYSTRING เป็นวิธีที่ง่ายที่สุดในการรีเฟรชแคชเซิร์ฟเวอร์และแคชไคลเอ็นต์
ตามที่กล่าวไว้ข้างต้น ฐานข้อมูลจะถูกจำลองแบบ อาจมีหลายต้นแบบและทาสหลายตัว และอาจถูกแบ่งส่วน ในกระบวนการประมวลผลข้อมูลในโปรแกรมของเรา วิธีที่ดีที่สุดคือสรุปข้อมูลและวางไว้ในเลเยอร์ที่แยกจากกัน ยกตัวอย่างโมเดล MVC ยอดนิยม ซึ่งก็คือการวางชั้นข้อมูลไว้ใต้ชั้น M โลกภายนอก ซ่อนรายละเอียดการเข้าถึงข้อมูล อย่ากลัวการเขียนที่น่าเกลียดภายในชั้นข้อมูลนี้ แต่ต้องมีฟังก์ชันการจัดเก็บข้อมูลทั้งหมด อย่าเห็นคำที่เกี่ยวข้องกับฐานข้อมูลในระดับอื่น เหตุผลก็คือ ในกรณีของฐานข้อมูลเชิงสัมพันธ์เดี่ยว คุณอาจ SELECT...JOIN...หรือ INSERT...INTO... ได้โดยตรง แต่คุณอาจเก็บบางตารางไว้ในฐานข้อมูลคีย์-ค่า หรือ แบ่งส่วนเหล่านั้น หลังจากนั้นจะต้องเปลี่ยนข้อความและวิธีการดั้งเดิมทั้งหมดหากกระจัดกระจายเกินไปจะต้องใช้ความพยายามอย่างมากในระหว่างการปลูกถ่ายหรือจะได้แบบจำลองที่มีขนาดใหญ่มาก ในแง่ของการออกแบบระดับข้อมูล พยายามหลีกเลี่ยงการสืบค้น JOIN เราสามารถดำเนินการซ้ำซ้อนและแคชข้อมูลได้มากขึ้น สำหรับการรวมข้อมูลที่ซับซ้อนยิ่งขึ้น เมื่อความต้องการแบบเรียลไทม์ไม่สูง ก็สามารถใช้การประมวลผลแบบอะซิงโครนัสได้ และผู้ใช้จะได้รับผลลัพธ์ที่ประมวลผลเมื่อเข้าถึงเท่านั้น เมื่อจัดการกับคีย์หลัก ให้หลีกเลี่ยงการใช้ ID ที่เพิ่มขึ้นอัตโนมัติ และใช้ค่าเฉพาะที่สร้างโดยกฎบางอย่างเป็นคีย์หลักนี้เป็นกลยุทธ์การกระจายการแบ่งส่วนที่ง่ายที่สุด แม้ว่าคุณจะใช้ ID การเพิ่มอัตโนมัติ วิธีที่ดีที่สุดคือใช้ตัวสร้าง ID ที่เพิ่มขึ้นอัตโนมัติ มิฉะนั้น หากมีการเขียนฐานข้อมูลทาสโดยไม่ตั้งใจ คีย์หลักจะขัดแย้งกันได้ง่าย
ตามที่กล่าวไว้ก่อนหน้านี้ มีแคชบางส่วนปิดกั้นด้านหน้าฐานข้อมูลของเรา อย่าถือว่าแคชการสืบค้นของ MySQL เป็นแคช เมื่อแอปพลิเคชันมีความซับซ้อนเล็กน้อย QUERY CACHE จะกลายเป็นภาระ การแคชมีการผสานรวมอย่างใกล้ชิดกับฐานข้อมูลและธุรกิจ เนื่องจากแคชมีความเกี่ยวข้องอย่างใกล้ชิดกับธุรกิจ จึงไม่มีแนวทางใดที่เหมาะกับทุกคน แต่เรายังมีกฎบางอย่างที่ต้องปฏิบัติตาม กฎข้อที่ 1: ยิ่งใกล้กับส่วนหน้ามากเท่าใด รายละเอียดแคชก็จะยิ่งมากขึ้นเท่านั้น ตัวอย่างเช่น ทั้งเพจถูกแคชไว้ที่ส่วนหน้าของเว็บ ส่วนหนึ่งของเพจจะถูกแคชในระดับถัดไป และเรกคอร์ดเดียวในพื้นที่นั้นจะถูกแคชในระดับถัดไป เนื่องจากยิ่งเราอยู่ใกล้แบ็กเอนด์มากเท่าใด ความสามารถในการทำงานของเราก็จะยิ่งมีความยืดหยุ่นมากขึ้นเท่านั้น และโค้ดส่วนหน้าที่เปลี่ยนแปลงมากที่สุดก็เขียนได้ง่ายกว่า ในทางปฏิบัติ เนื่องจากข้อกำหนดของผลิตภัณฑ์เปลี่ยนแปลงอย่างรวดเร็วและวงจรการวนซ้ำเริ่มสั้นลงเรื่อยๆ บางครั้งจึงเป็นเรื่องยากที่จะแยกแยะความแตกต่างระหว่างคอนโทรลเลอร์และโมเดลอย่างชัดเจนในระดับคอนโทรลเลอร์จึงเป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่จำเป็นต้องตรวจสอบให้แน่ใจว่าหากเป็นเช่นนั้น เกิดขึ้นตัวควบคุม แคชที่กำลังดำเนินการจะต้องไม่ส่งผลกระทบต่อฝ่ายที่ร้องขอข้อมูลอื่น ๆ นั่นคือต้องมั่นใจว่าข้อมูลแคชนี้ถูกใช้โดยคอนโทรลเลอร์นี้เท่านั้น กฎข้อที่ 2: โปรแกรมไม่สามารถสร้างข้อผิดพลาดได้หากไม่มีแคช เมื่อไม่ได้คำนึงถึงผลกระทบจากหิมะถล่มที่เกิดจากแคชที่ไม่ถูกต้อง โปรแกรมของคุณจะต้องมีแคชและเหมือนกับไม่มีแคช ไม่สามารถเป็นเหมือน Sina Weibo ได้ เมื่อแคชล้มเหลว แฟน Weibo จะว่างเปล่าและแอปพลิเคชันทั้งหมดจะว่างเปล่า เลอะเทอะ เมื่อการแคชเป็นสิ่งจำเป็น การให้ข้อความแสดงข้อผิดพลาดแก่ผู้ใช้ย่อมดีกว่าการให้ข้อความที่ทำให้เข้าใจผิด กฎข้อที่ 3: การอัปเดตแคชจะต้องเป็นแบบอะตอมมิกหรือเธรดที่ปลอดภัย โดยเฉพาะอย่างยิ่งเมื่อใช้แคชแบบพาสซีฟ มีโอกาสมากที่แคชเดียวกันจะได้รับการอัปเดตเมื่อมีผู้ใช้สองคนเข้าถึง โดยปกติแล้วนี่ไม่ใช่ปัญหาใหญ่และสามารถสร้างแคชใหม่ได้ หลังจากที่มันหมดอายุ นี่อาจเป็นสาเหตุหนึ่งของปฏิกิริยาลูกโซ่ กฎข้อที่ 4: การแคชก็มีค่าใช้จ่ายเช่นกัน ไม่ใช่แค่ต้นทุนด้านเทคโนโลยีเท่านั้น แต่ยังรวมถึงต้นทุนเวลาแรงงานด้วย หากฟังก์ชันใช้แคชและไม่ได้ใช้งาน ความแตกต่างในปริมาณการเข้าถึงที่คาดการณ์ได้นั้นมีน้อย แต่การใช้แคชจะเพิ่มความซับซ้อน ดังนั้นเราจึงไม่จำเป็นต้องเพิ่มเครื่องหมาย TODO และเพิ่มการประมวลผลแคชในการวนซ้ำครั้งถัดไป
ตามที่กล่าวไว้ข้างต้น พื้นที่จัดเก็บไฟล์มีความเป็นอิสระ ดังนั้นการดำเนินการกับไฟล์ทั้งหมดจึงเป็นการโทรระยะไกล คุณสามารถจัดเตรียมอินเทอร์เฟซ RESTful ที่เรียบง่ายบนไฟล์เซิร์ฟเวอร์ หรือคุณสามารถจัดเตรียมบริการ xmlrpc หรือ json ได้ ไฟล์ทั้งหมดที่สร้างและประมวลผลโดยเว็บเซิร์ฟเวอร์จะได้รับแจ้งไปยังเซิร์ฟเวอร์ไฟล์ผ่านอินเทอร์เฟซสำหรับการประมวลผล โดยที่เว็บเซิร์ฟเวอร์เองก็ไม่ต้องการ เพื่อจัดให้มีการจัดเก็บไฟล์ใดๆ คุณจะพบว่าการอัพโหลดรูปภาพและบันทึกบทความบนเว็บไซต์ขนาดใหญ่หลายแห่งเสร็จสิ้นในสองขั้นตอนด้วยเหตุนี้
จริงๆ แล้วผู้คนจำนวนนับไม่ถ้วนกล่าวถึงสิ่งที่ "กล่าวถึงก่อนหน้านี้" ข้างต้น ฉันเพิ่งพูดซ้ำด้วยคำพูดของฉันเองจากบทความก่อนหน้านี้ สาระสำคัญของการวิเคราะห์ที่แท้จริงนั้นง่ายมาก - นอกเหนือจากการแบ่งชั้นตรรกะการทำงานที่ดีแล้ว เรายังต้องมีการออกแบบด้วย อินเทอร์เฟซที่แยกจากกันสำหรับการเรียกทรัพยากรภายนอก เช่น พื้นที่จัดเก็บฐานข้อมูล แคช คิว และบริการไฟล์ คุณสามารถจินตนาการว่าโปรแกรมของคุณทำงานบน Amazon EC2 และใช้บริการบนเว็บทั้งหมด พื้นที่เก็บข้อมูลคือ S3 ของเขา ข้อแตกต่างเพียงอย่างเดียวคืออินเทอร์เฟซของ Amazon นั้นเป็นการโทรระยะไกล และของคุณคือการโทรภายใน
การเชื่อมต่อบริการสนับสนุนหมายความว่าการแทนที่ MySQL ด้วย PostgreSQL ไม่จำเป็นต้องมีการเปลี่ยนแปลงโปรแกรมประมวลผลทางธุรกิจ และทีมการย้ายข้อมูลไม่จำเป็นต้องสื่อสารกับทีมพัฒนาธุรกิจมากเกินไป หมายความว่าทีมพัฒนาธุรกิจกำลังเขียนโปรแกรมอินเทอร์เฟซแทน มากกว่าการเขียนโปรแกรมฐานข้อมูล หมายความว่าประสิทธิภาพจะไม่ช้าลงจากความผิดพลาดของนักพัฒนาธุรกิจ
หากคุณไม่สนใจความรู้ด้านโปรแกรม เพียงดูที่นี่——
หลังจากการออกแบบผลิตภัณฑ์เสร็จสมบูรณ์และสร้างเฟรมเวิร์กของโปรแกรมแล้ว อาจเกิดข้อขัดแย้งขึ้นในช่วงหัวเลี้ยวหัวต่อนี้ มีการร้องเรียนจากนักออกแบบผลิตภัณฑ์อย่างต่อเนื่องว่าแนวคิดของพวกเขาไม่บรรลุผลตามที่ต้องการ และโปรแกรมเมอร์บ่นว่าการออกแบบผลิตภัณฑ์ไม่สมจริง การร้องเรียนประเภทนี้ส่วนใหญ่เกิดจากการที่บุคลากรด้านผลิตภัณฑ์ไม่เข้าใจเทคโนโลยีและบุคลากรด้านเทคนิคไม่เข้าใจผลิตภัณฑ์ ในความหมายกว้างๆ ผลิตภัณฑ์ได้แก่ กลยุทธ์การตลาด วิธีการทางการตลาด และการออกแบบฟังก์ชัน เมื่อต้องโต้แย้งเกี่ยวกับผลิตภัณฑ์และเทคโนโลยี มักจะเน้นที่ฟังก์ชัน แต่จุดสนใจที่แท้จริงอยู่ที่ต้นทุนในการตระหนักถึงฟังก์ชันนี้และประโยชน์ที่ได้รับจากฟังก์ชันนี้ สามารถนำไปแปลงได้หรือไม่และนำมาพิจารณาได้หรือไม่ หากเป็นไปได้ให้แก้ไขข้อโต้แย้ง ถ้าไม่พลิกเหรียญและดูโชค มีตัวอย่างมากมายของตัวบ่งชี้ที่ระเบิดเนื่องจากการปรับปรุงฟังก์ชัน หรือความล่าช้าในการต่อสู้เนื่องจากความล่าช้าของโครงการ ผู้มีอำนาจตัดสินใจแบบหัวรุนแรงมุ่งเน้นไปที่ผลประโยชน์ ผู้มีอำนาจตัดสินใจแบบอนุรักษ์นิยมมุ่งเน้นไปที่การสูญเสีย และผู้มีอำนาจตัดสินใจที่ชาญฉลาดจะพิจารณาว่าปัญหานั้นร้ายแรงหรือไม่
ไม่มีใครคาดเดาได้ว่าจะเกิดอะไรขึ้นในอนาคต ไม่อย่างนั้น ครึ่งหนึ่งของการเริ่มต้นธุรกิจขึ้นอยู่กับโชค แต่มีหลายสิ่งที่สามารถพูดได้อย่างถูกต้องเสมอ และคุณต้องพึ่งพาข้อมูลเพื่อพูดเพื่อตัวมันเอง
ไม่ใช่ 100% แต่ 99.9% ของเว็บไซต์ได้ติดตั้งโค้ดสถิติการเข้าถึง แม้แต่ http://zhiyi.us ของฉันก็ไม่มีข้อยกเว้น และ Xinwen Network มักจะพูดถึงการตัดสินใจทางวิทยาศาสตร์และการพัฒนาทางวิทยาศาสตร์อยู่เสมอ ด้วยสถิติมีหลายสิ่งที่สามารถกำหนดได้ ตัวอย่างเช่น คุณสามารถวิเคราะห์ว่าแชแนลใดมีต้นทุนการได้มาต่อหัวต่ำสุดโดยพิจารณาจากอัตรา Conversion ของเป้าหมายต้นทาง เดาเหตุผลของอัตราตีกลับของผู้ใช้โดยพิจารณาจากการเข้าถึงเนื้อหาต้นทาง และพิจารณาว่าตำแหน่งลิงก์นั้นสมเหตุสมผลเมื่อพิจารณาจากการคลิกของผู้ใช้หรือไม่ พฤติกรรม. รวมข้อมูลด้วยวิธีต่างๆ เพื่อค้นหาการเชื่อมต่อภายใน วิเคราะห์ปัจจัยภายในและภายนอก กำหนดกลยุทธ์ที่สอดคล้องกัน และลดการตัดสินใจตบหน้าผาก การใช้ข้อมูลเพื่อสนับสนุนการดำเนินงานเป็นเรื่องที่เป็นมืออาชีพมาก แม้ว่าฉันจะไม่เข้าใจแบบจำลองทางคณิตศาสตร์ที่ลึกซึ้งและการคำนวณสูตรที่ซับซ้อน แต่ฉันได้เรียนรู้ทีละน้อยว่า B เป็นเพราะ A และ C เป็นเพราะ A และ B แต่ก็ยังค่อนข้างง่าย .
ผู้เขียนบทความ: Liu Zhiyi (โปรดระบุลิงก์แหล่งที่มาและผู้แต่งเมื่อพิมพ์ซ้ำ)
ที่มาบทความ: http://zhiyi.us/