درک الگوی دروازه API در Microservices: یک راهنمای ساده

انتقال از یک کاربرد واحد و یکپارچه به معماری میکروسرویس بسیاری از مشکلات را حل می کند. این به تیم ها اجازه می دهد تا به طور مستقل کار کنند، خدمات را به طور جداگانه مستقر کنند و بخش هایی از سیستم را در صورت نیاز مقیاس کنند. با این حال، چالش جدیدی را نیز معرفی می کند: ** مشتریان چگونه با این همه خدمات مستقل تعامل می کنند؟**

اگر ده، پنجاه یا صدها میکروسرویس کوچک دارید، آیا یک برنامه موبایل یا صفحه وب باید مستقیماً به هر یک از آنها متصل شود؟

اینجاست که API Gateway Pattern وارد می‌شود. در این راهنما، توضیح می‌دهیم که یک API Gateway چیست، چرا به آن نیاز دارید و چگونه سیستم میکروسرویس شما را با استفاده از کلمات ساده و تشابه‌های دنیای واقعی ساده می‌کند.

قیاس دنیای واقعی: مسئول پذیرش هتل

تصور کنید در حال ورود به یک هتل بزرگ و مجلل هستید. این استراحتگاه دارای بخش های مختلفی است:

• نظافت منزل (برای ملحفه های تمیز) *روم سرویس (برای غذا)
• دربان (برای رزرو تور)
• صورتحساب (برای پرداخت قبض)

اگر یک حوله تمیز می خواهید، در استراحتگاه قدم نمی زنید تا ساختمان خانه داری را پیدا کنید. اگر شام می خواهید، در آشپزخانه را نمی کوبید. درعوض، شما با کارشناس پذیرش میز تماس می گیرید.

مسئول پذیرش به درخواست شما گوش می دهد، تعیین می کند که کدام بخش می تواند آن را حل کند، و شما را متصل می کند یا آن را برای شما انجام می دهد.

در این سناریو:

• **شما ** مشتری (برنامه موبایل یا مرورگر) هستید.
• کارشناس پذیرش درگاه API است.
• بخش ها (خانه داری، خدمات اتاق، صورتحساب) خدمات خرد هستند.

مشکل: ارتباط مستقیم مشتری به سرویس

قبل از اینکه نگاهی به نحوه عملکرد دروازه بیندازیم، بیایید ببینیم اگر از آن استفاده نکنیم چه اتفاقی می افتد.

فرض کنید اپلیکیشن تجارت الکترونیک شما دارای سه ریزسرویس مجزا است:

1. سرویس کاربر (نمایه ها را مدیریت می کند)
2. سرویس محصول (کاتالوگ را مدیریت می کند)
3. سرویس سفارش (خروج را مدیریت می کند)

بدون API Gateway، برنامه مشتری باید درخواست‌های جداگانه را مستقیماً به آدرس جداگانه هر سرویس (IP یا URL) ارسال کند:

این رویکرد ارتباط مستقیم چندین سردرد عمده ایجاد می کند:

• نقاط پایانی خیلی زیاد: برنامه مشتری باید سه URL جداگانه را به خاطر بسپارد. اگر سرویسی را تقسیم کنید یا آدرس آن را تغییر دهید، باید برنامه مشتری را به روز کنید.
• کابوس امنیتی: هر میکروسرویس باید به طور جداگانه احراز هویت (بررسی نشانه های ورود به سیستم)، گواهینامه های SSL و قوانین فایروال را اجرا کند.
• سربار شبکه: مشتری ممکن است نیاز به سه درخواست شبکه جداگانه از طریق شبکه های تلفن همراه کند داشته باشد تا فقط یک صفحه را بارگیری کند (به عنوان مثال، واکشی نمایه، واکشی جزئیات محصول و واکشی سابقه سفارش).
• تفاوت های پروتکل: برنامه مشتری شما ممکن است استفاده از پروتکل های وب استاندارد مانند HTTP/JSON را ترجیح دهد، اما سرویس های داخلی شما ممکن است با استفاده از پروتکل های تخصصی مانند gRPC یا AMQP سریعتر ارتباط برقرار کنند.

راه حل: الگوی دروازه API

API Gateway یک سرور کمکی است که بین برنامه های مشتری و میکروسرویس های داخلی قرار می گیرد. این به عنوان تنها نقطه ورود برای همه درخواست های دریافتی عمل می کند.

به جای تماس با سه سرویس مختلف، مشتری یک تماس با دروازه API برقرار می کند. سپس دروازه درخواست را به سرویس داخلی صحیح ارسال می کند، نتایج را جمع آوری می کند و آنها را برای مشتری ارسال می کند.

مسئولیت های کلیدی یک دروازه API

یک دروازه API خیلی بیشتر از ترافیک مستقیم انجام می دهد. از “نگرانی های متقابل” مراقبت می کند - وظایفی که در غیر این صورت هر میکروسرویس باید برای آنها کد بنویسد:

1. مسیریابی: دروازه یک URL ورودی (مانند /api/v1/orders) را می گیرد و آن را به آدرس سرویس داخلی صحیح نگاشت می کند.
2. Authentication & Authorization: Gateway نشانه های امنیتی (مانند JWT) را در درب ورودی تایید می کند. اگر درخواست نامعتبر باشد، فوراً رد می‌شود و میکروسرویس‌های شما را از هدر دادن چرخه‌های CPU در درخواست‌های احراز هویت نشده نجات می‌دهد.
3. Rate Limiting: با محدود کردن تعداد درخواست هایی که کاربر در هر دقیقه می تواند ارسال کند، از ارسال هرزنامه توسط ربات های مخرب یا کلاینت های باگ جلوگیری می کند.
4. تعادل بار: دروازه می تواند ترافیک ورودی را به طور مساوی در چندین نمونه از یک میکروسرویس توزیع کند تا از بارگذاری بیش از حد هر سرور منفرد جلوگیری کند.
5. ترجمه پروتکل: می‌تواند درخواست‌های JSON کاربر را به پیام‌های gRPC داخلی با کارایی بالا ترجمه کند و به سرویس‌ها اجازه دهد به زبان‌های دلخواه خود با یکدیگر صحبت کنند.

یک پیاده سازی ساده: مثال کد

برای اینکه ببینیم مسیریابی چقدر آسان می شود، به دو روش متداول برای راه اندازی یک دروازه API نگاهی می اندازیم.

1. مسیریابی اعلانی (Spring Cloud Gateway YAML)

در سیستم های جاوا سازمانی، شما اغلب مسیریابی را با استفاده از یک فایل پیکربندی ساده پیکربندی می کنید. دروازه به طور خودکار درخواست ها را بر اساس این قوانین ارسال می کند:

spring:
  cloud:
    gateway:
      routes:
        - id: user_service_route
          uri: http://internal-user-service:8081
          predicates:
            - Path=/api/users/**
        - id: product_service_route
          uri: http://internal-product-service:8082
          predicates:
            - Path=/api/products/**

2. مسیریابی برنامه‌ای (مکاپ دروازه Node.js)

اگر می خواهید با استفاده از Express یک API Gateway سبک وزن در جاوا اسکریپت بسازید، به نظر می رسد:

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 3000;

// 1. Simple Security/Authentication Check at the door
const authenticate = (req, res, next) => {
    const token = req.headers['authorization'];
    if (token === 'secret-handshake-token') {
        next(); // Token is valid, proceed
    } else {
        res.status(401).json({ error: 'Unauthorized Access!' });
    }
};

// Apply auth check to all incoming gateway requests
app.use(authenticate);

// 2. Route requests to correct internal microservices
app.use('/api/users', createProxyMiddleware({ target: 'http://localhost:8081', changeOrigin: true }));
app.use('/api/products', createProxyMiddleware({ target: 'http://localhost:8082', changeOrigin: true }));
app.use('/api/orders', createProxyMiddleware({ target: 'http://localhost:8083', changeOrigin: true }));

app.listen(PORT, () => {
    console.log(`API Gateway running smoothly on port ${PORT}`);
});

مزایا و معایب الگوی دروازه API

مانند هر تصمیم معماری، استفاده از دروازه API دارای معاوضه هایی است:

نتیجه گیری

الگوی دروازه API سنگ بنای معماری میکروسرویس های مدرن است. با عمل به عنوان یک نقطه ورود هوشمند، از برنامه های مشتری در برابر پیچیدگی تنظیمات سرویس داخلی محافظت می کند. کد سمت کلاینت را ساده می کند، امنیت را متمرکز می کند و مدیریت ترافیک را به طور موثر مدیریت می کند.

در حالی که یک پرش شبکه کوچک را معرفی می کند و نیاز به راه اندازی با در دسترس بودن بالا در تولید دارد، مزایای پایگاه های کد تمیزتر، ایمن تر و قابل مدیریت آن را به یک الگوی بسیار توصیه شده برای هر سیستم توزیع شده در حال رشد تبدیل می کند.

درباره توسعه نرم‌افزار بیشتر و بینش‌های مهندسی باطن در Ghaznix Blog →