Các hệ thống ERP nguyên khối đã vận hành doanh nghiệp trong nhiều thập kỷ — nhưng khi tổ chức tăng trưởng, những vết nứt bắt đầu lộ rõ. Đây là cách kiến trúc microservices thay đổi tất cả.
Các doanh nghiệp hiện đại vận hành trong sự phức tạp. Bộ phận tài chính cần sổ cái thời gian thực. Chuỗi cung ứng đòi hỏi cập nhật tồn kho trong từng mili-giây. Hệ thống nhân sự phải đồng bộ với bảng lương, phúc lợi và tuân thủ pháp lý — đồng thời. Các nền tảng ERP nguyên khối truyền thống được xây dựng để xử lý tất cả những điều này trong một chỗ. Đó từng là một lợi thế. Giờ đây, nó thường là nút thắt cổ chai.
Kiến trúc microservices đưa ra một mô hình khác: phân tách ERP thành các dịch vụ nhỏ, có thể triển khai độc lập — mỗi dịch vụ sở hữu miền nghiệp vụ, dữ liệu và vòng đời triển khai riêng. Khi thực hiện đúng, cách tiếp cận này cho phép các mô-đun ERP riêng lẻ mở rộng độc lập, lỗi xảy ra cô lập, và phát triển mà không gây nguy hiểm cho toàn bộ hệ thống.
“Mục tiêu không phải là tách mọi thứ ra. Mà là vạch ra đúng ranh giới để thay đổi trong một miền không lan thành hỗn loạn trên toàn hệ thống.”
Tại sao ERP nguyên khối gặp khó khăn khi mở rộng
Một ERP truyền thống là một đơn vị triển khai duy nhất. Mô-đun tồn kho, sổ cái tài chính và công cụ mua sắm đều dùng chung codebase, cùng một cơ sở dữ liệu và cùng một chu kỳ phát hành. Khi nhóm mua sắm cần một tính năng mới, toàn bộ hệ thống phải được triển khai lại — kể cả sổ cái tài chính không thay đổi gì trong nhiều tháng.
Điều này tạo ra các vấn đề tích lũy: chu kỳ phát hành chậm lại, các nhóm kỹ thuật giẫm lên thay đổi của nhau, và một lỗi trong một mô-đun có thể làm ngã các tính năng ở những khu vực hoàn toàn không liên quan. Mở rộng một khối nguyên khối cũng có nghĩa là mở rộng mọi thứ — kể cả những phần không cần thiết.
Kiến trúc tham chiếu
Một ERP microservices được cấu trúc tốt được tổ chức xung quanh các năng lực kinh doanh, không phải các tầng kỹ thuật. Mỗi dịch vụ sở hữu một ngữ cảnh giới hạn: Tài chính, Tồn kho, Mua sắm, Nhân sự, CRM và Thực hiện đơn hàng là những phân chia tự nhiên. Chúng giao tiếp bất đồng bộ thông qua event bus và công khai dữ liệu qua các API có phiên bản.
Sáu nguyên tắc quan trọng nhất
1. Cơ sở dữ liệu riêng cho từng dịch vụ
Mỗi dịch vụ sở hữu schema của mình. Không chia sẻ bảng dữ liệu. Các truy vấn liên miền xảy ra thông qua API hoặc các projection hướng sự kiện. Đây là quy tắc cấu trúc quan trọng nhất — vi phạm nó sẽ tạo ra sự ràng buộc ẩn làm mất đi ý nghĩa của việc phân tách.
2. Bất đồng bộ là mặc định
Các dịch vụ giao tiếp qua các sự kiện miền được phát lên message bus (Kafka hoặc RabbitMQ là những lựa chọn tiêu chuẩn). Các lời gọi HTTP đồng bộ được dành riêng cho các truy vấn yêu cầu tính nhất quán ngay lập tức — thường là các thao tác đọc hướng người dùng, không phải ghi.
3. Ngữ cảnh giới hạn
Vạch ranh giới dịch vụ xung quanh năng lực kinh doanh, không phải các tầng kỹ thuật. “Khách hàng” có ý nghĩa khác nhau với CRM (cơ hội, liên hệ, lịch sử quan hệ) và Tài chính (thực thể thanh toán, hạn mức tín dụng, điều khoản thanh toán). Mỗi dịch vụ định nghĩa mô hình riêng của các khái niệm chung.
4. API theo hợp đồng trước
Định nghĩa hợp đồng API — OpenAPI hoặc Protobuf — trước khi bắt đầu triển khai. Khả năng tương thích ngược là không thể thương lượng. Các thay đổi phá vỡ hợp đồng yêu cầu tạo phiên bản mới, không phải cập nhật im lặng. Kiểm thử hợp đồng hướng người tiêu dùng (Pact) thực thi điều này ở cấp độ CI.
5. Mẫu Saga cho giao dịch phân tán
Các giao dịch phân tán yêu cầu các hành động bù trừ. Sử dụng saga dựa trên điều phối cho các luồng công việc dài như thực hiện đơn hàng: mỗi dịch vụ lắng nghe sự kiện, hành động và phát kết quả của mình. Nếu một bước hạ nguồn thất bại, các sự kiện bù trừ sẽ hoàn tác các bước trước đó.
6. Khả năng quan sát trước tiên
Các hệ thống phân tán thất bại theo những cách phân tán. Tracing tập trung (OpenTelemetry), ghi log có cấu trúc (ID tương quan xuyên ranh giới dịch vụ) và SLO cấp dịch vụ là không thể thiếu. Bạn không thể gỡ lỗi một giao dịch đa dịch vụ nếu không có chúng.
Phần khó nhất: tính nhất quán dữ liệu
Trong một khối nguyên khối, các giao dịch ACID xử lý tính nhất quán cho bạn. Trong ERP microservices, bạn từ bỏ điều đó — và sự đánh đổi là đáng kể. Khi một đơn đặt hàng được phê duyệt, dịch vụ Mua sắm phải thông báo cho Tồn kho để đặt giữ hàng, Tài chính để cập nhật cam kết, và có thể Thực hiện đơn hàng để lên lịch giao hàng. Các sự kiện này không thể thất bại theo kiểu nguyên tử.
Mẫu Saga giải quyết điều này bằng cách định nghĩa một chuỗi các giao dịch cục bộ và các hành động bù trừ của chúng. Nếu Tài chính từ chối phân bổ ngân sách sau khi Tồn kho đã đặt giữ hàng, saga sẽ phát một sự kiện bù trừ để giải phóng việc đặt giữ đó. Đây là tính nhất quán cuối cùng — nhưng với các luồng công việc ERP, điều đó thường chấp nhận được và thậm chí còn tốt hơn khóa phân tán.
Chiến lược di chuyển
Hầu hết các nhóm không thể viết lại ERP từ đầu. Dựng các microservices mới cạnh khối nguyên khối, định tuyến lưu lượng đến chúng dần dần, và loại bỏ chức năng của khối nguyên khối theo từng miền.
Khi nào nên tránh microservices
Microservices không phải lúc nào cũng vượt trội hơn. Các nhóm nhỏ, sản phẩm giai đoạn đầu, hoặc các hệ thống có lưu lượng thấp và miền đơn giản thường phải trả chi phí vận hành mà không nhận được lợi ích tương xứng. Nếu bạn không thể triển khai dịch vụ độc lập, nếu nhóm của bạn không có công cụ để quản lý distributed tracing và gỡ lỗi đa dịch vụ, hoặc nếu các ngữ cảnh giới hạn thực sự chưa rõ ràng — một khối nguyên khối được cấu trúc tốt sẽ phục vụ bạn tốt hơn.
Kiến trúc đúng đắn là kiến trúc phù hợp với quy mô, năng lực và tốc độ thay đổi của tổ chức bạn — không phải kiến trúc xuất hiện nhiều nhất trong các buổi hội thảo.