Chào mừng trở lại với bản tin Tech Radar, nơi chúng tôi lọc bỏ những tín hiệu nhiễu của ngành công nghệ để khám phá những xu hướng thực sự đang định hình Kiến trúc Hệ thống tương lai.

Tuần thứ hai của tháng 6 năm 2026 chứng kiến ba sự dịch chuyển khổng lồ, từ cơ sở hạ tầng cốt lõi (Go, Kubernetes) đến 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 bản cập nhật bạn không thể bỏ qua để tối ưu hóa các hệ thống High-Concurrency.


1. Golang 1.26: Kiến trúc GC “Green Tea” - Vị Cứu Tinh cho các Microservices ngốn RAM

Được bật mặc định trong Go 1.26, trình dọn dẹp rác (Garbage Collector) với tên mã “Green Tea” không chỉ là một bản vá hiệu suất; nó là một cuộc đại tu kiến trúc cốt lõi.

Vấn đề với GC cũ (Object-Based)

Trước đây, Go GC sử dụng thuật toán Concurrent Mark-and-Sweep, lần theo các đối tượng thông qua con trỏ. Điều này dẫn đến việc truy cập bộ nhớ ngẫu nhiên, gây ra tỷ lệ trượt bộ nhớ cache (cache miss) L1/L2 cực kỳ cao. Đối với CPU, đây là một “thảm họa kiến trúc”, buộc nó 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ừ “các Object riêng lẻ” sang “các Memory Page 8 KiB”. Thay vì lần mò qua các con trỏ, nó đưa toàn bộ một page chứa các object đang hoạt động vào hàng đợi và quét tuần tự.

Tác động kinh doanh:

  • Giảm 10% – 40% chi phí CPU dành cho việc dọn rác.
  • Giảm 15% – 20% độ trễ p99 (tail latency) trong các API Gateways hoặc các dịch vụ xử lý JSON/Protobuf cường độ cao.
  • SIMD Vectorization: Nhờ việc quét bộ nhớ liên tục, Go runtime giờ đây 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 pha mark.

Ghi chú của Architect: Nếu bạn đang chạy các microservices gRPC với tần suất cấp phát các object ngắn hạn cao, Go 1.26 sẽ mang lại tốc độ được cải thiện “miễn phí” mà không cần thay đổi một dòng code nào.


2. Kubernetes: In-Place Pod Resizing Chính Thức Đạt Chuẩn GA (v1.35+)

Bạn đã bao nhiêu lần phải chịu đựng các “khoảng gián đoạn” (rớt kết nối, xóa cache) khi sửa đổi cấu hình CPU/RAM cho một Pod? Kỷ nguyên đó đã chính thức kết thúc. In-Place Pod Resize đã đạt mức độ Khả dụng Chung (General Availability - GA).

Scaling Không Gián Đoạn (Zero-Downtime)

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

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

  • Kubernetes hiện phân tách rõ ràng các trạng thái tài nguyên thông qua API của nó:
    • spec.containers[*].resources (Mức tài nguyên mong muốn)
    • status.containerStatuses[*].allocatedResources (Tài nguyên được bảo lưu bởi Node)
    • status.containerStatuses[*].resources (Tài nguyên thực tế hiện đang sử dụng)

Chế độ InPlaceOrRecreate của VPA

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

Đây là một đòn bẩy tuyệt vời để loại bỏ hoàn toàn “thuế cấp phát dư thừa” (phân bổ gấp đôi 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 & Nhúng Agents vào Critical Request Path

Năm 2024, AI thường đứng ngoài rìa của kiến trúc lõi – hoạt động như một background worker (chạy các luồng tóm tắt) hoặc một lệnh gọi API bên 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à Agentic Workflows được kéo trực tiếp vào Critical Request Path (luồng xử lý đồng bộ trước khi trả về phản hồi cho người dùng).

Sự Trỗi Dậy của Mô hình “Flash” & DSLMs

Việc nhúng LLMs vào luồng Đồng bộ yêu cầu độ trễ < 500ms. Các mô hình khổng lồ (như GPT-4 hoặc Claude Opus) quá nặng và đắt đỏ cho việc này.

Thị trường đang chứng kiến sự trỗi dậy của DSLMs (Domain-Specific Language Models). Ví dụ nổi bật nhất tháng này là sự ra mắt của MAI-Code-1-Flash từ Microsoft.

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

Ghi chú của Architect: Khi thiết kế các hệ thống AI-Native, bạn phải đối xử với LLM Inference giống như một lệnh gọi Database: Nó yêu cầu Load Balancing, Circuit Breakers, Fallback Timeouts cứng, và đặc biệt là Semantic Caching để đảm bảo SLA cho Critical Path.


👉 Số trước: Tech Radar 11/06 – K8s Pod Resizing, Agentic Workflows & Go 1.26

👉 Số tiếp theo: Tech Radar 17/06 – Kratos Clean Architecture & Dapr Pub/Sub

Cảm ơn bạn đã đọc Tech Radar tuần này. Đừng quên xem các phần tiếp theo trong loạt bài High Concurrency SystemsModular Monolith Architecture trên blog.


🤝 Kết nối với tôi

Bạn đang gặp phải những thách thức tương tự về kiến trúc hệ thống, mở rộng quy mô (scaling) hay dịch chuyển (migration)? Hãy kết nối với tôi trên LinkedIn, theo dõi GitHub của tôi, hoặc gửi một email để trao đổi nhé.