Tôi nên làm gì để nhân rộng một trang web có lưu lượng truy cập cao?

Những thực hành tốt nhất nên được thực hiện cho một trang web cần "mở rộng quy mô" để xử lý dung lượng? Điều này đặc biệt có liên quan khi mọi người đang xem xét đám mây, nhưng có thể đang bỏ lỡ các nguyên tắc cơ bản.

Tôi muốn nghe về bất cứ điều gì bạn cho là thực tiễn tốt nhất từ ​​các nhiệm vụ cấp phát triển, đến cơ sở hạ tầng, đến quản lý.

Thiết kế cho đồng thời

Đó là, khi bạn đang viết mã, hãy lên kế hoạch cho việc có nhiều luồng đi. Lập kế hoạch trạng thái chia sẻ (thường chỉ là db). Lập kế hoạch cho nhiều quá trình. Kế hoạch phân phối vật lý.

Điều này cho phép bạn phân phối hệ thống của mình trên nhiều máy và trên nhiều quy trình với cân bằng tải. Nó cho phép bạn có các quy trình dự phòng đang chạy trong trường hợp thất bại và trong trường hợp bạn cần sửa đổi hệ thống tại chỗ, bạn không phải giết tất cả dịch vụ để làm như vậy.

Một vài điều bạn có thể cân nhắc:

• Tách các mặt đọc và ghi của bộ lưu trữ dữ liệu của bạn.
  
  • CQRS / Tìm nguồn cung ứng sự kiện
  • CQS
  • Truyền tin nhắn / Diễn viên
• Tránh quá trình chia sẻ và trạng thái luồng
  • Do đó tránh bị khóa
  • Bạn có thể tránh điều này thông qua hệ thống loại bằng cách tạo các lớp, cấu trúc và các loại dữ liệu khác của bạn thành bất biến, tức là không thay đổi sau khi xây dựng. Đặc biệt đối với các loại dữ liệu trừu tượng phức tạp, nó hoạt động tốt một cách đáng ngạc nhiên (ví dụ: triển khai jQuery)
• Không chặn chủ đề máy chủ web trên IO. Nếu bạn đang sử dụng ASP.Net, hãy sử dụng các trang / hành động không đồng bộ với thư viện song song mẫu / nhiệm vụ APM (TPL)
• Không lưu vô số trạng thái trong từ điển phiên người dùng
  • Điều này phải được di chuyển qua các luồng khi di chuyển luồng xảy ra trong IIS.
  • Có định tuyến thông minh, sao cho tài nguyên tĩnh / không bảo mật không được phục vụ với cùng một khung ứng dụng (ví dụ: ASP.Net) có thêm chi phí. Nhìn vào việc có các máy chủ web khác nhau, ví dụ.
• Viết mã chuyển tiếp liên tục với mẫu quy trình công việc không đồng bộ (ví dụ: bind (haskell) /callcc/T task.CContueWith/F#'s async)
• Sử dụng lý thuyết xếp hàng để tính toán nơi tắc nghẽn của bạn có thể xảy ra
• Sử dụng các bản cập nhật dựa trên đẩy thay vì kéo cho các mô hình đọc và trạng thái ứng dụng khác. Ví dụ: thông qua RabbitMQ / nServiceBus
• Sử dụng các tính năng tối thiểu 'trình xử lý http'
• Đối với các tệp tĩnh, cung cấp các thẻ điện tử và chính sách hết hạn bộ đệm để cho phép cơ sở hạ tầng web hoạt động như bình thường (ví dụ: với proxy mực)
• (Thuê tôi để giải quyết các vấn đề mở rộng quy mô của bạn và nhận hướng dẫn tại chỗ;))

Chia sẻ kiến ​​trúc Không có gì.

Với suy nghĩ đó, và trái với những gì bạn có thể nghĩ, đừng nhảy vào một giải pháp mở rộng ngay lập tức. Chi phí ngoài hệ thống so với cuộc gọi trong hệ thống không nên được cân nhắc quá mức. Chẳng hạn, phải mất rất nhiều thời gian để thực hiện kết nối DB trên bất kỳ giao diện mạng nào so với thực hiện cuộc gọi cục bộ. Ngân sách cần bao nhiêu thời gian trong quản lý, sức mạnh và nỗ lực điều chỉnh trong quy mô so với $ thêm cho một hệ thống lớn thực sự.

Bất kể, tôi vẫn có giá trị lớn trong kiến ​​trúc "không chia sẻ gì" và bạn có thể xếp lớp và nhân rộng các hệ thống của mình khi đến lúc.

Song song hóa các yêu cầu qua một số tên máy chủ

Một phần của tiêu chuẩn HTTP là một phần cho biết các khách hàng web sẽ yêu cầu tối đa 2 phiên cho mỗi Máy chủ DNS. Đây là một giải pháp trong đó bạn và bí danh ra www.domain.com của bạn và nhận được yêu cầu đồng thời cao hơn, giúp trang của bạn tải nhanh hơn:

/programming/3653609/how-do-i-code-my-asp-net-page-to-abulize-doads-across-hostnames

Về cơ bản, nó liên quan đến việc chỉnh sửa ASP.NET HTTP Handler của bạn để thay thế các máy chủ đích mà bạn gửi máy khách đến, trong đó mỗi máy chủ là một CNAME thành "www".

DNS an toàn, nhanh chóng, đáng tin cậy

Tôi tìm thấy một vài trang web có dung lượng cao sử dụng máy chủ DNS của nhà đăng ký, không có SLA cho thời gian hoạt động hoặc hiệu suất. Ngoài ra, các máy chủ của họ được đặt tại Ấn Độ và độ trễ một mình làm tăng khả năng một kẻ lừa đảo DNS có thể đầu độc khách hàng của bạn hoặc bộ đệm trung gian của ISP. Điều này sẽ khiến ngay cả lưu lượng được bảo vệ SSL của bạn bị chuyển hướng mà không ai biết.

Tốc độ DNS cũng ảnh hưởng đến thời gian tải ban đầu của máy chủ của bạn, trước khi các bản ghi được lưu trữ.

Tôi sử dụng DynDNS hoặc Neustar cho hầu hết các khách hàng của mình vì họ có cơ sở hạ tầng DNS khá vững chắc (mặc dù nó đắt tiền và tôi không có liên kết nào khác với các công ty đó).

Tôi nghĩ rằng chìa khóa sẽ đơn giản:

Có mã đơn giản. Điều đó có nghĩa là một cái gì đó mà bạn nhìn và hiểu. Khi bạn mở rộng và thay đổi máy chủ, bạn cần biết những gì đang xảy ra. Bạn cũng có thể cần thêm các lập trình viên cần nhanh chóng hiểu. Các tệp hook và XML gọi mã ngẫu nhiên không rõ ràng là rất xấu.

Sau đó, bạn có thể kiểm tra và tìm ra các vấn đề.

Xem tại đây: http://blog.servint.net/2013/08/27/ màng-big-how-to-scale-a-website-part-1-cơ sở hạ tầng-that-scales /

Chúng tôi tại stellarbuild cố gắng đảm bảo quy mô trang web của chúng tôi mà không mất thời gian. Điều đó có nghĩa là bạn cần có khả năng biết mã của bạn làm gì và mã đó ở đâu. Ngay cả khi bạn đang thử nghiệm một máy khác, bạn cũng không thể mất quá nhiều thời gian để mở rộng quy mô. Hầu hết mọi người chỉ bắt đầu khi đã quá muộn, thật đáng buồn. Bạn có thể tối ưu hóa chỉ khi bạn làm điều đó theo ý kiến ​​của tôi.