Gateway Offloading pattern.md

‏Gateway Offloading pattern عملکرد سرویس مشترک یا تخصصی را به‌صورت یک پروکسی gateway بارگیری کنید. این الگو می‌تواند توسعه برنامه را با انتقال عملکرد سرویس مشترک، مانند استفاده از گواهی‌‌های SSL، از سایر بخش‌‌های برنامه به درون gateway ساده کند.

 

زمینه و مشکل

  برخی از ویژگی‌ها به طور معمول در چندین سرویس استفاده می‌شوند و این ویژگی‌ها نیاز به پیکربندی، مدیریت و نگهداری دارند. یک سرویس توزیع شده به‌صورت اشتراکی یا خاص با هر deploy شدن مجدد برنامه سربار اجرایی و خطای deployment را افزایش می‌دهد. هرگونه به‌روزرسانی برای یک ویژگی اشتراکی باید در همه سرویس‌‌هایی که آن ویژگی را به اشتراک می‌گذارند، اجرا شود.

  مدیریت صحیح مسائل امنیتی (تأیید اعتبار رمز، رمزگذاری، مدیریت گواهینامه SSL) و سایر تسک‌‌های پیچیده می‌تواند به اعضای تیمی نیازمند شود که مهارت‌های بسیار تخصصی داشته باشند. به‌عنوان‌مثال، گواهی موردنیاز یک اپلیکیشن باید پیکربندی و در تمام نمونه‌های برنامه مستقر شود. با هر deployment جدید، این گواهی‌ها باید مدیریت شود تا از منقضی نشدن آن اطمینان حاصل شود. هر گواهی متداول که به‌زودی منقضی می‌شود باید در هر deployment برنامه به‌روزرسانی و آزمایش و تأیید شود.

  سایر سرویس‌‌های رایج مانند authentication, authorization, logging, monitoring یا throttling ممکن است برای پیاده‌سازی و مدیریت در تعداد زیادی از deploymentها دشوار باشد. شاید بهتر باشد که این نوع عملکرد را یکپارچه کنید تا سربار و احتمال خطا کاهش یابد.

 

راه‌حل:

  برخی از ویژگی‌ها را در یک gateway بارگذاری کنید، به‌ویژه نگرانی‌هایی مانند مدیریت گواهی، احراز هویت، خاتمه زمانی SSL، مانیتورینگ، ترجمه پروتکل‌ها یا throttling.

  نمودار زیر gateway ای را نشان می‌دهد که اتصالات SSL ورودی را خاتمه می‌دهد. داده‌ها را از طرف درخواست‌کننده اصلی از هر سرور HTTP بالادست gateway درخواست می‌کند.

 

    مزایای این الگو عبارت‌اند از:

  -‏ توسعه serviceها را با حذف نیاز به توزیع و نگهداری منابع پشتیبانی، مانند گواهی‌‌های وب سرور و پیکربندی برای وب‌سایت‌‌های امن را ساده کنید. پیکربندی ساده‌تر منجر به مدیریت و مقیاس‌پذیری آسان‌تر می‌شود و ارتقای سرویس‌ها را ساده‌تر می‌کند.

  -‏ به تیم‌‌های تخصصی اجازه دهید تا ویژگی‌‌هایی را اجرا کنند که به تخصصی خاصی مانند امنیت نیاز دارند. این به تیم اصلی شما اجازه می‌دهد تا روی عملکرد برنامه تمرکز کند و این نگرانی‌های تخصصی اما مقطعی را به کارشناسان مربوطه واگذار کند.

  -‏ برای ثبت request و logging و response و monitoring مقداری ثبات و صبر داشته باشید. حتی اگر یک سرویس به‌درستی تنظیم نشده باشد، gateway را می‌توان برای اطمینان از حداقلی سطح monitoring و logging پیکربندی کرد.

 

مسائل و ملاحظات:

  -‏ اطمینان حاصل کنید که gateway بسیار در دسترس است و در برابر failure و خطا مقاوم است. با اجرای چندین نمونه از gateway خود از نقاط failure اجتناب کنید.

  -‏ اطمینان حاصل کنید که gateway برای capacity و scaling موردنیاز برنامه و endpoints شما به‌درستی طراحی شده است. اطمینان حاصل کنید که gateway به یک bottleneck برای برنامه تبدیل نمی‌شود و به‌اندازه کافی مقیاس‌پذیر (scalable) است.

  -‏ فقط ویژگی‌هایی را بارگیری کنید که توسط کل برنامه استفاده می‌شود، مانند امنیت یا انتقال داده.

  -‏ مورد Business logic هرگز نباید در gateway بارگذاری شود.

  -‏ اگر نیاز به ردیابی و track کردن تراکنش‌ها دارید، شناسه‌‌های (IDs) منحصربه‌فردی را برای اهداف ورود به سیستم ایجاد کنید.

 

چه زمانی از این الگو استفاده کنیم؟

  از این الگو زمانی استفاده کنید که:

  -‏ استقرار (deployment) برنامه یک نگرانی مشترک مانند گواهینامه‌های SSL یا رمزگذاری دارد.

  -‏ یک ویژگی که در بین deployment برنامه‌‌هایی که ممکن است نیازمندی منابع متفاوتی داشته باشند، مانند منابع حافظه، ظرفیت ذخیره‌سازی یا اتصالات شبکه، رایج است.

  -‏ زمانی که می‌خواهیم مسئولیت مسائلی مانند امنیت شبکه، throttling، یا سایر نگرانی‌های مربوط به مرز شبکه را به یک تیم تخصصی‌تر منتقل کنید.

  این الگو در حالت اتصال محکم به سرویس‌‌های میانی مناسب نیست.

 

مثال:

  با استفاده از Nginx به‌عنوان ابزار offload SSL، پیکربندی زیر یک اتصال SSL ورودی را خاتمه می‌دهد و اتصال را به یکی از سه سرور HTTP بالادستی توزیع می‌کند.

upstream iis {
        server  10.3.0.10    max_fails=3    fail_timeout=15s;
        server  10.3.0.20    max_fails=3    fail_timeout=15s;
        server  10.3.0.30    max_fails=3    fail_timeout=15s;
}

server {
        listen 443;
        ssl on;
        ssl_certificate /etc/nginx/ssl/domain.cer;
        ssl_certificate_key /etc/nginx/ssl/domain.key;

        location / {
                set $targ iis;
                proxy_pass http://$targ;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
        }
}

در Azure، با تنظیم setting up SSL termination on Application Gateway می‌توان به این امر دست‌یافت.

منابع مرتبط:

• Backends for Frontends pattern
• Gateway Aggregation pattern
• Gateway Routing pattern