Mô hình kiến trúc workflow engine: Embedded và Remote

1. Định nghĩa các Mô hình Kiến trúc

Trước tiên, hãy làm rõ hai khái niệm chính của bài học.

• Embedded Engine (Engine Nhúng): Đây là mô hình chúng ta đã sử dụng xuyên suốt khóa học. Workflow engine được đóng gói như một thư viện (ví dụ: một file .jar) và chạy bên trong cùng một tiến trình (process) và máy ảo Java (JVM) với ứng dụng nghiệp vụ của bạn (ứng dụng Spring Boot). Engine và code nghiệp vụ của bạn chia sẻ cùng một bộ nhớ và tài nguyên.

• Remote Engine (Engine Từ xa): Trong mô hình này, workflow engine chạy như một tiến trình độc lập, một server riêng biệt. Ứng dụng nghiệp vụ của bạn giao tiếp với engine này qua mạng, thường là thông qua REST API hoặc gRPC. Engine và ứng dụng nghiệp vụ là hai hệ thống riêng biệt, có thể được triển khai và vận hành độc lập. Một ví dụ điển hình là Camunda Run hoặc Camunda Platform 8 (sử dụng Zeebe engine).

2. So sánh Ưu và Nhược điểm

Việc lựa chọn giữa embedded và remote là một sự đánh đổi. Không có mô hình nào "tốt hơn" tuyệt đối, mà chỉ có mô hình "phù hợp hơn" với bối cảnh cụ thể của bạn.

Để hiểu sâu hơn về sự đánh đổi này, hãy đọc bài viết sau từ blog của Camunda. Bài viết này giải thích lịch sử phát triển các khuyến nghị về kiến trúc của Camunda và phân tích rất rõ các điểm mạnh, yếu của từng cách tiếp cận.

Dưới đây là tóm tắt các điểm chính từ bài viết và một vài phân tích bổ sung:

Mô hình Embedded Engine

Mô hình Remote Engine

Để hình dung rõ hơn, hãy xem sơ đồ kiến trúc sau. Nó minh họa cách một ứng dụng Spring Boot có thể được cấu trúc trong cả hai mô hình.

3. Central (Tập trung) vs. Decentralized (Phi tập trung)

Câu chuyện "embedded vs. remote" còn liên quan mật thiết đến một quyết định kiến trúc lớn hơn trong bối cảnh microservices: bạn nên chạy một engine tập trung cho toàn bộ hệ thống, hay mỗi microservice nên có một engine phi tập trung của riêng nó?

Bernd Rücker, đồng sáng lập Camunda, đã phân tích rất rõ các lựa chọn này.

Dưới đây là tóm tắt các mô hình đó:

1. Decentralized Engines (Engine phi tập trung):

   • Mô tả: Mỗi microservice cần điều phối luồng nghiệp vụ sẽ nhúng (embed) một workflow engine của riêng nó. Đây là hiện thân của mô hình embedded trong thế giới microservices.
   • Ưu điểm: Tự chủ (autonomy) và cô lập (isolation) tối đa cho các đội phát triển.
   • Nhược điểm: Tăng gánh nặng vận hành (mỗi đội phải tự quản lý engine của mình), khó khăn trong việc giám sát tổng thể các luồng end-to-end.

2. One Central Engine (Một Engine tập trung):

   • Mô tả: Cả hệ thống chỉ sử dụng một workflow engine duy nhất, chạy như một dịch vụ độc lập. Các microservices kết nối đến engine này để thực thi quy trình. Đây chính là mô hình remote.
   • Ưu điểm: Dễ vận hành, có công cụ giám sát tập trung (như Cockpit), phù hợp khi engine đóng vai trò phân phối công việc (work distribution).
   • Nhược điểm: Giảm sự cô lập giữa các microservice, engine trở thành một điểm lỗi trung tâm (single point of failure) và có thể là một nút thắt cổ chai về hiệu năng.

3. Central Engine, used like Decentralized ones (Engine tập trung, dùng như phi tập trung):

   • Mô tả: Đây là một mô hình lai thú vị của Camunda 7. Nhiều microservice cùng nhúng (embed) engine, nhưng tất cả chúng đều kết nối vào cùng một cơ sở dữ liệu trung tâm.
   • Ưu điểm: Có được công cụ giám sát tập trung (vì tất cả dữ liệu đều ở một nơi) mà không cần một server engine riêng.
   • Nhược điểm: Vẫn có sự khớp nối ở tầng dữ liệu. Các microservice phải thống nhất phiên bản engine và cấu trúc database.

Khuyến nghị: Bernd Rücker có xu hướng ủng hộ mô hình phi tập trung vì nó phù hợp với triết lý của microservices. Tuy nhiên, mô hình tập trung lại rất hợp lý cho các công ty nhỏ hơn, nơi gánh nặng vận hành là một yếu tố quan trọng.

4. Hướng tới Tương lai: Kiến trúc của Camunda 8

Sự dịch chuyển sang mô hình remote không chỉ là một lựa chọn, mà còn là một xu hướng tất yếu, đặc biệt khi nói đến các hệ thống quy mô lớn, hiệu năng cao. Camunda Platform 8 và engine Zeebe của nó được thiết kế hoàn toàn dựa trên triết lý này.

Zeebe không sử dụng cơ sở dữ liệu quan hệ truyền thống để lưu trạng thái. Thay vào đó, nó sử dụng một kiến trúc event log phân tán, được tối ưu hóa cho thông lượng cao và khả năng chịu lỗi.

Để hiểu tại sao kiến trúc này lại có khả năng mở rộng vượt trội so với kiến trúc truyền thống, hãy xem video sau từ một hội thảo của Camunda.

Video này cho thấy rõ mô hình remote của Camunda 8 không chỉ đơn giản là "chạy engine trên một server khác", mà là một cuộc cách mạng về kiến trúc, được xây dựng từ đầu cho các ứng dụng đám mây (cloud-native) và microservices.

Tổng kết

Bài học hôm nay đã trang bị cho bạn một cái nhìn tổng quan và sâu sắc về các lựa chọn kiến trúc khi triển khai một workflow engine. Các điểm chính cần ghi nhớ:

• Mô hình Embedded: Đơn giản để bắt đầu, giao dịch nhất quán, nhưng khớp nối chặt và khó vận hành/mở rộng độc lập. Phù hợp cho các ứng dụng đơn khối (monolith) hoặc khi bắt đầu một dự án nhỏ.
• Mô hình Remote: Linh hoạt, đa ngôn ngữ, dễ vận hành và scale, nhưng đi kèm với độ trễ mạng và sự phức tạp của giao dịch phân tán. Đây là lựa chọn mặc định cho kiến trúc microservices.
• Việc lựa chọn giữa Centralized và Decentralized engine phụ thuộc vào quy mô tổ chức, văn hóa DevOps và yêu cầu về sự tự chủ của các đội nhóm.
• Camunda 8 (Zeebe) đại diện cho thế hệ engine remote hiện đại, được thiết kế cho khả năng mở rộng và chịu lỗi ở quy mô lớn, là một minh chứng cho xu hướng của ngành.

Xem trước bài học tiếp theo

Sau khi đã khám phá các kiến trúc ở tầm vĩ mô, trong bài học tiếp theo, chúng ta sẽ quay trở lại với việc thiết kế quy trình. Cụ thể, bạn sẽ học cách "Thiết kế quy trình có thể tái sử dụng bằng Sub-processes và Call Activities". Đây là một kỹ thuật mô hình hóa cực kỳ quan trọng để quản lý sự phức tạp, chia nhỏ các quy trình lớn và thúc đẩy việc tái sử dụng logic nghiệp vụ, dù bạn đang làm việc trên kiến trúc nào đi nữa.