Tweet
Tại sao đưa MCP lên Cloud lại "khó chịu" hơn? (Roadmap từ Stdio đến SSE)
Chào anh em,
Ở các bài trước, chúng ta đã viết MCP chạy ro ro trên máy tính cá nhân (Localhost). Mọi thứ thật đơn giản: Cấu hình JSON, trỏ vào file Python, xong.
Nhưng chuyện gì xảy ra khi Sếp bảo: "Cái tool tra cứu nội bộ này hay đấy, đẩy lên Server công ty cho cả team 100 người dùng đi em!"?
Lúc này ác mộng mới bắt đầu. Bạn sẽ nhận ra việc deploy MCP lên Cloud "khoai" hơn nhiều so với việc deploy một REST API bình thường. Tại sao lại thế?
1. Cuộc chiến Giao thức: Stdio vs. HTTP
Vấn đề cốt lõi nằm ở Giao thức vận chuyển (Transport Protocol).
🚕 API truyền thống (REST): Kiểu "Gọi xong dập máy"
2. Sự phức tạp của mô hình SSE
Để bạn dễ hình dung sự "rối rắm" thêm vào khi chuyển từ API sang MCP Cloud:
🟢 Mô hình API thường:
Client (LLM) --(HTTP Request)--> Cloud Server --(HTTP Response)--> Xong
🔴 Mô hình MCP Cloud (SSE):
Client (LLM) --(HTTP Connect)--> Cloud MCP
| ^
| <--(SSE Stream mở liên tục)----|
| |
| --(Gửi lệnh JSON-RPC qua POST)-->
| |
v |
Kết quả trả về qua luồng SSE ----------+
Giải thích: Khác với API "ăn liền", MCP cần một kênh SSE luôn mở để Server có thể "bắn" (push) danh sách công cụ, log, hoặc thông báo lỗi về cho Client bất cứ lúc nào, song song với việc nhận lệnh qua HTTP POST.
3. Khó hơn thì làm chi cho cực? (3 Lợi ích "Chí mạng")
Nếu phức tạp vậy, sao không dùng API quách cho rồi? Đây là lý do các doanh nghiệp vẫn quyết tâm dựng MCP Server:
4. Roadmap: Từ vọc vạch đến Enterprise
Nếu bạn muốn đi theo con đường chuyên nghiệp, đây là lộ trình dành cho bạn:
Giai đoạn 1: Localhost (Stdio) - "Dành cho cá nhân"
5. Kết luận
Đừng sợ sự phức tạp của Cloud MCP. Hãy bắt đầu với Stdio để hiểu rõ logic hoạt động của các Tools.
Khi cần lên Cloud, bản chất logic (hàm lấy giá chứng khoán, hàm query DB) vẫn giữ nguyên 100%. Bạn chỉ việc thay cái "lớp vỏ" bên ngoài: từ lớp vỏ Stdio sang lớp vỏ Web Server (SSE).
#MCP #CloudArchitecture #SSE #SystemDesign devops #EnterpriseAI
Chào anh em,
Ở các bài trước, chúng ta đã viết MCP chạy ro ro trên máy tính cá nhân (Localhost). Mọi thứ thật đơn giản: Cấu hình JSON, trỏ vào file Python, xong.
Nhưng chuyện gì xảy ra khi Sếp bảo: "Cái tool tra cứu nội bộ này hay đấy, đẩy lên Server công ty cho cả team 100 người dùng đi em!"?
Lúc này ác mộng mới bắt đầu. Bạn sẽ nhận ra việc deploy MCP lên Cloud "khoai" hơn nhiều so với việc deploy một REST API bình thường. Tại sao lại thế?
1. Cuộc chiến Giao thức: Stdio vs. HTTP
Vấn đề cốt lõi nằm ở Giao thức vận chuyển (Transport Protocol).
🚕 API truyền thống (REST): Kiểu "Gọi xong dập máy"
- Cơ chế: Stateless (Phi trạng thái).
- Quy trình: Client gọi GET /price ➡️ Server trả 50.000đ ➡️ Ngắt kết nối.
- Hạ tầng: Các nền tảng Cloud (AWS Lambda, Vercel, Render) cực thích kiểu này. Nó đơn giản, dễ scale.
- Cơ chế: Stdio (Standard Input/Output).
- Quy trình: Client (Claude Desktop) và Server (File Python) nằm chung trên một máy tính. Chúng nối với nhau bằng một đường ống trực tiếp.
- Vấn đề: Khi mang lên Cloud, bạn không thể dùng Stdio được nữa. Bạn không thể nối một cái ống nước từ máy tính ở Việt Nam sang Server ở Mỹ được.
2. Sự phức tạp của mô hình SSE
Để bạn dễ hình dung sự "rối rắm" thêm vào khi chuyển từ API sang MCP Cloud:
🟢 Mô hình API thường:
Client (LLM) --(HTTP Request)--> Cloud Server --(HTTP Response)--> Xong
🔴 Mô hình MCP Cloud (SSE):
Client (LLM) --(HTTP Connect)--> Cloud MCP
| ^
| <--(SSE Stream mở liên tục)----|
| |
| --(Gửi lệnh JSON-RPC qua POST)-->
| |
v |
Kết quả trả về qua luồng SSE ----------+
Giải thích: Khác với API "ăn liền", MCP cần một kênh SSE luôn mở để Server có thể "bắn" (push) danh sách công cụ, log, hoặc thông báo lỗi về cho Client bất cứ lúc nào, song song với việc nhận lệnh qua HTTP POST.
3. Khó hơn thì làm chi cho cực? (3 Lợi ích "Chí mạng")
Nếu phức tạp vậy, sao không dùng API quách cho rồi? Đây là lý do các doanh nghiệp vẫn quyết tâm dựng MCP Server:
- 🛡️ Bảo mật & Quản lý tập trung: Doanh nghiệp không muốn nhân viên chạy code lung tung trên máy cá nhân (Local MCP). Họ muốn MCP Server nằm trên Cloud công ty, có tường lửa, có Log kiểm soát xem nhân viên A đang hỏi AI về dữ liệu gì.
- 🔗 Chia sẻ tài nguyên (Pooling): Hãy tưởng tượng 100 nhân viên dùng Local MCP truy cập Database. Sẽ có 100 kết nối DB được mở. Nếu dùng Cloud MCP, chỉ cần 1 Server kết nối DB, phục vụ cho 100 người. Tiết kiệm và an toàn hơn hẳn.
- 🔔 Khả năng "Chủ động" (Push Notification): Đây là "vũ khí bí mật" của SSE.
- API thường: AI phải hỏi liên tục "Giá có đổi không? Giá có đổi không?".
- MCP SSE: Server nằm im, khi nào giá sập, nó tự động bắn tin nhắn: "Ê AI, giá cổ phiếu vừa sập nè, báo cho user đi!". Trải nghiệm Real-time cực tốt.
4. Roadmap: Từ vọc vạch đến Enterprise
Nếu bạn muốn đi theo con đường chuyên nghiệp, đây là lộ trình dành cho bạn:
Giai đoạn 1: Localhost (Stdio) - "Dành cho cá nhân"
- Công nghệ: Python script thuần, chạy qua command trong config.
- Ưu điểm: Cực nhanh, code ít, bảo mật (vì không hở port ra mạng).
- Khi nào dùng: Viết tool cá nhân, môi trường Dev, test logic.
- Công nghệ: Bọc code Python của bạn trong một Web Framework (như Starlette hoặc FastAPI) có hỗ trợ endpoint /sse.
- Thách thức: Phải xử lý Authentication (Ai được quyền kết nối?), Timeout (Giữ kết nối bao lâu?), và Load Balancing.
- Khi nào dùng: Xây dựng hệ thống RAG cho cả công ty, cần quản lý tập trung.
5. Kết luận
Đừng sợ sự phức tạp của Cloud MCP. Hãy bắt đầu với Stdio để hiểu rõ logic hoạt động của các Tools.
Khi cần lên Cloud, bản chất logic (hàm lấy giá chứng khoán, hàm query DB) vẫn giữ nguyên 100%. Bạn chỉ việc thay cái "lớp vỏ" bên ngoài: từ lớp vỏ Stdio sang lớp vỏ Web Server (SSE).
#MCP #CloudArchitecture #SSE #SystemDesign devops #EnterpriseAI