Thiết lập máy chủ của tôi cho API được sử dụng nhiều

Tôi sẽ sớm mua một loạt các máy chủ cho một ứng dụng mà tôi sắp khởi chạy nhưng tôi lo ngại về thiết lập của mình. Tôi đánh giá cao bất kỳ thông tin phản hồi tôi nhận được.

Tôi có một ứng dụng sẽ sử dụng API mà tôi đã viết. Những người dùng / nhà phát triển khác cũng sẽ sử dụng API này. Máy chủ API sẽ nhận các yêu cầu và chuyển tiếp chúng đến các máy chủ worker. API sẽ chỉ giữ một db mys mys của các yêu cầu cho mục đích ghi nhật ký, xác thực và giới hạn tỷ lệ.

Mỗi máy chủ worker thực hiện một công việc khác nhau và trong tương lai để mở rộng quy mô, tôi sẽ thêm nhiều máy chủ worker để sẵn sàng đảm nhận công việc. Tệp cấu hình API sẽ được chỉnh sửa để ghi chú các máy chủ worker mới. Các máy chủ worker sẽ thực hiện một số xử lý và một số sẽ lưu đường dẫn đến hình ảnh vào cơ sở dữ liệu cục bộ để sau đó được API truy xuất để xem trên ứng dụng của tôi, một số sẽ trả về chuỗi kết quả của một quá trình và lưu nó vào cơ sở dữ liệu cục bộ .

Thiết lập này có vẻ hiệu quả với bạn? Có cách nào tốt hơn để tái cấu trúc này không? Những vấn đề tôi nên xem xét? Xin vui lòng xem hình ảnh dưới đây, tôi hy vọng nó hỗ trợ sự hiểu biết.

Sẵn có cao hơn

Như Chris đề cập, máy chủ API của bạn là điểm thất bại duy nhất trong bố cục của bạn. Những gì bạn đang thiết lập là một cơ sở hạ tầng xếp hàng tin nhắn, điều mà nhiều người đã thực hiện trước đây.

Tiếp tục xuống cùng một con đường

Bạn đề cập đến việc nhận yêu cầu trên máy chủ API và chèn công việc vào MySQL DB chạy trên mỗi máy chủ. Nếu bạn muốn tiếp tục trên đường dẫn này, tôi khuyên bạn nên xóa lớp máy chủ API và thiết kế Công nhân cho mỗi lệnh chấp nhận trực tiếp từ Người dùng API của bạn. Bạn có thể sử dụng một cái gì đó đơn giản như DNS vòng tròn để phân phối trực tiếp từng kết nối Người dùng API đến một trong các nút worker có sẵn (và thử lại nếu kết nối không thành công).

Sử dụng máy chủ xếp hàng tin nhắn

Cơ sở hạ tầng xếp hàng tin nhắn mạnh mẽ hơn sử dụng phần mềm được thiết kế cho mục đích này như ActiveMQ . Bạn có thể sử dụng API RESTful của ActiveMQ để chấp nhận các yêu cầu POST từ Người dùng API và nhân viên nhàn rỗi có thể NHẬN tin nhắn tiếp theo trên hàng đợi. Tuy nhiên, điều này có thể là quá mức cần thiết cho nhu cầu của bạn - nó được thiết kế cho độ trễ, tốc độ và hàng triệu tin nhắn mỗi giây.

Sử dụng Zookeeper

Là một trung gian, bạn có thể muốn xem Zookeeper , mặc dù đó không phải là máy chủ xếp hàng tin nhắn. Chúng tôi sử dụng tại $ work cho mục đích chính xác này. Chúng tôi có một bộ ba máy chủ (tương tự máy chủ API của bạn) chạy phần mềm máy chủ Zookeeper và có một trang web để xử lý các yêu cầu từ người dùng và ứng dụng. Giao diện web, cũng như kết nối phụ trợ Zookeeper với công nhân, có bộ cân bằng tải để đảm bảo chúng tôi tiếp tục xử lý hàng đợi, ngay cả khi máy chủ ngừng hoạt động để bảo trì. Khi công việc hoàn thành, công nhân nói với cụm Zookeeper rằng công việc đã hoàn thành. Nếu một công nhân chết, công việc đó sẽ được gửi đến một công việc khác để hoàn thành.

Những mối quan tâm khác

• Đảm bảo công việc hoàn thành trong trường hợp công nhân không phản hồi
• Làm cách nào API biết rằng một công việc đã hoàn thành và để lấy nó từ cơ sở dữ liệu của công nhân?
• Cố gắng giảm sự phức tạp. Bạn có cần một máy chủ MySQL độc lập trên mỗi nút worker hay chúng có thể nói chuyện với máy chủ MySQL (hoặc cụm sao chép MySQL) trên (các) máy chủ API không?
• Bảo vệ. Bất cứ ai cũng có thể gửi một công việc? Có xác thực?
• Những công nhân nào sẽ nhận được công việc tiếp theo? Bạn không đề cập đến việc các tác vụ dự kiến ​​sẽ mất 10ms hoặc 1 giờ. Nếu chúng nhanh, bạn nên loại bỏ các lớp để giảm độ trễ. Nếu chúng chậm, bạn nên rất cẩn thận để đảm bảo các yêu cầu ngắn hơn không bị kẹt sau một vài yêu cầu dài.

Vấn đề lớn nhất tôi thấy là thiếu kế hoạch chuyển đổi dự phòng.

Máy chủ API của bạn là một điểm thất bại lớn. Nếu nó bị hỏng, thì không có gì hoạt động ngay cả khi máy chủ worker của bạn vẫn hoạt động. Ngoài ra, nếu một máy chủ worker ngừng hoạt động, thì dịch vụ mà máy chủ đó cung cấp sẽ không còn nữa.

Tôi khuyên bạn nên xem dự án Máy chủ ảo Linux ( http://www.linuxvirtualserver.org/ ) để có ý tưởng về cách cân bằng tải và chuyển đổi dự phòng hoạt động, và để có ý tưởng về cách những thứ này có thể có lợi cho thiết kế của bạn.

Có nhiều cách để cấu trúc hệ thống của bạn. Cách nào tốt hơn là một cuộc gọi chủ quan được bạn trả lời tốt nhất. Tôi đề nghị bạn làm một số nghiên cứu; cân nhắc sự đánh đổi của các phương pháp khác nhau. Nếu bạn cần thông tin về một phương pháp cấy ghép, sau đó gửi một câu hỏi mới.