Skip to content

Latest commit

 

History

History
156 lines (106 loc) · 12.9 KB

Gateway Routing pattern.md

File metadata and controls

156 lines (106 loc) · 12.9 KB

‏Gateway Routing pattern

در این الگو باید requestها را با استفاده از یک endpoint به چندین سرویس یا چندین instance از سرویس هدایت کنید. این الگو زمانی مفید است که می‌خواهید:

  -‏ چندین سرویس را در یک endpoint واحد نشان دهید و بر اساس request به سمت سرویس موردنظر بروید.

  -‏ چندین نمونه از یک سرویس را در یک endpoint برای تعادل بار (load balancing) یا جهت دردسترس‌بودن (availability) قرار دهیم.

  -‏ نسخه‌‌های مختلف از یک سرویس را در endpoint منحصربه‌فرد با مسیردهی ترافیک جداگانه در هر نسخه مختلف Expose کنید (برای یادآوری Expose به فصل مقدمه رجوع کنید).

 

زمینه و مشکل

  هنگامی که یک کاربر یا client نیاز به استفاده چندین سرویس دارد (چندین نمونه از یک سرویس یا ترکیبی از سرویس‌‌های مختلف) در این حالت کاربر باید از وضعیت ارتباطی سرویس‌ها آگاه باشد. به‌عنوان‌مثال سناریوهای زیر را در نظر بگیرید.

  -‏ Multiple disparate services (چندین سرویس متفاوت): یک برنامه تجارت الکترونیک (e-commerce application) ممکن است خدماتی مانند جستجو، بررسی، سبد خرید، تسویه‌حساب و تاریخچه سفارش ارائه دهد. هر سرویس دارای یک API متفاوت است که کلاینت باید با آن تعامل داشته باشد و کلاینت باید در مورد نحوه ارتباطی هر endpoint برای اتصال به سرویس‌ها بداند. اگر یک API تغییر کند، کلاینت نیز باید به‌روزرسانی شود. اگر یک سرویس را به دو یا چند سرویس جداگانه تغییر دهید، کد باید هم در سرویس و هم در کلاینت تغییر کند.

  -‏ Multiple instances of the same service (چندین نمونه از یک سرویس): سیستم می‌تواند نیاز به اجرای چندین نمونه از یک سرویس در جایی مشابه یا متفاوت داشته باشد. اجرای چندین نمونه را می‌توان برای اهداف تعادل بار (load balancing) یا برای برآوردن نیازهای دردسترس‌بودن (availability) انجام داد. هر بار که یک نمونه برای مطابقت با تعداد درخواست‌‌های بالا یا پایین روی اپلیکیشن تغییر می‌کند در این حالت client باید به‌روزرسانی شود.

  -‏ Multiple versions of the same service (چندین ورژن از یک سرویس): به‌عنوان بخشی از استراتژی deployment، نسخه‌‌های جدید یک سرویس را می‌توان در کنار نسخه‌‌های موجود مستقر یا deploy کرد که این به‌عنوان استقرار سبز آبی (blue green deployments) شناخته می‌شود. در این سناریوها، client باید هر بار که تغییراتی در درصد ترافیک هدایت شده به نسخه جدید و endpoint موجود ایجاد می‌شود را به‌روزرسانی کند.

   

راه‌حل:

  یک gateway در جلوی مجموعه‌ای از برنامه‌ها، سرویس‌ها، deploymentها قرار دهید. از مسیریابی لایه ۷ اپلیکیشن برای مسیریابی request به نمونه‌‌های مناسب استفاده کنید.

  با استفاده از این الگو، برنامه client فقط باید در مورد یک endpoint واحد بداند و با یک endpoint واحد ارتباط برقرار کند. موارد زیر نشان می‌دهد که چگونه الگوی gateway routing به سه سناریویی که در بخش طرح صورت‌مسئله شده‌اند، می‌پردازد.

 

روش Multiple disparate services (چندین سرویس نامساوی)

  gateway-multiple-services

    در روش چندین سرویس نابرابر (Multiple disparate services) الگوی gateway routing در این سناریو که یک client از چندین سرویس را استفاده می‌کند مناسب است. اگر یک سرویس یکپارچه، تجزیه یا جایگزین شود، client لزوماً نیازی به به‌روزرسانی ندارد و می‌تواند به requestهایی روی gateway ادامه دهد و فقط مسیردهی(routing) تغییر می‌کند.

  یک gateway همچنین این امکان را می‌دهد که backend service را از کلاینت‌ها abstract کنید و به شما این امکان را می‌دهد که فراخوانی‌‌های client را ساده نگه دارید و درعین‌حال تغییرات را در سرویس‌های backend در پشت gateway کنترل کنید. فراخوانی‌‌های client را می‌توان به هر سرویس یا سرویسی که برای مدیریت رفتار مورد انتظار client نیاز دارد هدایت کرد و این امکان را می‌دهد که سرویس را در پشت gateway بدون تغییر در سمت client به‌راحتی؛ اضافه، تقسیم و سازماندهی مجدد کنید.

   

 

‏Multiple instances of the same service (چندین نمونه از سرویس‌‌های مشابه)

  کلیدواژه Elasticity کلمه بسیار مهمی در رایانش ابری است. سرویس‌ها را می‌توان برای پاسخگویی به تقاضای روبه‌افزایش، زیاد (spun up) کرد و یا زمانی که تقاضا کم است برای صرفه‌جویی در هزینه‌ها، کاهش (spun down) داد. پیچیدگی ثبت و لغو ثبت نمونه سرویس‌ها در gateway خلاصه شده است. client از افزایش یا کاهش تعداد سرویس‌ها بی‌اطلاع است.

  همیشه نمونه سرویس‌ها می‌توانند در یک جا یا چند جا روی سرورهای مختلف مستقر شوند. الگوی Geode pattern توضیح می‌دهد که چگونه deployment در چند ناحیه یا node یا سرور می‌تواند تأخیر زمانی در ارتباط‌ها را بهبود بخشد و availability بودن یک سرویس را افزایش دهد.

 

‏ Multiple versions of the same service (چندین نسخه از سرویس‌‌های مشابه)

 

  این الگو را می‌توان برای deployment استفاده کرد و این امکان را می‌دهد که نحوه به‌روزرسانی به کاربران را مدیریت کنید. هنگامی که یک نسخه جدید از سرویس شما مستقر می‌شود، می‌توان آن را به‌موازات نسخه موجود مستقر کرد. مسیریابی به شما امکان می‌دهد تا کنترل کنید چه نسخه‌ای از سرویس به مشتریان ارائه می‌شود، و به شما این امکان را می‌دهد که از راهبُردهای انتشار مختلف استفاده کنید، چه به‌روزرسانی‌‌های incremental، parallel یا complete rollouts. هر مشکلی که پس از استقرار سرویس جدید مشاهده شود، می‌تواند به‌سرعت با ایجاد یک تغییر پیکربندی در gateway، بدون تأثیر بر کلاینت‌ها، بازگردانده شود.

 

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

  -‏ سرویس gateway می‌تواند یک نقطه شکست را ایجاد کند. مطمئن شوید که به‌درستی طراحی شده است تا نیازهای availability بودن برنامه را برآورده کند. قابلیت انعطاف‌پذیری(resiliency) و تحمل خطا را در اجرا در نظر بگیرید.

  -‏ سرویس gateway می‌تواند یک گلوگاه(bottleneck) ایجاد کند. اطمینان حاصل کنید که gateway عملکرد مناسبی برای مدیریت‌کردن load دارد و به‌راحتی می‌تواند مطابق با انتظارات scale یا مقیاس‌دهی شود.

  -‏ تست بار (load testing) را در برابر gateway انجام دهید تا مطمئن شوید که خرابی‌‌های زنجیره‌ای و دنباله‌دار برای سرویس‌ها ایجاد نمی‌کند.

  -‏ مسیریابی gateway در شبکه در لایه سطح ۷ است که می‌تواند بر اساس IP، port، header یا URL باشد.

  -‏ به‌طورکلی سرویس gateway می‌تواند سراسری (global) یا ناحیه‌ای (regional) باشد. Azure Front Door یک gateway سراسری است، درحالی‌که Azure Application Gateway به‌صورت ناحیه‌ای است. اگر راه‌حل شما به سرویس deployment به‌صورت چند ناحیه‌ای (multi-region) نیاز دارد، از یک gateway سراسری استفاده کنید. اگر workload به شکل ناحیه‌ای دارید که به کنترل دقیق نحوه متعادل‌سازی ترافیک نیاز دارد از Application Gateway استفاده کنید. به‌عنوان‌مثال؛ وقتی می‌خواهید ترافیک بین ماشین‌های مجازی را متعادل‌سازی کنید.

  -‏ سرویس gateway یک public endpoint برای سرویس‌‌هایی است که در جلو آن قرار دارد. محدودکردن دسترسی public network به سرویس‌‌های backend را در طراحی در نظر بگیرید آن هم فقط به‌صورت ایجاد دسترسی به سرویس‌ها فقط از طریق gateway یا از طریق یک private virtual network.

   

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

  -‏ یک client نیاز به استفاده از چندین سرویس دارد که در پشت یک gateway قابل‌دسترسی است.

  -‏ وقتی که می‌خواهیم برنامه‌های client را با استفاده از یک endpoint ساده کنید.

  -‏ وقتی که requestها را از externally addressable endpoints به internal virtual endpoints هدایت یا مسیردهی کنید، مانند قراردادن پورت‌‌های یک VM برای cluster کردن آدرس‌‌های IP مجازی.

  -‏ یک کلاینت باید سرویس‌‌هایی را که در چندین ناحیه مختلف (فیزیکی/مجازی) اجرا می‌شود برای رسیدن به تأخیر زمانی یا دسترسی مناسب، استفاده کند.

  -‏ یک کلاینت باید تعداد مختلفی از نمونه سرویس‌ها را مورداستفاده قرار دهد.

  -‏ وقتی که می‌خواهیم یک استراتژی deployment را پیاده‌سازی کنیم که در آن کاربرها به چندین نسخه از سرویس به طور هم‌زمان دسترسی داشته باشند.

 

مثال:

  با استفاده از Nginx به‌عنوان router؛ در مثال زیر یک فایل پیکربندی ساده برای سروری است که درخواست‌‌های برنامه‌‌های موجود در دایرکتوری‌‌های مجازی مختلف را به ماشین‌‌های مختلف در سرویس backend هدایت می‌کند.

server {
    listen 80;
    server_name domain.com;

    location /app1 {
        proxy_pass http://10.0.3.10:80;
    }

    location /app2 {
        proxy_pass http://10.0.3.20:80;
    }

    location /app3 {
        proxy_pass http://10.0.3.30:80;
    }
}

برای پیاده‌سازی الگوی gateway routing می‌توان از سرویس‌‌های Azure زیر استفاده کرد:

  -‏ یک Application Gateway instance که مسیردهی ناحیه‌ای لایه ۷ را فراهم می‌کند.

  -‏ یک Azure Front Door instance که مسیردهی سراسری لایه ۷ را فراهم می‌کند.

منابع مرتبط: