Nhưng mình nghĩ cách xài message queue sẽ scaleable hơn. Chẳng hạn bạn có thể toạ nhiều instance điều phối để đọc message để điều phối các worker con hơn.
Trong ví dụ mình dùng Kafka để giao tiếp. Kafka là dạng logs. Bạn đọc thêm bài vịết này của mình để so sanh giữa logs và queues. Đó là sự khác nhau chủ yếu giưa Kafka và RabitMQ https://cryptography101.substack.com/p/queues-va-logs
vậy mình thấy 2 cách phân tán hay tập trung cũng giống nhau phải không admin , có 1 service hoặc broker để handle các status của các service phải không bạn, vậy thì chia ra 2 cách triển khai để làm gì
Cách tập trung (orchestration) có nghĩa là có 1 service đứng giữa điều phối và ra lệnh cho cách services khác làm theo. Mỗi service con sẽ nhận message từ service điều phối, update database tưng ứng, sau đó gửi kết quả về service điều phối.
Còn cách phân tán (Choreography) ý tưởng của nó là mỗi services sẽ nhận message từ nhưng topic mà nó quan tâm, update database của nó, và gửi message vào topic tương ứng, và không quan tâm các services khác làm gì.
vậy dùng 2 cách trên cho từng trường hợp nào admin, hay cty có nhiều resource thì dùng broker, còn thiếu resource thì build con service ở giữa để handle
việc dùng phương pháp nào không phụ thuộc vào resource mà bạn có. Lợi thế của orchestration là nó đơn giản, không có bị ràng buộc vòng tròn nếu không được thiết kế cẩn thận. Nhưng gặp vấn để single point failure, ví dụ nếu service điều phối crash thì cả hệ thống bị treo.
Còn ở choreography nếu một services bị crash, cách service khác vẫn hoạt động bình thường.
Theo mình, nếu hệ thống đơn giản, ít services thì nên sử dụng choreography. CÒn các hệ thống phức tạp, cần nhiều services tương tác lẫn nhau thì orchestration có lợi thế hơn. Vì có một service điều khối, việc debug, logging ... đơn giản hơn so với choreography.
Mình nghĩ ngược lại. Nếu nhiều services nên dùng choreography tránh single point failure. Còn ít thì có thể xài orchestration cho an toàn và dễ xử lý hơn là event driven lúc init system. Ngoài ra việc debug thật ra có thể add thêm trong events gửi đi 1 traceId. Thì khi tìm kiếm root cause dựa vào traceId để hiểu issue ở đâu cũng rất dễ dàng
nếu mà dùng cách tập trung, vậy giao tiếp giữa các service với nhau thì admin dùng http hay grpc, cách nào sẽ tốt hơn không hay cách nào cũng được
cách nào cũng đc nha. Tuỳ vào bài toán của bạn.
Nhưng mình nghĩ cách xài message queue sẽ scaleable hơn. Chẳng hạn bạn có thể toạ nhiều instance điều phối để đọc message để điều phối các worker con hơn.
Trong ví dụ mình dùng Kafka để giao tiếp. Kafka là dạng logs. Bạn đọc thêm bài vịết này của mình để so sanh giữa logs và queues. Đó là sự khác nhau chủ yếu giưa Kafka và RabitMQ https://cryptography101.substack.com/p/queues-va-logs
vậy mình thấy 2 cách phân tán hay tập trung cũng giống nhau phải không admin , có 1 service hoặc broker để handle các status của các service phải không bạn, vậy thì chia ra 2 cách triển khai để làm gì
không hẳn như vậy,
Cách tập trung (orchestration) có nghĩa là có 1 service đứng giữa điều phối và ra lệnh cho cách services khác làm theo. Mỗi service con sẽ nhận message từ service điều phối, update database tưng ứng, sau đó gửi kết quả về service điều phối.
Còn cách phân tán (Choreography) ý tưởng của nó là mỗi services sẽ nhận message từ nhưng topic mà nó quan tâm, update database của nó, và gửi message vào topic tương ứng, và không quan tâm các services khác làm gì.
vậy dùng 2 cách trên cho từng trường hợp nào admin, hay cty có nhiều resource thì dùng broker, còn thiếu resource thì build con service ở giữa để handle
việc dùng phương pháp nào không phụ thuộc vào resource mà bạn có. Lợi thế của orchestration là nó đơn giản, không có bị ràng buộc vòng tròn nếu không được thiết kế cẩn thận. Nhưng gặp vấn để single point failure, ví dụ nếu service điều phối crash thì cả hệ thống bị treo.
Còn ở choreography nếu một services bị crash, cách service khác vẫn hoạt động bình thường.
Theo mình, nếu hệ thống đơn giản, ít services thì nên sử dụng choreography. CÒn các hệ thống phức tạp, cần nhiều services tương tác lẫn nhau thì orchestration có lợi thế hơn. Vì có một service điều khối, việc debug, logging ... đơn giản hơn so với choreography.
oke thank admin
Mình nghĩ ngược lại. Nếu nhiều services nên dùng choreography tránh single point failure. Còn ít thì có thể xài orchestration cho an toàn và dễ xử lý hơn là event driven lúc init system. Ngoài ra việc debug thật ra có thể add thêm trong events gửi đi 1 traceId. Thì khi tìm kiếm root cause dựa vào traceId để hiểu issue ở đâu cũng rất dễ dàng
Cảm ơn bạn đã chia sẻ góc nhìn của mình.
Việc áp dụng orchestration hay choreography đều có trade-off riêng. Mình thường cân nhắc dựa trên:
- Độ phức tạp của flow
- Độ quan trọng của tính linh hoạt
- Và tính data consistency
Sử dụng mô hình nào sẽ tuỳ theo bài toán cụ thể, rất vui được thảo luận thêm về chủ đề này.