← Bài trước | Series hub | Tiếp theo →

Chương 6: Vạch Rõ Lằn Ranh: API Gateway Đấu Với Service Mesh

Một khi ứng dụng Golang của bạn bung lụa scale từ vài chục vọt lên tới hàng trăm Microservices, quản lý luồng giao tiếp trở thành một thách thức vĩ mô. Bạn sẽ liên tục va chạm với hai khái niệm gắn chặt vào nhau như hình với bóng: API Gateway và Service Mesh.

Vô vàn kỹ sư vẫn hay thắc mắc: “Nếu tôi đã cất công dựng Istio (Service Mesh) rồi, liệu tôi có còn cần xài Kong (API Gateway) nữa không?” Lời giải đáp hoàn toàn nằm ở điểm dị biệt nền tảng giữa luồng traffic Bắc-Nam và Đông-Tây.

1. API Gateway: Kẻ Canh Cổng Trục Bắc-Nam

Answer-first: API Gateway có trách nhiệm kiểm soát dòng traffic Bắc-Nam (từ bên ngoài ập vào nội bộ) với trọng tâm nghiêng hẳn về Business Logic (logic nghiệp vụ), Authentication (Xác thực), và Rate Limiting nhằm thiết lập hàng rào bảo vệ vòng ngoài của cluster.

North-South Traffic (Traffic Bắc-Nam) đại diện cho dòng chảy dữ liệu bắt nguồn từ thế giới bên ngoài (Ứng dụng Mobile, Trình duyệt Web) thâm nhập vào bên trong mạng nội bộ riêng tư của bạn.

API Gateway ngự trị ở đường ranh giới ngoài cùng của hệ thống. Nó nhập vai một gã “Gatekeeper” (Người gác cổng) độc tôn. Lõi tính năng của một API Gateway bám rễ hoàn toàn vào Business Logic và Trải nghiệm của Client:

  • Authentication/Authorization (Xác thực/Phân quyền): Bóc tách kiểm định các tokens (JWT, OAuth2) trước khi thả cửa cho requests chui lọt vào trong.
  • Rate Limiting / Throttling: Chặn đứng spam hoặc siết hầu bao tính năng dựa trên các gói cước billing mà người dùng đã mua.
  • Protocol Translation (Chuyển Đổi Giao Thức): Đám microservices nội bộ thường thích trò chuyện với nhau bằng gRPC (rất lẹ nhưng lại khắc tinh với trình duyệt web). API Gateway đứng ra chuyển ngữ các request HTTP REST từ bên ngoài biến thành những lời gọi gRPC nội bộ.
  • Các gương mặt vàng: Kong Gateway, KrakenD (viết bằng ngôn ngữ Go), AWS API Gateway.

2. Service Mesh: Lưới Giao Thông Trục Đông-Tây

Answer-first: Service Mesh thống lĩnh dòng traffic Đông-Tây (luân chuyển nội bộ giữa service với service) để lo toan những vấn đề rặt mùi hạ tầng (infrastructure) ví dụ như mTLS, Circuit Breaking, và Tracing thông qua một kiến trúc Sidecar proxy.

East-West Traffic (Traffic Đông-Tây) chính là dòng chảy dữ liệu phương ngang di chuyển bên trong lòng mạng lưới nội bộ, đi từ Microservice này lang thang sang Microservice khác.

Một cái Service Mesh rành rành chỉ là một Tầng Hạ Tầng (Infrastructure Layer). Nó không mảy may quan tâm tới mấy cái business logic (chẳng hạn người dùng nạp vào ví bao nhiêu tiền). Nó được phái xuống để gỡ rối những chướng ngại vật mạng mẽo nội bộ phức tạp:

  • mTLS (Mutual TLS): Mã hóa toàn bộ đường truyền nội bộ. Rủi hacker có khoan thủng màng bọc Kubernetes cluster của bạn, chúng cũng đui mù không thể nghe lén gói dữ liệu qua lại giữa Service A và Service B.
  • Circuit Breaking & Retries (Ngắt Mạch & Thử Lại): Lỡ Service B đang hấp hối sập nguồn, Service Mesh lập tức dập cầu dao (trip the circuit) nhằm cứu Service A khỏi bị lây nghẽn cổ chai, rồi tự thân nó âm thầm thực thi nhồi lại (retries) khi mạng mẽo chỉ chập chờn.
  • Observability (Khả năng Quan Sát): Tự động thu thập các chuỗi distributed traces (như Jaeger, Zipkin) nhằm vạch mặt điểm nghẽn độ trễ xuyên suốt một dây chuyền chằng chịt đi qua 10 services.
  • Các gương mặt vàng: Istio, Linkerd.

Kiến Trúc Sidecar Proxy

Một Service Mesh vận hành bằng cách đính (inject) một cái Sidecar Proxy (hay dùng Envoy) ngồi chung chạ ngay bên trong cùng một Kubernetes Pod với cái ứng dụng Golang của bạn. Đoạn code Go của bạn chỉ việc ngây thơ gửi một chiếc HTTP request tẻ nhạt xuống localhost. Gã Envoy lao ra đánh chặn, trùm áo tàng hình mTLS lên request đó, chọn ra lộ trình tối ưu nhất, rồi áp tải nó bay thẳng qua tay gã Envoy của trạm đích. Lõi code ứng dụng hoàn toàn ngây thơ mờ tịt về sự hiện diện của gã Envoy này.

graph LR
    Client((Mobile/Web)) -->|North-South| Kong[API Gateway]
    
    subgraph Kubernetes Cluster
        Kong -->|gRPC / HTTP| S1[Service A]
        
        subgraph Pod A
            S1 <--> EnvoyA[Envoy Sidecar]
        end
        
        EnvoyA <-->|East-West / mTLS| EnvoyB[Envoy Sidecar]
        
        subgraph Pod B
            EnvoyB <--> S2[Service B]
        end
    end

3. Tại Sao Chạy Production Lại Phải Dùng Cả Hai?

Answer-first: Hệ thống high-concurrency huy động Kong/KrakenD chốt sổ ngoài vành đai để soát vé người dùng và đánh bật DDoS, trong lúc giăng lưới Istio/Linkerd chìm sâu bên trong để bảo kê mTLS và bẻ lái ngắt mạch (circuit breaking).

Cho dù đôi lúc đường ranh giới bị nhòa đi (ví dụ: gã Istio Ingress Gateway múa may làm trò sao chép mấy tính năng Gateway hạng xoàng), phương châm best practice dành cho các hệ high-concurrency là luôn tuân thủ nguyên tắc phân tách rạch ròi:

  1. Kong/KrakenD ở vòng ngoài (perimeter): Tập trung hỏa lực chuyên trách xác thực người dùng, định tuyến client, và ngăn chặn DDoS.
  2. Istio/Linkerd ở vòng trong (interior): Trấn thủ an ninh nội bộ, ngắt mạch hệ thống, và do thám lần vết (tracing) xuyên suốt hàng trăm con Go services.

Màn phân ly minh bạch này trao quyền cho đội Product mạnh tay nhào nặn tùy biến cấu hình Gateway cực kỳ an toàn, trong khi team DevOps/SRE cứ thong thả chăm nom Service Mesh mà chẳng sợ ai giẫm đạp lên chân ai.