Production

← Chương trước: Phần 1: Protocol Fundamentals & Transport Evolution | Mục lục Series | Chương tiếp theo: Phần 3: Identity & AuthN Cho Agentic Workflows → Answer-first: Xây dựng MCP Server production bằng Go đòi hỏi tuân thủ mô hình clean architecture, quản lý concurrency an toàn và kiểm soát context timeout. Bài viết cung cấp template hoàn chỉnh triển khai Tools, Resources qua mcp-golang SDK với zero memory leak và cấu hình SSE transport sẵn sàng cho Kubernetes. ...

← Chương trước: Phần 7 — Declarative Prompting với DSPy (2026) | Mục lục Series | Chương tiếp theo: Sự Tiến Hóa Của Context Engineering: Từ Prompt Basic Đến System-Level Architecture (2026) → Answer-first: Xây dựng pipeline PromptOps cấp production tích hợp CI/CD tự động kiểm thử regression, đánh giá qua LLM-as-a-Judge, giám sát độ trôi dạt (drift) và cơ chế tự động rollback khi chất lượng câu trả lời bị suy giảm. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Profiling Go trong production với pprof cho phép chẩn đoán chính xác CPU hotspots, phân biệt cấp phát bộ nhớ (alloc_space vs inuse_space) và định vị goroutine leaks với overhead dưới 2%. Bật endpoint trên port nội bộ cô lập, dùng kubectl port-forward và custom pprof labels để phân tích đa chiều. Yêu cầu tiên quyết: Hướng dẫn này đề cập đến việc profile và chẩn đoán các sự cố hiệu năng phức tạp trên production. Nếu bạn đang xử lý tình trạng số lượng goroutine tăng trưởng không kiểm soát, hãy chắc chắn rằng bạn đã hiểu các khái niệm nền tảng trong bài viết Phát hiện và Xử lý Goroutine Leak trên Production Go Services. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Quản lý đồng thời an toàn trong Go đòi hỏi các mẫu Goroutine Pool có giới hạn (bounded concurrency): errgroup cho tác vụ theo lô, semaphore có đệm cho I/O pipelines, và channel-based worker pools cho xử lý hàng đợi kèm backpressure, circuit breaking và graceful shutdown. Mọi kỹ sư Go cuối cùng đều viết cùng một sai lầm: một vòng lặp khởi chạy các goroutine vô điều kiện (unconditionally). Trong một bản demo với 10 mục, điều này hoạt động rất đẹp. Nhưng trong môi trường production (thực tế) với 50.000 sự kiện webhook đầu vào, nó sẽ sản sinh ra 50.000 goroutine cùng một lúc, làm cạn kiệt bộ nhớ và kích hoạt sát thủ diệt bộ nhớ (OOM killer). Kubernetes sẽ khởi động lại (restart) cái pod đó. Và rồi kỹ sư trực on-call nhận tiếng bíp gọi dậy lúc 3 giờ sáng. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Rò rỉ Goroutine xảy ra khi goroutine bị block vĩnh viễn trên unbuffered channel, context thiếu hủy, hoặc HTTP body chưa đóng, dẫn đến giữ heap memory và gây sự cố Kubernetes OOM (exit code 137). Chẩn đoán bằng pprof goroutine profile, chặn đứng qua goleak trong CI và áp dụng Go 1.26 goroutine leak detection. Một pod Kubernetes đột ngột khởi động lại với mã thoát (exit code) 137. Biểu đồ giám sát bộ nhớ (memory metrics dashboard) hiển thị một mô hình bậc thang tăng dần đều đặn kéo dài suốt ba ngày. Không có bất kỳ log panic nào trong stdout, không có lỗi database, và không có mức tăng đột biến CPU bất thường nào. Chỉ là một cái chết êm đềm và từ từ do lỗi OOM (Out Of Memory). ...

Answer-first: Vận hành AI API trên production đòi hỏi thay thế API key tĩnh bằng OAuth 2.1 JWT bearer token (RFC 7523) có thời hạn 2–15 phút, quản lý Prompt như code với SemVer ghim phiên bản kèm CI regression testing (golden datasets), và xây dựng Agent gateway giám sát token tracing thay vì tin tưởng abstraction framework. 🇬🇧 Read the English version of this article on tanhdev.com Việc vận hành các API AI trên môi trường production trong suốt 18 tháng qua đã mang lại ba bài học xương máu mà tôi không thể tìm thấy trong bất kỳ tài liệu hướng dẫn “bắt đầu với LLM” nào. Chúng rút ra từ các sự cố thực tế, các buổi họp rút kinh nghiệm (postmortems) và từ những tin nhắn Slack lúc 2 giờ sáng với cụm từ mà không kỹ sư nào muốn thấy trên production — “lỗi ngầm” (silent failure). ...