MCP Stateless یعنی هر درخواست اطلاعات لازم برای پردازش را همراه دارد و نمونه سرور به حافظه محلی درخواست قبلی وابسته نیست. این مدل مقیاس افقی و بازیابی را سادهتر میکند، اما همه MCP Serverها ذاتاً بدون وضعیت نیستند.
Stateless و Stateful چه تفاوتی دارند؟
| موضوع | Stateless | Stateful |
|---|---|---|
| مقیاس | توزیع ساده بین Replicaها | نیازمند Session routing یا Store مشترک |
| بازیابی | نمونه جایگزین درخواست بعدی را میگیرد | وضعیت باید بازیابی شود |
| مناسب | Toolهای کوتاه و مستقل | Stream و Session طولانی |
وضعیت را کجا نگه داریم؟
Credential را در Secret، Session ماندگار را در PostgreSQL یا Store مشترک و Cache کوتاه را در Redis بگذارید. فایل محلی کانتینر برای وضعیت لازم production مناسب نیست.
MCP Server را با Health Check و Worker جدا اجرا کنید.
Secret، Session Store، لاگ و مقیاس را متناسب با Toolها تنظیم کنید.
امنیت و احراز هویت
- Token کوتاهعمر و Scope محدود
- اعتبارسنجی Origin و ورودی Tool
- Rate Limit برای کاربر و Tool
- مسدودکردن شبکه خصوصی و metadata
- Audit بدون ذخیره Secret
استقرار روی PaaS
یک MCP Server HTTP را مانند API معمولی با Health Check و چند Replica اجرا کنید. Worker طولانی را جدا سازید و Retry را idempotent کنید. هاست AI Agent پاستا برای API، Worker و داده مسیر مستقل میدهد.
استاندارد و سازگاری
نسخه Transport و Client را Pin کنید. پشتیبانی Stateless در خبر رسمی GitHub MCP Server نمونهای از حرکت اکوسیستم است، اما قرارداد Server خودتان را با Conformance Test بسنجید.
Stateless دقیقاً چه چیزی را حذف میکند؟
Stateless به این معنا نیست که برنامه هیچ دادهای ندارد. سرور فقط برای پردازش درخواست بعدی به RAM یا دیسک محلی همان Replica وابسته نیست. Session، مجوز و نتیجه Task میتوانند در Store مشترک باشند. در نتیجه Load Balancer هر درخواست را به Replica سالم میفرستد و Restart یک نمونه، وضعیت کسبوکار را پاک نمیکند.
انتخاب معماری بر اساس نوع Tool
| نوع Tool | معماری مناسب | Store |
|---|---|---|
| محاسبه کوتاه و مستقل | Stateless HTTP | بدون Session یا Cache کوتاه |
| جستوجوی داده مجاز | Stateless با Auth | PostgreSQL و Policy دسترسی |
| کار چنددقیقهای | API + Queue + Worker | Task Store مشترک |
| Stream یا Session طولانی | Stateful کنترلشده | Session مشترک و reconnect |
الگوی استقرار روی پاستا
MCP Server HTTP را روی هاست AI Agent پاستا با Health Check اجرا کنید. API فقط درخواست را اعتبارسنجی و Task را ثبت کند. Worker جدا ابزار طولانی را اجرا کند و وضعیت در PostgreSQL مدیریتشده بماند. Cache و قفل کوتاهعمر را میتوان در Redis گذاشت؛ فایل محلی کانتینر محل Session ماندگار نیست.
- endpoint سلامت را از endpoint Tool جدا کنید.
- Replica API را بدون Sticky Session آزمایش کنید.
- در میانه Task یک Worker را Restart و ادامه یا Retry کنترلشده را بررسی کنید.
- Credential هر Tool را در Secret مستقل قرار دهید.
- برای مصرف مدل، کلید جدا از پنل AI بسازید.
Idempotency و Retry
Client ممکن است بعد از قطع ارتباط نداند درخواست اجرا شده یا نه. هر فرمان نوشتن باید یک شناسه یکتا داشته باشد. سرور پیش از اجرا Store را بررسی میکند؛ اگر نتیجه قبلاً ثبت شده، همان را برمیگرداند. این الگو برای ارسال پیام، ساخت منبع و عملیات مالی ضروری است. Retry کور فقط احتمال اثر تکراری را بیشتر میکند.
احراز هویت و مرز شبکه
Token کوتاهعمر را به Scope مشخص Tool محدود کنید. شناسه Tenant را از Token معتبر بگیرید، نه از فیلد دلخواه مدل. URL ورودی برای Fetch باید allowlist و در برابر SSRF محافظت شود. پاسخ Tool هم ممکن است حاوی دستور مخرب باشد؛ آن را داده در نظر بگیرید، نه دستور سیستمی.
مشاهدهپذیری
برای هر درخواست یک Trace ID از Client تا Worker و Tool نگه دارید. زمان صف، زمان اجرا، تعداد retry، وضعیت مدل و پاسخ نهایی را ثبت کنید. Log نباید Authorization، Secret یا متن کامل داده مشتری را نگه دارد. داشبوردی بسازید که نرخ خطا را به تفکیک Tool نشان دهد؛ میانگین کلی خطای یک Tool مشکلدار را پنهان میکند.
آزمون ظرفیت و خرابی
پیش از افزایش Replica، Store مشترک و API خارجی را زیر بار بسنجید. سپس Restart، timeout و قطع دیتابیس را شبیهسازی کنید. موفقیت معماری Stateless زمانی ثابت میشود که درخواست بعدی روی Replica دیگر ادامه پیدا کند و اثر تکراری نسازد، نه صرفاً وقتی دو کانتینر روشناند.