2010-05-31 5 views
23

Tôi đang lập kế hoạch xây dựng một ứng dụng sẽ nhận được một lượng lưu lượng truy cập lớn. (Xin đừng nói rằng tôi sẽ không nhận được lưu lượng truy cập, điều này là dành cho mạng nội bộ, vì vậy lưu lượng truy cập sẽ ở đó. Chỉ cần cố gắng tránh 'Bạn sẽ không nhận được nhiều lưu lượng truy cập, đừng lo lắng về điều đó.)Điều gì tạo nên một trang web cần phải mở rộng quy mô?

Đối với loại lưu lượng truy cập nào tôi mong đợi, người dùng sẽ duyệt qua các tạo động khác nhau (dựa trên chi tiết tài khoản người dùng). Trên các trang web đó, người dùng có thể gửi đầu vào văn bản. Cả hai tải các trang và xử lý đầu vào của người dùng sẽ nhấn vào cơ sở dữ liệu. Tải rõ ràng sẽ được đọc, nhưng xử lý đầu vào sẽ yêu cầu cả hai lần đọc & viết. Các đầu vào cũng có thể ảnh hưởng đến các chế độ xem của người dùng khác. Nếu điều này xảy ra, tôi sẽ cần phải thông báo cho những người dùng khác làm mới trang.

Tôi cần phải làm những việc gì để không chỉ đơn giản là gặp sự cố với số lượng người dùng lớn?

Điều gì sẽ trở thành yếu tố hạn chế? Cơ sở dữ liệu? I/O với giao diện người dùng?

Tôi chưa bao giờ thực sự phát triển một ứng dụng web nghiêm túc trước đây và đang tìm kiếm trợ giúp.

EDIT: Tôi đã cân nhắc việc sử dụng Erlang cho chương trình phụ trợ vì tôi đã sử dụng nó một chút và thực sự thích tất cả các công cụ tương tranh. Đây có phải là một sự lựa chọn khả thi hay tôi nên thử một thứ gì đó truyền thống hơn?

+5

Xem http://highscalability.com/ - các bài viết rất thú vị về chính xác chủ đề của bạn. Đặc biệt là các trường hợp thực tế và giải thích (mặc dù terse) là wortwhile để đọc. –

+1

Vui lòng giải thích về loại lưu lượng truy cập bạn mong muốn có. Sẽ có tải lên/tải xuống tệp lớn không? Nó có tương tác không? Nó sẽ là một trong những ứng dụng chính trong mạng đó? Hoặc chỉ cần nhấp và xem các trang tĩnh vài lần một ngày? – stagas

+0

Thuộc về ServerFault, methinks. –

Trả lời

17

Đây là một chủ đề rất lớn và có thể bạn sẽ muốn thực hiện nhiều nghiên cứu theo thời gian cho phép. Có một số chủ đề lớn cần xem xét.

  1. Bộ nhớ trạng thái phiên. Rõ ràng, bộ nhớ phiên chiếm bộ nhớ hoặc dung lượng đĩa. Bạn cần phải có một chiến lược để lưu trữ thông tin phiên đúng và theo cách có thể được sử dụng bởi một trang trại.

  2. Caching. Một chiến lược bộ nhớ đệm mạnh mẽ có thể giảm tải đáng kể. Thực hiện rất nhiều nghiên cứu về thời gian, những gì và nơi bạn nên lưu vào bộ nhớ đệm.

  3. Khả năng mở rộng và thử nghiệm tải. Suy nghĩ thêm phải đi vào từng hoạt động tìm nạp tài nguyên để đảm bảo rằng nó được thực hiện vài lần khi cần thiết. Tải thử nghiệm và hồ sơ mã có thể giúp xác định tắc nghẽn ở đây nếu bạn sử dụng các công cụ tốt.

  4. Tối ưu hóa cơ sở dữ liệu. Hãy chắc chắn rằng bạn hiểu làm thế nào để tối ưu hóa cơ sở dữ liệu của bạn đúng cách cho hàng ngàn (hàng triệu) hoạt động mỗi phút. Nếu ứng dụng của bạn là viết nặng, bạn có thể cần phải xem xét lưu trữ dữ liệu cũ hơn mà không cần phải được bao gồm trong các chỉ mục nữa để tăng tốc độ hoạt động viết của bạn.

  5. Đường dẫn nâng cấp. Lưu lượng truy cập của bạn có tăng lên theo thời gian không? Hãy chắc chắn để hiểu làm thế nào bạn sẽ cắm thêm nhiều máy chủ và bộ nhớ cho ứng dụng của bạn nếu/khi nó cần thiết, và những gì sẽ được yêu cầu.

Có rất nhiều sách xung quanh bạn có thể đầu tư vào điều đó có thể sẽ trả hết bằng cổ tức lớn. Thực hiện tìm kiếm "xây dựng ứng dụng web có thể mở rộng" ở amazon hoặc chương và bạn có thể sẽ tìm thấy rất nhiều văn bản để tiếp tục, cả về công nghệ cụ thể và thuyết bất khả tri.

+0

Cảm ơn! Điều đó cung cấp một số nội dung để xem xét. – samoz

+0

Nếu bạn đang sử dụng ASP.Net hoặc ASP.Net MVC làm ngăn xếp công nghệ của bạn, trang MSDN có rất nhiều bài viết có thể giúp bạn bắt đầu với tất cả các khái niệm này cho các công nghệ đó. – womp

+0

Mẹo hay về # 2 là sử dụng proxy bộ nhớ cache nếu có thể, ví dụ: Varnish hoặc mực. Điều đó có thể làm giảm đáng kể tải trên máy chủ ứng dụng của bạn vì chúng sẽ không phải tạo lại các trang cho mỗi khách truy cập. – Martin

0

chỉ không làm nhiều hơn mức bạn cần. nếu bạn giữ điều đó, bạn có thể xử lý hầu hết mọi thứ ngắn của các hiệu ứng metablog.

1

Ngoài mọi thứ khác được đề cập ở đây, bạn nên xem xét thời gian lưu lượng truy cập của mình.Nó có tương đối không đổi theo thời gian không? Hay nó đến trong các vụ nổ, nơi bạn sẽ nhận được lượng lưu lượng truy cập cao hơn nhiều trong một khoảng thời gian ngắn?

Bằng và lớn, bạn sẽ muốn thiết kế một hệ thống có thể xử lý các tải trọng cao cấp một cách duyên dáng (mặc dù không nhất thiết phải ở mức hiệu suất lý tưởng). Nếu lưu lượng truy cập của bạn là rất bursty thì bạn sẽ phải dành nhiều nỗ lực để làm cho nó quy mô hơn bạn sẽ nếu bạn có cùng một lượng lưu lượng truy cập dần dần.

1

Theo như Erlang đi: nó có vẻ giống như một ngôn ngữ chấp nhận tốt (dựa trên ít tôi biết về nó), nhưng nó chắc chắn không phải là một cây đũa thần cung cấp cho bạn khả năng mở rộng. Có hàng tá yếu tố và sản phẩm khác nhau để xem xét. Lựa chọn ngôn ngữ là một trong số đó ... và có lẽ là một trong những thứ ít quan trọng nhất.

Bạn có thể nên làm theo những gì bạn đã biết & tìm hiểu cách làm cho quy mô thay vì đi đến một công nghệ mới/không xác định và hy vọng rằng nó sẽ mở rộng cho bạn.

+0

Tôi đến từ chủ yếu là nền C hoặc hệ thống cấp độ C, vì vậy tôi có thể bắt đầu từ mọi nơi. Tôi thích nhìn vào Erlang bởi vì nó là một ngôn ngữ chức năng nhưng cũng vì các khía cạnh tương tranh cao mà nó đã chào hàng. – samoz

1

Bộ nhớ phụ trợ, xử lý cơ sở dữ liệu, nội dung động ở mặt trước và bộ nhớ đệm là một điều. Việc xem xét nhà cung cấp dịch vụ lưu trữ của bạn và băng thông mạng có sẵn là khác.

Kiểm tra dịch vụ lưu trữ của bạn trên giới hạn băng thông, phân bổ bộ nhớ tối đa theo yêu cầu, kích thước tải lên tệp tối đa và truy vấn cơ sở dữ liệu tối đa. Nếu máy chủ lưu trữ hiện tại của bạn không cung cấp dịch vụ giá rẻ phù hợp với yêu cầu mở rộng quy mô của bạn, sau đó chuyển sang máy chủ khác trước khi bạn tắt hoặc bị cảnh báo bằng hóa đơn hàng tháng có ba chữ số để vượt qua băng thông được phân bổ của bạn.

Chỉnh sửa: chỉ cần đọc lại và bắt gặp tham chiếu "mạng nội bộ" của bạn. Vì vậy, trong trường hợp này, bạn có thể sẽ không bị mắc kẹt với một vài trăm đô la hóa đơn bởi quản trị mạng của bạn, nhưng họ vẫn có thể đóng cửa bạn. Hãy chắc chắn để giữ cho các đường giao tiếp mở với quản trị viên mạng và quản trị viên của bất kỳ dịch vụ nào khác mà trang web của bạn tương tác với, hoặc bạn có thể sẽ làm cho kẻ thù của họ tất cả khá nhanh chóng. Nói cách khác: nghi thức mạng tốt. Ngoài ra, nếu bạn thực sự sở hữu và xây dựng máy chủ, hãy đảm bảo rằng hệ điều hành, ngăn xếp phần mềm và phần cứng đều được cập nhật với phiên bản phần mềm và chương trình cơ sở ổn định, có thể xử lý tải và theo dõi để chạy trơn tru tại tất cả thời gian.

Chỉnh sửa # 2: Tôi biết bạn đã hỏi cụ thể về cách ứng dụng của bạn có thể xử lý tải và tôi có thể xem xét chủ đề ở đây, nhưng bạn cũng phải cân nhắc xem bạn và đồng đội của bạn có thể xử lý tải không. Băng thông nhân lực cũng quan trọng và không được khuyến khích bởi tải công việc là cách các dự án như thế này thất bại. Bia là người bạn tốt nhất của lập trình viên, đặc biệt là khi giải quyết các nhiệm vụ lập trình phức tạp và sáng tạo, nhưng nó có thể dẫn đến các vấn đề nghiêm trọng về uống rượu nếu nhân lực không được quản lý đúng cách hoặc thiếu nguồn nhân lực. Ai sẽ trả lời thông báo ngừng hoạt động lúc 3 giờ sáng? Ai sẽ trả lời cho những người theo chủ nghĩa tôn giáo hay kẻ lừa đảo, hoặc thu thập thông qua luật và bằng sáng chế để xác minh xem thông báo đó có phải là giả mạo không? Trừ khi đó là một buổi biểu diễn có thể trả các hóa đơn, có thể hầu hết mọi người không thể dành nhiều thời gian và năng lượng. Tôi không có ý muốn ngăn cản bạn, và hy vọng bạn đã được bảo hiểm này.

+0

Cảm ơn lời khuyên. Nếu chúng tôi chuyển điều này lên internet (có thể xảy ra sau cùng nếu thí điểm này thành công), tôi sẽ nhớ xem xét điều đó. – samoz