Vì sao bạn nên Migrate từ Magento sang Microservices (Và...

Hãy nói thẳng với nhau: Magento không phải là một nền tảng tồi. Đối với hàng ngàn doanh nghiệp, nó là công cụ hoàn hảo. Nó có một hệ sinh thái plugin lâu đời, một cộng đồng developer đông đảo, và một hồ sơ theo dõi đã được chứng minh qua vô số dự án thương mại điện tử enterprise.

Nhưng nó có một cái trần nhà (ceiling). Và khi bạn đụng trần, bạn sẽ cảm nhận được sự đau đớn ở khắp mọi nơi — trong hệ thống deploy, trong thời gian chạy query database, trong khả năng các team có thể tự vận chuyển (ship) tính năng một cách độc lập, và cuối cùng là trong khả năng phục vụ khách hàng ổn định ở quy mô lớn.

Bài viết này nói về việc cái trần nhà đó trông như thế nào dưới góc độ kỹ thuật, tại sao nó lại tồn tại về mặt kiến trúc, và việc migrate sang microservices thực sự giải quyết được bài toán gì — và bài toán gì thì không.

Vấn đề Cốt lõi: Magento là một khối Monolith Dùng chung Trạng thái (Shared-State)

Kiến trúc của Magento về cơ bản là một ứng dụng duy nhất dùng chung một cluster cơ sở dữ liệu MySQL duy nhất. Mọi module — catalog, order, payment, inventory, customer, promotion — đều đọc và ghi vào cùng một cluster database đó.

graph TB
    subgraph "Magento Monolith"
        APP["Một Ứng dụng PHP duy nhất<br>Catalog · Orders · Payment<br>Inventory · Customers · CMS"]
        APP --> DB[("Một MySQL DB duy nhất<br>300+ bảng")]
        APP --> CACHE["Varnish / Redis Cache"]
    end

    CLIENT["Web / Mobile"] --> APP

Thiết kế này hoạt động cực tốt ở quy mô từ nhỏ đến trung bình. Vấn đề chỉ lộ ra khi bạn cần bành trướng.

1. Bạn Không thể Scale Cục bộ (Selective Scaling)

Trong một đợt Flash Sale, module Order và Checkout của bạn bị đập tơi bời. Trong khi đó module Catalog gần như ngồi chơi. Trong Magento, bạn không thể chỉ scale mỗi luồng checkout — bạn bắt buộc phải scale toàn bộ cục application. Mỗi worker PHP bạn đẻ thêm ra phải cõng theo toàn bộ sức nặng của mọi module khác, bất kể module đó có đang chịu tải hay không.

Trong kiến trúc microservice, bạn scale như một ca phẫu thuật:

# Chỉ scale Order service trong giờ flash sale
# Các service khác giữ nguyên mức cơ bản
order-service:    replicas: 10   # x10 lần lúc sale
checkout-service: replicas: 8
payment-service:  replicas: 6
catalog-service:  replicas: 2   # Không đổi
analytics-service: replicas: 1  # Không đổi

Sự khác biệt về chi phí ở quy mô lớn là có thể đong đếm được. Trong môi trường production của chúng tôi, việc scale cục bộ trong các đợt flash sale đã giảm chi phí server EC2 khoảng 60% so với việc scale toàn bộ stack Magento một cách đồng đều — bởi vì chúng tôi chỉ scale 3 service đang thực sự chịu tải, chứ không phải cả 21.

2. Một Chỗ Chết, Chết Lây Cả Đám

Trong Magento, một cái extension code ngu, một câu query database chậm chạp, hay một lỗi rò rỉ bộ nhớ (memory leak) ở một module có thể kéo sập toàn bộ website. Ứng dụng này dùng chung một không gian xử lý (process space) và dùng chung một hồ chứa kết nối (connection pool) database.

Trong một hệ thống phân tán, sự thất bại bị cô lập:

Magento:          Module Review crash → Sập toàn site
Microservices:    Service Review crash → Khách hàng vẫn lướt web, thêm vào giỏ, và thanh toán bình thường

Đây không phải là lý thuyết suông. Việc service Review chết không bao giờ được phép ảnh hưởng đến service Payment. Sự cô lập database ép buộc điều này ở tầng hạ tầng — mỗi service sở hữu một instance PostgreSQL của riêng nó. Một câu query chậm ở database Analytics không thể khóa (lock) row bên database Order.

3. Schema EAV Biến thành Cục Nợ Hiệu năng

Catalog sản phẩm của Magento sử dụng mô hình Entity-Attribute-Value (EAV). Thay vì lưu dữ liệu sản phẩm trong các hàng phẳng (flat rows), nó băm nhỏ thuộc tính ra làm nhiều bảng: catalog_product_entity_varchar, catalog_product_entity_int, catalog_product_entity_decimal, v.v.

Việc lấy thông tin một sản phẩm có 30 thuộc tính có thể đòi hỏi việc JOIN 5+ bảng. Ở mức 25,000+ SKUs với các bộ thuộc tính phức tạp, điều này trở thành một vấn đề độ trễ (latency) rõ ràng — đặc biệt là ở các trang tìm kiếm và danh sách sản phẩm. Đoạn SQL để xuất một file kê khai đơn hàng cơ bản từ Magento trông sẽ như thế này:

-- Chỉ để lấy order đi kèm ID của payment và shipment — đã tốn 3 cái JOINs
SELECT 
    sales_order.entity_id        AS "Order ID",
    sales_order_payment.entity_id AS "Payment ID",
    sales_shipment.entity_id      AS "Shipment ID",
    sales_order.status            AS "Order Status",
    sales_order.grand_total       AS "Total"
FROM sales_order
LEFT JOIN sales_order_payment 
    ON (sales_order.entity_id = sales_order_payment.parent_id)
LEFT JOIN sales_shipment 
    ON (sales_order.entity_id = sales_shipment.entity_id)
ORDER BY sales_order.created_at ASC;

Và đó mới chỉ là đơn hàng. Việc JOIN bảng EAV của catalog sản phẩm còn thảm họa hơn nhiều — lấy một sản phẩm 30 thuộc tính sẽ phải chạm vào catalog_product_entity_varchar, catalog_product_entity_int, catalog_product_entity_decimal, và nhiều bảng nữa trong một câu query duy nhất. Để xem bản phân tích đầy đủ về cách trích xuất và làm phẳng mớ dữ liệu này trong quá trình migration, hãy xem bài Export Dữ liệu Đơn hàng Magento 2: Vượt mặt Mô hình EAV với Clean SQL & Node.js.

Một Catalog Service chuyên dụng với schema được thiết kế riêng và một Elasticsearch read model sẽ giải quyết vấn đề này cực kỳ gọn gàng:

• Luồng Ghi (Writes) đi vào một schema PostgreSQL đã chuẩn hóa do Catalog service sở hữu.
• Một luồng Đọc (read model) theo pattern CQRS nằm trong Elasticsearch sẽ phục vụ việc hiển thị và tìm kiếm sản phẩm với thời gian phản hồi dưới 100ms.
• Các cập nhật về Giá và Tồn kho sẽ được tuyên truyền thông qua các sự kiện Dapr, giữ cho index tìm kiếm luôn tươi mới ở tốc độ gần thời gian thực (near real-time).

Luồng CQRS hoạt động như sau: khi service Catalog hoặc Pricing cập nhật một sản phẩm, nó sẽ publish sự kiện catalog.product.updated hoặc pricing.price.updated vào lưới sự kiện Dapr. Service Search theo dõi các topic này và build lại document Elasticsearch cho riêng SKU đó — không có cron jobs, không reindex toàn bộ, không có dữ liệu ôi thiu.

graph LR
    CAT[Catalog Service] -- "catalog.product.updated" --> DAPR[Dapr PubSub]
    PRC[Pricing Service] -- "pricing.price.updated" --> DAPR
    WH[Warehouse Service] -- "warehouse.stock.changed" --> DAPR
    DAPR --> SEARCH[Search Service Worker]
    SEARCH --> ES[(Elasticsearch)]
    ES -- "đọc < 100ms" --> GW[API Gateway]

4. Các Team Giẫm Đạp Lên Nhau

Ở quy mô lớn, nhiều squad (đội nhóm) cần làm việc trên cùng một nền tảng tại cùng một thời điểm. Trong Magento, điều này đồng nghĩa với việc nhiều team cùng sửa một codebase, cùng chọc vào một database schema, và phải deploy cùng một lúc.

Định luật Conway có thật: kiến trúc hệ thống của bạn sẽ phản chiếu lại cấu trúc sơ đồ tổ chức của công ty bạn. Một hệ thống monolith ép các team phải phối hợp deploy, thương lượng khi đổi schema, và xài chung chu kỳ release. Con bug của team này sẽ chặn đứng tính năng mới của team kia.

Các ranh giới ngữ cảnh (Bounded contexts) sẽ giải quyết việc này. Khi team Payment làm chủ service của họ từ đầu tới cuối (end-to-end) — codebase của họ, database của họ, pipeline deploy của họ — họ có thể vận chuyển (ship) code độc lập. Lỗi của service Loyalty không thể cản trở bản release của team Checkout.

5. Giao dịch Phân tán (Distributed Transactions) Đòi hỏi Thiết kế Rõ ràng

Magento xử lý checkout bằng một giao dịch database đồng bộ: giữ tồn kho, tạo đơn hàng, trừ tiền — tất cả nằm chung trong một khối BEGIN ... COMMIT. Điều này đơn giản và chính xác đối với một database duy nhất.

Ở quy mô lớn, nó lại biến thành cục nợ. Một cái response chậm chạp từ cổng thanh toán bên thứ ba sẽ ngâm cái giao dịch database đó không cho nó kết thúc, qua đó ngốn đi một slot trong connection pool. Dưới tải nặng, hiệu ứng domino này dẫn đến việc cạn kiệt connection hoàn toàn.

Câu trả lời của giới microservice là Saga pattern: mỗi bước là một giao dịch cục bộ độc lập, và nếu thất bại thì sẽ kích hoạt các giao dịch bù trừ (compensating transactions) thay vì rollback cứng ở cấp độ database.

sequenceDiagram
    participant CK as Checkout Service
    participant WH as Warehouse Service
    participant PAY as Payment Service
    participant ORD as Order Service

    CK->>WH: Giữ tồn kho (TTL 15 min)
    WH-->>CK: Đã giữ ✅

    CK->>PAY: Xác thực thẻ
    PAY-->>CK: Thành công ✅

    CK->>ORD: Tạo đơn hàng
    ORD-->>CK: Đã tạo ✅

    Note over CK,ORD: Nếu việc thanh toán bị lỗi ở bất kỳ bước nào:
    CK->>WH: Giải phóng giữ hàng (bù trừ)
    CK->>PAY: Hủy xác thực thẻ (bù trừ)

Không còn các giao dịch database kéo dài lê thê. Không còn cạn kiệt connection pool. Mỗi service tự lo liệu trạng thái của riêng nó, và mọi thất bại đều kích hoạt logic rollback bù trừ rõ ràng thay vì trông cậy vào rollback ngầm của database.

Microservices Thực sự Mang lại Điều gì

Dựa trên kinh nghiệm chạy production của một hệ sinh thái 21-service Go gánh 10.000+ đơn/ngày, đây là những giá trị cụ thể bằng xương bằng thịt mà kiến trúc này mang lại:

Sự khác biệt giữa hai mô hình sự kiện này rất đáng để mổ xẻ. Trong Magento, events là các observer PHP chạy đồng bộ (synchronous) — nếu observer chạy chậm hoặc quăng ra lỗi (exception), nó sẽ block (chặn) luôn toàn bộ request đó:

// Magento: Observer đồng bộ — nó block toàn bộ HTTP request
class OrderPlaceAfterObserver implements ObserverInterface
{
    public function execute(Observer $observer)
    {
        $order = $observer->getEvent()->getOrder();
        // Nếu cục call API bên thứ 3 này bị chậm hoặc lỗi,
        // nguyên cái request checkout của khách hàng sẽ bị treo hoặc báo lỗi
        $this->loyaltyService->awardPoints($order->getCustomerId(), $order->getGrandTotal());
        $this->analyticsService->trackPurchase($order); // Thêm một cú call blocking nữa
    }
}

Trong mô hình microservice, service Order sẽ ghi cái sự kiện đó vào một bảng outbox nằm chung trong cùng một giao dịch database với bản thân cái order đó — sau đó một worker chạy ngầm sẽ publish nó đi một cách bất đồng bộ (async):

// Go: Transactional Outbox — sự kiện được đảm bảo an toàn, không-blocking
func (uc *OrderUsecase) CreateOrder(ctx context.Context, o *Order) error {
    return uc.repo.WithTx(ctx, func(tx Tx) error {
        // 1. Lưu đơn hàng
        if err := tx.SaveOrder(ctx, o); err != nil {
            return err
        }
        // 2. Ghi sự kiện vào outbox ngay trong CÙNG MỘT giao dịch
        // Nếu DB commit thành công, sự kiện ĐƯỢC ĐẢM BẢO sẽ được publish
        return tx.SaveOutboxEvent(ctx, "orders.order.created", o)
    })
    // Một worker ngầm sẽ nhặt các event trong outbox để publish lên Dapr
    // Request checkout sẽ trả về kết quả cho user NGAY LẬP TỨC — không hề bị block bởi các service phía sau
}

Mô hình outbox này đảm bảo việc gửi sự kiện thành công ngay cả khi Dapr broker bị sập tạm thời. Observer của Magento không hề có cơ chế bảo kê nào như thế — một observer bị lỗi sẽ âm thầm vứt bỏ luôn cái sự kiện đó.

Cái giá Thực sự của việc Migration

Đây là chỗ mà đa số các bài viết hô hào migration bắt đầu bớt thành thật. Microservices không hề miễn phí.

Độ phức tạp vận hành tăng phi mã. Bạn giờ đây đang phải chạy 21+ services, mỗi cái có database riêng, pipeline deploy riêng, và các chế độ lỗi riêng. Bạn cần Kubernetes, cần service mesh, distributed tracing, centralized logging, và một cái team hiểu rõ tất cả những thứ đó.

Hệ thống phân tán đẻ ra các chế độ lỗi mới tinh. Phân mảnh mạng lưới (Network partitions), lỗi thứ tự sự kiện (event ordering), bug do mất tính lũy đẳng (idempotency bugs), và các edge-case của eventual consistency là những thứ không bao giờ tồn tại ở một khối monolith. Chúng đòi hỏi sự đầu tư năng lực kỹ sư một cách rõ ràng để xử lý cho đúng.

Bản thân quá trình migration là một trò rủi ro cao. Đập đi viết lại kiểu “big bang” ngây thơ chính là cách mà các dự án triệu đô chết yểu. Con đường an toàn duy nhất là di cư tăng dần (incremental migration) sử dụng Strangler Fig pattern — bóp nghẹt traffic từ monolith sang service mới một cách từ từ trong khi vẫn duy trì tính nhất quán dữ liệu thông qua các pipeline CDC và đồng bộ 2 chiều (bidirectional sync).

Quy mô đội ngũ rất quan trọng. Một team 2-3 devs không thể nào ôm nổi 21 services. Nội cái chi phí bảo trì vận hành thôi cũng đã cần một nguồn lực platform engineering chuyên biệt. Với các team nhỏ, Shopify hoặc xài Magento cloud có quản lý (managed) mới là câu trả lời đúng đắn.

Khi nào nên Migrate (Và khi nào thì không)

HÃY migrate khi:

• Bạn có từ 5+ developers trở lên và có năng lực DevOps chuyên trách.
• Bạn đang đụng phải cái trần scale của Magento (deploy chậm chạp, kẹt xe database dùng chung, conflict các module).
• Bạn cần sự tự trị và độc lập làm việc giữa nhiều squad.
• Bạn bắt buộc phải có các luồng thanh toán custom dị thường, WMS đa kho, hoặc các tích hợp đặc thù Việt Nam mà Magento xử lý quá cồng kềnh.
• Bạn muốn sở hữu trọn vẹn source code mà không tốn một cắc phí bản quyền (licensing) nào cho vendor.

ĐỪNG CÓ migrate khi:

• Team của bạn có dưới 5 người.
• Bạn cần phải launch dự án tính bằng tuần, chứ không phải bằng tháng.
• Lượng traffic của bạn vẫn hoàn toàn xử lý ngon ơ trên một stack Magento đã được tinh chỉnh (well-tuned) đàng hoàng.
• Bạn phụ thuộc sinh tử vào hệ sinh thái plugin có sẵn của Magento.
• Bạn không có đủ độ trưởng thành vận hành (operational maturity) để quản lý Kubernetes trên production.

Lời chốt hạ

Kiến trúc monolith của Magento không phải là một khiếm khuyết — nó là một sự lựa chọn thiết kế có chủ đích nhằm tối ưu hóa sự đơn giản và độ giàu có của hệ sinh thái. Đối với đại đa số các doanh nghiệp thương mại điện tử, nó vẫn là sự lựa chọn chính xác.

Quá trình migrate sang microservices chỉ có ý nghĩa khi cái giá phải trả cho sự đơn giản kia — sự kẹt xe của database dùng chung, không thể scale cục bộ, rủi ro deploy chùm, chết chùm dây chuyền — đã vượt quá mức chi phí đánh đổi cho sự phức tạp của hệ thống phân tán.

Cái điểm giao cắt đó là có thật, và khi bạn chạm đến nó, khoản đầu tư cho kiến trúc mới sẽ tự bù đắp lại bằng tốc độ đẻ tính năng mới (deployment velocity), sức bền vận hành (operational resilience), và khả năng chỉ scale đúng cái chỗ nào đang cần được scale — không thừa, không thiếu.

Để xem cuốn sổ tay chiến thuật chính xác về cách thực hiện pha migration này một cách an toàn — bao gồm Strangler Fig pattern 3 giai đoạn, các pipeline Debezium CDC, và đồng bộ 2 chiều — hãy đọc Bản vẽ Zero-Downtime: Di chuyển từ Magento sang Microservices.

Nếu bạn vẫn đang ở khâu đánh giá năng lực team trước khi migration, hãy đọc Lập trình viên Magento ở Việt Nam: Hướng dẫn Thuê và Đánh giá Kỹ thuật và Lập trình Magento tại Việt Nam: Cách Scope, Estimate và Đánh giá một Dự án.