Micro Frontend là "thiết kế quá mức" hay "tất yếu"?
Micro Frontend (MFE) kể từ khi xuất hiện lần đầu trên ThoughtWorks Technology Radar năm 2018 đã nhận được cả lời khen và chỉ trích cực đoan. Trong thời kỳ "monorepo + Turborepo" thịnh vượng 2022-2023, nó mất đi sự hiện diện, nhưng từ năm 2025 trở đi, với ba làn gió thuận: Module Federation 2.0 ổn định, Rspack thực dụng hóa trên sản xuất, và khoảng cách năng suất giữa các nhóm do AI agent mở rộng, nó lại được chú ý. Bài viết này tổng quan stack công nghệ MFE tính đến tháng 4 năm 2026 và giới thiệu 3 trường hợp chuyển dịch từng bước của các doanh nghiệp tài chính, SaaS và EC lớn ở Nhật Bản.
Module Federation 2.0: Hoàn thiện thế hệ thứ hai
Module Federation là cơ chế tải động module từ remote vào runtime, được giới thiệu trong Webpack 5 năm 2020. Phiên bản 2.0 đã chuẩn bị API mới hỗ trợ cả Webpack/Rspack nhờ đóng góp của nhóm Rspack (ByteDance). Có 3 điểm cải thiện. Thứ nhất là hệ thống plugin runtime, cho phép ghi đè động "danh sách remote" và "phiên bản dependency chia sẻ" vào runtime, hiện thực A/B test và phân phối theo thuộc tính người dùng mà không cần reload. Thứ hai là tính an toàn kiểu — 2.0 đóng gói `.d.ts` trong container remote và IDE completion hoạt động. Thứ ba là tiện ích mở rộng Chrome DevTools "Module Federation Inspector" cho phép trực quan hóa thời gian thực trạng thái tải.
Rspack / Vite / Webpack: Mặt trận công cụ build
Webpack 5 có vị thế legacy nhưng là lựa chọn hàng đầu cho các dự án quy mô lớn hiện có nhờ hệ sinh thái dày dặn. Rspack 1.x là builder tương thích Webpack dựa trên Rust, tốc độ gấp 5-10 lần, hỗ trợ chính thức Module Federation 2.0 và đã trở thành tiêu chuẩn từ năm 2025 trở đi. Vite 6 hỗ trợ qua plugin `@module-federation/vite` nhưng tương thích kém giữa HMR và giải quyết runtime, nên an toàn hơn khi coi là experimental trong lúc phát triển. Turbopack tính đến tháng 4 năm 2026 chưa triển khai hỗ trợ chính thức cho Module Federation, và nếu sử dụng Module Federation thì việc rút lui về Webpack/Rspack là thực tế.
Single-SPA và iframe: Con đường khác
Single-SPA là phương thức shell ứng dụng quản lý lifecycle của nhiều SPA, và vẫn là lựa chọn tốt nhất cho các tổ chức cần hỗn hợp framework khác nhau (React + Vue + Angular). Phiên bản 7.0 năm 2025 giảm 40% overhead khởi động. Trong thực tế, cân bằng nhất là hybrid Module Federation + Single-SPA, trong đó Single-SPA đảm nhiệm kiểm soát mount, Module Federation đảm nhiệm chia sẻ dependency. Cấu hình này được áp dụng bởi Zalando, IKEA và các trường hợp Nhật Bản được đề cập sau.
Phân phối Edge và vô hiệu hóa cache
Thách thức vận hành lớn nhất của MFE là "tính nhất quán phiên bản của remote". Thực hành tốt nhất năm 2026 là Immutable Assets + Manifest Indirection. Đặt tên file dựa trên hash nội dung cho JS chunk của remote và phân phối lưu trữ dài hạn với `max-age=31536000, immutable`, chỉ phân phối `mf-manifest.json` là điểm vào với cache ngắn hạn (max-age=60, stale-while-revalidate=300). Manifest hoạt động như indirection của chuyển đổi phiên bản, và khi cập nhật điểm vào, tất cả host sẽ nhận phiên bản mới sau TTL tiếp theo.
Trên Cloudflare, Fastly, CloudFront đều đã ổn định vận hành quản lý manifest tập trung tại edge KV. Canary có trường `traffic_split` trong manifest và tỷ lệ phán xét bằng plugin runtime của Module Federation 2.0.
Trường hợp 1: Phân tách "Frontend kế toán" của megabank
Một ngân hàng lớn Internet banking đã phân tách ứng dụng React nguyên khối (khoảng 2,4 triệu LoC) thành 7 MFE theo từng nhóm. Nguyên nhân là những vấn đề phình to điển hình: "thay đổi của một nhóm chặn release của 6 nhóm khác", "npm install mất 8 phút", "build mất 22 phút".
Cấu hình được áp dụng là Webpack + Module Federation 2.0 + Single-SPA. Host là shell mỏng chỉ chứa tổng quan tài khoản, điều hướng và xác thực, và tải động 7 MFE: "chuyển tiền", "quỹ đầu tư", "vay", "thẻ", "khai thuế", "bảo hiểm", "liên hệ".
Chuyển dịch từng bước được lên kế hoạch 18 tháng, bắt đầu từ "Strangler Facade" tách shell trước và bao gói nguyên khối hiện có như một MFE. Tiếp theo, tách MFE từ nguyên khối hiện có theo đơn vị tính năng. Mỗi nhóm có thể nâng phiên bản React độc lập, và tại thời điểm hoàn thành chuyển dịch, phiên bản React của từng MFE phân bố từ 18 đến 19.2.
Kết quả rõ ràng. Thời gian build trung bình mỗi nhóm 3 phút (giảm 86% từ 22 phút), tần suất deploy từ 1 lần/tuần lên trung bình 12 lần/ngày, phạm vi ảnh hưởng sự cố từ "toàn bộ tính năng dừng" xuống "chỉ MFE liên quan". Trong đối phó kiểm toán tuân thủ quy định tài chính, việc có thể lưu bằng chứng deploy độc lập theo từng MFE là lợi ích bổ sung.
Trường hợp 2: Cùng tồn tại Rspack + Vite của SaaS
Một công ty SaaS HR Tech vận hành cổng admin (Rspack) và dịch vụ self-service cho nhân viên (Vite) với các công cụ build khác nhau. Yêu cầu khác nhau là lý do chia công cụ build: cổng admin khổng lồ cần tương thích IE11 (yêu cầu khách hàng legacy), cổng nhân viên lấy mobile làm trung tâm ưu tiên DX.
Kết nối MFE là 4 tính năng: thanh điều hướng chung, trung tâm thông báo, tìm kiếm, chat trợ giúp. Mỗi tính năng được build bằng Rspack từ repository độc lập, và cả hai cổng tải qua Module Federation 2.0. Phía Vite được tích hợp như phía tiêu thụ remote bằng plugin `@module-federation/vite`.
Bài học là "shared dependency ở mức tối thiểu". Ban đầu nhiều thư viện như React, dayjs, Zustand được chỉ định là shared, nhưng đã xảy ra 3 sự cố sản xuất do xung đột singleton, và cuối cùng chỉ giới hạn còn 3: React, React-DOM và i18n context. Bundle size tăng lên nhưng tính ổn định vận hành được cải thiện đáng kể.
Trường hợp 3: Chuyển sang phân phối Edge của nền tảng EC
Một SaaS shop builder EC lớn có tính tương thích cao với MFE vì tính chất cung cấp frontend tùy chỉnh cho từng tenant. Năm 2025 chuyển sang Rspack + Module Federation 2.0 và Cloudflare Workers tạo động MFE manifest từ tenant ID. Việc "công bố tính năng mới dần dần chỉ cho khách hàng cụ thể" hay "phân phối thiết kế giới hạn ngày lễ theo từng tenant" trở nên khả thi mà không cần engineer deploy. Cạm bẫy là SEO, được giải quyết bằng giải quyết manifest trước trong SSR và nhúng tĩnh structured data. Tỷ lệ hiệu lực index được cải thiện từ 92% lên 98%.
Có nên áp dụng MFE không: Checklist quyết định
Việc chấp nhận hay từ chối nên được phán xét theo các tiêu chí sau. Nếu có từ 3 mục trở lên, MFE cần được xem xét nghiêm túc. Số nhóm từ 5 trở lên với chu kỳ release độc lập / thời gian build monorepo vượt 10 phút / cùng tồn tại framework và phiên bản khác nhau / phân phối tùy chỉnh theo tenant / muốn giới hạn ảnh hưởng sự cố theo đơn vị tính năng / cần bằng chứng kiểm toán độc lập theo tính năng. Ngược lại, nếu nhóm 1-2 người, build dưới 3 phút, ưu tiên tối đa sự đơn giản của lần tải đầu tiên thì MFE là quá mức.
Kết luận: MFE trong thời đại "tái khám phá"
Với làn gió thuận của Module Federation 2.0, sự trưởng thành của Rspack, tiến hóa phân phối edge và sự tự chủ của nhóm nhờ AI agent, MFE năm 2026 đã được nâng cấp từ "công nghệ của một số tổ chức tiên tiến" lên "định thức cho tổ chức phù hợp điều kiện". Điều quan trọng không phải là giới thiệu MFE như "giải pháp vạn năng" mà là giới thiệu như đơn thuốc cụ thể cho vấn đề của tổ chức và yêu cầu kinh doanh. Như 3 trường hợp được giới thiệu trong bài viết này cho thấy, MFE trong điều kiện phù hợp mang lại cải thiện đột biến về thời gian build, tần suất release, phạm vi ảnh hưởng sự cố và tự do tùy chỉnh. Trước khi bỏ qua "MFE? Cũ rồi" trong cuộc họp kiến trúc tiếp theo, có giá trị nhìn lại một lần nữa hiện trạng của tổ chức.