Các doanh nghiệp trong quá trình chuyển đổi số sẽ có nhu cầu cấp thiết là làm thế nào để kết nối các ứng dụng, dữ liệu và thiết bị của họ. Con đường dẫn đến thành công thường bao gồm chuyển sang chiến lược tích hợp dựa trên API-led. Các API đóng một vai trò riêng biệt và cụ thể trong cách tiếp cận tích hợp của tổ chức – chúng cho phép mở khóa dữ liệu từ các hệ thống, soạn dữ liệu thành các quy trình hoặc cung cấp trải nghiệm. Event-driven APIs là một phần của tổ hợp các công nghệ sẽ giúp doanh nghiệp đạt được lợi thế cạnh tranh với tích hợp thời gian thực.
Trong bài viết này, Gimasys sẽ thảo luận về cách Nền tảng Anypoint của MuleSoft cung cấp hỗ trợ cho kiến trúc Event-driven Architecture và cách nó được sử dụng cùng với phương pháp tiếp cận API-led connectivity.
- Thời gian đọc: 05 phút
- Bài viết dành cho: Các cấp lãnh đạo và quản lý
Các mặt của Sự kiện – Dimensions of Events
- Lập trình: Về bản chất, chủ yếu là hướng tiếp cận giao tiếp có lập trình, có mục đích sử dụng trong giao tiếp giữa các thành phần của ứng dụng.
- Ý nghĩa: Một event mô tả một trạng thái thay đổi xảy ra trong một thành phần ứng dụng, đóng vai trò tạo ra event (event producer).
- Tính chất động: Một event mô tả một cái gì đó đã xảy ra.
- Tính chi tiết: Một event thường đi cùng cho một sự thay đổi trạng thái được xác định rõ.
- Tính đồng bộ: Các events được trao đổi không đồng bộ và do đó, event producer và consumer được tách ra kịp thời.
- Đường dẫn truyền thông: Events được event producer gửi đến một điểm đích. Ví dụ: queue, topic, message exchange, tùy thuộc vào mô hình message, và sau đó được nhận bởi event consumers của điểm đích đó.
- Broker: Việc trao đổi các events cần phải có các message broker, ví dụ như Anypoint MQ, Kafka, ActiveMQ, or RabbitMQ
- Hợp đồng: Hợp đồng cho một event là sự kết hợp của điểm đích và loại event (data) và có thể được mô tả bằng định nghĩa AsyncAPI.
Sự kết hợp giữa kiến trúc Event-driven và kết nối API-led
MuleSoft định nghĩa kết nối API-led thông qua cách tiếp cận ba cấp. Nó tạo thành từ experience APIs, process APIs và system APIs. Mặc dù các thành phần ứng dụng trao đổi events có thể được tổ chức tương tự, tuy nhiên đây không phải là một phần cố định của event-driven architecture.
Kết nối API-led hạn chế các kiểu mẫu giao tiếp theo ba cấp (về cơ bản là từ trên xuống dưới), trong khi các thành phần ứng dụng trao đổi các events không cần phải tuân theo các hạn chế về kiểu mẫu giao tiếp như vậy.
Kiến trúc event-driven architecture cần phải có các message broker làm thành phần bổ sung cho kiến trúc công nghệ, cùng với tất cả các thành phần ứng dụng có event trao đổi sử dụng chung các message broker này.
Các tài nguyên API được công khai để các đối tượng tiêu thụ tự phục vụ, tự xác định kết nối API-led trong các mạng ứng dụng. Việc triển khai API thường có các phụ thuộc tĩnh được xác định rõ ràng với các API khác hoặc các hệ thống backend.
Tham khảo: Kết nối API-led là gì? Phương pháp tiếp cận Kết nối API-led của MuleSoft
Một số tình huống cần các yếu tố từ kiến trúc Event-driven Architecture:
Tích hợp với các ứng dụng SaaS: Chúng phụ thuộc nhiều vào các phương pháp tiếp cận từ event-driven architecture để đảm bảo tính khả dụng và khả năng mở rộng cao (ví dụ: event-driven architecture trên Nền tảng Salesforce Customer 360).
Internet of Things: Khối lượng events khổng lồ được truyền trực tuyến từ các thiết bị cần phải được truy cập theo thời gian thực và ở quy mô lớn, điều này khiến việc chỉ sử dụng các API request-response tuần tự là không hợp lý.
Khả năng chịu lỗi: Hệ thống lắng nghe thông báo khi các giao dịch hoặc đơn đặt hàng trong hệ thống Thương mại điện tử bị hủy hoặc không thành công.
Tránh polling: Xử lý thông báo (ví dụ: đơn đặt hàng đã được cập nhật), quyết định hành động cần thực hiện và định tuyến phản hồi thích hợp đến hệ thống backend thay vì liên tục polling để tìm các thay đổi.
Legacy systems: Chúng cần xử lý các thông báo nhưng gặp phải các vấn đề về độ tin cậy.
Ví dụ bên dưới cho thấy việc sử dụng Kafka connector để tiêu thụ và tạo ra các events cho việc xử lý các topics (event-driven) trong khi vẫn tuân theo cách tiếp cận kết nối API-led.
Lợi ích của việc kết hợp kiến trúc Event-driven Architecture với kết nối API-led
Với cách tiếp cận kết hợp, bạn có thể tái sử dụng lại quy trình và hệ thống các API cho các trường hợp trong tương lai mà không cần phải viết lại các biến đổi logic và kết nối với các hệ thống backend.
Hơn nữa, bạn có thể sử dụng messaging queues để đảm bảo không mất message, tăng độ tin cậy và tính mạnh mẽ cho các ứng dụng CNTT của bạn.
Một công cụ nữa có thể được thêm vào để giải quyết các tình huống mà việc sử dụng các API request-response tuần tự là không tối ưu.
Gimasys với đội ngũ chuyên gia giàu kinh nghiệm trong việc triển khai MuleSoft sẽ hỗ trợ xác định chiến lược tích hợp và nền tảng phù hợp với nhu cầu kinh doanh của doanh nghiệp. Chúng tôi có đủ kiến thức chuyên môn, giúp doanh nghiệp của bạn có thể kết nối nhanh hơn!
LIÊN HỆ với Gimasys, đối tác của MuleSoft tại Việt Nam, ở form bên dưới để được tư vấn thêm về triển khai MuleSoft NGAY HÔM NAY.
