Hoàng coolfire
Member
Mình k thấy topic nào nên mạn phép tạo r để trao đổi, đợi tí mh viết bài chia sẻ KN của mh đang làm với SAGA outbox
thảo luận Trao đổi về Microservice, SAGA, event sourcing.... cloud..
- Người tạo chủ đề Hoàng coolfire
- Ngày bắt đầu
Hoàng coolfire
Member
THẾ NÀO LÀ CỔ BẠN
à mình có follow theo 1 khóa trên udemy về devops cho .net nhưng thằng đấy dạy setup từ core 2.0 mà h lên net 8 rồi set up thấy cấu hình cũng khác nhanh gọn hơn nên muốn kiếm chỗ nào mới mà hiệu quả các bác đã học qua gợi ý mình luôn
darkrose1
Member
anh này là @gaconkute đúng ko nhỉ
TomorrowNeverDie
Member
Đánh dấu chờ thớt share bài
Rhett Butler567
Senior Member
Muốn học ci cd bdau từ đâu các fen. Có lộ trình k nhỉ
Darabeny
Junior Member
Tiện chủ đề này thì em có thắc mắc luôn mấy câu hỏi 
:
- Em cũng apply outbox vào service nhưng khi phình to số lượng event, mà mỗi event sẽ đi kèm 1 outbox table tương đương thì sẽ có n table tương ứng. Và cảm giác như đang hơi "thừa" nhiều.
=> Hiện tại thì em chỉ apply cơ bản cho những event bắt buộc idempotent. Bác nghĩ thế nào về vấn đề này
- Khi mà xảy ra exception khi call các service khác để lấy data (REST, grpc,..) nhưng không phân biệt được là do không có data hay vấn đề network (nên không lấy được data) mà theo outbox thì sẽ không xử lý lại được event này nữa. Vậy thì trong trường hợp này sẽ xử lý như thế nào?
:- Em cũng apply outbox vào service nhưng khi phình to số lượng event, mà mỗi event sẽ đi kèm 1 outbox table tương đương thì sẽ có n table tương ứng. Và cảm giác như đang hơi "thừa" nhiều.
=> Hiện tại thì em chỉ apply cơ bản cho những event bắt buộc idempotent. Bác nghĩ thế nào về vấn đề này
- Khi mà xảy ra exception khi call các service khác để lấy data (REST, grpc,..) nhưng không phân biệt được là do không có data hay vấn đề network (nên không lấy được data) mà theo outbox thì sẽ không xử lý lại được event này nữa. Vậy thì trong trường hợp này sẽ xử lý như thế nào?
billy_don
Senior Member
Outbox đẻ ra để xử lý vấn đề như thím mô tả mà. Sau khi service handle xong event đẩy xuống outbox, đặt scheduler đến khi nào event được đẩy đi thì thôi. Check idempotent tại consumer.
này chắc do cách bác thiết kế, em làm chỉ đặt chung là outbox event thôi, cụ thể event gì thì nhét vào payload, làm như này thì ko cần phải bôi ra nhiều table như bác đang làm
Sửa lần cuối:
martin98
Senior Member
Mình đang hiểu case của bạn ntn: có 2 step, step 1 là gọi service khác lấy data xử lý rồi sang step 2 là dùng data đã qua xử lý bắn event vào kafka.
Như này có đúng k nhỉ
Darabeny
Junior Member
Nếu chỉ 1 outbox event chung thì bác dùng gì để xác định nó là 1 idempotent (em đang xác định unique bằng 1 vài data trong payload và mỗi loại event thì unique này nó sẽ khác nhau). Có thể cách em triển khai chưa hợp lý lắm, bác cho em tham khảo cách thiết kế phát
Đúng như bác @martin98 nói, em đang xử lý theo kiểu:
- Idempotent tại consumer nhưng event chỉ chứa thông tin id, chứ không có data.
- Vì vậy em cần call lại các service khác,
- Và vấn đề khi mà em validate những cái data lấy về kia, thì em xác định ra 2 loại exception:
- Những cái exception là expected được (ví dụ dữ liệu validate thất bại) thì em cũng coi nó như là đã xử lý xong. => Đã idempotent
- Tất nhiên là những cái exception không expected được sẽ fail và không idempotent
Chủ đề tương tự
