Từ Một Hệ Thống Duy Nhất Đến Hệ Sinh Thái Phân Tán
Hai năm trước, tôi gặp một nhà máy thực phẩm ở TP. HCM. Doanh nghiệp này vừa ký hợp đồng xuất khẩu với một siêu thị chuỗi lớn, và yêu cầu đầu tiên của khách hàng không phải về chất lượng sản phẩm — mà là truy xuất nguồn gốc đầy đủ. Lô hàng đầu tiên phải có QR Code trên mỗi sản phẩm, kèm theo dữ liệu chi tiết về ngày sản xuất, nguyên liệu, quy trình đóng gói, và từng bước vận chuyển.
Có vẻ đơn giản trên giấy. Nhưng khi họ bắt đầu triển khai, vấn đề xuất hiện rất nhanh. Nhà máy có 5 phân xưởng ở các vị trí khác nhau, mỗi phân xưởng quản lý dữ liệu sản xuất bằng một hệ thống riêng. Bộ phận logistics dùng phần mềm khác để quản lý container và shipment. Và bộ phận kho hàng, họ vẫn dùng sổ Excel.
Bây giờ, tất cả dữ liệu này phải được kết nối, đồng bộ, và có sẵn trong vòng vài phút khi khách hàng quét QR Code. Sẽ ra sao nếu cô ấy cố gắng dùng một hệ thống duy nhất — một monolith khổng lồ — để xử lý tất cả?
Sau ba tháng "vật lộn", họ nhận ra rằng một kiến trúc truyền thống sẽ không cắt được lưỡi. Họ cần tới một cách tiếp cận khác: microservices.
Tại Sao Microservices Lại Là Câu Trả Lời
Microservices không phải là xu hướng công nghệ sơ sài mới. Nó là cách tổ chức phần mềm sao cho mỗi chức năng — như quản lý sản xuất, theo dõi vận chuyển, hoặc lưu trữ dữ liệu nguyên liệu — được xây dựng dưới dạng các dịch vụ nhỏ, độc lập, và có thể giao tiếp với nhau.
Cái tinh tế của hệ thống truy xuất nguồn gốc là nó liên quan tới nhiều bộ phận của doanh nghiệp. Sản xuất cần ghi nhận khi sản phẩm được tạo ra. Logistics cần cập nhật vị trí container khi chúng di chuyển qua các địa điểm khác nhau. Bộ phận bán hàng cần truyền dữ liệu chứng nhận GS1 đến hệ thống. Và tất cả điều này phải xảy ra song song, mà không làm "chết" toàn bộ hệ thống nếu một phần bị gián đoạn.
Với một hệ thống monolith truyền thống, nếu bạn muốn thay đổi cách quản lý dữ liệu container, bạn phải cập nhật toàn bộ cơ sở dữ liệu. Nếu bộ phận sản xuất cần thêm các trường mới — chẳng hạn như loại vật liệu bao bì — bạn lại phải làm. Mỗi thay đổi nhỏ đều có rủi ro "làm bể" cả hệ thống.
Microservices giải quyết vấn đề này bằng cách cho phép mỗi bộ phận tồn tại độc lập. Dịch vụ sản xuất có thể được cập nhật mà không ảnh hưởng đến dịch vụ vận chuyển. Dịch vụ blockchain — nếu bạn quyết định sử dụng nó để lưu trữ dữ liệu trên sổ cái phân tán — có thể được thêm vào mà không cần viết lại toàn bộ code.
Các Thành Phần Chính Của Một Hệ Thống Microservices
Hãy tưởng tượng hệ thống truy xuất nguồn gốc của bạn như một nhà hàng. Mỗi bộ phận — bếp, quầy phục vụ, quán quân — là một dịch vụ độc lập. Nếu bếp bận, quầy phục vụ vẫn có thể tiếp khách hàng. Nếu một đầu bếp bỏ việc, bạn chỉ cần thay một người trong bếp; bạn không cần tuyển lại toàn bộ nhân viên nhà hàng.
Trong hệ thống truy xuất nguồn gốc, các dịch vụ chính bao gồm:
Dịch vụ quản lý sản xuất ghi nhận khi sản phẩm được tạo ra. Nó lưu trữ thông tin như ngày giờ sản xuất, công thức, nguyên liệu được sử dụng, và địa điểm sản xuất (phân xưởng nào, vùng sản xuất nào). Dịch vụ này cần có khả năng xử lý lượng dữ liệu lớn — một nhà máy có thể tạo ra hàng chục nghìn sản phẩm mỗi ngày. Nó cũng cần đảm bảo dữ liệu không bị mất ngay cả khi có sự cố mất điện hay lỗi phần cứng.
Dịch vụ quản lý vận chuyển theo dõi sự di chuyển của container, shipment, và các lô hàng. Nó tích hợp với GPS, cảm biến nhiệt độ, và thậm chí là blockchain để ghi lại từng điểm dừng. Khi một container rời khỏi kho hàng, dịch vụ này phải ghi lại. Khi nó đến một bến cảng hoặc một trạm trung chuyển khác, lại phải ghi lại. Tất cả các sự kiện này phải được lưu trữ theo chuỗi thời gian, sao cho bất kỳ ai quét QR Code cũng có thể thấy toàn bộ hành trình.
Dịch vụ quản lý nguyên liệu lưu trữ thông tin về các nhà cung cấp, lô hàng nguyên liệu thô, và chứng chỉ GS1. Khi một lô sữa từ một trang trại cụ thể được nhập vào nhà máy, dịch vụ này phải biết lô đó là từ đâu, khi nào được sản xuất, và chất lượng của nó. Nó cũng phải có khả năng tra cứu nhanh chóng — nếu có vấn đề về chất lượng với một sản phẩm cuối cùng, bạn cần biết rất nhanh rằng nguyên liệu này từ lô nào, và lô đó lại được dùng ở những sản phẩm nào khác.
Dịch vụ ghi nhận QR Code là "gương mặt" của hệ thống hướng tới khách hàng cuối cùng. Khi ai đó quét QR Code, dịch vụ này phải truy vấn tất cả các dịch vụ khác — sản xuất, vận chuyển, nguyên liệu — để kéo tất cả dữ liệu liên quan về sản phẩm đó. Nó phải nhanh (khách hàng không muốn chờ lâu), và nó phải an toàn (dữ liệu nhạy cảm về công thức không nên được hiển thị cho tất cả mọi người).
Mỗi dịch vụ này có thể được phát triển bởi một nhóm khác nhau, lưu trữ dữ liệu của nó bằng cách riêng (một dịch vụ có thể dùng PostgreSQL, một dịch vụ khác có thể dùng MongoDB), và được triển khai độc lập lên máy chủ.
Cách Các Dịch Vụ Giao Tiếp Với Nhau
Nhưng một câu hỏi tự nhiên nảy sinh: nếu mỗi dịch vụ là độc lập, làm sao họ giao tiếp? Nếu dịch vụ vận chuyển cần biết sản phẩm đó là gì, nó phải hỏi dịch vụ sản xuất — nhưng điều gì sẽ xảy ra nếu dịch vụ sản xuất không hồi đáp?
Có hai cách chính: một là qua API (gọi trực tiếp), hai là qua các hàng đợi tin nhắn.
API là một loại "hợp đồng" giữa các dịch vụ. Dịch vụ A nói, "Nếu bạn muốn biết sản phẩm được sản xuất khi nào, gửi một yêu cầu ở URL này, và tôi sẽ trả lời". Đây là cách trực tiếp và đơn giản. Nhưng nó cũng có rủi ro: nếu dịch vụ A bị quá tải hoặc quá chậm, dịch vụ B sẽ bị chờ.
Hàng đợi tin nhắn — chẳng hạn như RabbitMQ hoặc Kafka — là một cách khác. Thay vì gọi trực tiếp, dịch vụ A đặt một tin nhắn vào hàng đợi: "Một sản phẩm mới vừa được tạo ra". Bất kỳ dịch vụ nào quan tâm đến sự kiện này — chẳng hạn như dịch vụ QR Code, hoặc dịch vụ phân tích — có thể lắng nghe hàng đợi và nhận tin nhắn này. Lợi ích là dịch vụ A không cần biết ai đang lắng nghe, và nếu một dịch vụ gặp sự cố, dịch vụ A vẫn tiếp tục hoạt động.
Nhà máy thực phẩm mà tôi đề cập ở đầu bài viết đã chọn sử dụng cả hai. API được dùng cho các truy vấn nhanh ("Sản phẩm này được tạo ra khi nào?"), trong khi các hàng đợi tin nhắn được dùng cho các sự kiện quan trọng ("Một lô hàng vừa được vận chuyển").
Những Thách Thức Thực Tế
Tất cả điều này nghe rất tốt trên giấy, nhưng triển khai nó lại là một vấn đề khác. Khi bạn có nhiều dịch vụ chạy song song, một loạt vấn đề mới xuất hiện.
Đầu tiên, bảo mật dữ liệu. Nếu mỗi dịch vụ có khóa truy cập riêng, làm sao bạn đảm bảo rằng dịch vụ vận chuyển không thể đọc công thức sản xuất của bạn? Làm sao bạn kiểm soát ai có quyền xem dữ liệu nhạy cảm? Với một hệ thống monolith, bạn có một điểm kiểm soát duy nhất. Với microservices, bạn cần xây dựng một hệ thống ủy quyền phức tạp hơn.
Thứ hai, tính nhất quán của dữ liệu. Hãy tưởng tượng dịch vụ sản xuất ghi lại một sản phẩm được tạo ra, và dịch vụ QR Code bắt đầu trả lời các truy vấn về nó — nhưng dịch vụ nguyên liệu chưa kịp cập nhật danh sách nguyên liệu được sử dụng. Khách hàng sẽ thấy thông tin không đầy đủ. Trong một monolith, điều này khó có thể xảy ra vì tất cả dữ liệu được cập nhật cùng một lúc.
Thứ ba, giám sát và gỡ lỗi. Khi bạn có một hệ thống duy nhất, bạn có thể dễ dàng theo dõi những gì đang xảy ra. Nhưng khi bạn có mười dịch vụ chạy, mỗi dịch vụ tạo ra hàng triệu log, làm sao bạn tìm được lỗi? Khi một khách hàng nói rằng "QR Code tôi không hoạt động", bạn cần theo dõi yêu cầu qua tất cả các dịch vụ để tìm xem vấn đề ở đâu.
Nhà máy thực phẩm đã học được những bài học này một cách "đau đớn". Trong những tuần đầu tiên, họ sử dụng một hệ thống giám sát rất nguyên sơ, và khi có sự cố — chẳng hạn như một dịch vụ bị quá tải — họ mất hàng giờ để chẩn đoán vấn đề.
Những Công Cụ Giúp Bạn Thành Công
Hwang tốt, có nhiều công cụ và nền tảng có sẵn để giúp bạn triển khai microservices. Không cần phải "phát minh lại bánh xe".
Docker và Kubernetes là hai công cụ mà hầu hết các doanh nghiệp lớn sử dụng. Docker cho phép bạn đóng gói một dịch vụ — bao gồm tất cả các thư viện, phụ thuộc, và cấu hình — vào một "hộp" nhỏ gọi là container. Kubernetes là một "nhà quản lý" cho các container này. Nó tự động khởi động lại các container bị hỏng, phân phối tải giữa các máy chủ, và cho phép bạn nâng cấp các dịch vụ mà không cần dừng hệ thống.
API Gateway là một người trung gian giữa khách hàng cuối cùng (hay một trang web, hay ứng dụng di động) và các dịch vụ của bạn. Nó chịu trách nhiệm xác thực người dùng, định tuyến yêu cầu đến dịch vụ đúng, và quản lý các vấn đề về bảo mật. Nó cũng giúp bạn quản lý tốc độ (rate limiting) — nếu một khách hàng gửi quá nhiều yêu cầu, API Gateway có thể từ chối hoặc chậm lại yêu cầu đó.
Observability stack (như ELK, Prometheus, Grafana) là những công cụ giúp bạn nhìn thấy điều gì đang xảy ra bên trong hệ thống. Bạn có thể theo dõi hiệu suất, lỗi, và độ trễ của từng dịch vụ.
Nhà máy thực phẩm đã chọn sử dụng Kubernetes để quản lý các dịch vụ của họ, và họ đã triển khai một stack observability để theo dõi mọi thứ. Kết quả? Thời gian triển khai các tính năng mới giảm từ 2-3 tuần xuống còn 2-3 ngày. Và khi có sự cố, họ có thể chẩn đoán và sửa chữa trong vài phút thay vì vài giờ.
Blockchain và GS1: Nơi Microservices Tỏa Sáng
Một lĩnh vực mà microservices thực sự tỏa sáng là khi bạn muốn tích hợp blockchain hoặc GS1 vào hệ thống truy xuất nguồn gốc của mình.
Nếu bạn quyết định sử dụng blockchain để lưu trữ một bản sao của dữ liệu truy xuất — để tăng độ tin cậy, hoặc để tuân thủ các quy định — bạn không cần thay đổi toàn bộ hệ thống. Bạn chỉ cần thêm một dịch vụ blockchain mới. Dịch vụ sản xuất và dịch vụ vận chuyển không cần biết về sự tồn tại của nó. Dịch vụ blockchain chỉ "lắng nghe" các sự kiện từ các dịch vụ khác và ghi chúng lên sổ cái.
Tương tự, nếu bạn muốn hỗ trợ GS1 — chuẩn quốc tế để xác định sản phẩm, vị trí, và tài sản — bạn có thể tạo một "adapter" GS1 riêng. Adapter này sẽ dịch dữ liệu từ định dạng nội bộ của bạn sang định dạng GS1. Khách hàng của bạn, khi quét QR Code, sẽ nhận được dữ liệu GS1 tiêu chuẩn. Nếu sau này GS1 có bản cập nhật mới, bạn chỉ cần cập nhật adapter này, không cần thay đổi bất kỳ dịch vụ nào khác.
Bắt Đầu: Điều Gì Cần Thiết?
Nếu bạn đang quản lý một doanh nghiệp sản xuất hoặc logistics, và bạn đang xem xét triển khai hệ thống truy xuất nguồn gốc với QR Code hoặc blockchain, hãy suy nghĩ về microservices. Nhưng đừng cố gắng xây dựng mọi thứ cùng một lúc.
Bắt đầu nhỏ. Có lẽ bạn chỉ cần một dịch vụ sản xuất để ghi nhận khi sản phẩm được tạo ra. Sau đó, thêm một dịch vụ vận chuyển khi bạn cần theo dõi shipment. Sau đó là QR Code. Khi doanh nghiệp của bạn phát triển, hệ thống của bạn cũng sẽ phát triển.
Đặc biệt, hãy đầu tư vào observability ngay từ đầu. Đó là sự khác biệt giữa một hệ thống hoạt động tốt và một hệ thống gây đau đầu cho từng người.
Và cuối cùng, hãy chọn một nền tảng hoặc một nhà cung cấp có kinh nghiệm. Microservices là một lĩnh vực phức tạp, và bạn không cần phải là chuyên gia để triển khai nó thành công — nhưng bạn cần có ai đó bên cạnh để hướng dẫn.
Nhà máy thực phẩm mà tôi biết? Họ giờ đã hỗ trợ chuỗi cung ứng cho hơn 50 khách hàng xuất khẩu khác nhau. Mỗi khách hàng có những yêu cầu khác nhau, những hệ thống khác nhau, và những tiêu chuẩn khác nhau. Nhưng nhờ kiến trúc microservices, họ có thể dễ dàng cộng tác với từng khách hàng mà không cần xây dựng lại mọi thứ từ đầu. Đó là sức mạnh thực sự của microservices.
