Điều gì làm cho một ứng dụng có thể mở rộng?

Tôi tiếp tục thấy trong các bài đăng công việc rằng ứng viên phải có kinh nghiệm viết các ứng dụng "có thể mở rộng". Điều gì làm cho một ứng dụng có thể mở rộng và làm cách nào để biết rằng mã của tôi có thể mở rộng tới hàng triệu người dùng?

Tôi đoán một cách tốt hơn để diễn đạt câu hỏi này là: Làm thế nào tôi có thể viết mã của mình với khả năng mở rộng trong tâm trí? Vì vậy, mã có thể được mở rộng từ get-go trái ngược với suy nghĩ lại. Có phương pháp thiết kế nhất định? Hay đơn giản chỉ là vấn đề chọn các thuật toán chính xác cho công việc?

Có hai hướng khả năng mở rộng:

• dọc (hay còn gọi là tăng tỷ lệ): CPU nhanh hơn, RAM nhiều hơn, nhiều không gian đĩa hơn;
• chiều ngang (hay còn gọi là nhân rộng): nhiều lõi hơn trong CPU, nhiều CPU hơn, nhiều máy chủ hơn;

Đối với người đầu tiên, bạn chỉ cần lưu ý rằng bạn không có bất kỳ giới hạn tùy ý. Những điều này là do kích thước số nguyên quá nhỏ hoặc cấu trúc chiều dài cố định / giới hạn. Các cấu trúc này có thể liên quan đến hệ điều hành cơ bản. Ví dụ: nếu bạn cố gắng mở rộng quy mô bằng cách sử dụng nhiều luồng hoặc quy trình hơn, tại một số điểm bạn sẽ đạt đến giới hạn của HĐH. Đó là lý do tại sao các máy chủ hiện tại xây dựng cho khả năng mở rộng cao đang thực hiện đồng thời dựa trên các sự kiện không đồng bộ. Vấn đề này được mô tả trong tài liệu C10K nổi tiếng .

Thứ hai là khó khăn hơn. Nó đòi hỏi phải lập trình với hai điều cần lưu ý: dữ liệu sẽ được xử lý song song và dữ liệu có thể được phân phối vật lý. Giao tiếp giữa các nút nên được hạn chế. Trong thực tế, điều đó thường có nghĩa là hy sinh một số phần của ACID (điều đó được chứng minh rằng bạn không thể có ACID đầy đủ và khả năng mở rộng quy mô cùng một lúc). Giải pháp được biết đến nhiều nhất cho việc lưu trữ dữ liệu trong mô hình đó là các giải pháp NoQuery . Chúng bao gồm từ các kho lưu trữ khóa-giá trị rất đơn giản, đến các hệ thống giống như RDBMS, chỉ bị tước khả năng tham gia. Các cửa hàng khóa-giá trị là siêu quy mô, nhưng đó là một mức giá. Về cơ bản bạn chỉ có thể truy vấn trên khóa chính. Tuy nhiên, có giải pháp cho vấn đề đó, đó là giảm bản đồ. Nó có vẻ rất tối ưu nếu bạn nhìn vào quan điểm phức tạp tích lũy, nhưng bạn phải ghi nhớ rằng nó chạy song song.

Nếu bạn muốn đọc thêm về khả năng mở rộng với các ví dụ thực tế, hãy xem blog HighScalability.com .

Khả năng mở rộng được đo lường về mặt thông lượng dựa trên một số biến. Ví dụ: số lượng yêu cầu / giây với người dùng X. Cách đơn giản nhất để mô tả khả năng mở rộng là:

Một thước đo hiệu quả khi tải tăng.

Điều đầu tiên bạn cần hiểu trong việc thiết kế khả năng mở rộng là phép đo nào là quan trọng nhất cho ứng dụng của bạn? Có một số cách đo lường hiệu quả là thành phần chính của khả năng mở rộng:

• Yêu cầu đồng thời mỗi giây
• Thời gian phản hồi trung bình cho mỗi yêu cầu
• Số lượng hồ sơ được xử lý mỗi giây / phút

Có nhiều phép đo hiệu quả hơn có thể được sử dụng, nhưng chúng là phổ biến cho các hệ thống dựa trên web hoặc hệ thống xử lý hàng loạt.

Khía cạnh tiếp theo của khả năng mở rộng là đo lường những gì xảy ra với hiệu quả của bạn khi tải được tăng lên. Các cách phổ biến để tải tăng là:

• Nhiều người dùng nhấn máy chủ (tức là lưu lượng truy cập web nhiều hơn)
• Nhiều dữ liệu hơn trong cơ sở dữ liệu (nghĩa là các truy vấn mất nhiều thời gian hơn hoặc quá trình xử lý mất nhiều thời gian hơn)
• Lỗi ổ cứng trong RAID (hiệu suất lưu trữ / độ tin cậy bị ảnh hưởng)
• Mạng bão hòa

Mục tiêu cho một ứng dụng có thể mở rộng là duy trì hoặc cải thiện hiệu quả khi chúng ta xử lý vấn đề tải. Nói tóm lại, nếu thời gian phản hồi mất quá nhiều thời gian, chúng ta có thể thêm một máy chủ khác để phân phối tải đồng đều không? Cách tiếp cận này làm giảm khối lượng công việc cho một máy chủ thực hiện và giữ cho các máy chủ hoạt động ở "điểm ngọt" đó để đạt hiệu quả.

Ứng dụng của bạn sẽ cần phải được thiết kế đặc biệt để mở rộng quy mô. Điều đó có nghĩa là bạn phải cẩn thận với dữ liệu phiên, định tuyến các yêu cầu đến đúng máy chủ, giảm các tắc nghẽn làm hạn chế khả năng ứng dụng mở rộng quy mô.

Về cơ bản, bạn muốn tránh tắc nghẽn hiệu suất khi bạn tăng số lượng người dùng và / hoặc xử lý một tập dữ liệu lớn hơn và / hoặc cung cấp giao diện của bạn bằng nhiều ngôn ngữ hơn, v.v.

Về cơ bản, bạn hãy xem lược đồ cơ sở dữ liệu, thuật toán và quy trình phát triển phần mềm của bạn và cố gắng dự đoán các vấn đề trong tương lai. Bạn cũng muốn thiết lập giám sát hiệu suất để xác định các vấn đề khi chúng bắt đầu xây dựng.

Tôi đã chọn những lời khuyên này khi tôi đọc Xây dựng trang web có thể mở rộng (liên kết đến amazon).

Hi vọng điêu nay co ich!

Cách duy nhất mà các ứng dụng có thể thực sự có khả năng mở rộng, là không có bất kỳ hạn chế nào không thể vượt qua (hoặc chỉ rất tốn kém).

Một ví dụ điển hình là điều gì xảy ra khi bạn hết chu kỳ cpu có sẵn? Nếu chương trình của bạn có nhiều bước, bạn có thể chạy trên một hộp có nhiều lõi nhưng điều gì xảy ra khi bạn không thể mua một hộp lớn hơn nữa? Ứng dụng của bạn đơn giản là không thể phát triển được nữa và do đó không thể mở rộng được.

Bất kỳ ứng dụng thực sự có khả năng mở rộng nào cũng phải có khả năng trải rộng trên nhiều máy tính một cách minh bạch và làm như vậy mà không có bất kỳ sự va chạm đáng chú ý nào. Điều này không dễ dàng, và đó là một trong những lý do tại sao Google đã rất thành công.

Có những vấn đề độc đáo đi kèm với việc hỗ trợ các ứng dụng quy mô lớn. Việc đăng việc đang tìm kiếm những ứng viên đã làm việc trong môi trường đó và phải giải quyết những vấn đề như vậy.

Từ một ứng dụng cấp cao được tạo ra có thể mở rộng bằng cách liên tục đặt câu hỏi điều gì sẽ xảy ra nếu đoạn mã này được yêu cầu chạy hàng nghìn lần trong một khoảng thời gian rất nhỏ. Điều này có nghĩa là quản lý dấu chân bộ nhớ của bạn, sử dụng bộ nhớ đệm của tổng số và dữ liệu, sử dụng các nguồn dữ liệu có thể tự mở rộng, v.v.

Nếu bạn đang xây dựng một tính năng tìm kiếm hoạt động tốt khi nó có 100 hàng trong DB để tìm kiếm và 10 người dùng sử dụng nó cùng một lúc. Nó sẽ hoạt động tốt như thế nào khi 100 người dùng đang sử dụng nó cùng một lúc và có 100K hàng để tra cứu.

Nếu nó thực hiện như nhau không có vấn đề gì thì nó rất tốt. nếu nó thực hiện tỷ lệ thuận với lượng người dùng / dữ liệu (nghĩa là thêm 10 lần dữ liệu = = 10 lần để xử lý) thì tốt. Nếu nó thực hiện thấp hơn nhiều dữ liệu mà nó có (dữ liệu chế độ 10 x = = 10 ^ 10 lâu hơn để xử lý) thì nó không mở rộng tốt.

Các ví dụ của tôi thực sự nên được hiển thị trong ký hiệu Big O nhưng hiện tại tôi không biết rõ về nó để viết ra các ví dụ trong Big O.

Bạn có thể mô phỏng nhiều dữ liệu hơn bằng cách đưa dữ liệu giả vào DB của mình và có các công cụ để mô phỏng nhiều người dùng hơn như Apache AB.