Chào mừng trở lại với bản tin Tech Radar, nơi chúng ta chắt lọc những tín hiệu nhiễu loạn của giới công nghệ để tìm ra những xu hướng thực sự định hình kiến trúc hệ thống (System Architecture) trong tương lai.

Tuần thứ 2 của tháng 6/2026 chứng kiến 3 cú huých cực mạnh từ hạ tầng lõi (Go, Kubernetes) cho tới sự trưởng thành của kiến trúc AI-Native. Dưới góc nhìn của một System Architect, đây là những cập nhật bạn không thể bỏ qua để tối ưu hóa hệ thống High-Concurrency của mình.

1. Golang 1.26: Kiến trúc “Green Tea” GC - Cứu tinh của Microservices ngốn RAM

Mặc định được kích hoạt trên Go 1.26, bộ gom rác (Garbage Collector) mang tên mã “Green Tea” không chỉ là một bản vá hiệu năng, mà là một cuộc đại tu kiến trúc cốt lõi.

Vấn đề của GC cũ (Object-Based)

Trước đây, Go GC sử dụng thuật toán Concurrent Mark-and-Sweep theo vết các object qua các con trỏ (pointers). Điều này dẫn đến việc truy cập bộ nhớ ngẫu nhiên (random memory access), gây ra tỷ lệ trượt cache (L1/L2 cache misses) cực cao. Đối với CPU, đây là một “thảm họa vi kiến trúc” khiến CPU phải liên tục chờ đợi dữ liệu từ Main Memory.

Cú hích từ “Green Tea” (Page-Based Architecture)

Green Tea thay đổi đơn vị xử lý từ “từng Object” sang “từng Page bộ nhớ 8 KiB”. Thay vì dò dẫm từng con trỏ, nó đưa toàn bộ một page chứa các object còn sử dụng vào hàng đợi và quét tuần tự.

Tác động thực tế (Business Impact):

  • Giảm 10%–40% CPU overhead dành cho việc dọn rác.
  • Giảm 15%–20% p99 tail latency ở các hệ thống API Gateway hoặc các service xử lý JSON/Protobuf cường độ cao.
  • SIMD Vectorization: Nhờ việc quét bộ nhớ liên tục, Go runtime nay đã có thể tận dụng các tập lệnh vector hóa của CPU hiện đại để tăng tốc độ mark phase.

Architect’s Note: Nếu bạn đang chạy các gRPC microservices với tần suất cấp phát object ngắn hạn lớn, Go 1.26 sẽ mang lại một đợt tăng tốc “miễn phí” mà không cần sửa một dòng code nào.

2. Kubernetes: In-Place Pod Resizing chính thức lên GA (v1.35+)

Đã bao nhiêu lần bạn phải chịu cảnh “chớp tắt” (connection drops, cache wipes) khi đổi cấu hình CPU/RAM cho một Pod? Kỷ nguyên đó đã chính thức chấm dứt. In-Place Pod Resize đã đạt mức General Availability (GA).

Zero-Downtime Scaling

Tính năng này cho phép bạn thay đổi trực tiếp resources.requests và resources.limits của container mà không kích hoạt chu kỳ Evict -> Recreate.

Điều này thay đổi luật chơi cho các hệ thống Stateful (như Kafka, Redis, In-memory Caches, hoặc JVM).

  • Kubernetes nay phân tách rõ ràng trạng thái tài nguyên qua API:
    • spec.containers[*].resources (Mức tài nguyên mong muốn)
    • status.containerStatuses[*].allocatedResources (Mức tài nguyên Node đã giữ chỗ)
    • status.containerStatuses[*].resources (Mức tài nguyên đang thực dùng)

VPA InPlaceOrRecreate Mode

Sự kết hợp hoàn hảo nhất của tính năng này là với Vertical Pod Autoscaler (VPA). VPA nay hỗ trợ mode InPlaceOrRecreate. Nó sẽ cố gắng “Hot-swap” CPU trước bằng subresource resize. Chỉ khi Node vật lý thực sự hết tài nguyên, nó mới buộc phải restart Pod sang Node khác.

Đây là đòn bẩy tuyệt vời để cắt giảm hoàn toàn “thuế over-provisioning” (cấp dư x2 RAM để phòng hờ) mà không sợ rủi ro gián đoạn dịch vụ.

3. Kiến trúc AI-Native & Việc nhúng Agent vào Critical Request Path

Năm 2024, AI thường đứng ngoài lề kiến trúc cốt lõi — hoạt động như một background worker (chạy job tóm tắt) hoặc một API gọi ngoài với độ trễ tính bằng giây.

Giữa năm 2026, chứng kiến sự bùng nổ của kiến trúc AI-Native, nơi RAG (Knowledge Plane) và các Agentic Workflows bị kéo thẳng vào Critical Request Path (luồng xử lý đồng bộ trước khi trả response về cho user).

Lên ngôi của các mô hình “Flash” & DSLMs

Việc nhúng LLM vào luồng đồng bộ (Synchronous) đòi hỏi độ trễ phải < 500ms. Các mô hình siêu lớn (như GPT-4 hay Claude Opus) là quá nặng nề và đắt đỏ cho việc này.

Thị trường đang chứng kiến sự trỗi dậy của các DSLMs (Domain-Specific Language Models). Điển hình nhất trong tháng này là sự kiện Microsoft ra mắt MAI-Code-1-Flash.

  • Chỉ 5 Tỷ tham số (5B Parameters) nhưng đạt ~51% trên tập benchmark cực khó SWE-Bench Pro.
  • Được xếp vào class “Haiku”, cực kỳ tối ưu cho Inference, biến nó thành lựa chọn hoàn hảo để làm “Agentic Router” (bộ định tuyến logic) ngay trong vòng đời của một API Request.

Architect’s Note: Khi thiết kế hệ thống AI-Native, bạn bắt buộc phải coi LLM Inference như một lời gọi Database: Phải có Load Balancing, Circuit Breakers, Fallback Timeouts cứng, và đặc biệt là Semantic Caching để đảm bảo SLA cho Critical Path.

Cảm ơn các bạn đã theo dõi Tech Radar tuần này. Đừng quên đón đọc các phần tiếp theo trong Series về System Design và Core Banking Architecture trên blog.