Google Cloud Pub/Sub Overview - Episode 1

Vấn đề thực tế: Khi hệ thống trở thành "domino effect"

Hãy tưởng tượng bạn đang vận hành một hệ thông e-commerce với hàng nghìn đơn hàng mỗi ngày. Mọi thứ hoạt động bình thường cho đến khi... một service bất ngờ downtime và kéo theo toàn bộ hệ thống sập như hiệu ứng domino

Kiến trúc truyền thống monolith hoặc Tightly Coupled Microservices

Chúng ta sẽ cùng nhau tìm hiểu 1 ứng dụng mua hàng online điển hình, ứng dụng có 4 services chính:

• Order Service: Nhận đơn hàng từ người dùng
• Packaging Service: Đóng gói sản phẩm
• Shipping Service: Vận chuyển hàng hóa
• Notification Service: Gửi thông báo cho khách hàng

Flow xử lý:

1. Order Service nhận order → gọi Packaging Service → cập nhật trạng thái (Notification Service)
2. Packaging Service đóng gói → gọi Shipping Service → cập nhật trạng thái
3. Shipping Service vận chuyển → gửi thông báo cuối cùng Nhìn thì có vẻ đơn giản, nhưng ứng dụng này tiềm ẩn các vấn đề nghiêm trong.

Những vấn đề nghiêm trọng

• Lỡ như Packaging Service bị downtime thì sao? Không thể xử lý đóng gói đơn hàng mới, mất dữ liệu đơn hàng khi downtime xảy ra, làm mất trải nghiệm người dùng cũng như gây mất doanh thu.
• Nếu chúng ta muốn triển khai thêm các service khác thì làm sao? Ta phải cập nhật code cho các services có liên quan? Giả xử ta có thêm 1 Monitoring service dùng để centralize log của tất cả các service, lúc này ta phải đi update code để log cho từng service? Điều này quá phức tạp.
• Nếu như ta muốn thực hiện test cho từng service cụ thể, ví dụ như packaging service? Bởi vì nó phụ thuộc vào Order service, Shipping service và Notification service thì lúc này ta sẽ phải mock toàn bô 3 services đó chỉ để test cho Packaging service. ==> Đây chính là lý do Event-Driven Architecture với Google Cloud Pub/Sub ra đời để giải quyết triệt để những pain points này, biến hệ thống thành "resilient, loosely-coupled microservices ecosystem".

Event-Driven Architecture với Google Cloud Pub/Sub

Trong kiến trúc mới này Pub/Sub sẽ đóng vai trò là hạt nhân trung tâm, là 1 message broker điều phối hoạt động của toàn bộ application thông qua events.

Flow xử lý:

1. Order tới → Order Service xử lý → Publish event "order.created" đến Pub/Sub
2. Pub/Sub phân phối event→ Packaging Service + Notification Service
3. Packaging service nhận event từ Pub/Sub → đóng gói xong → Publish event "package.ready" đến Pub/Sub→ Shipping Service + Notification Service
4. Pub/Sub phân phối event→ Shipping Service + Notification Service
5. Shipping service nhận event từ Pub/Sub → xử lý xong → Publish event "shipment.dispatched" đến Pub/Sub
6. Pub/Sub phân phối event → Notification Service

• Với cái kiến trúc này nếu như bất kì một service nào bị failed thì cũng không lo bị mất dữ liệu. Với trường hợp Packaging service bị failed các đơn hàng mới sẽ được Pub/Sub store lại trong Message Storage để lưu trữ trong 1 khoản thời gian nhất định trước khi bị xóa hoàn toàn khỏi Message Storage.
• Nếu như ta có thêm 1 service mới như là monitoring service, thì đơn giản chỉ cần subscribe đến Pub/Sub thì khi có event thì Pub/Sub sẽ gửi đến cho service xử lý.
• Nếu muốn test đơn lẻ từng service thì chỉ cần mock message input của Pub/Sub và verify message output là xong, ta không cần phải mock các dependence service như trước kia. → Nhờ có Pub/Sub mà service của chúng ta có khả năng chịu lỗi hơn, khả năng scale và không bị mất dữ liệu nếu như có service downtime xảy ra. Tiếp theo hãy cùng đi qua khái niệm về Pub/Sub và các key concepts của nó.

Cloud Pub/Sub là gì?

Pub/Sub is a publish/subscribe (Pub/Sub) service, a messaging service where the senders of messages are decoupled from the receivers of messages.

• Đơn giản Pub/Sub là một messages service, nơi nhận và publish các messages, lỡ đâu Subscriber bị downtime thì nó sẽ đảm bảo không bị mất dữ liệu và tiếp tục xử lý khi Subscriber hoạt động lại bình thường.

Các components của Pub/Sub:

• Publisher: tạo messages và gửi chúng đến Pub/Sub Topic
• Message: json data cái được gửi từ Publisher -> Topic hoặc từ Topic -> Subscription -> Subscriber
• Topic: là nơi để nhận message
• Schema: dùng để quản lý data format để đảm bảo message được gửi đến có đúng schema
• Subscription: là nơi nhận messages từ Topic
• Subscriber: là nơi nhận messsages từ 1 Subscription

Tổng kết

=> Chúng ta đã tìm hiểu được Pub/Sub topic là gì? Nó giải quyết được vấn đề gì? Qua phần tiếp theo chúng ta sẽ tìm hiểu về các khái niệm Publisher và Subscriber

Tài liệu tham khảo

1. https://www.youtube.com/watch?v=cvu53CnZmGI&list=PLIivdWyY5sqKwVLe4BLJ-vlh9r9zCdOse&index=1&pp=iAQB
2. https://cloud.google.com/pubsub/docs/pubsub-basics

Lời nhắn nhủ

Vì đây là bài viết chia sẽ, cũng không thể tránh những thiếu sót, mình rất sẵn lòng nhận những lời góp ý, bổ xung từ mọi người. Cũng như đừng ngần ngại đặt câu hỏi cho mình, mình sẽ cố gắng trả lời câu hỏi của mọi người.