Khi nào bắt đầu suy nghĩ về khả năng mở rộng? [đóng cửa]


10

Tôi đang có một vấn đề hài hước nhưng cũng khủng khiếp. Tôi sắp ra mắt một ứng dụng (iPhone) mới. Đây là một trò chơi nhiều người chơi theo lượt chạy trên phần phụ trợ tùy chỉnh của riêng tôi. Nhưng tôi sợ ra mắt.

Vì một số lý do, tôi nghĩ nó có thể trở thành một thứ gì đó lớn lao và sự phổ biến của nó sẽ giết chết máy chủ đơn độc + cơ sở dữ liệu MySQL của tôi.

Một mặt tôi nghĩ rằng nếu nó phát triển, tốt hơn hết là tôi nên chuẩn bị và có sẵn một cơ sở hạ tầng có thể mở rộng.

Mặt khác, tôi chỉ cảm thấy muốn đưa nó ra thế giới và xem điều gì sẽ xảy ra.

Tôi thường đọc những thứ như "tối ưu hóa sớm là gốc rễ của mọi tội lỗi" hoặc mọi người nói rằng bạn nên xây dựng trò chơi giết người của mình ngay bây giờ, với các công cụ trong tay và lo lắng về những thứ khác như khả năng mở rộng sau này.

Tôi muốn nghe một số ý kiến ​​về điều này từ các chuyên gia hoặc những người có kinh nghiệm với điều này. Cảm ơn!


1
Dường như mọi người đều bỏ lỡ phần đầu tiên của câu nói đó: "Chúng ta nên quên đi những hiệu quả nhỏ, nói về 97% thời gian" ... hiệu quả nhỏ + 97%
Guy Sirton

Hãy để nó trở thành một vấn đề, đừng sửa nó nếu nó không bị hỏng. Tôi đã thấy hàng tá dự án nơi mọi người bị treo lên vì những lo ngại về khả năng mở rộng. Đoán những gì đã xảy ra? Nhiều dự án không bao giờ làm cho nó ra khỏi cửa.
CodeART

"Nói khoảng 97% thời gian" nghe có vẻ như tối ưu hóa sớm quá trình tối ưu hóa. ;) </ Kidding>
Rob

Câu trả lời:


22

Đó thực sự là một lựa chọn dễ dàng.

Ngay bây giờ, bạn không có người dùng và khả năng mở rộng không phải là vấn đề.

Lý tưởng nhất là bạn muốn đạt đến điểm mà bạn có hàng triệu người dùng và khả năng mở rộng trở thành một vấn đề.

Ngay bây giờ, bạn không có vấn đề về khả năng mở rộng; bạn có một vấn đề về số lượng người dùng. Nếu bạn làm việc với vấn đề về khả năng mở rộng, bạn sẽ không khắc phục được vấn đề về số lượng người dùng, điều đó có nghĩa là bạn sẽ giải quyết được vấn đề mà bạn chưa có và bạn sẽ không giải quyết được vấn đề bạn gặp phải. Kết quả rất có thể là sản phẩm của bạn sẽ không làm được, và tất cả công việc của bạn sẽ chẳng là gì cả.

Nếu bạn làm việc với vấn đề số lượng người dùng, bạn sẽ giải quyết vấn đề bạn có ngay bây giờ, và sau đó bạn có thể tập trung vào vấn đề tiếp theo, có thể là khả năng mở rộng.

Điều tốt đẹp về các vấn đề về khả năng mở rộng là, theo định nghĩa, có chúng thường có nghĩa là kinh doanh khá tốt và điều này có nghĩa là bạn có thể chi tiền để tối ưu hóa khả năng mở rộng. Bạn không đi từ số người dùng 0 đến mười triệu chỉ sau một đêm và nếu bạn để mắt đến hiệu suất của hệ thống, bạn sẽ có nhiều thời gian để tối ưu hóa khi đến lúc.

Tất nhiên nó giúp ghi nhớ khả năng mở rộng trong khi viết mã bạn cần ngay bây giờ, nhưng sẽ không có ý nghĩa gì khi dành hàng chục hoặc thậm chí hàng trăm giờ cho một tính năng mà bạn không biết nếu bạn biết Sẽ không bao giờ cần đến nó, và kịch bản rất có thể là bạn sẽ không. Ngay bây giờ, mối quan tâm chính của bạn là để vận chuyển. Điều gì xảy ra sau đó; tốt, bạn có thể lo lắng về điều đó sau.


6

Không có lý do để tối ưu hóa cho đến khi bạn biết tối ưu hóa là cần thiết. Làm thế nào để bạn biết tối ưu hóa là cần thiết? Bạn đo lường.

Giả sử rằng máy chủ của bạn có một số loại giao diện dựa trên web, bạn có thể mô phỏng rất nhiều người dùng bằng cách sử dụng các công cụ như Apache JMeter . Tìm hiểu cách sử dụng công cụ, sau đó bắt đầu kiểm tra căng thẳng của bạn. Bạn sẽ có thể học đủ để biết giới hạn của hệ thống là gì. Sau đó, bạn có thể kết hợp thông tin đó với số lượng người dùng bạn có và số lượng trung bình đang chạy cùng một lúc, để quyết định khi nào sẽ tăng quy mô.


6

TL; DR Bạn nên suy nghĩ về khả năng mở rộng trước khi dòng mã đầu tiên được viết.

Điều đầu tiên đầu tiên. Khả năng mở rộng! = Tối ưu hóa

Bạn nên suy nghĩ về khả năng mở rộng trước khi dòng mã đầu tiên được viết. Điều này không có nghĩa là bạn xây dựng một số cơ sở hạ tầng lớn nếu không có khả năng trò chơi của bạn có thể thành công. Suy nghĩ về khả năng mở rộng có nghĩa là:

  • Hãy chắc chắn rằng mã được viết để nó có tỷ lệ. Tôi đã thấy rất nhiều dự án mà không có suy nghĩ nào được đưa ra cần phải mở rộng quy mô. Kết quả là một cơ sở mã hóa sẽ không mở rộng bất kể phần cứng bạn ném vào nó, hay quá đắt đối với quy mô.
  • Chỉ ra chiến lược mở rộng của bạn. Có một kế hoạch về cách hỗ trợ tất cả người dùng. Bạn có một db MySQL, bạn sẽ sắp xếp nó hoặc cụm, hoặc cái gì khác. Các chiến lược như shending đòi hỏi một số suy nghĩ trước vì nó đặt ra yêu cầu về kiến ​​trúc. Phân cụm, ít như vậy. Bạn có hỗ trợ phiên không, và phiên sẽ phản ứng thế nào với nhiều máy chủ ngoại vi. Bạn sẽ cần phiên dính, trong cân bằng tải của bạn.
  • Chỉ ra chiến lược thực hiện. Bạn sẽ sử dụng AWS để nhân rộng. Bạn có thể tận dụng bất kỳ sản phẩm hoặc dịch vụ nào cung cấp cho bạn khả năng mở rộng quy mô không? Điều này cũng liên quan đến việc hiểu chi phí của bạn.

NHƯNG có vẻ như bạn đã có một cơ sở mã. Câu hỏi bây giờ là khi nào bắt đầu nhân rộng. Điều này hoàn toàn phụ thuộc vào mã của bạn.

Nếu mã của bạn cho vay để mở rộng quy mô thì bạn đã hoàn thành phần khó. Bạn có thể có được một tài khoản AWS, quay vòng các máy chủ khi cần thiết và bạn sẽ đi.

Nếu mã của bạn không mở rộng quy mô hoặc có nút cổ chai thì bạn phải làm việc. Bạn cần xác định những điểm nghẽn của bạn là gì và khắc phục chúng. "Khi nào" thực sự rất khó để biết. Một số dịch vụ cao nguyên, một số tăng đều đặn, và một số bùng nổ. Quyết định khi nào nên ném tài nguyên vào một cái gì đó như nhân rộng thường là một chức năng của kinh doanh và đó là đánh giá rủi ro.

Ở vị trí của bạn , tôi có thể phát hành dưới dạng "beta" và quản lý kỳ vọng của người dùng. Bằng cách đó tôi có thể lấy sản phẩm ra và xem nó mở ra như thế nào.


5
Đây là lời khuyên khủng khiếp. Có đủ để nghĩ về bất cứ khi nào bắt đầu một doanh nghiệp mới, khả năng mở rộng nên là mục cuối cùng. Vấn đề hàng đầu cần là làm thế nào để nhanh chóng nhận được phản hồi hữu ích về những cách mà bạn xây dựng không phải là những gì bạn cần phải xây dựng. Điều thứ hai nên là làm thế nào để không vẽ mình vào một góc. Tuy nhiên, ngày nay bạn có thể dễ dàng tạo một cơ sở dữ liệu đơn giản dựa trên quy mô trang web thành hàng triệu trang động mỗi giờ (tôi nên biết, tôi đã thực hiện nó). Lo lắng rằng cơ sở dữ liệu sẽ là một nút cổ chai trước khi bạn có người dùng đầu tiên của bạn bị ngược.
btilly

Cố gắng thực hiện loại dự đoán hướng tới tương lai này trên thực tế có nghĩa là mọi biến số duy nhất trong mỗi lớp không nên là một thể hiện riêng lẻ, mà là một tập hợp. (MasterServer trở thành MasterServerCollection, Viewport trở thành ViewportCollection được lưu trữ trong ClientDevice, SceneGraph của máy chủ trở thành WorldInstanceCollection) ... độ trễ là 20-20. Nếu bạn biết các vấn đề tiềm ẩn ở phía trước, bạn có thể chắc chắn rằng những điều chỉnh đó dễ thực hiện. Vài người trong số họ.
Katana314

1
Điểm rất tốt. Dự án hợp đồng lớn đầu tiên tôi được đưa vào, vì một số lý do tôi đã nghĩ đến khả năng mở rộng ngay cả khi nó không được yêu cầu. Tôi giao hàng kịp thời và không có vấn đề gì. Vài năm sau, đồng nghiệp gọi cho tôi chỉ để nói với tôi rằng thật tuyệt vời khi họ được yêu cầu mở rộng hệ thống và các bộ phận tôi đã tạo ra rất dễ dàng! Nhưng đó là những năm sau đó, và chỉ để cho tôi một số lời khen.
Raybarg

3

Vì vậy, có hai lần bạn nên nghĩ về khả năng mở rộng.

Đầu tiên, cần suy nghĩ nhẹ nhàng trước khi bạn viết một dòng mã. Điều này là để đảm bảo bạn không tự viết vào lỗ hổng khả năng mở rộng và để đảm bảo mã của bạn được cung cấp cho bạn các phép đo bạn cần cho lần thứ hai.

Lần thứ hai để xem xét khả năng mở rộng là đủ trước một sự việc trở nên chậm chạp không thể chấp nhận được. Điều đó có nghĩa là bạn cần biết "quá chậm" nghĩa là gì và sự việc của bạn phản ứng như thế nào khi tải. Nếu bạn có một dịch vụ có trình điều khiển (có thể là qps) tăng N% mỗi tháng, bạn có thời gian khá khác so với "95% tài nguyên máy đã tiêu thụ" nếu việc sử dụng tài nguyên của bạn là tải bình phương hoặc tải tuyến tính.

Với trò chơi theo lượt, bạn phải có một mức độ an toàn khá cao (có lẽ bạn không có một thế giới trò chơi duy nhất và nếu bạn làm như vậy, có lẽ có một hình học bên trong, nghĩa là bạn không có "mọi người tương tác với mọi người biến "vấn đề).

Không biết chi tiết cụ thể, tôi sẽ mất một hoặc hai ngày để suy nghĩ về nơi bạn gặp vấn đề mở rộng và những chiến lược có thể bạn có để giải quyết chúng. Nhưng, điều này rất quan trọng, Hãy nghĩ về. Không làm, chỉ cần suy nghĩ (và tài liệu). Trừ khi bạn gặp vấn đề về khả năng mở rộng bắt đầu biểu hiện ở vài trăm người dùng, thì bạn nên có thời gian để kiểm tra tải và quay vòng nhiều tài nguyên phụ trợ hơn.


2

Từ mô tả của bạn, có vẻ như có hai kết quả có thể xảy ra:

  • Trò chơi là một thất bại và sau đó bạn không quan tâm.
  • Trò chơi đã thành công và sau đó phần phụ trợ của bạn sẽ không thể xử lý tải và kết quả sẽ là một thất bại.

Hừm.

Dưới đây là một số câu hỏi để tự hỏi:

  • Có bao nhiêu người dùng có thể xử lý phụ trợ hiện tại của bạn với hiệu suất chấp nhận được?
  • Bạn có kế hoạch nào đó để hạn chế tác động đối với người dùng hiện tại không nếu bạn đang thấy một số loại tăng trưởng nhanh chóng (ví dụ: tạm thời kéo trò chơi khỏi cửa hàng ứng dụng)
  • Làm thế nào nhanh chóng bạn có thể đến với một phụ trợ tốt hơn nếu bạn thành công?
  • Ý nghĩa kinh doanh của việc chờ đợi là gì. Bạn có thể tự ăn? Những rủi ro là gì?
  • Ý nghĩa kinh doanh của việc phát hành bây giờ đưa ra câu trả lời cho câu hỏi trên.

Câu trả lời cho câu hỏi của bạn sẽ trở nên rõ ràng một khi bạn xem xét những điều này. Không chuyên gia nào có thể cho bạn biết phải làm gì nếu không có thêm thông tin vì mọi hệ thống đều khác nhau và mọi doanh nghiệp đều khác nhau.


1

Máy chủ của bạn sẽ được sử dụng tương tác bởi người dùng. Điều này có nghĩa là độ trễ đang ảnh hưởng đến trải nghiệm người dùng một cách rất sâu sắc. Độ trễ xấu luôn dẫn đến trải nghiệm người dùng xấu.

Ít nhất là thực hiện một số thử nghiệm tải ad-hoc như được mô tả bởi Bryan.


Một cách tiếp cận nghiêm túc hơn

Thực hiện một số mô phỏng chạy và tìm hiểu độ trễ nào đối với trải nghiệm người dùng của bạn (sử dụng mô phỏng độ trễ mạng hoặc chỉ ngủ () bên trong ứng dụng của bạn). Tìm hiểu xem độ trễ nào đáng chú ý, gây khó chịu và không sử dụng được.

Sau đó đến bước đầu tiên theo hướng tối ưu hóa. Quyết định SLA cho máy chủ của bạn: ví dụ: ở mức 10% cuộc gọi tồi tệ nhất với độ trễ khó chịu và 1% cuộc gọi có độ trễ không sử dụng được. Với những giới hạn đó, bạn có thể sử dụng kiểm tra tải để tìm hiểu có bao nhiêu người dùng mà máy chủ của bạn có thể hỗ trợ.

Kiểm tra thông lượng thuần túy mà không đo độ trễ (hoặc ít nhất là sử dụng máy chủ theo cách thủ công trong quá trình kiểm tra tải) không hữu ích vì nó không cho bạn biết liệu số lượng thông lượng đo được có dẫn đến trải nghiệm người dùng có thể chịu được hay không.

Một bài thuyết trình rất hay về đo độ trễ của Gil Tene: http://www.infoq.com/presentations/latency-pit thác


1

Ở giai đoạn yêu cầu kinh doanh, sau đó được sử dụng để thiết lập sự hiểu biết chung về hiệu suất cho tất cả các yếu tố hạ nguồn như kiến ​​trúc, ops, phát triển, QA và giám sát trong prod. Nếu bạn không thiết lập một sự hiểu biết chung cho những gì được yêu cầu trước thì bạn sẽ có từng bộ phận của tổ chức đưa ra các giả định về hiệu suất (hoặc không nghĩ gì về chúng) khi tham gia vào các nhiệm vụ cụ thể trong suốt vòng đời của ứng dụng. Điều này đúng cho dù bạn đang tham gia vào thác nước, thác nước ngắn, nhanh nhẹn hay bất cứ phương pháp phát triển nào của thời điểm này đều hấp dẫn trong danh sách từ khóa tiếp tục.

Hiệu suất và khả năng mở rộng là khó khăn. Chức năng rất dễ dàng. Mã mở rộng kém sẽ phát triển để lấp đầy bất kỳ nguồn tài nguyên nào bạn cung cấp cho nó, do đó, việc thay đổi bong bóng chi phí bằng cách mua phần cứng lớn hơn chỉ đưa bạn đến trước khi bạn phải sửa mã không hiệu quả hoặc mua thêm phần cứng. Để điều này để ưu tiên cuối cùng cũng rất tốn kém. Có những quyết định về kiến ​​trúc và thiết kế được đưa ra sớm trong vòng đời của ứng dụng có thể phải hoàn toàn đảo ngược để đạt được yêu cầu đến muộn liên quan đến hiệu suất - Hãy nghĩ đến một chiếc xe thể thao hiệu suất cao phải chuyển từ nhôm sang sợi carbon vào cuối chu kỳ thiết kế để đạt tỷ lệ công suất / trọng lượng liên quan đến hiệu suất và cách điều này tác động đến công cụ, đào tạo, xây dựng xe hơi, v.v ...

Hỏi các kiến ​​trúc sư, nhà phát triển và những người trong tổ chức của bạn các yêu cầu về hiệu suất cho ứng dụng là gì. Nếu những điều này không được nắm bắt từ doanh nghiệp thì đừng ngạc nhiên nếu bạn nhận được câu trả lời khác nhau (hoặc không có câu trả lời) từ các cá nhân khác nhau ngay cả trong cùng một nhóm. Những "giả định" đó luôn quay trở lại để đập phá tổ chức đang triển khai.


"Hỏi các kiến ​​trúc sư, nhà phát triển và những người trong tổ chức của bạn ..." - Không có gì trong câu hỏi chỉ ra rằng đây là cho một tổ chức, đó chỉ là dự án phụ của anh chàng này.
Graham
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.