วิธีที่ดีที่สุดในการออกแบบเว็บไซต์ให้มีความยืดหยุ่นสูงคืออะไร?


34

สำหรับเว็บไซต์ที่ต้องปรับขนาดได้สูงเช่นเครือข่ายสังคมออนไลน์อย่าง facebook วิธีที่ดีที่สุดในการออกแบบเว็บไซต์คืออะไร

  1. ฉันควรมีบริการเว็บที่เว็บไซต์สอบถามเพื่อรับข้อมูลที่ต้องการหรือไม่

    หรือ

  2. ควรสอบถามฐานข้อมูลเว็บไซต์โดยตรงหรือไม่ (สามารถทำได้โดยใช้ built-in สร้างภาษาเพื่อเติมตารางอัตโนมัติ ฯลฯ )

ฉันคิดว่าบริการเว็บเป็นการออกแบบที่ดีกว่าเนื่องจากให้การเข้าถึงข้อมูลจากส่วนกลางและสิ่งต่าง ๆ เช่นแคชและสิ่งที่คล้ายกันนั้นควบคุมได้ง่ายกว่า แต่คนอื่น ๆ คิดอย่างไร


นอกจากนี้ยังมีคำถามว่าสถาปัตยกรรมใดที่จะใช้ (เช่น MVC หรือชอบ)
อีวาน

โดยไม่ต้องทราบเพิ่มเติมเกี่ยวกับสิ่งที่คุณกำลังจะเปิดตัวมันเป็นเรื่องยากมากที่จะให้คำตอบ แต่โปรดจำไว้ว่า "บริการคลาวด์" อาจเป็นไปได้ว่าแอปพลิเคชันของคุณเหมาะกับแอป SaaS (เป็นแบบรวมศูนย์)
deepcell

โดยทั่วไปฉันจะบอกว่าไม่มีอะไรพิเศษในใจ ..
Daniel

1
สร้างมันใน 'คลาวด์' และใช้เวลาอ่าน HighScalability.com เป็นจำนวนมาก
Evan Plaice

คำตอบ:


36

ว้าวนี่เป็นคำถามง่าย ๆ ซึ่งเป็นคำตอบที่เป็นไปได้มากมาย ส่วนที่ชัดเจนของคำถามของคุณถามว่ามันสามารถปรับขนาดได้เพื่อเชื่อมต่อกับฐานข้อมูลของคุณโดยตรงหรือผ่านบริการเว็บ คำตอบนั้นง่าย: ค้นหาฐานข้อมูลโดยตรง การเข้าใช้บริการผ่านเว็บช่วยเพิ่มเวลาในการตอบสนองทั้งที่ไม่จำเป็นสำหรับการใช้รหัสหลังไฟร์วอลล์ (โดยและขนาดใหญ่) ตัวอย่างเช่นบริการเว็บต้องการส่วนประกอบบางอย่างในการรับคำขอ, ยกเลิกการจัดทำมัน, สืบค้นฐานข้อมูล, เรียงลำดับการตอบสนองและส่งกลับ ดังนั้นหากรหัสของคุณทำงานอยู่หลังไฟร์วอลล์ให้ช่วยตัวเองให้เกิดปัญหาและเพียงแค่สอบถาม DB โดยตรง

การทำให้เว็บไซต์สามารถปรับขนาดได้ แต่นอกเหนือไปจากคำถามที่คุณโพสต์ในตอนแรก ดังนั้นยกโทษให้ฉันถ้าฉันไปสัมผัสที่นี่ แต่ฉันคิดว่ามันอาจจะมีประโยชน์พิจารณาว่าคุณพูดถึง Facebook โดยเฉพาะ

ฉันอยากจะแนะนำให้คุณอ่านเกี่ยวกับงานและเครื่องมือที่สร้างขึ้นโดยแบรดฟิตซ์แพททริก (ผู้ก่อตั้ง LiveJournal และตอนนี้ที่ Google) เมื่อฉันทำงานกับเขาที่ Six Apart นี่คือบางสิ่งที่ฉันเรียนรู้จากเขาและเกี่ยวกับสถาปัตยกรรมของ LiveJournal ที่ทำให้มันปรับขนาดได้

  1. ใช้ตารางฐานข้อมูลแคบเมื่อเทียบกับคนที่กว้าง สิ่งที่น่าสนใจเกี่ยวกับสิ่งนี้คือการเรียนรู้ว่าอะไรเป็นแรงบันดาลใจในสถาปัตยกรรมนี้ซึ่งกำลังสร้างระบบที่ง่ายและรวดเร็วอัพเกรด หากคุณใช้ตารางกว้างหรือตารางที่แต่ละเขตข้อมูลหรือคุณสมบัติเป็นคอลัมน์ในตารางเมื่อถึงเวลาที่จะอัพเกรดสคีมาฐานข้อมูลตัวอย่างเช่นการเพิ่มคอลัมน์ใหม่ระบบจะต้องล็อคตารางในขณะที่สคีมา มีการนำการเปลี่ยนแปลงมาใช้ เมื่อใช้งานในระดับนี้หมายความว่าการเปลี่ยนแปลงแบบง่าย ๆ กับสกีมาฐานข้อมูลอาจทำให้ฐานข้อมูลขนาดใหญ่ดับ ซึ่งดูดอย่างเห็นได้ชัด ตารางที่แคบในอีกทางหนึ่งก็เพียงเก็บแต่ละคุณสมบัติที่เกี่ยวข้องกับวัตถุเป็นแถวเดียวในฐานข้อมูล ดังนั้นเมื่อคุณต้องการเพิ่มคอลัมน์ใหม่ในฐานข้อมูลทั้งหมดที่คุณต้องทำคือบันทึก INSERT ในตารางซึ่งเป็นการดำเนินการที่ไม่ล็อค ตกลงนั่นเป็นพื้นหลังเล็ก ๆ มาดูกันว่าแบบจำลองนี้แปลในระบบการทำงานเช่น LiveJournal ได้อย่างไร

    สมมติว่าคุณต้องการโหลดรายการบันทึก 10 รายการสุดท้ายในบล็อกของบุคคลและสมมติว่ารายการบันทึกประจำวันแต่ละรายการมีคุณสมบัติสิบรายการ ในเค้าโครงตารางแบบกว้างแบบคลาสสิกแต่ละคุณสมบัติจะสัมพันธ์กับคอลัมน์บนตาราง ผู้ใช้จะสอบถามตารางหนึ่งครั้งเพื่อดึงข้อมูลทั้งหมดที่ต้องการ แบบสอบถามจะส่งคืน 10 แถวและแต่ละแถวจะมีข้อมูลทั้งหมดที่ต้องการ (เช่น SELECT * จากรายการเรียงลำดับตามวันที่ จำกัด 10) ในรูปแบบตารางแคบ ๆ แต่สิ่งต่าง ๆ เล็กน้อย ในตัวอย่างนี้มีสองตารางจริง ๆ : ตารางแรก (ตาราง A) เก็บเกณฑ์ง่ายๆที่ต้องการค้นหาโดยเช่น id ของรายการ, id ของผู้เขียน, วันที่ของรายการ, ฯลฯ ตารางที่สอง (ตาราง B) จากนั้นเก็บคุณสมบัติทั้งหมดที่เกี่ยวข้องกับรายการ ตารางที่สองนี้มีสามคอลัมน์: entry_id, key และ value สำหรับทุกแถวในตาราง A จะมี 10 แถวในตาราง B (หนึ่งแถวสำหรับแต่ละคุณสมบัติ) ดังนั้นเพื่อที่จะดึงข้อมูลและแสดงสิบรายการที่ผ่านมาคุณจะต้องมี 11 แบบสอบถาม แบบสอบถามแรกให้รายการรหัสรายการจากนั้นแบบสอบถามสิบรายการถัดไปจะดึงคุณสมบัติที่เกี่ยวข้องกับแต่ละรายการที่ส่งคืนในแบบสอบถามแรก

    "Holy moly!" คุณพูดว่า "วิธีการบนโลกที่สามารถปรับขนาดได้มากขึ้น!" มันตอบโต้ได้ง่ายใช่มั้ย ในสถานการณ์แรกเราเพิ่งมีแบบสอบถามฐานข้อมูลหนึ่ง แต่ในโซลูชันที่ "ปรับขนาดได้มากขึ้น" ที่สองเรามี 11 แบบสอบถามฐานข้อมูล ไม่สมเหตุสมผลเลย คำตอบสำหรับคำถามนั้นขึ้นอยู่กับสัญลักษณ์แสดงหัวข้อย่อยถัดไป

  2. ใช้ memcache อย่างอิสระ ในกรณีที่คุณไม่ทราบ memcache นั้นเป็นระบบแคชแบบกระจายเครือข่ายไร้สายแฝงต่ำ มันถูกใช้โดย Facebook, Google, Yahoo และเกือบทุกเว็บไซต์ยอดนิยมและปรับขนาดได้บนโลกใบนี้ มันถูกคิดค้นโดย Brad Fitzpatrick บางส่วนเพื่อช่วยชดเชยค่าใช้จ่ายฐานข้อมูลโดยธรรมชาติในการออกแบบฐานข้อมูลตารางที่แคบ ลองมาดูตัวอย่างเดียวกันกับที่กล่าวไว้ใน # 1 ข้างต้น แต่คราวนี้เรามาแนะนำ memcache กัน

    เริ่มกันเลยเมื่อผู้ใช้เยี่ยมชมเพจเป็นครั้งแรกและไม่มีสิ่งใดอยู่ในแคช คุณเริ่มต้นด้วยการสืบค้นตาราง A ซึ่งส่งคืน ID ของ 10 รายการที่คุณต้องการแสดงในหน้า สำหรับแต่ละรายการเหล่านั้นคุณจะค้นหาฐานข้อมูลเพื่อดึงคุณสมบัติที่เกี่ยวข้องกับรายการนั้นและจากนั้นใช้คุณสมบัติเหล่านั้นเป็นวัตถุที่รหัสของคุณสามารถเชื่อมต่อกับ (เช่นวัตถุ) จากนั้นคุณซ่อนวัตถุนั้น (หรือรูปแบบที่เป็นอนุกรมของวัตถุนั้น) ใน memcache

    ครั้งที่สองที่มีคนโหลดหน้าเดียวกันคุณเริ่มต้นด้วยวิธีเดียวกัน: โดยการสืบค้นตาราง A สำหรับรายการ ID รายการที่คุณจะแสดง สำหรับแต่ละรายการคุณไปที่ memcache ก่อนและพูดว่า "คุณมีรายการ #X ในแคชหรือไม่" ถ้าใช่แล้ว memcache จะส่งคืนวัตถุรายการให้คุณ ถ้าไม่เช่นนั้นคุณต้องค้นหาฐานข้อมูลอีกครั้งเพื่อดึงคุณสมบัติของมันประกอบเป็นวัตถุและสะสมใน memcache ส่วนใหญ่ครั้งที่สองมีคนเข้าชมหน้าเดียวกันมีแบบสอบถามฐานข้อมูลเดียวเท่านั้นข้อมูลอื่น ๆ ทั้งหมดจะถูกดึงจาก memcache โดยตรง

    ในทางปฏิบัติสิ่งที่เกิดขึ้นกับ LiveJournal ส่วนใหญ่คือข้อมูลส่วนใหญ่ของระบบโดยเฉพาะข้อมูลที่มีความผันผวนน้อยกว่านั้นถูกแคชไว้ใน memcache และการสืบค้นเพิ่มเติมไปยังฐานข้อมูลที่จำเป็นในการรองรับสคีมาตารางแคบล้วน แต่ชดเชยทั้งหมด

    การออกแบบนี้จะทำให้การแก้ปัญหาที่เกี่ยวข้องกับการประกอบรายการโพสต์ที่เกี่ยวข้องกับเพื่อนของคุณลงในลำธารหรือ "กำแพง" มากมากได้ง่ายขึ้น

  3. จากนั้นให้พิจารณาการแบ่งพาร์ติชันฐานข้อมูลของคุณ แบบจำลองที่กล่าวถึงพื้นผิวด้านบนยังมีปัญหาอื่นและนั่นคือตารางแคบ ๆ ของคุณจะมีขนาดใหญ่ / ยาวมาก และยิ่งแถวเหล่านั้นยิ่งมีงานบริหารมากขึ้น เพื่อชดเชยสิ่งนี้คุณควรจัดการขนาดของตารางของคุณด้วยการแบ่งพาร์ติชั่นของตารางในบางวิธีเพื่อให้กลุ่มผู้ใช้บริการโดยฐานข้อมูลเดียว สิ่งนี้กระจายโหลดบนฐานข้อมูลและรักษาข้อความค้นหาให้มีประสิทธิภาพ

  4. ในที่สุดคุณต้องมีดัชนีที่ยอดเยี่ยม ความเร็วของการสอบถามของคุณจะขึ้นอยู่กับการจัดทำดัชนีตารางฐานข้อมูลของคุณเป็นอย่างดี ฉันจะไม่ใช้เวลามากเกินไปในการอภิปรายว่าดัชนีคืออะไรยกเว้นจะบอกว่ามันเป็นเหมือนระบบแคตตาล็อกบัตรยักษ์ที่จะทำให้การค้นหาเข็มในกองหญ้ามีประสิทธิภาพมากขึ้น หากคุณใช้ mysql ฉันขอแนะนำให้เปิดบันทึกการสืบค้นที่ช้าเพื่อตรวจสอบการสืบค้นที่ใช้เวลานานในการปฏิบัติตาม เมื่อเคียวรีปรากฏขึ้นบนเรดาร์ของคุณ (เช่นเพราะมันช้า) ให้หาดัชนีที่คุณต้องการเพิ่มลงในตารางเพื่อเร่งความเร็ว

"ขอบคุณสำหรับภูมิหลังที่ยอดเยี่ยมทั้งหมดนี้ แต่เป็นสิ่งศักดิ์สิทธิ์ที่เป็นรหัสจำนวนมากที่ฉันจะต้องเขียน"

ไม่จำเป็น. ห้องสมุดหลายแห่งถูกเขียนขึ้นซึ่งทำให้การเชื่อมต่อกับ memcache นั้นง่ายมาก ยังห้องสมุดอื่น ๆ ได้ประมวลกฎหมายกระบวนการทั้งหมดที่อธิบายไว้ข้างต้น; Data :: ObjectDriver ใน Perl เป็นเพียงห้องสมุด สำหรับภาษาอื่นคุณจะต้องทำวิจัยของคุณเอง

ฉันหวังว่าคุณจะพบคำตอบนี้เป็นประโยชน์ สิ่งที่ฉันได้พบบ่อยกว่านั้นคือความสามารถในการปรับขนาดของระบบมักจะน้อยลงและน้อยลงสำหรับรหัสและยิ่งเพิ่มมากขึ้นสำหรับการจัดเก็บข้อมูลเสียงและกลยุทธ์การจัดการ / การออกแบบทางเทคนิค


3
+1 ฉันรักว้าว
Pankaj Upadhyay

1
ฉันไม่เห็นด้วยกับ 'สอบถามฐานข้อมูลโดยตรง' คุณพูดถึงการแบ่งพาร์ติชันฐานข้อมูลเพื่อประสิทธิภาพเมื่อมันจะง่ายกว่าที่จะใช้สถาปัตยกรรม multi-slave หลายหลักด้วยอินเตอร์เฟส API ประโยชน์ของการแยกดีบีออกจากแอปพลิเคชันคือเลเยอร์ API สามารถกระจายคำขอได้ตามที่คุณต้องการ API เป็นสิ่งที่เป็นนามธรรมที่ให้คุณเปลี่ยนการใช้งานพื้นฐานและ / หรือนำข้อมูลกลับมาใช้ใหม่โดยไม่ทำให้แอปพลิเคชันหยุดทำงาน
Evan Plaice

1
(ต่อ) การทำให้เป็นอนุกรมจะเพิ่มค่าใช้จ่ายเสมอ แต่เฉพาะในเลเยอร์ API ซึ่งมักจะประกอบด้วยหลายอินสแตนซ์ที่ทำงานพร้อมกัน หากคุณกังวลเกี่ยวกับความเร็วในการโอนข้ามสายให้เปลี่ยนเป็น JSON และส่วนใหญ่จะถูกบีบอัดด้วย gzip อยู่ดี การเพิ่มประสิทธิภาพที่ง่ายที่สุดสามารถพบได้เมื่องานถูกส่งจากเซิร์ฟเวอร์ไปยังไคลเอนต์ คำถามสำคัญที่ต้องถามคือคุณต้องการกระจายคำขอภายในแอปพลิเคชันหรือระดับเซิร์ฟเวอร์หรือไม่ การทำสำเนาใดที่ง่ายกว่า
Evan Plaice

1
@EvanPlaice - จุดที่ยอดเยี่ยมในการใช้งานซ้ำและเปลี่ยนการใช้ตรรกะของบริการเมื่อใช้บริการ นอกจากนี้ - โครงสร้างพื้นฐานแคชยังสามารถใช้บริการแทนการเรียกฐานข้อมูลโดยตรง
Ashish Gupta

1
@AishishGupta ความแตกต่างเพียงอย่างเดียวในการแบ่งพาร์ติชันข้อมูลไปยังบริการที่แยกต่างหากคือสิ่งที่ผู้ใช้ได้รับ แทนที่จะรวบรวมเนื้อหา html + บนเซิร์ฟเวอร์แทน ผู้ใช้รับข้อมูลและ html แยกจากกันและไคลเอ็นต์เบราว์เซอร์จัดการ reassembly ด้วยข้อมูลที่เป็นบริการแยกต่างหากจึงเป็นไปได้ที่จะทำให้แอปพลิเคชันมือถือหรือไคลเอนต์ที่ไม่ใช่เว็บอื่น ๆ (เช่นสมาร์ททีวี)
Evan Plaice

13

สำหรับเว็บไซต์ที่ต้องปรับขนาดได้สูงเช่นเครือข่ายสังคมออนไลน์อย่าง facebook วิธีที่ดีที่สุดในการออกแบบเว็บไซต์คืออะไร?

วัด.

ฉันจะคิดว่า ...

นโยบายไม่ดี

ต้องทำการวัดจริง


FTW การวัดเชิงปริมาณ
bhagyas

1
โอเค ... หลังจากการวัดอะไร
Pacerier

9

Scalablility ไม่ได้เป็นฟังก์ชั่นของกลยุทธ์การใช้งานที่เฉพาะเจาะจง แต่เป็นการออกแบบสถาปัตยกรรมแอปพลิเคชันของคุณเพื่อให้ชั้นการเข้าถึงข้อมูลสามารถพัฒนาได้โดยไม่ต้องปรับโครงสร้างและเขียนใหม่จำนวนมาก

เทคนิคสำคัญในการสร้างระบบที่ปรับขนาดได้คือการทำความเข้าใจข้อกำหนดการเข้าถึงข้อมูลระดับสูงของคุณและสร้างสัญญาส่วนต่อประสานกับพวกเขา ตัวอย่างเช่นคุณอาจมีความต้องการที่จะได้รับใช้อย่างใดอย่างหนึ่งหรือรายการภาพถ่าย 50 โพสต์มากที่สุดเมื่อเร็ว ๆ นี้โดยผู้ใช้

คุณไม่จำเป็นต้องมีช่องสัญญาณเครือข่ายระหว่างตรรกะทางธุรกิจแอปพลิเคชันของคุณและตรรกะการเข้าถึงข้อมูล การเรียกเมธอดทางอ้อมด้วยวิธีหนึ่งต่อการดำเนินการเชิงตรรกะจะเริ่มต้นได้ดี

ทำให้วิธีการเข้าถึงข้อมูลเหล่านี้ง่ายที่สุดเท่าที่จะเป็นไปได้ในการเริ่มต้น เป็นการยากมากที่จะคาดการณ์ว่าปัญหาด้านประสิทธิภาพจะอยู่ที่ใดจนกว่าแอปพลิเคชันของคุณจะให้บริการรูปแบบการใช้งานจริงและคุณกำลังรวบรวมข้อมูลเกี่ยวกับที่ที่คุณมีปัญหาคอขวด

ด้วยการมีอินเทอร์เฟซการเข้าถึงข้อมูลที่กำหนดไว้อย่างดีคุณสามารถพัฒนาการใช้งานการเข้าถึงข้อมูลของคุณโดยไม่ต้องเปลี่ยนแปลงแอพพลิเคชั่นทั้งหมด คุณสามารถตัดสินใจเปลี่ยนเป็นสถาปัตยกรรมบริการเว็บเป็นตรรกะทางธุรกิจของคุณได้อย่างชัดเจน

คำตอบหลายข้อข้างต้นให้คำแนะนำที่ดีเกี่ยวกับวิธีการดำเนินการเมื่อคุณค้นพบคอขวดของคุณ แต่ถ้าคุณใช้เร็วเกินไปคุณจะกลายเป็นอุปสรรคต่อความซับซ้อนของรหัสของคุณก่อนที่คุณจะรู้ว่าความซับซ้อนนั้นจำเป็นหรือไม่


4

พัฒนาเว็บไซต์อย่างง่ายและให้ถึงระดับการรับส่งข้อมูล คุณจะได้เรียนรู้วิธีสร้างเว็บไซต์ที่ปรับขนาดได้

จนกว่าคุณจะพบปัญหาคุณไม่สามารถคิดวิธีแก้ปัญหาได้

เชื่อใจฉันเมื่อคุณมีเว็บไซต์ที่มีการหมุนเวียนและเผชิญกับความต้องการในการปรับขนาดคุณจะรู้วิธีการทำเช่นนั้นอย่างแน่นอน :-)


อ้างดี !!!!!!!!!!
AmirHossein

2

เป็นที่ยอมรับกันโดยทั่วไปว่าเว็บแอพพลิเคชั่นควรออกแบบด้วยสามระดับโดยค่าเริ่มต้น - เว็บ (การนำเสนอ) แอปพลิเคชันและเลเยอร์ฐานข้อมูล การแบ่งส่วนนี้เกิดจากข้อกำหนดที่แตกต่างกันในแต่ละเลเยอร์ - โดยทั่วไปแล้วการเข้าถึงดิสก์ / การจัดเก็บข้อมูลคุณภาพสำหรับฐานข้อมูล, CPU / หน่วยความจำสูงที่เลเยอร์แอพและการกระจายแบนด์วิดท์ / หน่วยความจำ / แอ็พพลิเคชัน / ฐานข้อมูลเลเยอร์มักจะรวมกันเป็นหนึ่งจนกระทั่งต่อมาในวงจรชีวิตของแอปพลิเคชันเนื่องจากเครื่องฐานข้อมูลมักจะเป็นเซิร์ฟเวอร์ขนาดใหญ่ซึ่งสามารถสร้างขึ้นเพื่อรองรับการโหลดแอปพลิเคชันก่อนหน้าเช่นกัน

อย่างไรก็ตามจำนวนเลเยอร์และสถาปัตยกรรมที่เหมาะสมสำหรับแอปพลิเคชันของคุณไม่จำเป็นต้องตรงกับรุ่นนี้หรือรุ่นอื่นใด

วางแผนที่จะต้องวัดและติดตามกิจกรรมทั้งหมดในระบบของคุณ เริ่มจากการออกแบบระดับสองหรือสามชั้นและมุ่งเน้นไปที่ส่วนใดส่วนหนึ่งซึ่งในขณะที่คุณสร้างมันดูเหมือนว่าจะต้องใช้ทรัพยากรจำนวนมากที่สุด ให้แอปพลิเคชั่นที่ทำงานอยู่เป็นแนวทางในการออกแบบของคุณในระดับนี้ ยิ่งคุณรวบรวมข้อมูลได้มากขึ้นและยิ่งมีความแม่นยำและรายละเอียดมากเท่าไหร่การตัดสินใจที่ดีขึ้นเกี่ยวกับการออกแบบแอปพลิเคชันก็จะยิ่งเพิ่มมากขึ้นเท่านั้น

เลือกเฟรมเวิร์กและสถาปัตยกรรมที่จะช่วยให้คุณสามารถหมุน / เปลี่ยนแปลงตามต้องการได้อย่างรวดเร็วและไม่เจ็บปวดเท่าที่จะทำได้ในภายหลัง แม้ว่าการเข้าถึงข้อมูล / การจัดเก็บ / การประมวลผลและการประมวลผลแอปพลิเคชันของคุณจะดำเนินการในการปฏิบัติการเดียวกันหากพวกเขาถูกแยกตัวประกอบอย่างเหมาะสมมันจะไม่เป็นการยากที่จะแยกพวกเขาออกเป็นสองชั้นในภายหลัง


2

ขั้นตอนเพิ่มเติมใด ๆ ในการเชื่อมต่อกับฐานข้อมูลเป็นเพียงค่าใช้จ่าย ตัวอย่างเช่นระหว่างUI -> Business Facade -> Business -> Data Access -> DatabaseและUI -> Databaseวิธีที่สองนั้นเร็วกว่า อย่างไรก็ตามยิ่งคุณลบขั้นตอนออกไปมากเท่าใดระบบของคุณก็จะสามารถบำรุงรักษาได้น้อยลงและจะมีการทำซ้ำมากขึ้น ลองนึกภาพการเขียนรหัสที่จำเป็นเพื่อเรียกดูรายชื่อเพื่อนในโปรไฟล์หน้าบ้านหน้าการจัดการสหาย ฯลฯ

ดังนั้นคุณควรให้ความสมดุลนี่ระหว่างประสิทธิภาพการทำงานที่สูงขึ้น (ซึ่งแน่นอนว่าส่งผลกระทบโดยตรง scalability สูงกว่า) และการบำรุงรักษาที่ดีกว่า

แต่อย่า จำกัดหัวข้อการเชื่อมต่อฐานข้อมูลเมื่อคุณคิดถึงการสร้างเว็บไซต์ที่ปรับขนาดได้ พิจารณารายการเหล่านี้ด้วย:

  1. การเลือกแพลตฟอร์มที่เหมาะสม (PHP นั้นเร็วกว่าเนื่องจากลักษณะการเขียนสคริปต์ แต่ ASP.NET ต้องการรวบรวมไฟล์ที่ต้องการเพื่อดำเนินการและให้บริการบางอย่างนอกจากนี้node.jsยังอ้างว่าสามารถปรับขนาดได้มากกว่าเนื่องจากการโทรกลับ - สถาปัตยกรรมตาม )
  2. การใช้สถาปัตยกรรม RESTful แทนโมเดลเว็บเซอร์วิส (SOA)
  3. การใช้ JSON สำหรับการถ่ายโอนข้อมูลแทน XML (ซึ่งส่งผลให้ไบต์น้อยกว่าที่จะถ่ายโอน)
  4. ปฏิบัติตามหลักเกณฑ์ด้านประสิทธิภาพของ Yahoo
  5. หัวข้อเครือข่ายและฮาร์ดแวร์เช่นload balancingหรือสถาปัตยกรรมระดับ

2
คุณไม่สามารถพูดได้ว่า PHP นั้นเร็วกว่า แอปพลิเคชัน ASP.NET ที่เขียนอย่างถูกต้องสามารถมีประสิทธิภาพสูงกว่า PHP ในหลายกรณี naspinski.net/post/AspNet-vs-php--speed-comparison.aspx
Andrew Lewis

+1 ที่จริงแล้วโซลูชัน 'ที่เรียบง่าย' ของคุณจะเป็น UI -> การเข้าถึงข้อมูล -> ฐานข้อมูล 2 REST นั้น 'ง่าย' เพราะมันได้สร้างไว้แล้วในเบราว์เซอร์ส่วนใหญ่ ไม่จำเป็นต้องสร้างวงล้อ API ตอบกลับคำสั่งอีกครั้ง 3 ไม่เพียง แต่มีขนาดเล็กกว่า JSON แต่ต้องการขั้นตอนน้อยลงในการทำให้เป็นอนุกรมเนื่องจากคุณไม่จำเป็นต้องตรวจสอบเอนทิตี HTML สิ่งที่ดี.
Evan Plaice

1

มีสองวิธีหลักในการไต่ระดับขึ้นและลง

การขยายขนาดกำลังแทนที่เครื่องจักรด้วยเครื่องจักรที่มีประสิทธิภาพมากกว่า การขยายออกหมายถึงการเพิ่มเครื่องอื่นเพื่อทำงานที่เครื่องเดิมทำอยู่

เว็บไซต์ที่มีปริมาณการใช้งานสูงจำเป็นต้องมีความสามารถในการขยาย สถาปัตยกรรมซอฟต์แวร์จำเป็นต้องทำเช่นวิธีการเพื่อให้เครื่องจักรเพิ่มเติมสามารถเพิ่มได้อย่างง่ายดายยุ่งเว็บไซต์ได้รับ

โดยทั่วไปแล้วนี่หมายถึงการแยกแอปพลิเคชันออกเป็นระดับเพื่อให้สามารถเชื่อมต่อและเล่นเซิร์ฟเวอร์ได้มากขึ้นในแต่ละชั้น

ฉันจะทำตัวเลือกที่ 1 มีบริการแทนการทำโดยตรง คุณสามารถขยายแอปพลิเคชันแบบเสาหินได้เท่านั้น


0

พัฒนาเว็บไซต์ของคุณโดยใช้แพลตฟอร์มเทคโนโลยีที่ได้รับการสนับสนุนอย่างสมบูรณ์แบบสำหรับคลาวด์

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.