Azure ServiceBus: đợi cho đến khi tất cả người đăng ký xử lý tin nhắn


8

Kịch bản của tôi là tôi đang lên kế hoạch tạo một chủ đề ServiceBus với nhiều người đăng ký (chưa biết). Họ có thể sử dụng các bộ lọc chủ đề, vì vậy sẽ không xử lý từng thông báo từ chủ đề.

Tôi cần một tin nhắn (Id) nhất định để đợi cho đến khi tất cả các trình xử lý đã hoàn thành công việc của họ để tiếp tục công việc. Đương nhiên, mỗi trình xử lý sẽ tạo ra một thông báo sau khi hoàn thành và tôi có thể sử dụng ví dụ như Hàm bền để chờ danh sách các sự kiện.

Nhưng câu hỏi là làm thế nào tôi có thể biết danh sách tin nhắn đăng ký đã / sẽ được gửi đến?

Với Microsoft.Azure.ServiceBus.Management.ManagementClient.GetSubscriptionsAsync()tôi có thể nhận được danh sách tất cả các mục đăng ký cho chủ đề của tôi. Nhưng tôi không thể tìm ra cách đánh giá liệu nó sẽ lấy một tin nhắn nhất định hay không theo các bộ lọc.

Nếu điều đó là không thể đạt được với ServiceBus, có bất kỳ giải pháp thay thế nào (ngoài việc phát minh lại bánh xe với triển khai tùy chỉnh Pub / Sub) để thực hiện loại kịch bản này không?


Bạn có thể chia các mục đăng ký của bạn thành nhiều chủ đề không? Bạn có thể giải thích bức tranh rộng lớn hơn về những gì bạn đang cố gắng làm không? (Ví dụ: vui lòng giải thích lý do tại sao bạn cần làm việc đó chứ không phải những gì bạn cần làm.)
Slothario 23/12/19

@Slothario Nếu chúng tôi chia chủ đề thành nhiều luồng: một luồng cho mỗi người đăng ký, chúng tôi sẽ phá vỡ toàn bộ ý tưởng rằng nhà xuất bản độc lập với người đăng ký. Chúng tôi sẽ không thể tự động thêm người đăng ký mới mà không sửa đổi mã của nhà xuất bản ...
Sasha

Bạn đang cố gắng để làm gì? Có vẻ như bạn đang cố gắng làm một cái gì đó như shending dựa trên tải, và đó là một kịch bản cực kỳ phổ biến. Tôi không nghi ngờ rằng Service Bus làm điều gì đó tương tự, và tôi biết một cái gì đó như Kafka có thể xử lý nó. Tuy nhiên, thật khó để nói trừ khi tôi biết bạn đang cố gắng giải quyết vấn đề gì. meta.stackexchange.com/questions/66377/what-is-the-xy-probols
Slothario 23/12/19

1
Tôi hiểu rồi Nhưng những gì tôi đã học được về microservice là chúng rất dễ thực hiện, nhưng trở nên rất phức tạp nhanh vì điện toán phân tán khó hơn dường như. Microservice là một chiến lược để giảm các dòng giao tiếp trong một tổ chức, không phải để tổ chức mã. Để tổ chức mã, sử dụng các mẫu thiết kế tốt. Tôi thực sự khuyên bạn nên đọc một số bài để thuyết phục bản thân mình đó là sự thật. Tuy nhiên, nếu bạn không có tổ chức trong tổ chức của mình để thực hiện thay đổi, tôi cũng hiểu điều đó.
Slothario

1
Tôi sẽ có một dịch vụ cốt lõi lắng nghe các sự kiện và điều phối các cuộc gọi "bổ trợ" thông qua phần còn lại để xử lý. Ngoài ra, một phần trong đó mỗi plugin sẽ cần phải "đăng ký" (Bạn có thể dễ dàng thực hiện điều đó như một phần của các thiên thần) trong lõi để nói rằng tôi có thể xử lý một số loại sự kiện. Trong trường hợp này, bạn sẽ có sự linh hoạt của các dịch vụ vi mô để bạn có thể triển khai từng đoạn riêng biệt nhưng bạn vẫn có thể kiểm soát ai và khi nào xử lý sự kiện của mình. Thậm chí nhiều hơn bây giờ bạn có thể đặt hàng xử lý sự kiện, bạn cũng có thể ngắt thực thi nếu cần để bạn không gọi cho bộ xử lý khác, bạn có thể thêm quy tắc, v.v.
Volodymyr Bilyachat

Câu trả lời:


0

Tôi sẽ bắt đầu bằng cách loại bỏ khả năng lọc.

Tạo các chủ đề máy chủ (không phải là một chủ đề cho mỗi thuê bao) là một xấp xỉ của các bộ lọc.

Mỗi thuê bao đăng ký một chủ đề phải xử lý tất cả các tin nhắn cho chủ đề đó. Ngay cả khi nó được nói rằng họ không làm gì với nó.

Sau đó, bạn biết ai đã đăng ký từng chủ đề và ai đã xử lý từng tin nhắn trên mỗi chủ đề.


Tôi nghĩ ý tưởng của ServiceBus là các thuê bao quyết định tin nhắn nào họ muốn nghe. Và thật khó để khiến họ không sử dụng các bộ lọc khi họ có thể sử dụng API tiêu chuẩn để đăng ký ... Và các bộ lọc đã được giới thiệu để tiết kiệm chi phí - nếu một số Chức năng Azure cần xử lý 1% trong số triệu yêu cầu mỗi giờ, thì đó sẽ là một tiết kiệm chi phí tốt để áp dụng bộ lọc. Nhưng thực sự, tôi đã đi đến cùng một kết luận rằng hiện tại nó không được hỗ trợ và mọi người đăng ký sẽ cần phải trả lời mọi tin nhắn một cách đáng tiếc.
Sasha

Vấn đề xảy ra khi bạn cần phân biệt giữa các tin nhắn mà họ muốn và chưa đọc, và những tin nhắn mà họ không quan tâm và bị lọc đi.
Shiraz Bhaiji
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.