Chào bạn,
Trong module trước, chúng ta đã cùng nhau học "ngôn ngữ" của các quy trình nghiệp vụ - BPMN 2.0. Bạn đã đi từ việc đọc hiểu một sơ đồ có sẵn đến việc tự tay mô hình hóa một quy trình đơn giản. Đây là nền tảng vững chắc để chúng ta bước vào thế giới của các công cụ thực thi.
Hôm nay, chúng ta sẽ bắt đầu Module 2: Khởi tạo dự án với Camunda và Spring Boot. Bài học đầu tiên sẽ giải quyết một câu hỏi mang tính chiến lược và kiến trúc: Sự khác biệt chính giữa Camunda 7 và Camunda 8 là gì?
Việc hiểu rõ hai phiên bản này không chỉ là về việc chọn một con số. Nó là việc bạn chọn một triết lý kiến trúc, một mô hình vận hành, và một cách tiếp cận để phát triển. Đối với một software developer, việc nắm bắt những khác biệt này ngay từ đầu sẽ giúp bạn đưa ra những quyết định thiết kế đúng đắn, dù là cho một dự án tự động hóa nội bộ, một hệ thống điều phối microservices, hay xây dựng một workflow engine cho sản phẩm của riêng bạn.
1. Một sự thay đổi về Hệ tư tưởng (Paradigm Shift)
Điều quan trọng nhất cần hiểu là việc chuyển từ Camunda 7 sang Camunda 8 không phải là một bản cập nhật thông thường, mà là một sự thay đổi hoàn toàn về hệ tư tưởng.
- Camunda 7 được xây dựng dựa trên kiến trúc truyền thống, mạnh mẽ và ổn định. Hãy hình dung nó như một ứng dụng monolithic hoặc một thư viện được tích hợp chặt chẽ vào ứng dụng của bạn.
- Camunda 8 được thiết kế lại từ đầu cho thế giới cloud-native. Hãy hình dung nó như một hệ thống dựa trên microservices, nơi các thành phần được tách biệt và giao tiếp với nhau qua mạng.
Để hiểu sâu hơn về sự thay đổi nền tảng này, hãy bắt đầu với bài viết sau.
Camunda 7 vs. Camunda 8: A Real-World Look at the Orchestration Shift
Bài viết "Camunda 7 vs. Camunda 8: A Real-World Look at the Orchestration Shift" trên Medium đưa ra một góc nhìn rất trực quan về sự thay đổi này.
Hãy đọc phần giới thiệu và mục "The Engine Room: From Monolith to Microservices". Chú ý đến các so sánh và cách tác giả mô tả sự khác biệt cốt lõi về engine thực thi.
Như bạn đã đọc, sự khác biệt nền tảng nhất nằm ở kiến trúc của workflow engine.
2. So sánh chi tiết các khía cạnh chính
Dựa trên sự khác biệt về kiến trúc, chúng ta có thể phân tích các ảnh hưởng trực tiếp đến cách bạn, với vai trò là một developer, sẽ xây dựng và vận hành một giải pháp.
| Khía cạnh | Camunda 7 (Kiến trúc truyền thống) | Camunda 8 (Kiến trúc Cloud-Native) |
|---|---|---|
| Kiến trúc Engine | Embedded Engine: Chạy như một thư viện bên trong ứng dụng Java của bạn (ví dụ: Spring Boot). Engine và code của bạn chia sẻ cùng JVM, thread pool, và có thể cả transaction. | Remote Engine (Zeebe): Một dịch vụ độc lập, chạy riêng biệt. Ứng dụng của bạn giao tiếp với engine qua gRPC. Engine và code của bạn hoàn toàn tách biệt. |
| Lưu trữ Trạng thái | Dùng cơ sở dữ liệu quan hệ (Relational Database) như PostgreSQL, Oracle. Việc này có thể trở thành điểm nghẽn khi cần mở rộng quy mô lớn (scaling bottleneck). | Dùng Event Sourcing và một bản ghi phân tán (distributed log). Được thiết kế để mở rộng theo chiều ngang (horizontal scaling) gần như vô hạn. |
| Thực thi Logic | JavaDelegate: Code logic (thường là Java) được thực thi đồng bộ (synchronously) bên trong transaction của engine. Gắn chặt với hệ sinh thái Java. | External Task Worker: Code logic được thực thi bất đồng bộ (asynchronously). Worker (viết bằng bất kỳ ngôn ngữ nào) chủ động lấy (poll) công việc từ engine. Hỗ trợ đa ngôn ngữ (polyglot). |
| Biến quy trình | Có thể lưu trữ các đối tượng Java phức tạp đã được tuần tự hóa (serialized Java objects). | Chỉ cho phép lưu trữ các kiểu dữ liệu nguyên thủy (primitive types) hoặc JSON. Điều này đảm bảo tính độc lập về ngôn ngữ. |
| Ngôn ngữ Biểu thức | JUEL (Java Unified Expression Language): Có thể truy cập vào các Spring bean và code Java bên trong ứng dụng. | FEEL (Friendly-Enough Expression Language): An toàn hơn, chỉ có thể truy cập vào dữ liệu của bản thân quy trình (process variables). |
| Tooling (Bản Community) | Cung cấp Cockpit (giám sát) và Tasklist (giao diện user task) sẵn sàng cho môi trường production. | Operate (tương tự Cockpit) và Tasklist chỉ dành cho môi trường development. Để dùng trong production, bạn cần bản thương mại hoặc tự xây dựng tool. |
Để có cái nhìn trực quan hơn về sự khác biệt kiến trúc khi tích hợp với Spring Boot, hãy xem sơ đồ sau từ tài liệu chính thức của Camunda.
Sự thay đổi trong mô hình thực thi logic được phản ánh rất rõ ngay trên công cụ Camunda Modeler.
Để tìm hiểu sâu hơn về các điểm khác biệt này từ góc độ kỹ thuật, bạn có thể tham khảo tài liệu của Camunda.
Conceptual differences | Camunda 8 Docs
Tài liệu "Conceptual differences" từ trang chủ của Camunda cung cấp một bản phân tích chi tiết và chính xác về các thay đổi.
Hãy đọc các mục sau: "No embedded engine in Camunda 8" "Different data types" "Expression language" "Process solutions using Spring Boot" Các mục này sẽ củng cố những gì chúng ta vừa thảo luận trong bảng so sánh.
3. Khi nào nên chọn phiên bản nào? Và Lộ trình của chúng ta
Vậy, với hai triết lý khác biệt như vậy, khi nào bạn nên sử dụng Camunda 7 và khi nào nên hướng đến Camunda 8?
Hãy cân nhắc Camunda 7 nếu:
- Dự án của bạn có quy mô vừa phải và không yêu cầu khả năng xử lý hàng nghìn quy trình mỗi giây.
- Bạn cần các giao dịch ACID chặt chẽ giữa engine và logic nghiệp vụ của ứng dụng (ví dụ: cập nhật CSDL của ứng dụng và trạng thái quy trình trong cùng một transaction).
- Bạn đang làm việc trong một hệ sinh thái chủ yếu là Java/Spring và ưa thích mô hình tích hợp chặt chẽ.
- Bạn muốn sử dụng các công cụ web (Cockpit, Tasklist) đã có sẵn cho môi trường production mà không tốn chi phí bản quyền.
Hãy chọn Camunda 8 nếu:
- Yêu cầu hàng đầu của bạn là khả năng mở rộng cực lớn (massive scale).
- Bạn đang xây dựng một kiến trúc microservices, đa ngôn ngữ (polyglot), và hướng tới cloud-native.
- Bạn ưu tiên sự kiên cường (resilience) và tách biệt hoàn toàn giữa engine và các ứng dụng nghiệp vụ.
- Bạn sẵn sàng chi trả cho bản thương mại hoặc tự xây dựng các giao diện quản lý, giám sát của riêng mình.
Lộ trình của khóa học:
Trong khóa học này, chúng ta sẽ bắt đầu với Camunda 7 tích hợp cùng Spring Boot. Lý do cho lựa chọn này là:
- Môi trường học tập toàn diện: Camunda 7 Community Edition cung cấp một bộ công cụ đầy đủ (bao gồm cả engine, Cockpit, Tasklist) và miễn phí cho cả việc học và triển khai, giúp bạn có trải nghiệm trọn vẹn nhất.
- Dễ dàng khởi tạo: Mô hình embedded engine đơn giản hơn để thiết lập và chạy dự án "Hello, World!" đầu tiên.
- Kiến thức nền tảng: Rất nhiều khái niệm cốt lõi bạn học với Camunda 7 (mô hình hóa BPMN, gateways, service/user tasks, biến) có thể được áp dụng tương tự với Camunda 8.
- Tính thực tiễn: Vẫn còn rất nhiều hệ thống lớn đang vận hành ổn định trên Camunda 7. Nắm vững nó vẫn là một kỹ năng có giá trị.
Sau khi đã thành thạo các khái niệm cơ bản với Camunda 7, chúng ta sẽ khám phá các pattern của Camunda 8, như External Task, để bạn sẵn sàng cho các kiến trúc hiện đại.
Tổng kết bài học
Hôm nay, chúng ta đã phân tích sự khác biệt chiến lược giữa Camunda 7 và Camunda 8. Các điểm chính cần nhớ:
- Kiến trúc là điểm khác biệt lớn nhất: Camunda 7 là embedded/monolithic, trong khi Camunda 8 là remote/microservices.
- Khả năng mở rộng: Camunda 7 dựa vào CSDL quan hệ, Camunda 8 sử dụng engine Zeebe với kiến trúc event-sourcing để đạt quy mô lớn.
- Mô hình lập trình: Camunda 7 ưu tiên
JavaDelegate(đồng bộ), còn Camunda 8 sử dụng External Task Worker (bất đồng bộ, đa ngôn ngữ). - Chiến lược lựa chọn: Việc chọn phiên bản nào phụ thuộc vào yêu cầu về quy mô, kiến trúc, và ngân sách của dự án.
Xem trước bài học tiếp theo
Bây giờ khi đã có quyết định chiến lược là bắt đầu với Camunda 7, bước tiếp theo của chúng ta sẽ hoàn toàn là thực hành. Trong bài học tới, chúng ta sẽ xắn tay áo lên và tạo một project Spring Boot tích hợp Camunda Engine (embedded). Đây sẽ là dự án "Hello, World!" của bạn trên nền tảng Camunda.