توسعه دهنده نرم افزار
API Gateway به زبان ساده (قسمت آخر)
درادامه پست قبلی به بررسی ابعاد دیگری از API Gateway می پردازیم
پیاده سازی امنیت
همانطور که اشاره شد در یک سیستم مبتنی بر معماری میکروسرویس یک درخواست به چندین درخواست تقسیم میشود بنابراین دسترسی مشتری به هر یک از این سرویس ها باید از نظر احراز هویت و سطح دسترسی معتبر و مجاز باشد. این بدان معنی است که یک منطق امنیتی باید در هر سرویس تکرار شود. اگر قرار باشد برای هر سرویس اطلاعات کاربر از سرویس مربوطه گرفته شود و دسترسی ها چک شود این کار سربار زیادی به سیستم تحمیل می کند. راه کار بهینه اینست که هر درخواست در API Gateway اعتبار سنجی وبررسی شود . در شکل های بعد این مکانیزم نشانداده شدهاست.
در ادامه به اختصار مراحل را بررسی می نماییم
یک)مشتری اعتبارنامه خود را به سرور هویت سنجی ارسال میکند تا یک توکن دسترسی دریافت کند.
دو) سرور عمل تایید اعتبارنامه را انجام می دهد. اگر اعتبارنامه مشتری معتبر باشد، سرور یک توکن دسترسی را به مشتری میفرستد ،درواقع سرور هویت سنجی محتوای این توکن را در مخزن داده ای خود ذخیره خواهد کرد و یک شناسه منحصر به فرد برای این توکن صادر و به مشتری ارسال خواهد کرد. این شناسه یک عبارت تصادفی و رمزنگاری شده میباشد که در خارج از شبکه مورد استفاده قرار میگیرد.
سه)زمانی که مشتری به شناسه توکن دست یافت برای ارسال درخواستهایش ، درخواست و شناسه توکن هر دو را به API Gateway ارسال میکند.
چهار)وقتی API Gateway درخواستی از مشتری دریافت کرد شناسه توکن دریافت شده همراه درخواست مشتری را به سرور هویت سنجی ارسال میکند.
پنج) سرور هویت سنجی شناسه توکن را تایید میکند و یک توکن JWT(JSON Web
Token) را به API Gateway برمی گرداند. JWT شامل اطلاعات کاربر و اطلاعات دسترسی / مجوز است.
شش) API Gateway از JWT درون شبکه استفاده میکندو درخواست مشتری را به همراه توکن JWT به سرویس های مربوطه میفرستد حالا، سرویس ها با استفاده از محتویات JWT ،دسترسی مشتری را بررسی می کنند.اگر مشتری دسترسی لازم را داشت پاسخ مناسب را ارسال می کنند در غیراینصورت در خواست را رد می کنند.
هفت) یک توکنJWT حاوی تمام اطلاعات هویت (از جمله مجوزها) است, که این امر سبب اجتناب از فراخوانی های اضافی (برای مثال, یک پرس و جو پایگاهداده) برای بدست آوردن اطلاعات کاربر می شود.
اکتشاف سرویس و مسیریابی با API Gateway
کشف سرویس را میتوان به دو روش انجام داد: (۱) کشف در سمت کلاینت و (۲) کشف در سمت سرور. اکتشاف طرف سرور را میتوان با یک API Gateway به صورتی که در شکل نشانداده شدهاست، اجرا کرد.
زمانی که یک مشتری درخواستی ارسال میکند، API Gateway مخزن سرویس های ثبت شده را برای یافتن سرویس مناسب و مطابق با درخواست مشتری را جستجو میکند. اگر این سرویس موردنظر را پیدا کند، این درخواست را به سرویس مربوطه منتقل میکند.نکته ای در اینجا باید توجه شد این است که هر یک از سرویس ها نسخه خود را دارند و مدیریت نسخه ها نیز توسط API Gateway انجام می شود. API Gateway را میتوان برای آرشیو کردن ،بروزرسانی های نقاط نهایی(=endponit) نسخههای مختلف سرویس طراحی کرد.هنگامیکه مشتری درخواستی را ارسال می کند API Gateway یک نسخه به روز رسانی شده از سرویس مورد نظر پیدا می کند و درخواست را به آن ارجاع می دهد.
تجمیع دادهها با API Gateway
همانطور که قبلاً ذکر شد، در معماری میکروسرویس، سرویس ها با دو معیار اصلی طراحی میشوند، (الف) هر سرویس باید یک مسئولیت مشخص را انجام دهد و (ب) هر سرویس باید دادههای مخصوص خود را بدون به اشتراک گذاری داشته باشد. این امر منجر به ایجاد سرویس های زیادی که ساده وبا دادههای مربوطه به خود هستند میشود. حال موقعیتهایی وجود دارند که در آن یک مشتری به دنبال اطلاعاتی است که در اختیار چندی سرویس مختلف است. اینجاست که، API Gateway را میتوان برای جمعآوری و تجمیع دادهها از سرویس های مربوطه و ارائه به کاربر طراحی کرد. بطور مثال همانطور که در شکل نشانداده شدهاست، مشتری به دنبال سفارشات و میزان پرداختی کاربری با شناسه "۵۶۴۹" می باشد.درخواست مرتبط با سه سرویس به نامهای سرویس مشتری، سرویس سفارش و سرویس پرداخت می باشد. اکنون API Gateway سه سرویس را فرخوانی میکند، دادهها را بدست میآورد و دادههای جمعآوریشده را ترکیب میکند، و آن را به مشتری باز میگرداند.
فرمت داده / پروتکل تبدیل در API Gateway
معماری میکروسرویس هیچ محدودیتی برای فنآوریهای مورد استفاده توسعه تعیین نمیکند ، بنابراین سرویس ها قالبهای دادهای متفاوتی برای serialization یا پروتکلهای مختلف انتقال دارند . هنگامی که یک درخواست به API Gateway داده می شود ممکن است با فرمت های داده متفاوت یا پروتکل انتقال متفاوت از سرویس ها باشد ، اینجا API Gateway باید فرمت دهه داده مورد نیاز و تبدیل پروتکل را انجام دهد و درخواست را به سرویس مربوطه منتقل کند ،مانندآنچه در شکل نشانداده شدهاست .
توابع Edge در API Gateway
برای استفاده از توابع Edge میتوان از ظرفیت های API Gateway بهره برد موارد ذیل جزو این توابع هستند :
الف) محدودسازی نرخ درخواست : API Gateway تعیینکننده میزان درخواست برای یک سرویس در یک ثانیه است و میتواند درخواستها را به یک سرویس خاص محدود کند.
ب) Caching : در API Gateway می توان تنظیمات را طوری انجام داد تا نتایج سرویس هایی که بصورت مکرر توسط مشتریان فراخوانی می شود را از Caching به مشتریان بازگرداند بدون اینکه درخواستی به سرویس موردنظر ارجاع بدهد.
ج) جمعآوری سنجه ها : برای جمعآوری سنجه های مختلف مانند استفاده از سرویس یا میزان دسترسی به دادهها و محاسبه صورتحساب مشتریان می توان از API Gateway استفاده نمود.
د) واقعهنگاری (=Logging) عملیات و ممیزی : ثبت لاگ عملیات مختلف و حسابرسی دقیق تر و متنوع تر رخدادهای عملیاتی ثبتشده را می توان در API Gateway انجام داد.
مزایای اصلی API Gateway
مزایای اصلی API Gateway شامل موارد ذیل می شود :
۱. یک نقطه ورود یکتا به برنامه فراهم میکند.
۲. فراخوانی ها را در یک شبکه محلی با سرعت بالا انجام می دهد.
۳. از دسترسی مستقیم به برنامه توسط مشتریان جلوگیری میکند.
۴. کد مشتری را ساده میکند. برای مثال، تبدیل فرمت دادهها یا تبدیل پروتکل را انجام میدهد.
۵. کشف سرویس ها و مسیریابی های مورد نیاز را انجام می دهد.
۶. با ترکیب سرویس ها و تجمع دادهها تعداد درخواستهای مشتری را کاهش می دهد.
۷. خدمات اصلی مشترک از قبیل احراز هویت و دسترسی ها را یکبار انجام می دهد؛ در غیر این صورت، هر سرویس باید چنین کارهاییانجام دهد.
معایب API Gateway
تنها جز اصلی که همه مشتریان با آن تعامل دارند API Gateway است، مشخص است که از حساسیت زیادی برخوردار است و می بایست دارای قابلیت های دسترس پذیری بالا و مقیاس پذیری باشد. بنابراین باید به طور مناسب توسعه، مستقر و مدیریت شود. API Gateway باید طوری طراحی شود که به یک تنگنای توسعه و بهکارگیری برنامه ها تبدیل نشود. کارکردهای API Gateway باید به کمترین مقدار ممکن رساند و تنها کارکردهای ضروری به API Gateway منتقل شوند.
مطلبی دیگر از این انتشارات
Scalability and Costs
مطلبی دیگر از این انتشارات
مدل های Communication در معماری میکروسرویس (قسمت سوم)
مطلبی دیگر از این انتشارات
مدل های Communication در معماری میکروسرویس (قسمت اول)