ฉันควรทำอย่างไรเพื่อขยายเว็บไซต์ที่มีอัตราการเข้าชมสูง

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

ฉันสนใจที่จะรับฟังทุกสิ่งที่คุณพิจารณาว่าเป็นแนวปฏิบัติที่ดีที่สุดตั้งแต่ระดับงานการพัฒนาไปจนถึงโครงสร้างพื้นฐานไปจนถึงการจัดการ

ออกแบบเพื่อการทำงานพร้อมกัน

นั่นคือในขณะที่คุณกำลังเขียนโปรแกรมวางแผนที่จะให้มีหลายเธรด วางแผนสถานะที่แชร์ (มักจะเป็นแค่ฐานข้อมูล) วางแผนสำหรับหลายกระบวนการ แผนสำหรับการกระจายทางกายภาพ

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

บางสิ่งที่คุณอาจพิจารณา:

• การแยกที่อ่านและเขียนของที่เก็บข้อมูลของคุณ
  
  • CQRS / การจัดหากิจกรรม
  • CQS
  • การส่งผ่านข้อความ / นักแสดง
• หลีกเลี่ยงกระบวนการที่แบ่งใช้และสถานะเธรด
  • ดังนั้นหลีกเลี่ยงการล็อค
  • คุณสามารถหลีกเลี่ยงปัญหานี้ผ่านระบบการพิมพ์โดยการสร้างคลาส, structs และชนิดข้อมูลอื่น ๆ ให้ไม่เปลี่ยนรูปนั่นคือไม่เปลี่ยนแปลงหลังจากการก่อสร้าง โดยเฉพาะอย่างยิ่งสำหรับชนิดข้อมูลนามธรรมที่ซับซ้อนมันทำงานได้ดีอย่างน่าประหลาดใจ (เช่นการนำ jQuery ไปใช้)
• ไม่บล็อกเว็บเซิร์ฟเวอร์เธรดบน IO หากคุณใช้ ASP.Net ให้ใช้เพจ / แอ็คซิงโครนัสกับรูปแบบ APM / ไลบรารีแบบขนานงาน (TPL)
• ไม่บันทึกการโหลดสถานะในพจนานุกรมเซสชันผู้ใช้
  • สิ่งนี้จะต้องถูกย้ายข้ามเธรดเมื่อการโยกย้ายเธรดเกิดขึ้นใน IIS
  • มีการกำหนดเส้นทางอัจฉริยะเช่นทรัพยากรที่ไม่มีการรักษาความปลอดภัย / คงไม่ได้รับการบริการด้วยกรอบงานแอปพลิเคชันเดียวกัน (เช่น ASP.Net) ที่เพิ่มค่าใช้จ่าย ดูที่เว็บเซิร์ฟเวอร์ที่ต่างกันตัวอย่างเช่น
• การเขียนโค้ดส่งต่อที่มีรูปแบบเวิร์กโฟลว์แบบอะซิงโครนัส (เช่น bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• ใช้ทฤษฎีแถวคอยเพื่อคำนวณจุดที่เกิดปัญหาคอขวดของคุณ
• ใช้การผลักดัน - แทนการปรับปรุงแบบดึงเพื่ออ่านรุ่นและสถานะการใช้งานอื่น ๆ เช่นผ่าน RabbitMQ / nServiceBus
• ใช้คุณลักษณะ 'ตัวจัดการ http' ที่ใช้งานได้น้อยที่สุด
• สำหรับไฟล์แบบคงที่ให้บริการนโยบายการหมดอายุของแท็ก e-tags และแคชเพื่อให้โครงสร้างพื้นฐานของเว็บทำงานได้อย่างที่ควรจะเป็น (เช่นกับ squid proxy)
• (จ้างฉันเพื่อแก้ปัญหาเรื่องการปรับขนาดของคุณและรับบทช่วยสอนในสถานที่))

ไม่แบ่งปันสถาปัตยกรรมใด ๆ

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

โดยไม่คำนึงถึงฉันยังคงมีคุณค่าอย่างยิ่งในสถาปัตยกรรม "ไม่มีส่วนแบ่ง" และคุณสามารถเลเยอร์และขยายระบบของคุณเมื่อถึงเวลา

เรียงลำดับคำขอผ่านชื่อโฮสต์หลายชื่อ

ส่วนหนึ่งของมาตรฐาน HTTP คือส่วนที่ระบุว่า webclients จะขอสูงสุด 2 เซสชันต่อโฮสต์ DNS นี่คือทางออกที่คุณและนามแฝงของคุณ www.domain.com และรับคำขอพร้อมกันที่สูงขึ้นทำให้หน้าของคุณโหลดเร็วขึ้น:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

โดยทั่วไปจะเกี่ยวข้องกับการแก้ไข ASP.NET HTTP Handler ของคุณเพื่อสลับโฮสต์เป้าหมายที่คุณส่งให้ลูกค้าโดยที่แต่ละโฮสต์คือ CNAME ถึง "www"

ปลอดภัยรวดเร็วเชื่อถือได้ DNS

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

ความเร็ว DNS ยังส่งผลต่อความเร็วในการโหลดเริ่มต้นของเซิร์ฟเวอร์ของคุณก่อนที่จะมีการบันทึกแคช

ฉันใช้ DynDNS หรือ Neustar กับลูกค้าส่วนใหญ่ของพวกเขาเนื่องจากพวกเขามีโครงสร้างพื้นฐาน DNS ที่ค่อนข้างแข็งแกร่ง (แม้ว่าจะมีราคาแพงและฉันไม่มีส่วนเกี่ยวข้องใด ๆ กับ บริษัท เหล่านั้น)

ฉันคิดว่ากุญแจจะเรียบง่าย:

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

จากนั้นคุณสามารถทดสอบและค้นหาปัญหา

ดูที่นี่: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

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