تحلیل سلسله مراتبی فیلترها در Spring Cloud Gateway

نویسنده: سهیل مهروزی

     Spring Cloud Gateway(SCG) ، کتابخانه ای برای ساخت API Gateway مبتنی بر Spring است . در معماری میکروسرویس،API Gateway  بعنوان نقطه ورودی واحد عمل می‌کند . درخواست های ورودی و پاسخ ها را برای سرویس ها اداره نموده  بطوریکه قابلیت هایی مانند محدودسازی نرخ درخواست‌ها (Rate limiting)، دسترسی ها، امنیت ، مسیردهی ، لاگ گیری  (Logging) و غیره را فراهم می نماید . یکی از اجزای اصلی آن، زنجیرهٔ فیلترها است که روی درخواست‌های ورودی و پاسخ‌ها اعمال می‌شوند.  GlobalFilter  و GatewayFilter  فیلترهای SCG  هستند . علاوه بر آن‌ها، WebFilter  بعنوان فیلتر WebFlux  هم در این زنجیره نقش دارد .

SCG   بر روی بستر Spring WebFlux  ساخته می شود ، از این رو همه درخواست های ورودی ابتدا از لایه        زیر ساختی  SCG عبور می کنند. این لایه ، یک فریم ورک وب واکنشی (reactive)  است که کاملا  ناهمزمان (asynchronous) و غیر مسدود کننده (non-blocking) عمل می کند . بطوریکه تعداد زیادی درخواست را             با کارایی بالا و منابع کمتر مدیریت و پردازش می نماید.
این رویکرد ، امکان مسیریابی درخواست‌ها و اعمال فیلترها را به صورت واکنشی  فراهم می‌ آورد.
از طرفی ، در فریم ورک Spring ، پکیج reactive.observation  زیر ساخت مشاهده پذیری (Observability) را در لایه WebFlux  فراهم می کند و به صورت یک  فیلتر غیرمداخله ای برای اهداف نظارتی مانند رصد و ثبت   متریک ها  مورد استفاده قرار گیرد.  پیکربندی خودکار spring boot actuator فیلترهای Observability را در    این لایه به صورت خودکار ایجاد می کند که دارای order یا اولویت بسیار بالا (@Order(-2147483647)) هستند. بدین ترتیب این فیلترها تقریبا نخستین فیلترهای اجرا شده در این لایه می باشند . 
 WebFilter  بعنوان یکی از فیلترهای اصلی  لایه WebFlux  عمل می‌کند و روی همه درخواست‌های WebFlux اعمال می‌شود . وابسته به مسیر (route) نیست .  اما می‌تواند URI را بررسی کند و با شرط‌ گذاری داخل کد ، روی درخواست‌های خاص اعمال شود. از طرفی ، امکان رهگیری و تغییر درخواست‌های ورودی و پاسخ‌های خروجی را دارد . در زمینه کاربردهای آن می توان به لاگ گیری  (Logging) ، تغییر Headers  و مدیریت CORS  ( با استفاده از CorsWebFilter ) اشاره کرد . ترتیب اجرای این نوع فیلتر در این لایه با مقدار @Order مشخص می شود. بطوریکه هر چقدر عدد order کوچکتر باشد ، فیلتر مورد نظر زودتر اجرا می شود . در صورت نداشتن order به عنوان ordered.lowest_precedence ( کمترین اواویت ) یا بیشترین عدد ممکن (2147483647) برای آن فیلتر در نظر گرفته می شود  و به عنوان آخرین فیلتر این لایه اجرا می گردد. 
GlobalFilter ، روی همه مسیرها (all routes) اعمال می‌شود ، مگر اینکه به‌ صورت اختیاری شرط‌ هایی تعریف شود تا فقط روی برخی مسیرها اجرا شود. پیکربندی خارجی ندارد، مگر اینکه شرط داخل کد گذاشته شود.   از کاربردهای آن می توان  block user ، Throttling و لاگ گیری  (Logging) را ذکر کرد. 
GatewayFilter  ، فقط روی یک مسیر خاص ( route خاص ) اعمال می شود و به دو نوع  ساده (Simple) و قابل پیکربندی (Configurable) تقسیم می‌شود. فیلتر ساده ، فیلتر ثابت و بدون پیکربندی خارجی می باشد . در این حالت ، برای تغییر بایستی کد را ویرایش و دوباره کامپایل کنیم.
ارث بری از AbstractGatewayFilterFactory  رایج ترین روش برای فیلترهای قابل پیکربندی می باشد. در این فیلتر ، پارامترهای ورودی فیلتر را از پیکربندی خارجی (مثلYAML )  به فیلتر منتقل کنیم تا رفتار آن را تغییر دهیم بدون اینکه کد فیلتر را دوباره بنویسیم.  از بازنویسی مسیر (RewritePath) ، Encrypt/Decrypt وlimiting Rate بعنوان کاربرد های آن می توان  نام برد.
جریان درخواست ها در ابتدا از فیلتر WebFlux- Observation عبور می کنند . بعد از اجرای Observation ، 
درخواست ها وارد WebFilter‌  WebFlux- می‌شوند. سپس ، درخواست ها به SCG منتقل می گردند . وقتی که درخواستی با یک مسیر مطابقت دارد ، GlobalFilter و GatewayFilter مرتبط به زنجیره فیلتر اضافه می شوند . 
این زنجیره فیلتر که ترکیبی از هر دو نوع  فیلتر اصلی  SCG می باشند . با مقدار دهی به Order   چگونگی ترتیب فیلترها مشخص خواهد شد .
مدل مفهومی زنجیره فیلترها :

عکس 2

 درSCG  ،  سه سناریو برای ترتیب اجرای فیلترها قابل تصور است : 

سناریوی اول: فیلتر فقط در کد دارای مقدار order می باشد و در YAML وجود ندارد .

سناریوی دوم : فیلتر فقط در YAML وجود دارد و در کد دارای مقدار order نمی باشد.

سناریوی سوم : فیلتر هم در YAML وجود دارد و هم در کد دارای مقدار order می باشد . 

  در زمینه چگونگی ترتیب اجرای فیلترها در زمینه سناریوهای فوق ، بایستی گفت که ترتیب اجرای فیلترها در اولویت اول بر اساس مقدار order کد مشخص می شود.  در نتیجه در سناریوی اول و سوم وضعیت ترتیب اجرای فیلترها بر اساس مقدار order مشخص میشود .

در سناریوی دوم ، فیلترها با پایین ترین اولویت بعد از فیلترهای دارای مقدار order ، طبق ترتیب در YAML اجرا میشوند .
در  SCG بین مرحله pre  (قبل از فراخوانی سرویس downstream) ومرحله post  ( بعد از دریافت پاسخ) برای اجرای فیلترهایش تمایز قائل می‌شود بطوریکه اجرای اولین فیلتر درمرحله pre ، اجرای آخرین فیلتر در مرحله post می باشد .
درک دقیق تر از ترتیب و نقش فیلترها باعث می شود ساختار بهینه ای  برای API Gateway طراحی و ایجاد کرد و همچنین مدیریت کارآمدتری بر جریان درخواست‌ها و پاسخ‌ها اعمال نمود.