Kiến trúc vi dịch vụ (MSA, Micro Service Architecture)

1. Tổng quan

A. Định nghĩa và đặc điểm

MSA là phong cách kiến trúc tổ chức một ứng dụng thành tập hợp các dịch vụ nhỏ có thể phát triển, triển khai và mở rộng độc lập. Mỗi dịch vụ đảm nhận một chức năng nghiệp vụ, có cơ sở dữ liệu riêng, giao tiếp qua API gọn nhẹ (chủ yếu HTTP/REST, nhắn tin) và vận hành tự chủ.

Ý tưởng cốt lõi của MSA là 'chia một khối khổng lồ thành nhiều phần nhỏ và cho mỗi phần độc lập'. Kiến trúc nguyên khối (Monolith) truyền thống gói UI, logic nghiệp vụ, truy cập dữ liệu vào một đơn vị triển khai lớn. Khi quy mô nhỏ, cấu trúc này đơn giản và hiệu quả, nhưng khi ứng dụng lớn dần thì xuất hiện ba căn bệnh kinh niên. Thứ nhất, dù sửa nhỏ cũng phải build và triển khai lại toàn bộ nên chu kỳ triển khai chậm. Thứ hai, không thể mở rộng riêng một chức năng nên dù lưu lượng dồn vào một chức năng vẫn phải nhân bản toàn bộ ứng dụng. Thứ ba, rò rỉ bộ nhớ hay sự cố của một mô-đun làm tê liệt toàn bộ tiến trình, sự cố lan ra toàn diện.

MSA giải quyết vấn đề này bằng cách phân rã thành các dịch vụ độc lập theo đơn vị chức năng (ví dụ thành viên, đặt hàng, thanh toán, giao hàng). Mỗi dịch vụ có kho lưu trữ riêng và được triển khai độc lập, nên có thể chỉ sửa logic thanh toán và chỉ triển khai dịch vụ thanh toán (triển khai nhanh), khi đơn hàng bùng nổ chỉ cần nhân dịch vụ đặt hàng thành nhiều bản (mở rộng hiệu quả), và dù dịch vụ giao hàng chết, thành viên và đặt hàng vẫn tiếp tục hoạt động (cô lập sự cố). Về mặt tổ chức, cũng nảy sinh tính tự chủ khi mỗi đội nhỏ nắm toàn quyền phát triển và vận hành từng dịch vụ. Tính tự chủ này là lợi ích lớn nhất của MSA, nhưng nhất định phải hiểu song song rằng cái giá là phải gánh một loại vấn đề có độ khó hoàn toàn khác gọi là 'hệ thống phân tán' — độ trễ mạng, thất bại cục bộ, nhất quán dữ liệu, độ phức tạp vận hành.

B. Bối cảnh ra đời

Bối cảnh MSA nổi lên là sự đan xen của ba dòng chảy. Thứ nhất là tốc độ kinh doanh. Khi cạnh tranh dịch vụ web, di động gay gắt, sự nhanh nhạy 'triển khai hàng chục lần mỗi ngày' trở thành điều kiện sinh tồn, và kiến trúc nguyên khối triển khai toàn bộ cùng lúc không thể đạt tốc độ này. Thứ hai là sự trưởng thành của đám mây và container. Hạ tầng co giãn — tăng giảm máy chủ tức thì khi cần — cùng container (Docker) đóng gói và triển khai dịch vụ gọn nhẹ và điều phối (Kubernetes) ra đời, tạo nền tảng để thực sự vận hành được vô số dịch vụ nhỏ. Thứ ba là lý thuyết tổ chức (định luật Conway). Từ nhận thức "cấu trúc hệ thống giống cấu trúc giao tiếp của tổ chức tạo ra nó", nỗ lực làm khớp cấu trúc đội nhỏ, tự chủ với cấu trúc dịch vụ nhỏ, tự chủ đã dẫn tới MSA.

C. Nguyên tắc khi hiện thực

Trong các nguyên tắc này, cái thường bị phá vỡ nhất trong thực tế là 'dữ liệu phân tán'. Nếu nhiều dịch vụ vì tiện mà dùng chung một cơ sở dữ liệu, dù triển khai đã tách nhưng dữ liệu vẫn bị buộc chặt, chỉ đổi một lược đồ là nhiều dịch vụ phải triển khai cùng nhau, rơi vào 'nguyên khối phân tán (distributed monolith)'. Đây là dạng tồi tệ nhất gánh đồng thời độ ghép nối của nguyên khối và độ phức tạp của MSA, nên giữ quyền sở hữu dữ liệu theo dịch vụ là kỷ luật cốt lõi quyết định thành bại của MSA.

2. Cấu trúc nguyên khối vs MSA

Sơ đồ cấu trúc dưới đây cho thấy khác biệt về cấu trúc triển khai và sở hữu dữ liệu của hai kiến trúc. Nguyên khối là một tiến trình và một CSDL, còn MSA là nhiều dịch vụ và CSDL riêng theo dịch vụ được kết nối bằng API.

flowchart TB
  subgraph MONO["Nguyên khối"]
    direction TB
    MA["Ứng dụng duy nhất<br/>(UI+logic+truy cập dữ liệu)"] --> MDB[("CSDL dùng chung")]
  end
  subgraph MICRO["MSA"]
    direction TB
    GW["API Gateway"] --> S1["Dịch vụ đặt hàng"]
    GW --> S2["Dịch vụ thanh toán"]
    GW --> S3["Dịch vụ giao hàng"]
    S1 --> D1[("CSDL đặt hàng")]
    S2 --> D2[("CSDL thanh toán")]
    S3 --> D3[("CSDL giao hàng")]
  end
  style MICRO fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Khác biệt của hai cấu trúc không đơn thuần là 'một khối hay chia nhỏ' mà là khác biệt độ phức tạp nằm ở đâu. Với nguyên khối, độ phức tạp nằm bên trong mã (cơ sở mã khổng lồ); với MSA, độ phức tạp chuyển ra giữa các dịch vụ (mạng, giao tiếp, nhất quán dữ liệu). Do đó, MSA có độ phức tạp ban đầu cao và với dịch vụ quy mô nhỏ, đơn giản lại trở thành thiết kế thừa. Mục 'phù hợp' trong bảng dưới là tiêu chí cho phán đoán này.

Về trường hợp thực tiễn, việc các dịch vụ thương mại điện tử, streaming lớn không kham nổi lưu lượng tăng đột biến và việc thêm chức năng liên tục nên chuyển từ nguyên khối sang MSA đã được biết đến rộng rãi. Ngược lại, cũng thường gặp trường hợp startup giai đoạn đầu chạy theo trào lưu, chia ngay từ đầu thành hàng chục dịch vụ, rồi không kham nổi do thiếu nhân lực vận hành và tự động hóa nên quay lại nguyên khối (gọi là 'rollback MSA'). Bài học từ các trường hợp trái ngược này rất rõ — MSA không phải là mục đích, mà là phương tiện được chọn khi đã có quy mô cần gánh cùng năng lực tổ chức và tự động hóa.

3. Giao tiếp giữa các dịch vụ và nhất quán dữ liệu

Khi dịch vụ được tách ra, 'các tác vụ phải cùng thành công hoặc cùng thất bại' phải được xử lý trải qua nhiều dịch vụ. Chẳng hạn, 'tạo đơn hàng → phê duyệt thanh toán → trừ tồn kho' là một giao dịch logic nhưng rải rác ở ba dịch vụ. Nếu là nguyên khối thì có thể xử lý nguyên tử bằng một giao dịch CSDL, nhưng trong MSA nơi CSDL tách theo dịch vụ, giao dịch phân tán truyền thống (2PC) không phù hợp do vấn đề hiệu năng và tính sẵn sàng.

sequenceDiagram
  participant C as Máy khách
  participant G as API Gateway
  participant O as Dịch vụ đặt hàng
  participant P as Dịch vụ thanh toán
  participant D as Dịch vụ giao hàng
  C->>G: Yêu cầu đặt hàng
  G->>O: Tạo đơn hàng
  O-->>P: Yêu cầu thanh toán (sự kiện)
  P-->>O: Thanh toán hoàn tất (sự kiện)
  O-->>D: Chỉ thị giao hàng (sự kiện)
  Note over O,D: Khi thất bại, dùng giao dịch bù trừ<br/>hoàn tác bước trước (Saga)
  O-->>G: Xác nhận đơn hàng
  G-->>C: Phản hồi

Vì vậy MSA từ bỏ nhất quán mạnh (khớp tức thì) và chấp nhận nhất quán cuối cùng (eventual consistency), thay vào đó điều chỉnh tính chính xác dữ liệu bằng cách hoàn tác thất bại. Mẫu tiêu biểu là Saga. Saga thực thi tuần tự các giao dịch cục bộ của nhiều dịch vụ, và nếu thất bại giữa chừng thì thực thi 'giao dịch bù trừ (compensating transaction)' hủy các bước đã hoàn tất để hoàn tác toàn bộ. Trong chuỗi trên, nếu chỉ thị giao hàng thất bại thì hoàn tiền thanh toán (bù trừ) và hủy đơn hàng. Saga lại chia thành cách điều phối tập trung (orchestration), trong đó một dịch vụ chỉ huy luồng, và cách biên đạo (choreography), trong đó mỗi dịch vụ đăng ký nhận sự kiện và phản ứng tự chủ.

Một trục khác ứng phó thất bại cục bộ là các mẫu khả năng phục hồi (resilience). Để ngăn tình trạng khi một dịch vụ chậm đi hoặc chết, lời gọi chờ vô hạn và lan thành sự cố dây chuyền (cascading failure), dùng circuit breaker chặn lời gọi đến dịch vụ sự cố trong một thời gian, và phong tỏa thất bại bằng timeout, thử lại, bulkhead (cô lập tài nguyên). Không có các mẫu này thì lợi ích cô lập sự cố của MSA — 'sự cố một dịch vụ không lan ra toàn bộ' — chỉ dừng ở lý thuyết. Tức là trong MSA, cô lập sự cố không tự nhiên có được mà là kết quả thiết kế chỉ hiện thực khi các mẫu này được triển khai tường minh.

4. Service Mesh

Trong MSA, khi dịch vụ tăng lên hàng chục, hàng trăm, việc hiện thực thử lại, circuit breaker, xác thực, giám sát nói trên bằng mã cho từng dịch vụ trở nên phi thực tế. Nếu ngôn ngữ, framework mỗi nơi một kiểu thì phải viết lại cùng logic nhiều lần, và mỗi lần đổi chính sách phải triển khai lại mọi dịch vụ. Service mesh là cách tách 'mối quan tâm chung của giao tiếp giữa các dịch vụ' này khỏi mã ứng dụng và xử lý đồng loạt ở tầng hạ tầng (sidecar proxy).

Ý tưởng cốt lõi là gắn sidecar proxy (Envoy, v.v.) bên cạnh mỗi dịch vụ, để mọi lưu lượng dịch vụ trao đổi đều đi qua proxy này. Khi đó, định tuyến lưu lượng, thử lại, circuit breaker, mã hóa mTLS, xác thực, giám sát được proxy xử lý thay, và lập trình viên có thể chỉ tập trung vào logic nghiệp vụ. Chính sách được thiết lập khai báo ở trung tâm (control plane) và áp dụng đồng loạt cho mọi dịch vụ mà không cần sửa mã hay triển khai lại.

Hiện thực tiêu biểu là Istio, gồm data plane (proxy Envoy) và control plane. Tuy nhiên, service mesh cũng không miễn phí. Sidecar tăng lên thì tiêu hao tài nguyên và độ trễ tăng, độ khó vận hành cũng cao hơn, nên khi số dịch vụ ít thì lợi ích thực tế của việc áp dụng không lớn. Gần đây xuất hiện xu hướng gọn nhẹ hóa (ambient mesh) dùng proxy theo nút thay cho sidecar, nên cần lưu ý rằng service mesh cũng là đối tượng lựa chọn theo quy mô và nhu cầu, không phải phụ kiện bắt buộc của MSA.

5. Chuyên sâu — Chiến lược chuyển đổi MSA và xu hướng gần đây

Nguyên nhân thất bại thực tế nhất khi áp dụng MSA không phải công nghệ mà là 'cách bắt đầu'. Nguyên tắc kinh nghiệm được áp dụng rộng rãi là 'nguyên khối trước (Monolith First)': ở giai đoạn đầu khi ranh giới miền chưa chắc chắn, bắt đầu bằng nguyên khối được cấu trúc tốt, học về nghiệp vụ và ranh giới, rồi chuyển đổi dần bằng cách tách thành dịch vụ từ những phần hay thay đổi hoặc cần mở rộng độc lập — đây là cách an toàn. Kỹ thuật tiêu biểu được dùng khi đó là mẫu Strangler Fig (cây sung bóp nghẹt): không gỡ bỏ nguyên khối cũ một lần mà thay thế dần các chức năng mới hoặc chức năng tách ra bằng dịch vụ mới phía sau gateway, từ từ 'bóp nghẹt' hệ thống cũ cho đến khi biến mất. Việc chuyển sang MSA của các dịch vụ lớn trên thực tế phần lớn đều đi theo con đường tuần tự này.

Việc chia ranh giới dịch vụ như thế nào có tiêu chí lý thuyết là 'Bounded Context' của thiết kế hướng miền (DDD). Tức là phải chia dịch vụ theo ranh giới ý nghĩa nghiệp vụ chứ không theo tầng kỹ thuật (màn hình, logic, dữ liệu) thì mới được phân rã có độ gắn kết cao và ghép nối thấp. Chia quá vụn (nano-service hóa quá mức) thì chi phí giao tiếp và gánh nặng vận hành bùng nổ, chia quá lớn thì lợi ích MSA biến mất, nên việc xác lập ranh giới này chính là năng lực cốt lõi của kiến trúc sư.

Về xu hướng gần đây, thứ nhất, với chuẩn hóa cloud native, Kubernetes đã trở thành nền tảng tiêu chuẩn trên thực tế cho triển khai và vận hành MSA; thứ hai, khả năng quan sát (Observability) được hợp nhất xoay quanh truy vết phân tán (OpenTelemetry, v.v.) và trở thành năng lực bắt buộc của vận hành MSA. Thứ ba, từ sự phản tỉnh về tác dụng phụ của vi dịch vụ hóa quá mức, 'macroservice' hướng tới dịch vụ kích thước hợp lý và 'nguyên khối mô-đun (modular monolith)' giữ tính mô-đun nhưng triển khai đơn nhất đang được nhìn nhận lại như phương án thay thế. Có thể đọc điều này là kết quả của việc ngành công nghiệp đã học được rằng MSA không phải vạn năng mà là một lựa chọn đánh đổi.

6. Những điều cần cân nhắc và hàm ý

1. Độ phức tạp của hệ thống phân tán là cái giá căn bản. MSA đổi lấy khả năng mở rộng, tính độc lập, cô lập sự cố bằng việc gánh độ trễ mạng, thất bại cục bộ, nhất quán dữ liệu, gánh nặng vận hành. Phải thường xuyên quản lý độ phức tạp này bằng các mẫu và công cụ như circuit breaker, saga, API Gateway, truy vết phân tán, và nếu không có tiền đề năng lực tự động hóa (CI/CD) và khả năng quan sát đủ để gánh vác, MSA lại trở thành thuốc độc.
2. Phân rã dịch vụ phù hợp quyết định thành bại. Phải chia khớp với ranh giới nghiệp vụ dựa trên Bounded Context của thiết kế hướng miền. Chia quá chi tiết gây chi phí giao tiếp và quản lý, chia quá thô làm mất lợi ích, nên tìm 'kích thước phù hợp' là phán đoán cốt lõi của kiến trúc sư.
3. Chuyển đổi tuần tự là thực tế. Thay vì nhắm tới MSA hoàn chỉnh ngay từ đầu, bắt đầu bằng nguyên khối và tách dần các phần cần thiết bằng mẫu strangler sẽ giảm rủi ro. 'Có áp dụng MSA hay không' phải là quyết định tổng hợp quy mô tổ chức, tần suất thay đổi, năng lực vận hành chứ không phải trào lưu công nghệ.
4. Bắt buộc phải đồng bộ với cấu trúc tổ chức (định luật Conway). Dịch vụ tự chủ lấy đội tự chủ làm tiền đề. Dịch vụ đã chia nhưng quyền ra quyết định, triển khai vẫn bị buộc ở trung tâm thì lợi ích nhanh nhạy của MSA biến mất. Chuyển đổi kiến trúc chính là chuyển đổi tổ chức.
5. Phải thiết kế khả năng quan sát và bảo mật ngay từ đầu. Khi dịch vụ phân tán, truy vết nguyên nhân sự cố trở nên khó, nên phải trang bị truy vết phân tán, ghi log tập trung, metric ngay từ đầu, và giao tiếp giữa các dịch vụ nội bộ cũng phải được bảo vệ theo góc nhìn Zero Trust như mTLS. Đây là năng lực nền tảng khó bổ sung về sau.

Tài liệu tham khảo

• Martin Fowler, "Microservices": https://martinfowler.com/articles/microservices.html
• Tài liệu chính thức Istio: https://istio.io/latest/docs/
• microservices.io (Chris Richardson, danh mục mẫu): https://microservices.io/

Tóm tắt một câu: MSA là kiến trúc phân rã ứng dụng thành các dịch vụ nhỏ có thể triển khai và mở rộng độc lập, đổi lấy triển khai nhanh, mở rộng hiệu quả, cô lập sự cố bằng cái giá là độ phức tạp phân tán (nhất quán cuối cùng, thất bại cục bộ, gánh nặng vận hành), và chỉ thành công khi chế ngự độ phức tạp đó bằng xác lập ranh giới dựa trên DDD, saga/circuit breaker, service mesh, Kubernetes, chuyển đổi tuần tự.