MCP Gateway: o, ChatGPT ilə sizin servisləriniz arasında niyə lazımdır

1. Ümumiyyətlə niyə daha bir qat lazımdır?

Demək olar ki, hamı eyni cür başlayır: bir MCP serveriniz olur, o, bir neçə aləti təsvir edir, ChatGPT ona birbaşa HTTPS ilə müraciət edir və elə bil ki, hər şey əladır. Şərti arxitektura belə görünür:

ChatGPT  →  sizin MCP serveriniz  →  verilənlər bazası / xarici API-lər

“pet project” mərhələsində bu, həqiqətən normal seçimdir. Amma tətbiq funksional baxımdan böyüməyə, komanda isə genişlənməyə başlayan kimi problemlər çox tez üzə çıxır.

Birincisi, MCP serveri “God‑object”ə çevrilir. Orada eyni anda həm hədiyyə seçimi alətləri, həm checkout, həm analitika, həm də “gəlin bura da hesabatı soxaq” tipli nələrsə yaşayır. Koddakı müxtəlif hissələrin SLA-ları və təhlükəsizlik tələbləri fərqlidir, amma hamısı bir prosesdə yapışdırılıb.

İkincisi, ChatGPT və digər müştərilər sizin servislərinizin topologiyasını bilməyə məcbur olur. Məsələn, yarım ildən sonra commerce üçün əlavə bir MCP serveri yaranarsa, müştəriləri yenidən qoşmalı, konfiqləri və təsvirləri dəyişməli olacaqsınız. “Vahid giriş nöqtəsi” əvəzinə URL‑lərin zooparkı alınır.

Üçüncüsü, hamı üçün ümumi olan şeyləri harada reallaşdırmağın düzgün olduğu anlaşılmaz olur: autentifikasiya, loglama, metriklər, rate limiting, token yoxlaması, lokallaşdırma və regionlara görə marşrutlaşdırma. Bunu bütün MCP/Agent servislərinə səpsəniz, çoxlu dublikat və servislər arasında fərqli davranışlar əldə edəcəksiniz.

Bu sıx bağlılığı qırmaq və eyni zamanda ChatGPT‑dən daxili mürəkkəbliyi gizlətmək üçün oyuna MCP Gateway daxil olur — MCP trafiki üçün şəbəkə şlyuzu və vahid giriş nöqtəsi.

2. ChatGPT App kontekstində MCP Gateway nədir

Formal olaraq MCP Gateway — MCP müştəriləri (ChatGPT, MCP Jam, sizin daxili alətləriniz) ilə sizin backend servislərinizin toplusu arasında proksi qatı və vahid giriş nöqtəsidir — adətən bunlar REST/HTTP‑API, mikroservislər, Agents servisləri, commerce‑backend və s. olur.

Gateway özü kənara MCP protokolunu təqdim edir (ChatGPT üçün o, tək bir MCP serveri kimi görünür), içəridə isə sadəcə adi REST endpoint‑lərə HTTP/gRPC ilə gedir.

tools/list sorğusunda gateway çağırışı içəri proksi etmir, öz alətlər siyahısını qaytarır: o, ya kodda sərt təsvir olunub, ya da konfiqurasiyadan yığılır. Hər bir alət konkret REST endpoint‑ə və verilənlər sxeminə bağlıdır. tools/call sorğusunda gateway alətin adını götürür, uyğun REST marşrutunu tapır və onu fetch/HTTP müştərisi ilə çağırır.

Sxematik olaraq bunu belə təsəvvür etmək olar:

flowchart LR
    ChatGPT["ChatGPT / model"] --> |MCP JSON-RPC| Gateway["MCP Gateway<br/>(yeganə MCP serveri)"]
    Gateway --> GiftAPI["Gift REST API<br/>/ hədiyyələr mikroxidməti"]
    Gateway --> CommerceAPI["Commerce REST API<br/>/ ACP / ödənişlər"]
    Gateway --> AnalyticsAPI["Analytics Service<br/>/ hadisələr və metriklər"]

ChatGPT üçün bu tək serverdir: bir URL, bir alətlər dəsti, bir hadisə axını. Sizin üçün — müxtəlif “soyuq” və “isti” servislərə trafiki marşrutlaşdırmaq üçün çevik bir nöqtə.

3. GiftGenius arxitekturasında MCP Gateway

Abstraksiyadan az danışmaq və gateway‑i “canlı sistemdə” göstərmək üçün GiftGenius nümunəmizi davam etdirək — hədiyyələri seçən və ACP/Instant Checkout vasitəsilə sifarişləri rəsmiləşdirə bilən tətbiq.

Sadə versiyada bizdə həm suggest_gifts, həm də checkout_start edə bilən bir MCP serveri var idi. İndi tətbiq böyüdükcə vəzifələri ayırırıq:

• Gift REST API — hədiyyələrin axtarışı və tövsiyələri, kataloq və feed ilə iş (adi HTTP/REST servis).
• Commerce REST API — ACP, checkout sessiyaları, sifariş statusları, ödəniş provayderi ilə əlaqə.
• Analytics Service / REST API — hadisələrin və metriklərin toplanması (hansı seçimlər açılır, nə alınır).
• Ayrı Agents servisi (lazımdırsa) — mürəkkəb çoxaddımlı ssenarilər. O da MCP deyil, HTTP/REST ilə əlçatandır.

MCP Gateway bu komponentlərin hamısı üçün vahid giriş nöqtəsinə çevrilir. O:

• sorğuda tools/list alətlərin vahid siyahısını qaytarır və onu özü təsvir edir: hər alət servislərdən birinin konkret REST endpoint‑inə bağlıdır;
• sorğuda tools/call alətin adına (params.name) baxır, marşrutlaşdırma cədvəlinə əsasən hansı REST servisinə getməli olduğunu müəyyənləşdirir və uyğun HTTP metodunu çağırır (fetch, axios və s. vasitəsilə).

Əgər tools/call suggest_gifts adı ilə gəlirsə, gateway Gift REST API‑də uyğun REST endpoint‑i çağırır. Əgər bu, checkout_start‑dırsa, sorğu Commerce REST API‑yə gedəcək.

Express üslubunda TypeScript üzrə kiçik pseudo‑kod belə görünə bilər:

// MCP sorğularının çox sadə emalçısı
app.post("/mcp", async (req, res) => {
  const mcpReq = req.body as { method: string; params?: any };
  const ctx = buildContextFromHeaders(req); // auth, locale və s.

  const toolName = mcpReq.params?.name;
  const backendRes = await callBackend(toolName, mcpReq, ctx);

  res.json(backendRes);
});

Daxildə pickBackend metodunda siz metod adından, alət adından, istifadəçinin lokalından və hətta servisin versiyasından (bu modulda sonra danışacağımız “canary” və blue/green relizlər üçün) istifadə edə bilərsiniz.

4. MCP Gateway‑in öhdəlikləri: o, dəqiq nə edir

Gateway‑in GiftGenius arxitekturasına necə oturduğuna baxdıq. İndi isə konkret tətbiqdən asılı olmayaraq, ayrıca qat kimi onun hansı öhdəlikləri olduğunu dəqiq qeyd edək. Gateway‑i şəbəkə və kross‑servis qat kimi qavramaq vacibdir. Onun vəzifəsi — hədiyyələrin biznes məntiqi haqqında düşünmək yox, onların ətrafındakı infrastruktur vəzifələrini həll etməkdir.

Sorğuların marşrutlaşdırılması

Birinci rol — marşrutlaşdırıcı. Gateway MCP sorğusunu qəbul edir və onun məzmununa, istifadəçi kontekstinə və öz konfiqurasiyasına əsasən hədəf servisi seçir.

Məsələn, GiftGenius‑də sadə bir marşrutlaşdırma cədvəli yarada bilərsiniz:

const TOOL_ROUTES: Record<string, "gift" | "commerce" | "analytics"> = {
  suggest_gifts: "gift",
  get_similar_gifts: "gift",
  checkout_start: "commerce",
  get_order_status: "commerce",
  log_event: "analytics",
};

Və sonra ondan istifadə edin:

function pickBackend(req: McpRequest, ctx: GatewayContext): Backend {
  if (req.method === "tools/list") return "aggregator";
  if (req.method === "tools/call") {
    const toolName = req.params?.name;
    const group = TOOL_ROUTES[toolName] ?? "gift";
    return group === "commerce" ? commerceBackend : giftBackend;
  }
  return giftBackend;
}

Bizim halda giftBackend, commerceBackend, analyticsBackend — bunlar adi REST servisləridir: hər birinin baza URL‑i var ("https://gift-api.internal", "https://commerce-api.internal", …). Gateway MCP‑ni içəri ötürmür, MCP çağırışını lazımi REST endpoint‑ə HTTP sorğusuna çevirir.

Perimetrdə autentifikasiya və avtorizasiya

İkinci əsas funksiya — perimetrin qorunması. Gateway — tokeni yoxlamaq, istifadəçinin kim olduğunu, hansı təşkilatdan gəldiyini və hansı icazələrə (permissions) malik olduğunu anlamaq üçün əlverişli yerdir.

Məsələn, o, ChatGPT‑dən və ya sizin MCP Auth serverinizdən OAuth tokenini qəbul edə, onu valıdasiya edə bilər (üstünlük verilən kitabxana ilə, özəl kripto yazmadan) və səliqəli kontekst obyektinə çevirə bilər:

type GatewayContext = {
  userId: string | null;
  tenantId: string | null;
  locale: string;
};

function buildContextFromHeaders(req: Request): GatewayContext {
  const token = req.headers["authorization"]; // "Bearer ..."
  const claims = token ? verifyJwt(token) : null;

  return {
    userId: claims?.sub ?? null,
    tenantId: claims?.tenant ?? null,
    locale: (req.headers["x-openai-locale"] as string) || "en-US",
  };
}

Daxili backend/REST servisləri onda xam HTTP başlıqlarını və tokenləri açmaqla əlləşməyəcək, artıq normallaşdırılmış context alacaq: userId, tenantId və locale ilə. MCP sənədləri birbaşa tövsiyə edir: tokenlərin valıdasiyasını “sıfırdan” etməyin, sınanmış kitabxanalardan və qısaömürlü tokenlərdən istifadə edin.

Loglama, treysinq və metriklər

Üçüncü rol — müşahidə olunma. Gateway bütün daxil olan MCP sorğularını və cavablarını görür, buna görə correlation‑id qoymaq, alət parametrlərini (həssas məlumatlar olmadan) loglamaq, cavab vaxtını və statusu yazmaq üçün ideal yerdir.

Ən sadə ideya:

app.use((req, res, next) => {
  const requestId = crypto.randomUUID();
  (req as any).requestId = requestId;

  const start = Date.now();
  res.on("finish", () => {
    const ms = Date.now() - start;
    console.log(
      `[${requestId}] ${req.method} ${req.url} -> ${res.statusCode} in ${ms}ms`
    );
  });

  next();
});

Modulun müşahidə olunma hissəsində bu məlumatları sadəcə console.log‑a deyil, strukturlaşdırılmış saxlanmaya göndərə biləcək və onlar üzrə dashboardlar qura biləcəksiniz.

Yükün əsas nəzarəti

Dördüncü, amma vacib vəzifə — ilkin yük nəzarəti. Gateway‑də istifadəçilər, təşkilatlar, alətlər və endpointlər üzrə çağırış sayğacları qoymaq rahatdır ki, bir “çılğın” müştəri sizin klasterinizi və model büdcənizi yandırmasın.

Bu modulda hələ ki, ideyanı sabitləşdiririk: rate limiting və növbələr gateway səviyyəsində yaşayır, reallaşdırma detallarını (Redis, token bucket, leaky bucket) perimetrin qorunması haqda növbəti mühazirədə araşdıracağıq.

Sorğuların kontekstlə zənginləşdirilməsi

Və nəhayət, gateway — MCP müştərisinin xam kontekstini daxili alətlər üçün səliqəli arqumentlərə çevirmək üçün yaxşı bir yerdir.

Məsələn, ChatGPT istifadəçinin lokalını openai/locale və _meta["openai/userLocation"] vasitəsilə ötürə bilər. Gateway bunları edə bilər:

• lazımi regional servisi seçmək (ru server, en server və s.);
• locale‑u alət çağırışının arqumentlərinə əlavə etmək, alətin JSON Schema‑da bunu açıq şəkildə tələb etmədiyi halda belə (məsələn, ixtiyari sahə kimi).

Şərti olaraq:

function enrichToolArgs(args: any, ctx: GatewayContext) {
  return {
    ...args,
    locale: args.locale ?? ctx.locale,
    tenantId: ctx.tenantId,
  };
}

Nəticədə Gift API dərhal “zəngin kontekst” alır və məsələn, "ru-RU" üçün hədiyyələrin rus dilində, "en-US" üçün isə ingiliscə təsvirlərini çəkə bilər.

5. MCP Gateway nə ETMƏMƏLİDİR

İnkişaf etdiricinin “hər şeyin keçdiyi sehrli yer”i olanda, o, əvvəl ayrı servislərdə olan hər şeyi bura da yığmaq istəyə bilər. Beləcə gateway monstra çevrilə bilər.

Bu qatda, qayda olaraq, yaşamamalı olan bir neçə şey var.

Birincisi, mürəkkəb biznes məntiqi. Hədiyyə seçimi, endirim qaydaları, çatdırılma qiymətinin hesablanması, ACP məntiqi — bunların hamısı ixtisaslaşmış backend/commerce servislərinin içində qalmalıdır. Gateway maksimum yüngül ilkin validasiya edə bilər (məsələn, qiymətin mənfi olmadığını yoxlamaq), amma SKU seçməməli və regionlara görə vergi hesablamamalıdır.

İkincisi, uzunömürlü istifadəçi vəziyyəti (state). Gateway tipik stateless servistir. O, yanlayına (horizontal) asan miqyaslana bilməli, lokal yaddaşa güvənməməli və fəsadsız yenidən işə düşməlidir. Əgər orada, məsələn, checkout sehrbazının vəziyyətini və ya səbətin müvəqqəti məzmununu saxlamağa başlasanız, instanslar arasında sinxronizasiya ağrıları sürətlə yaranacaq.

Üçüncüsü, ixtisaslaşmış funksiyalar, hansı ki, məntiqli olaraq servislərin özündə (Gift API, Commerce API) yerləşməlidir. Məsələn, əgər Gift backend hədiyyə axtarışının nəticələrini keşləmək istəyirsə, qoy bunu özü etsin, lazım gələrsə Redis istifadə etsin. Gateway bu daxili optimizasiyanı bilməli deyil. Perimetrin qorunması barədə ayrıca danışacağıq və məhz orada vurğulanır: şlyuz şəbəkə və kross‑servis funksiyaları üçündür, tövsiyə biznes qaydaları üçün deyil.

Dördüncüsü, ağır hesablamalar. Gateway daxilində LLM modellərini çağırmağa, mürəkkəb transformasiyalar və aqreqasiyalar etməyə başlasanız, o, “yüngül” ön qat olmaqdan çıxar və miqyaslamaq və sazlamaq çətin olan daha bir “qalın” backend‑ə çevrilər.

6. Gateway, lokallaşdırma və servis versiyaları

Gateway‑in əsas öhdəliklərini və ora nəyi qoymamağın daha yaxşı olduğunu müzakirə etdik. İndi isə məhz bu qatda rahat həll olunan iki tipik “qabaqcıl” vəzifəyə baxaq: lokallaşdırma və servis versiyalaşdırması. Gateway‑in daha bir maraqlı rolu — lokala və servislərin versiyalarına görə ağıllı routringdir.

ChatGPT sizin App‑i çağıranda, onda artıq istifadəçinin dilinə dair təsəvvür olur (openai/locale) və tez‑tez onun geolokasiyasına dair də olur (_meta["openai/userLocation"]). Gateway bu məlumatdan istifadə edərək sorğuları lazımi backend servislərinə göndərə bilər.

Məsələn, “bir gateway — çox monodil backend serverləri” arxitekturasını qura bilərsiniz:

• ru‑Gift API — yalnız rus dilində hədiyyə kataloqu və mətnlər.
• en‑Gift API — yalnız ingilis dili.
• jp‑Gift API — yapon dili (dünyanı fəth etməyə qərar verəndə).

Bu halda Gateway ChatGPT üçün MCP serveri kimi çıxış edir və locale və userLocation üzrə lazımi daxili servisi seçir.

Şərti olaraq:

function pickGiftBackendByLocale(ctx: GatewayContext): Backend {
  if (ctx.locale.startsWith("ru")) return giftRuBackend;
  if (ctx.locale.startsWith("ja")) return giftJpBackend;
  return giftEnBackend;
}

Elə orada ən sadə canary routringini də reallaşdırmaq rahatdır. Production arxitekturası barədə bu modulda məhz gateway‑dən istifadə etməyi təklif edirik ki, trafikin bir hissəsini servisin yeni klasterinə, qalanını isə köhnəsinə göndərək.

Çox kobud canary nümunəsi:

function pickGiftBackendCanary(ctx: GatewayContext): Backend {
  const hash = hashUser(ctx.userId ?? "anonymous");
  const bucket = hash % 100;
  return bucket < 5 ? giftBackendV2 : giftBackendV1; // trafikin 5%-i v2-yə gedir
}

Beləcə Gift API‑nin yeni versiyasını metriklərə və xətalara baxaraq təhlükəsiz şəkildə buraxa bilərsiniz, bütün produ birdən sındırmadan.

7. Tipik arxitekturalar: “hamısı bir yerdə”dən Gateway‑ə

Kursda daha əvvəl ChatGPT App üçün bir neçə production arxitektura variantı görmüsünüz. Bu modulda 90% hallarda kifayət edən üç baza topologiyanı ayırırıq.

Birincisi — “hamısı bir yerdə”. App vidcet (Next.js), MCP serveri, Agents məntiqi və sadə commerce backend bir servis daxilində, çox vaxt bir repozitoriyada və hətta bir Vercel tətbiqində yaşayır. Bu yanaşmanın üstünlüyü — demək olar ki, DevOps yoxdur, deploy sadədir, gecikmə minimaldır. Mənfi tərəfi — ayrı hissələri miqyaslamaq çətindir, bir “isti” xüsusiyyət bütün tətbiqi yıxa bilər və komponentlər arasındakı sərhədlər bulanıqdır.

İkincisi — App + MCP Gateway + bir neçə backend servisi. Burada Next.js vidceti ayrı yaşayır (məsələn, Vercel‑də), bütün MCP trafiki isə Gift REST API, Commerce REST API, Agents xidməti, ACP backend və digərlərinə sorğuları marşrutlaşdıran Gateway vasitəsilə gedir. Bu, məhz indi GiftGenius çərçivəsində müzakirə etdiyimiz və real production halların 90%‑nə uyğun olan sxemdir.

Üçüncüsü — eynisi, amma bir neçə regionda (multi‑region), gateway qarşısında qlobal balanslaşdırıcı ilə. Onda Avropadan olan istifadəçi eu klasterinə, ABŞ‑dan olan isə us klasterinə düşür, hər region isə “Gateway + bir neçə backend servisi” sxemi ilə qurulur. Bu, artıq qlobal auditoriyalı kifayət qədər böyük layihələr üçün hekayədir.

Bizim üçün indi bütün variantları əzbərləməkdən çox, gateway‑i arxitekturanın ayrıca məntiqi komponenti kimi düşünməyə öyrəşmək vacibdir, hətta ilk mərhələlərdə onun rolunu, tutalım, bir MCP monolit və ya App‑inizin backend hissəsi oynasa belə.

8. MCP Gateway fiziki olaraq harada yaşayır

Yaxşı xəbər: MCP Gateway mütləq Kubernetes üzərində böyük ayrı servis deyil. Çox vaxt o, bir neçə yetkinlik mərhələsindən keçir.

Ən kiçik miqyasda gateway rolunu elə MCP serveri özü oynaya bilər. Bu halda sadəcə kodu səliqəli strukturlamaq lazımdır: marşrutlaşdırmanı, autentifikasiya və loglamanı bir modulda, alət məntiqini isə başqa modullarda saxlamaq. Bu modulda açıq şəkildə qeyd edirik ki, kiçik sistemlərdə gateway funksiyaları MCP serverinin içində və ya App‑in backend hissəsində (məsələn, Next.js API route‑da) ola bilər.

Növbəti addım — ayrıca Node/TypeScript servisi. Bu, "/mcp" dinləyən və içəridə bir neçə HTTP servisinə gedən Express/Fastify tətbiqi ola bilər. Bir çox komandalar üçün bu rahat variantdır: o, adət edilmiş DevOps alətlərinə yaxşı oturur.

Belə servisin ən sadə skeleti:

const app = express();
app.use(express.json());

app.post("/mcp", handleMcpRequest); // gateway sehrinin hamısı burada

app.listen(4000, () => {
  console.log("MCP Gateway listening on :4000");
});

Daha yetkin mərhələdə gateway‑i idarə olunan həllər üzərində reallaşdırmaq olar: AWS API Gateway, Cloudflare Workers/Routes, NGINX/Envoy marşrutlaşdırma konfiqi və Lua/JS skriptləri ilə. Anlamaq vacibdir ki, bu, konsepsiya deyil, reallaşdırma dəyişikliyidir. Arxitektura baxımından ChatGPT yenə də bir nöqtəyə gedir və bütün detallar gateway tərəfindən açılır.

9. Mini‑nümunə: GiftGenius üçün sadə MCP Gateway

Artıq marşrutlaşdırmaya, kontekstə və tools/list işlənməsinə ayrıca baxmışdıq. İndi deyilənlərin hamısını bir kiçik, amma dəqiq nümunədə toplayaq. Gəlin, iki daxili REST servisin olduğunu fərz edək:

• GIFT_API_BASE = "https://gift-api.internal";
• COMMERCE_API_BASE = "https://commerce-api.internal".

Və bir gateway, ChatGPT isə ona "https://gateway.giftgenius.com/mcp" ünvanı ilə müraciət edir.

Əvvəlcə bir neçə tipi təyin edək:

type Backend = "gift" | "commerce";

type ToolRoute = {
  backend: Backend;
  method: "GET" | "POST";
  path: string;
};

const TOOL_ROUTES: Record<string, ToolRoute> = {
  suggest_gifts: {
    backend: "gift",
    method: "POST",
    path: "/api/gifts/suggest",
  },
  checkout_start: {
    backend: "commerce",
    method: "POST",
    path: "/api/checkout/start",
  },
  get_order_status: {
    backend: "commerce",
    method: "GET",
    path: "/api/orders/status",
  },
};

Sonra backend seçimini və çağırışı reallaşdıraq:

async function callBackend(toolName: string, mcpReq: McpRequest, ctx: GatewayContext) {
  const route = TOOL_ROUTES[toolName];
  if (!route) {
    throw new Error(`Unknown tool: ${toolName}`);
  }

  const base =
    route.backend === "gift" ? GIFT_API_BASE : COMMERCE_API_BASE;

  const url = base + route.path;

  // tools/call MCP çağırışında gələn args
  const args = {
    ...(mcpReq.params?.arguments ?? {}),
    locale: ctx.locale,
  };

  const res = await fetch(url, {
    method: route.method,
    headers: { "content-type": "application/json" },
    body: route.method === "POST" ? JSON.stringify(args) : undefined,
  });

  const data = await res.json();

  // REST servisinin cavabını MCP cavabına bükürük
  return {
    result: data,
  } satisfies McpResponse;
}

Və nəhayət, əsas işləyici, o:

1. Başlıqlardan kontekst qurur (auth, locale).
2. Backend seçir.
3. tools/list‑i ya aqreqasiya edir, ya da tools/call‑ı proksi edir.

app.post("/mcp", async (req, res) => {
  const mcpReq = req.body as McpRequest;
  const ctx = buildContextFromHeaders(req);

  if (mcpReq.method === "tools/list") {
    // Gateway alətləri və onların sxemlərini özü elan edir
    const tools = [
      {
        name: "suggest_gifts",
        description: "Büdcəyə və maraqlara görə hədiyyələr seçir.",
        inputSchema: { /* ... JSON Schema ... */ },
      },
      {
        name: "checkout_start",
        description: "Sifariş üçün qara layihə yaradır və checkout-u başladır.",
        inputSchema: { /* ... */ },
      },
      // ...
    ];

    return res.json({ result: { tools } });
  }

  if (mcpReq.method === "tools/call") {
    const toolName = mcpReq.params?.name;
    const backendRes = await callBackend(toolName, mcpReq, ctx);
    return res.json(backendRes);
  }

  res.status(400).json({ error: { message: "Unsupported MCP method" } });
});

Bu, əlbəttə, sadələşdirilmiş sxemdir, amma artıq əsas ideyaları göstərir:

• gateway Gift API‑nin hədiyyələri necə seçdiyini bilmir;
• o, sadəcə səliqəli şəkildə marşrutlaşdırır, arqumentləri zənginləşdirir və istəsəniz, çağırışları loglayır və limitləyir.

10. Bunların hamısı modulun növbəti mövzuları ilə necə bağlıdır

MCP Gateway — modulun qalan mühazirələrində danışacağımız hər şeyin fundamental hissəsidir:

• Növbəti mövzuda perimetrin qorunmasından danışacağıq: rate limiting, növbələr və backpressure. Bütün bunlar ilk növbədə gateway səviyyəsində yaşayır, çünki məhz o, bütün daxil olan trafiki görür və sorğular backend‑ləri “basmadan” artıq hissəni kəsə bilər.
• Sonra dayanıqlılığı müzakirə edəcəyik: timeouts, circuit breakers, bulkheads. Gateway — xarici çağırışlara taym‑aoutları mərkəzləşdirilmiş şəkildə təyin etmək və problemli servisləri açıb‑söndürmək üçün əlverişli nöqtədir (məsələn, Commerce API xətalara gedirsə onu müvəqqəti “söndürmək”).
• Və nəhayət, miqyaslama və deploy barədə danışarkən gateway‑ə ayrıca klaster kimi baxacağıq, hansı ki, balanslaşdırıla, blue/green və canary sxemləri ilə buraxıla və daxili MCP servislərindən asılı olmadan geri qaytarıla bilər.

Əslində, əgər əvvəl “məndə App və MCP serveri var” deyirdinizsə, indi sxem “məndə App, MCP Gateway, bir neçə backend/Agents klasteri və commerce backend var”a qədər genişlənir. Və məhz gateway ChatGPT üçün konfiqurasiyanı mürəkkəbləşdirməməyə imkan verir — o, yenə də tək MCP nöqtəsini görür.

11. MCP Gateway ilə işləyərkən tipik səhvlər

Səhv №1: gateway‑i “biznes monstru”na çevirmək.
Tez‑tez rast gəlinən tələ: hər şey gateway‑dən keçirsə, niyə ora endirim hesablaması, SKU seçimi, mürəkkəb kateqoriya qaydaları və ya promokodların validasiyasını əlavə etməyək? Nəticədə miqyaslamaq və dəyişmək çətin olan “şişman” servis alırsınız və Gift API, Commerce API və digər ixtisaslaşmış komponentlərə bölməyin mənasını itirirsiniz. Gateway‑i incə şəbəkə qatı kimi saxlayın, bütün sahəyə məxsus məntiq isə profil servislərin içində qalsın.

Səhv №2: gateway‑də uzunömürlü istifadəçi vəziyyəti saxlamaq.
“Gəlin istifadəçinin səbətini elə gateway yaddaşında saxlayıb” ideyası sizdə bir instans olduqca cazibədardır. İkinci instans görünən kimi ağrı başlayır: əsl səbət A instansındadır, yoxsa B‑də? Restartdan sonra nə olacaq? Gateway stateless qalmalıdır: maksimum — kiçik handshake və ya konfiq keşləri, bütün sessiya və sifariş vəziyyəti isə DB‑də və ya ixtisaslaşmış servislərdə saxlanılır.

Səhv №3: ChatGPT‑ni daxili servis topologiyasından xəbərdar etmək.
Əgər ChatGPT‑yə bir neçə API serverini (ayrı‑ayrı Gift API, ayrı Commerce API) birbaşa ötürməyə başlayır və gateway‑dən “yerlərlə” istifadə edirsinizsə, əsas üstünlüyü itirirsiniz: vahid giriş və mərkəzləşdirilmiş nəzarət. Topologiya dəyişəndə bir neçə yerdə konfiqurasiyanı dəyişməli olacaqsınız. MCP Gateway‑i App üçün rəsmi endpoint kimi bir dəfə qurmaq və bütün daxili dəyişiklikləri onun arxasında gizlətmək daha asandır.

Səhv №4: kross‑servis məntiqini bütün backend‑lərdə təkrarlamaq.
Bəzən komandalar autentifikasiya, rate limiting, loglama və lokallaşdırmanı hər REST servisdə ayrıca reallaşdırmağa çalışırlar. Nəticədə hüquqlar və limitlər siyasəti Gift API‑də bir cür, Commerce API‑də başqa cür olur və App‑in davranışı qeyri‑proqnozlaşdırılan hala gəlir. Gateway məhz bunun üçün lazımdır ki, bu şeyləri mərkəzləşdirsin: tokeni yoxlamaq, tenant və locale müəyyənləşdirmək, çağırışı loglamaq, limitləri tətbiq etmək, sonra isə konkret servisin içinə getmək.

Səhv №5: gateway‑i ağır hesablamalar və LLM çağırışları ilə yükləmək.
Texniki baxımdan sizi gateway‑dən başqa bir LLM modelini çağırmaqdan, mürəkkəb aqreqasiyalar və ya uzun batch əməliyyatları etməkdən heç nə saxlamır. Amma bu, onu tez bir zamanda normal miqyaslana və izolyasiya oluna bilməyən daha bir ağır backend‑ə çevirəcək. Gateway sürətli və proqnozlaşdırılan qalmalıdır: maksimum yüngül transformasiya və marşrutlaşdırma. Bütün ağır şeylər — REST servislərin içinə və ya bu modulda danışacağımız növbələr/worker‑lərə.

Səhv №6: infrastrukturu çox tez mürəkkəbləşdirmək.
Əks hədd — kiçik tədris App‑i naminə dərhal ayrıca Kubernetes klasteri, NGINX stack‑i, Cloudflare Workers və bir dəstə mürəkkəb konfiqlər qurmaq. Real yük və dayanıqlılıq tələbləri olmadan bunun mənası yoxdur. Tamamilə normaldır ki, bir MCP monolit və ya sadə Node gateway ilə başlayasınız və yalnız böyüdükcə ayrı komponentləri klasterlərə və idarə olunan servislərə çıxarasınız.