Dịch vụ vi mô - bù lỗi dịch vụ với hàng đợi

Chúng tôi đang sử dụng một số cách tiếp cận microservice trong ứng dụng của mình (mặc dù nó không thực sự được tuân thủ).

Khi một dịch vụ ngừng hoạt động hoặc ném ngoại lệ, cách tiếp cận là đưa nó vào hàng đợi (ActiveMQ) và thử lại khi dịch vụ hoạt động trở lại.

Đây có phải là một giải pháp "tiêu chuẩn"? Hoặc nó nên được tránh vì một số lý do?

Hoặc có một giải pháp tốt hơn, hoặc thay thế cho vấn đề này?

microservices message-queue

— người dùng140547
nguồn

Vấn đề với giải pháp hiện tại là gì? Giải pháp tốt nhất / tốt hơn là giải pháp hoàn toàn phù hợp với yêu cầu của bạn. Làm như vậy hiện tại?

— Laiv

@Laiv: Không có vấn đề gì cả, nhưng vì tôi không có kinh nghiệm với kiến trúc đó, tôi chỉ hỏi, liệu có bất kỳ vấn đề hoặc hạn chế tiềm năng nào của phương pháp này cần được xem xét.

— user140547

Điều gì xảy ra nếu hàng đợi xuống?

— Jon Raynor

@JonRaynor: từ bỏ và trả lại lỗi, vì có thể sẽ quá mức cần thiết để thực hiện cơ chế dự phòng thứ hai ...

— user140547

Câu trả lời:

Giả sử bạn có thể thực hiện các cuộc gọi của mình không đồng bộ (bạn không cần nhận phản hồi từ dịch vụ để tiếp tục), làm như vậy thường là một ý tưởng tốt.

Nó cho phép dịch vụ gọi tiếp tục hoạt động mà không bị chậm trễ (hoặc lỗi hoàn toàn) do gọi dịch vụ kia. Nó cho phép bạn có logic thử lại phức tạp hơn và trải đều tải hơn theo thời gian.

Trong nhiều trường hợp, bạn có thể nhận được nhiều hơn từ nó bằng cách từ bỏ các đảm bảo đặt hàng được cung cấp bởi hàng đợi và chuyển sang Kafka hoặc một nhà môi giới tin nhắn không đồng bộ khác. Hermes cung cấp API REST tiện lợi hơn trên Kafka.

— Michał Kosmulski
nguồn

Tôi nêu lên câu trả lời này giả sử bối cảnh là chúng ta đang nói về khách hàng. Đây thực sự không phải là một câu hỏi dịch vụ vi mô. Đó là một quyết định thiết kế của khách hàng. Nếu dịch vụ có đồng bộ hay không và nó sẽ hoạt động hoặc không. Nó không được phát âm rõ ràng trong câu hỏi nhưng nó thực sự chỉ có ý nghĩa nếu chúng ta đang nói về một khách hàng.

— JimmyJames

Đây là một cách tiếp cận xấu trong quan điểm của tôi. bạn cũng nên

Luôn giao tiếp xem hàng đợi: Ứng dụng của bạn không cần phải có phản hồi ngay lập tức và do đó quy trình công nhân không phải có sẵn 100%
Luôn sử dụng comms kiểu RPC. Tải yêu cầu số dư trên nhiều trường hợp dịch vụ: Nếu một dịch vụ bị lỗi, một dịch vụ khác sẽ trả lời yêu cầu, do đó bạn có 100% thời gian hoạt động

Có luồng, dịch vụ cuộc gọi, gặp lỗi, đặt hàng đợi, nhớ kiểm tra hàng đợi để trả lời một số tin nhắn của tôi nhưng không phải tất cả chúng. là quá phức tạp.

chỉnh sửa: quá phức tạp ở chỗ bạn phải lập trình cả phong cách giao tiếp đồng bộ và không đồng bộ thay vì chỉ một hoặc khác.

— Ewan
nguồn

Tôi đồng ý với điều này. Đó là nhiều phức tạp. Cho dù nó quá phức tạp rất khó để đánh giá mà không hiểu kiến trúc lớn hơn. Vấn đề với việc dựa trên hàng đợi 100% là nó thêm một điểm thất bại mới và tạo ra một số thách thức khác. Ví dụ: nếu quy trình của bạn đang bị quá tải với các tác vụ, việc ghi vào hàng đợi thường rất nhanh vì vậy không có vấn đề rõ ràng nào ở phía đầu vào cho đến khi bùng nổ hàng đợi. Nếu nguồn yêu cầu không thể được điều chỉnh, bạn có thể gặp vấn đề lớn. Không thể vượt qua nhưng nó thêm vào sự phức tạp của riêng nó.

— JimmyJames

Nếu tôi có thể, tôi sẽ đề nghị viết lại câu cuối cùng. 'Ghi nhớ' thực sự không phải là vấn đề ở đây, một khi mã được viết để đọc từ hàng đợi, không có gì để nhớ. Nó chỉ đơn giản là mã bổ sung để viết và duy trì nhưng nó không khác nhiều so với những gì bạn sẽ có nếu bạn luôn đọc từ hàng đợi.

— JimmyJames

trong các lỗi duy nhất goto queue senario VÀ bạn muốn trả lời bạn phải viết cả kiểm tra hàng đợi VÀ xử lý phản hồi ngay lập tức. Vì vậy, bạn phải 'nhớ' những cuộc gọi bị lỗi đó chứ không phải những cuộc gọi ngay lập tức

— Ewan

@jimmy bạn nhận được những vấn đề với bất kỳ giải pháp. luôn luôn xếp hàng, xếp hàng đôi khi hoặc tất cả RPC.

— Ewan

Bạn thực sự không có một số vấn đề này khi nhà sản xuất của bạn đang chờ đợi người tiêu dùng. Ví dụ: nếu bạn nhận được tối đa 1000 yêu cầu một giây và công suất nội bộ của bạn giảm xuống 100 giây, các nhà sản xuất của bạn sẽ bị chặn theo cách tiếp cận đơn giản. Họ cũng sẽ bị hạn chế. Nếu bạn chỉ cần chèn một hàng đợi ở giữa, các nhà sản xuất thường sẽ không bị ảnh hưởng bởi sự sụt giảm công suất và tiếp tục ở tốc độ tối đa của họ. Hàng đợi sau đó sẽ lấp đầy cho đến khi bạn đạt đến giới hạn dung lượng và việc ghi bắt đầu không thành công (ở 1000 lần thất bại một giây.)

— JimmyJames