Chuyển đổi sang Composable Commerce: Từ Magento 2 → Microservices Golang#
Cửa hàng Magento 2 của bạn có đang ngốn $125,000–$200,000/năm cho phí bản quyền Enterprise không? Đội ngũ kỹ sư của bạn có đang đốt 60% thời gian của mỗi sprint để chạy theo fix các vấn đề tương thích PHP và viết những đoạn override module chắp vá thay vì phát triển tính năng mới? Bạn có đang chạm ngưỡng chịu tải mỗi khi chạy flash-sale chỉ vì bạn bắt buộc phải scale toàn bộ hệ thống nguyên khối cùng một lúc?
Chào mừng bạn đến với cẩm nang toàn tập về Chuyển đổi sang Composable Commerce (Thương mại lắp ghép) — cách phẫu thuật tháo dỡ một khối monolith Magento 2 thành một nền tảng microservices chuẩn production được xây dựng trên Go 1.25, Kratos v2, Dapr PubSub, và Rush monorepo, mà không làm rơi rớt một đơn hàng nào trong quá trình chuyển đổi.
Về Series này
Nội dung này được đúc kết từ quá trình xây dựng một Nền tảng Composable Commerce thực tế — 21 Go microservices + 2 frontend đảm nhiệm toàn bộ hành trình thương mại: Duyệt (Browse) → Tìm kiếm (Search) → Giỏ hàng (Cart) → Thanh toán (Checkout) → Trả tiền (Pay) → Hoàn tất (Fulfill) → Vận chuyển (Ship) → Hoàn hàng (Return) — với 0 đồng phí bản quyền Magento và nắm toàn quyền sở hữu dữ liệu. Mọi quyết định kiến trúc trong series này đều được đúc kết từ một trong 24 Hồ sơ Quyết định Kiến trúc (ADRs) của chúng tôi.
🎯 Tư vấn Chuyển đổi#
Đội ngũ của bạn đang lên kế hoạch thoát khỏi Magento hay đang đánh giá việc chuyển đổi sang kiến trúc composable commerce? Bạn cần một buổi Đánh giá Kiến trúc (Architecture Review) cho nền tảng hiện tại trước khi cam kết với một chiến lược chuyển đổi?
👉 Đặt lịch Tư vấn Kiến trúc 1:1 với Senior Architect Lê Tuấn Anh — Hơn 17 năm kinh nghiệm xây dựng các nền tảng e-commerce enterprise tại Việt Nam và Đông Nam Á.
📚 Chương trình Cốt lõi#
Lược đồ EAV, khóa chính dạng số nguyên (integer primary keys), và sự phụ thuộc module PHP của Magento làm cho việc chuyển đổi trở nên đặc biệt hiểm nghèo. Series này mang đến cho bạn cẩm nang Strangler Fig 3 giai đoạn hoàn chỉnh kèm code Go có thể chạy được:
Phần 0: Tóm tắt cho Quản lý — Tại sao $200K/Năm lại là một Cái Bẫy
Chi phí thực sự của Magento Enterprise, và tại sao kiến trúc composable lại tự hoàn vốn ngay trong Năm 1.
Phần 1: Bounded Contexts trong DDD — Phân rã các Module Magento
Cách ánh xạ cấu trúc module của Magento thành 21 bounded context sử dụng Domain-Driven Design — không cần làm một cuộc đập đi xây lại kiểu Big Bang.
Phần 2: Rush Monorepo — Quản lý 21 Go Services + 2 Frontends
Tại sao chúng tôi chọn Microsoft Rush thay vì Nx/Turborepo cho một monorepo trộn lẫn Go + Next.js + React, và cách thiết lập nó.
Phần 3: Golang + Kratos v2 — Đi sâu vào Framework Microservice
Kratos v2 xử lý transport, tiêm phụ thuộc (dependency injection), và mô hình common library xuyên suốt 21 service như thế nào.
Phần 4: Kiến trúc gRPC Internal + REST Gateway
Giao tiếp giữa các service (service-to-service) bằng gRPC, phơi bày REST thông qua gRPC-Gateway, và chiến lược định tuyến API Gateway.
Phần 5: Chuyển đổi Lược đồ EAV — Cạm bẫy Lớn nhất của Magento
Gỡ rối catalog_product_entity_varchar, ánh xạ định danh integer → UUID, và các câu truy vấn trích xuất SQL chính xác và hiệu quả.
Phần 6: Giai đoạn 1 — Strangler Fig: Chuyển đổi Read-Only + CDC
Triển khai các Go service dưới dạng read-only (chỉ đọc) đằng sau API Gateway, triển khai đồng bộ CDC thời gian thực từ Magento MySQL, và sử dụng feature flag để điều hướng traffic với mức rủi ro bằng không.
Phần 7: Giai đoạn 2 — Dual-Write: Dapr PubSub + Feature Flags
Kích hoạt các API ghi (write APIs) trên microservices, triển khai đồng bộ hai chiều (bidirectional sync) qua Dapr PubSub + Transactional Outbox, và giải quyết xung đột bằng chính sách timestamp-wins.
Phần 8: Giai đoạn 3 — Chuyển đổi Hoàn toàn: Zero Downtime + GitOps
Quá trình chuyển dịch traffic tăng dần 25/50/75/100% cho mỗi service, Magento chuyển sang chế độ dự phòng nóng (hot-standby) với cửa sổ rollback 30 ngày, và mô hình triển khai ArgoCD GitOps.
Phần 9: Transactional Outbox + Saga Pattern Giữa các Service
Cách luồng saga Checkout → Order → Payment → Warehouse vận hành với đảm bảo giao nhận thành công sử dụng Transactional Outbox và Dapr PubSub Dead Letter Queue.
Phần 10: Điểm lại các ADR — Giải thích 24 Quyết định Kiến trúc
Mọi quyết định lớn — Dapr vs Kafka, database-per-service, gRPC vs REST, monorepo vs polyrepo — cùng với những sự đánh đổi dẫn đến từng lựa chọn.
🆚 Nền tảng này Thay thế cho cái gì#
| Tính năng | Magento Enterprise | Nền tảng này |
|---|
| Chi phí bản quyền | $125,000–$200,000/năm | $0 |
| Thanh toán VNPay / MoMo | Dùng plugin bên thứ ba, thiếu ổn định | Tích hợp gốc, có circuit breaker, tự động failover |
| Khả năng chịu tải Flash sale | Scale toàn bộ monolith gấp 10 lần | Chỉ scale riêng Order + Payment gấp 10 lần |
| Hệ thống WMS đa kho | Chỉ có ở bản Enterprise (add-on) | Tích hợp sẵn: quản lý bin location, nhặt hàng theo lô (batch picking) |
| Độ tin cậy của sự kiện (Event) | Webhook hay rớt, xử lý đồng bộ (synchronous hooks) | Transactional Outbox + Dapr PubSub + DLQ |
| Quyền sở hữu dữ liệu | Vendor-hosted (bị phụ thuộc) | Tự host, kiểm soát toàn diện 100% |
🧭 Bạn Nên Bắt đầu Từ đâu?#
Các Câu Hỏi Thường Gặp (FAQ)#
Series này có mặc định rằng tôi đang chạy Magento 2 không?Đúng vậy. Các hướng dẫn chuyển đổi này nhắm tới Magento 2.x (bản Open Source hoặc Commerce). Lược đồ EAV, primary keys dạng integer, và mô hình phụ thuộc module đều là các điểm đặc thù của Magento 2. Nếu bạn đang ở trên Magento 1, các mô hình DDD và Golang vẫn có thể áp dụng nhưng các câu truy vấn trích xuất SQL sẽ khác đi.
Nền tảng này sử dụng phiên bản Golang và framework nào?Nền tảng Composable Commerce chạy trên Go 1.25 với Kratos v2 (go-kratos), framework microservice cấp độ production của Google được sử dụng ở Bilibili và nhiều hệ thống Go quy mô lớn khác. Cả 21 service chia sẻ chung một thư viện common (v1.10.0) nhằm tiêu chuẩn hóa các tác vụ outbox, idempotency (tính lũy đẳng), health checks, và quản lý cấu hình.
Rush là gì và tại sao không dùng workspace tiêu chuẩn của Go hoặc Nx?Microsoft Rush là một trình quản lý đa ngôn ngữ (polyglot monorepo manager) có khả năng quản lý cả các Go service lẫn Node.js frontend (Next.js + React) nằm chung dưới một repo duy nhất với khả năng incremental build (biên dịch tăng dần), các quy tắc workspace, và quản lý bộ thay đổi (changeset management). Chúng tôi chọn Rush thay vì Nx nhờ khả năng xử lý vượt trội các repo đa ngôn ngữ (mixed-language repos) và hỗ trợ hàng đầu cho PNPM workspace ở phía frontend.
Quá trình chuyển đổi có thể thực hiện mà không cần ngắt hệ thống (zero downtime) không?Có. Phương pháp tiếp cận Strangler Fig 3 giai đoạn (Read-Only → Dual-Write → Cutover) được thiết kế chuyên biệt cho zero downtime (không gián đoạn). Giai đoạn 1 chỉ điều hướng luồng dữ liệu đọc (reads) sang microservices; luồng ghi (writes) vẫn đi vào Magento. Giai đoạn 2 đưa vào chế độ dual-write (ghi song song) kèm feature flags giúp có thể lập tức rollback trong chưa tới 10 giây. Giai đoạn 3 chuyển dịch dần traffic 25% → 50% → 75% → 100% cho mỗi service, trong khi giữ nguyên hệ thống Magento ở chế độ hot standby để duy trì cửa sổ rollback an toàn kéo dài 30 ngày.
Bất kỳ đội ngũ kỹ thuật nào xây dựng hệ thống nghiêm túc trên Magento cuối cùng cũng sẽ đụng phải ba bức tường giống nhau: bức tường bản quyền, bức tường khả năng chịu tải (scaling), và bức tường tốc độ phát triển (developer velocity). Câu hỏi chỉ là bạn sẽ đụng phải chúng trước hay sau khi chúng bào mòn tiền bạc và khách hàng thực sự của bạn.
...
Bất kỳ team Magento nào khi quyết định chuyển dịch sang microservices cũng đều phải đối mặt với cùng một câu hỏi đầu tiên: cần bao nhiêu service?
Ngành công nghiệp thường bảo là 4–6. “Service danh mục (Catalog), service đơn hàng (Order), service khách hàng (Customer), service tồn kho (Inventory), service thanh toán (Payment), và có thể thêm CMS nữa.” Mọi bài blog, mọi bài diễn thuyết ở hội thảo đều tựu trung ở danh sách này. Đó là một điểm khởi đầu hợp lý — nhưng nó hoàn toàn sai lầm khi áp dụng cho e-commerce nghiêm túc ở quy mô lớn.
...
Khi bạn sở hữu 21 Go microservices và 2 ứng dụng frontend, câu hỏi hạ tầng đầu tiên không phải là Kubernetes hay CI/CD — mà là làm thế nào để bạn quản lý chính bản thân phần source code?
Hai lựa chọn sau sẽ thất bại ngay lập tức: polyrepo (hơn 21 repo Git rời rạc, bất khả thi để duy trì phiên bản đồng nhất) và một monorepo ngây ngô (vứt tất tần tật mọi thứ vào chung một thư mục, dependency ma ám ngập tràn). Bạn cần một công cụ quản lý monorepo thực thụ.
...
Đối với các kỹ sư chuyển từ Magento PHP sang, việc chuyển dịch sang Go microservices không chỉ đơn thuần là đổi ngôn ngữ lập trình — mà nó là một cách thức tổ chức code khác biệt về mặt bản chất. Magento có controller, model, block, helper, và plugin. Còn Go với Kratos v2 sở hữu chính xác 5 lớp (layer), mỗi lớp mang một trách nhiệm được định nghĩa rạch ròi.
...
Mọi API hướng ra công chúng (public-facing) trong Nền tảng Composable Commerce đều bắt đầu từ một file .proto. Phần code — bao gồm các hàm handler gRPC viết bằng Go, TypeScript SDK, các route HTTP, kiểm tra tính hợp lệ của request (request validation), các mã lỗi — tất cả đều được tự động generate ra từ bản hợp đồng (contract) đó. Bài viết này sẽ ghi chép lại những quy ước đằng sau để hệ thống đó vận hành mượt mà.
...
Cấu trúc EAV schema chính là lý do khiến phần lớn các dự án chuyển đổi khỏi Magento chuốc lấy thất bại.
Nhìn từ bên ngoài, nó có vẻ dễ xơi: dữ liệu của sản phẩm bị băm ra rải rác ở catalog_product_entity, catalog_product_entity_varchar, catalog_product_entity_int, catalog_product_entity_decimal, catalog_product_entity_datetime, và catalog_product_entity_text. Sáu cái bảng, viết một cái job ETL đơn giản, làm một cuối tuần là xong.
Nhưng rồi bạn phát hiện ra rằng attribute_id = 75 mang ý nghĩa “tên sản phẩm” (product name) trong cái database của bạn, nhưng nó lại mang nghĩa “màu sắc” (color) trong cái database trên môi trường staging. Mỗi một mã ID thuộc tính (attribute ID) được sinh ra tự động ngay tại thời điểm cài đặt (install time) và nó hoàn toàn khác biệt giữa các môi trường với nhau. Bất kỳ script ETL nào dám cả gan gán cứng (hardcode) các mã attribute ID này sẽ lập tức đẻ ra một đống dữ liệu rác bẹp dí (corrupted data) khi mang lên chạy ở production.
...
Giai đoạn 1 (Phase 1) là giai đoạn an toàn nhất trong toàn bộ cuộc di dời — đó là chủ ý thiết kế (by design). Sẽ không có bất kỳ thao tác ghi (write) dữ liệu nào chạm tới hệ thống microservice mới. Magento vẫn là nguồn sự thật duy nhất (source of truth) cho mọi sửa đổi dữ liệu. Việc duy nhất mà Giai đoạn 1 làm, đó là chứng minh rằng đống microservice của bạn có thể phục vụ các thao tác đọc (read) với tốc độ nhanh hơn và độ ổn định cao hơn Magento.
...
Ở Giai đoạn 1, cả hai hệ thống đều tồn tại song song nhưng chỉ có duy nhất một thằng được phép ghi dữ liệu: Magento. Sang Giai đoạn 2, cả hai hệ thống sẽ cùng thi nhau ghi dữ liệu cùng một lúc (simultaneously). Đây là giai đoạn phức tạp nhất về mặt kỹ thuật — và cũng là nơi mà phần lớn các dự án di dời tự tay làm hỏng (corrupt) dữ liệu của chính mình nếu họ không chuẩn bị sẵn một chiến lược phân xử xung đột (conflict resolution strategy) rõ ràng sòng phẳng.
...
Giai đoạn 3 (Phase 3) là hồi kết: 100% traffic chuyển hẳn sang hệ thống microservice, Magento chính thức lùi về làm một kho lưu trữ thụ động (passive archive), và toàn bộ nền tảng vận hành hoàn toàn trên các microservice Go thông qua quy trình GitOps. Sẽ không còn bóng dáng của PHP trong những luồng request quan trọng nữa. Và cũng chấm dứt luôn chuỗi ngày phải è cổ ra đóng tiền gia hạn giấy phép (license) cho Magento.
...
Khi một khách hàng bấm nút đặt hàng trên nền tảng Composable Commerce, có tới 7 sự kiện bắt buộc phải diễn ra theo chuỗi vắt ngang qua 4 service hoàn toàn độc lập: Tạo Đơn hàng (Order created) → Duyệt Thanh toán (Payment authorized) → Giữ chỗ Tồn kho (Stock reserved) → Kích hoạt Giao nhận (Fulfillment triggered) → Bắn Thông báo (Notification sent) → Cộng Điểm thưởng (Loyalty points awarded) → Tạo Mã vận đơn (Shipping label generated). Bất kỳ mắc xích nào trong số này cũng có thể đứt. Mạng có thể rớt. Database có thể sập. Một cái cổng thanh toán (payment gateway) của bên thứ ba có thể bị timeout.
...
21 services. 24 quyết định. 3.5 tháng trời cân lên đặt xuống được ghi chép cẩn thận vào các bản Ghi nhận Quyết định Kiến trúc (Architecture Decision Records - ADR).
ADR là một tài liệu ngắn gọn gọn gàng trả lời rạch ròi câu hỏi: “Tại sao chúng ta lại cắm đầu chọn phương án X trong khi hai thằng Y và Z cũng ngon lành không kém?” Nếu không có ADR, mọi tri thức kiến trúc (architectural knowledge) sẽ chỉ tồn tại mỏng manh trong đầu các kỹ sư. Lỡ ngày đẹp trời nào đó họ nộp đơn nghỉ việc, mớ tri thức đó cũng đội nón ra đi — và thế là team mới vào tiếp quản sẽ lại cặm cụi đập đi xây lại cái component y chang cái cách mà đội ngũ cũ đã từng hăm hở thử nghiệm rồi vứt sọt rác (tried and rejected).
...