مروری بر مفهوم API Gateway و معماری نرم افزار آن

چکیده

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

کلمات کلیدی : رابط برنامه نویسی کاربردی ، درگاه رابط برنامه نویسی کاربردی، اقتصاد رابط برنامه نویسی کاربردی، ارائه دهنده رابط برنامه نویسی کاربردی، مشتری رابط برنامه نویسی کاربردی

1.مقدمه

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

1-1. رابط برنامه نویسی نرم افزار کاربردی (API)

مخفف عبارت Application Programming Interface ، به معنی "رابط برنامه نویسی نرم افزار کاربردی" است. با یک مثال ساده و کاربردی مفهوم آن را توضیح می‌دهیم.

فرض کنید به یک رستوران رفته‌اید و منوی رستوران را در اختیار شما قرار می‌دهند و شما صرفا غذای مورد نظر خود را انتخاب می‌کنید و همان غذا برای شما سرو می‌شود و شما از جزئیات نحوی پخت آن توسط رستوران اطلاعی ندارید. اگر شما منو را یک API در نظر بگیرید توسعه دهندگان از جزئیات پیاده سازی آن اطلاعی ندارند و نیازی به دانستن آن نیز ندارند فقط برحسب نیاز خود از آن استفاده می‌کنند.

1-2. مدیریت API

با رشد روز افزون API ها و ارتباطات گسترده آن‌ها با یک دیگر نیاز به یک بستر امن و سریع برای کنترل و مدیریت API ها داریم که API Gateway این بستر را برای ما فراهم می‌کند که در ادامه بصورت کامل عملکرد و اجزای آن را شرح داده‌ایم.

1-3. معماری نرم افزار

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

1-4. میکروسرویس

این مفهوم یک سبک معماری است که به این صورت عمل می‌کند که نرم افزار را به اجزا کوچکتر تقسیم می‌کند و هر میکروسرویس فقط یک کار مستقل را نجام می‌دهد با یک مثال کاربردی بخواهیم توضیح دهیم به این صورت است که یک ساندویچ فروشی را تصور کنید برای تهیه یک ساندویچ باید ابتدا نان را اماده کنیم سپس سبزیجات آن را اضافه کنیم و سپس محتویات اصلی آن را حالا اگر برای هر بخش یک نیرو داشته باشیم که صرفا یکی از عملیات را انجام دهد ما سه نیرو داریم که می‌توان کار هر فرد را یک میکروسرویس توصیف کرد که علاوه بر اینکه هریک کار خاصی انجام می‌دهند می‌توانند باهم ارتباط نیز داشه باشند که ارتباط آن‌ها از طریق API ها ممکن است.

2.تعریف API

در تعریف اولیه API ها می‌توان گفت که یک نوع رابط کاربری هستند. سازمان‌ها و سیستم‌های نرم افزاری از دو طریق خدمات خود را به مشتری‌های خود ارائه می‌دهند اولین و رایج‌ترین روش ارائه خدمات از طریق رابطه کاربری یا همان ui است و روش دوم ارائه خدمات از طریق API ها هستند که معمولا API ها در اختیار کاربران ماشینی قرار می‌گیرد.

از جمله شباهت‌های API و رابط کاربری می‌توان به مواردی همچون موارد زیر اشاره کرد : هردو در جهت بهبود و سهولت ارتباط بین اجزای یک سیستم نرم افزاری استفاده می‌شوند با این تفاوت که رابط کاربری برای ارتباط انسان با سیستم و API در جهت ارتباط سیستم با سیستم است. همچنین هردو برای محصورسازی منطق و پیچیدگی‌های یک سیستم می‌باشند.

یکی دیگر از ویژگی‌های API ها این است که یک ساختار دقیق و مشخص برای ارتباط دارند که ارتباطات آن‌ها مبتنی بر پروتکل‌هایREST و SOAP و یا GraphQL است. از جمله کاربردهای مفید API ها، امکان یکپارچه‌سازی و ساخت سیستم‌های مقیاس بزرگ را فراهم می‌کند تا آن‌ها بتوانند از طریق یک استاندارد مشخص و تعریف شده به راحتی با یکدیگر ارتباط برقرار کنند.

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

2-1. انواع API

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

2-2. نکات پیاده‌سازی API

در هنگام پیاده‌سازی API ها توجه به نکاتی و عمل به آنها حائز اهمیت است. از جمله این نکات می‌توان به موارد زیر اشاره کرد.

• در بحث API ها این است که API ها یک محصول هستند و سازمان‌ها همانند سایر محصولات خود API‌های تولیدی خود را به کاربران ارائه می‌کنند.
• هنگام پیاده‌سازی API ها باید به ساده‌سازی آن توجه کرد. همچنین هنگام استفاده از آن‌ها باید تا حد ممکن از استفاده ناصحیح جلوگیری شود. مثلا اگر خارج از قالب تعیین شده API از آن استفاده شود و یا آن را ناصحیح فراخوانی کنند نباید اجرا شود.
• باید پیچیدگی‌های سیستم را پنهان و هر API باید یک سرویس خاص را ارائه دهد و نباید چندین کار انجام شود.
• هر API باید قابلیت دسترسی راحتی داشته باشد و شرکت‌های ارائه دهنده API باید یک پورتال برای ارائه API‌های خود فراهم کنند. از طرفی باید مستندات کاملی برای هر API داشته باشیم تا نحوی استفاده از آن را شرح دهند. مانند Swagger ها که بر پایه json هستند.
  توافق نامه‌ها، سطح خدمات را به کاربران ارائه می‌کنند و به کاربران این اطمینان را می‌دهند که API که دریافت می‌کنند بدون خرابی کار و یکسری قوانین ارائه می‌دهد. هردو طرف توافق نامه باید به آن پایبند باشند. از پروتکل‌های احراز هویت مانند OAuth2 پشتیبانی می‌کنند تا مورد حمله سوم شخص قرار نگیرند و کسی نتواند به صورت غیر مجاز از API ها استفاده کنند.
  در مهندسی نرم افزار سامانه‌هایی وجود دارند که توسعه‌دهندگان بتوانند قبل از اینکه در محیط عملیاتی آن‌ها را اجرا کنند ابتدا در محیط‌های تست بدون اینکه تاثیری روی آن‌ها بگذارند API ها را اجرا کنند.

3. معرفی API Gateway

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

3. معرفی معماری داخلی API Gateway ها
اجزای داخلی API Gateway ها از دوبخش اصلی BSS که مربوط به بخش بیزینس و فروش API هاست، و OSS که مربوط به بخش پشتیبانی از ارائه API هاست، تشکیل می‌شود که به معنی سیستم‌های پشتیبانی کسب‌وکار و سیستم‌های پشتیبانی عملیاتی تعبیر می‌شوند.
3-1. سیستم‌های پشتیبانی عملیاتی
مسیریابی : هر سرویس برای دسترسی به امکاناتش یک API ارائه می‌دهد هنگامی که کاربران درخواست‌های خود را به API Gateway ارسال می‌کنند، آن درخواست‌ها را به سمت API مورد نظرش هدایت می‌کند. در واقع درخواست را از مصرف کنند دریافت می‌کند و آن را به سمت ارائه دهنده خدمات هدایت می‌کند و جواب را بر می‌گردانند.
احراز هویت و مجوز : ممکن است API Gateway کاربران متفاوتی داشته باشد و هریک سطح دسترسی خاصی داشته باشند، هرگاه بخواهند درخواست خود را ارسال کنند قبل از اتصال به API مورد نظر ابتدا احراز هویت می‌شوند و سطح دسترسی آن‌ها بررسی می‌شود. در صورتی که مجاز نباشد، اجازه دسترسی به آن API را به کاربر نمی‌دهد. این امر باعث می‌شود از دسترسی‌های غیر مجاز به سرویس‌ها جلوگیری شود.

مدیریت امنیت : هنگامی که سازمان‌ها داده‌ها و اطلاعات خود را روی API Gateway قرار می‌دهند انتظار دارند که امنیت اطلاعات آن‌ها در برابر حملات، دسترسی غیرمجاز و... حفظ شود. به همین دلیل API Gateway ها اطلاعات را در برابر حملات با استفاده از روش‌های مختلف مانند تشخیص الگوهای نرمال و غیرنرمال و قرار دادن کاربران در دو لیست سیاه و لیست سفید حفظ می‌کنند. به این ترتیب می‌توان از سرویس‌ها در برابر حملات محافظت کرد.
مدیریت ترافیک : API Gateway ها وظیفه دارند که تعدادی درخواست را دریافت کنند و پاسخ مورد نظر را به آن برگردانند. اگر بر روی ارسال درخواست‌ها نظارتی وجود نداشته باشد، ممکن است باعث از دسترس خارج شدن سیستم شود به همین دلیل از دو مکانیزم برای کنترل ترافیک وارد شده به سرویس‌ها استفاده می‌کند.

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

تغییر و ارکستراسیون : هنگام استفاده از API Gateway ها لازم است همگی از یک پروتکل یکسان برای برقراری ارتباط استفاده کنند، به همین دلیل هنگامی که سرویس‌های مختلف باهم ارتباط برقرار می‌کنند اگر هر یک از آن‌ها از پروتکل‌های متفاوتی استفاده کنند مانند REST و یا SOAP آنها را به هم تبدیل می‌کند تا برای هریک از آن‌ها قابل فهم و استفاده باشد.

3-2. سیستم‌های پشتیبانی کسب‌وکار
پس از مدیریت ارتباط بین API ها باهم و کاربران آن، لازم است یک بستر برای دسترسی به API ها فراهم کنیم و آن‌ها را بر روی یک پورتال قرار دهیم تا به راحتی بتوان به آن‌ها دسترسی داشت.
پورتال: API ها پس از پیاده‌سازی برای مصرف بر روی یک پورتال قرار می‌گیرند. ابتدا کاربران باید در پورتال مورد نظر ثبت نام کنند. به ازای هر API یک کاتالوگ وجود دارد که نحوی کار با آن API اعم از ورودی و خروجی و منطق API در آن تعریف شده است که Swagger این کار مستندسازی را انجام می‌دهد. همچنین یک سند وجود دارد که گزارش کاملی از میزان مصرف هر API ارائه می‌دهد که چند بار فراخوانی شده است. بخش مهم دیگر پورتال، اطلاعات صورتحساب است که هر کاربر باید اطلاعات دقیقی از میزان هزینه که به آزاری API هایی که استفاده کرده، داشته باشد. هنگامی که کاربران می‌خواهند از API ها استفاده کنند باید یک SLA بین ارائه دهنده خدمات و گیرنده خدمات تنطیم شود که لا توجه به آن کیفیت خدمات تضمین شود همچنین با توجه به آن بتوان مشتری‌ها را رتبه‌بندی کرد و به هریک سطح خدمات متفاوتی ارائه کرد.

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

صورتحساب و CRM : ماژول‌های مدیریتی که در این بخش وجود دارد را در ادامه شرح می‌دهیم. با استفاده از ماژول فعال‌سازی و غیر فعال‌سازی است که از طریق آنها می‌توان سطح دسترسی کاربران را کنترل کرد. در واقع با استفاده از این ماژول می‌توان سطح دسترسی‌ها را ارتقا و یا محدود کرد. ماژول حسابداری شامل بدهکاری و بستانکاری و میزان مصرف کاربران است‌. سرویس‌دهندگان باید یک راه و سکوی ارتباطی برای مصرف‌کنندگان ایجاد کنند تا در صورت بروز خرابی بتوانند گزارش‌های خرابی را از سمت مصرف کنندگان دریافت کنند. همچنین سیاست‌های متفاوتی برای قیمت گذاری API ها وجود دارد مانند رتبه‌بندی مشتریان، میزان استفاده و خرید API‌ها قیمت‌های متفاوتی ارائه کرد. پس از خریداری API ها صورتحساب هر کاربر بررسی می‌شود، اگر ظرفیت خود را مصرف کرده باشند و تسویه نکرده باشند، دسترسی خدمات آن‌ها قطع شود. در تنظیم SLA نیز شرایط جریمه‌های لازم و میزان آن باید بین سرویس دهنده و سرویس گیرنده تعریف شود.
ورود به سیستم : در این بخش بحث‌های امنیتی سیستم و تقلب‌ها قابل مدیریت و پیگیری است و تراکنش‌های کاربر باید در قالب Log ثبت شوند.
نظارت و تجزیه و تحلیل : با استفاده از ابزارهای هوش تجاری می‌توان به پاسخی دقیق برای سوالاتی همچون موارد زیر رسید.

• کدام API ها پر طرفدار بوده‌اند؟
• کدام یک از API ها مهم تر هستند؟‌
• چقدر ظرفیت لازم است برای آن‌ها افزایش داد؟

همانند هر محصول دیگری API Gatewayها نیز در یک پروژه نرم افزاری مزایا و معایبی را با خود به همراه دارند. در ادامه هر از آنها را بررسی می‌کنیم.

3-3. مزایا API Gateway

• کاربران نیازی به درک منطق و مسیریابی APIها را ندارند.
• تبدیل فرمت‌های مختلف داده‌ها به یکدیگر نیاز نیست.
• می‌توان با کش کردن برخی از درخواست‌های رایج، سرعت پاسخ‌دهی را افزایش داد.
• می‌توان مسئولیت authentication/authorization میکروسرویس‌ها را به عهده گرفت.
• می‌توان عملکرد سرویس‌های مختلف را مانیتور و تحلیل کرد.

3-4. معایب API Gateway

• افزودن یک پیچیدگی به سیستم
• گلوگاه شدن در سیستم
• تنظیم مجدد API Gateway در صورت تغییر هر میکروسرویس یا API

4. معماری میکروسرویس

در این بخش ابتدا به تعریف معماری میکروسرویس و سپس کاربرد این معماری در پیاده‌سازی API Gateway‌ها و در نهایت هم به روش‌هایی جهت پیاده سازی بهتر این سبک از معماری می‌پردازیم :

4-1. تعریف معماری میکروسرویس

امروزه یکی از معماری‌های رایج و پرکاربرد معماری میکروسرویس است. این معماری در جهت شکستن سیستم به بخش‌های کوچک و هر بخش در قالب یک سرویس تعریف و پیاده‌سازی می‌شود. معماری میکروسرویس متشکل از مجموعه‌ای از خدمات کوچک است که هر سرویس صرفا یک کار واحد را انجام می‌دهد. همچنین یک سبک معماری معروف برای ساخت برنامه‌هایی که نیاز به انعطاف پذیری، مقیاس پذیری، استقلال در استقرار دارند بسیار پر کاربرد است. سرویس‌ها را می‌توان بصورت توزیع شده، پیاده‌سازی و مستقر کرد. همچنین هریک از آن‌ها می‌توانند پایگاه داده مخصوص به خود را داشته باشند. همچنین هریک از سرویس‌ها از طریق API می‌توانند باهم ارتباط برقرار کنند. به همین دلیل خاطر پیاده‌سازی آن‌ها از سایر سرویس‌ها پنهان می‌ماند.
با توجه به اینکه میکروسرویس بر پایه API کار می‌کند می‌توان نتیجه گرفت که تنها معماری مورد استفاده در API Gateway‌ها معماری میکروسرویس است. اما می‌توان معماری میکروسرویس را با روش‌هایی که در ادامه معرفی می‌کنیم جهت رسیدن به نتیجه مطلوب با توجه به نیازمندی مطرح شده، بهبود داد.
از جمله ویژگی‌های برتر معماری میکروسرویس می‌توان به موارد زیر اشاره کرد :
چابکی : همانطور که گفتیم میکروسرویس‌ها را می‌توان به صورت مستقل مستقر کرد. به همین دلیل خطایابی و رفع خطاهای سرویس‌ها به راحتی انجام می‌شود همچنین بروزرسانی و نگهداری از آن‌ها نیز بهتر می‌شود. هنگام بروز خطا در سیستم فقط سرویس دچار خرابی متوقف می‌شود و دیگر نیاز نیست کل سیستم متوقف شود.
وجود تیم‌های کوچک و متمرکز : میکروسرویس‌ها می‌توانند توسط تیم‌های مجزا و کوچیک طراحی، تولید و تست شوند. گاهی کوچک بودن تیم باعث می‌شود تیم منسجم‌تر باشد و بازدهی بیشتری داشته باشند. از طرفی هرچه تیم‌ها بزرگتر باشند مدیریت و ارتباط همه افراد هزینه‌بر و سخت‌تر می‌شود.

پایه اصلی کدها کوچک و سبک است : در یک برنامه یکپارچه به مرور زمان سرویس‌ها نیاز به تغییر و یا ادغام با سایر سرویس‌ها را دارند این سبک معماری وابستگی بین کدها را به حداقل می‌رساند و باعث می‌شود هنگام تغییرات، فقط بخش کوچکی از کد را تغییر داد‌‌.
استفاده از فناوری‌های مختلف : تیم‌ها می‌توانند با توجه به فناوری‌های موجود با توجه به شرایط سرویس بهترین فناوری را جهت ارائه بهتر خدمات انتخاب و استفاده کنند.
مقیاس پذیری : سرویس‌ها را می‌توان به صورت مستقل مقیاس‌بندی کرد. به این صورت که اگر یک سرویس نیاز به منابع بیشتری داشت فقط منابع همان سرویس را افزایش داد. زیرا اگر منابع کل سیستم افزایش یابد ممکن است حجم زیادی از آن بدون استفاده باقی بماند.

در بخش بعد اصول طراحی و نکات پیاده‌سازی معماری میکروسرویس‌ را بررسی می‌کنیم.

4-2. اصول طراحی و نکات پیاده‌سازی معماری میکروسرویس

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

به طور کلی برای پیاده‌سازی میکروسرویس ها باید چند نکته را به شرح زیر در نظر گرفت:

• ارتباط بین سرویس‌ها synchronize یا asynchronize باشد. در ارتباط asynchronize از مواردی چون پروتکل mqtt و صف پیام استفاده می‌شود تا سرویس‌ها بتوانند در زمان مناسب پیام‌های خود را بردارند. اما در ارتباط synchronize از پروتکل‌هایی مانند rest استفاده می‌شود.
• رابطه بین میکروسرویس‌ها چند به چند باشد؟ به عنوان مثال سرویس گزارش‌گیری رابطه یک به n است. زیرا یک سرویس از n سرویس دیگر باید گزارش بگیرد. همچنین ارتباط بین سرویس‌ها و دیتابیس‌ها نیز باید تعیین شود.
• از طرفی انتخاب تکنولوژی تا حد خیلی زیادی به ارتباط بین میکروسرویس‌ها بستگی دارد.

همچنین برای استفاده از معماری میکروسرویس در توسعه‌ی یک نرم افزار باید به یک سری اصول طراحی به شرح زیر توجه داشته باشیم:

• خدمات مستقل و خود مختار
• مقیاس پذیری
• تمرکززدایی
• خدمات انعطاف پذیر
• بالانس کردن load در زمان واقعی
• تحویل مستمر با استفاده از DevOps
• یکپارچه سازی API و پایش مستمر
• ایزوله کردن از Failurها

4-3. الگوهای طراحی میکروسرویس

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

به طور کلی الگوی‌های طراحی معماری میکروسرویس‌ها را می‌توان به چندین روش به شرح زیر تقسیم کرد. در ادامه هر یک از موارد زیر با جزئیات بیشتری بررسی خواهم کرد.

• Aggregator
• API Gateway
• Chained or Chain of Responsibility
• Asynchronous Messaging
• Database or Shared Data
• Event Sourcing
• Branch
• Command Query Responsibility
• Segregator
• Circuit Breaker
• Decomposition

4-3-1. الگوی Aggregator

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

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

بنابراین،‌ برای مثال اگر دو سرویس a و b را در نظر بگیریم، می‌توان به طور جداگانه این سرویس‌ها را با ارائه داده به میکروسرویس ترکیبی مقیاس کرد.

4-3-2. الگوی طراحی API Gateway

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

• زمانی که ارتباط بین سرویس‌ها زیاد شود مدیریت آنها کار ساده‌ای نیست.
• چگونه می‌توان از چند میکروسرویس درخواست اطلاعات کرد؟
• چگونه پروتکل‌های درخواست‌های مختلف هندل شود؟

با کمک الگوی طراحی API Gateway می‌توان مسئولیت‌های زیر را بر عهده گرفت:

• مسئولیت authentication/authorization میکروسرویس‌ها
• ترجمه پروتکل
• امنیت
• مانیتورینگ
• اولویت‌بندی کاربران

بنابراین، هنگامی که مشتری درخواستی را ارسال می‌کند، این درخواست‌ها به API Gateway ارسال می‌شود که به عنوان یک نقطه ورودی برای ارسال درخواست‌های مشتری به میکروسرویس‌های مناسب عمل می‌کند. سپس با کمک لودبالانسر، بار درخواست رسیدگی شده و درخواست به سرویس‌های مربوطه ارسال می‌شود. میکروسرویس‌ها از Service Discovery استفاده می‌کنند که به عنوان راهنما برای یافتن مسیر ارتباط بین هر یک از آنها عمل می‌کند. سپس میکروسرویس‌ها از طریق گذرگاه درخواست/پیام HTTP با یکدیگر ارتباط برقرار می‌کنند.

4-3-3. الگوی طراحی Chain

این الگو در واقع زنجیره‌ای از میکروسرویس‌ها است که با دریافت یک ورودی از کاربر یک خروجی واحد را تولید می‌کند. تمام سرویس‌ها در الگوی زنجیره‌ای از پروتکل HTTP برای تبادل پیام با یکدیگر استفاده می‌کنند. به عنوان مثال اگر سه سرویس به صورت زنجیره‌ای وجود داشته باشیم، ابتدا درخواست مشتری توسط سرویس A دریافت می‌شود. سپس این سرویس با سرویس بعدی یعنی B ارتباط برقرار می‌کند و داده‌ها را جمع‌آوری می‌کند. در نهایت سرویس دوم با سرویس سوم برای تولید خروجی تلفیقی ارتباط برقرار می‌کند. تا زمانی که درخواست از تمام سرویس‌ها عبور نکند و پاسخ‌های مربوطه ایجاد نشود، مشتری هیچ خروجی دریافت نمی‌کند. بنابراین در الگو همواره توصیه می‌شود که از زنجیره‌های بلند جهت جلوگیری از افزایش انتظار کاربر برای پاسخ‌دهی سیستم جلوگیری شود.

4-3-4. الگوی پیام رسان ناهمزمان (Asynchronous Messaging Design Pattern)

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

در این الگوی طراحی همه سرویس‌ها می‌توانند با یکدیگر ارتباط برقرار کنند، اما لازم نیست که به صورت متوالی با یکدیگر ارتباط برقرار کنند. بنابراین، اگر 3 سرویس را در نظر بگیریم: سرویس A، سرویس B، و سرویس C. درخواست مشتری می‌تواند به طور همزمان به سرویس C و B ارسال شود. این درخواست‌ها در یک صف خواهند بود.

4-3-5. الگوی طراحی داده مشترک (Shared Data Pattern)

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

• تکراری بودن داده‌ها و ناهماهنگی
• سرویس‌های مختلف انواع مختلفی از نیازهای ذخیره‌ سازی دارند
• تعداد کمی از تراکنش‌های تجاری می‌توانند داده‌ها را با چندین سرویس جستجو کنند
• غیر عادی سازی داده‌ها

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

4-3-6. الگوی طراحی منبع رویداد (Event Sourcing Design Pattern)

این الگوی طراحی رویدادهایی را در مورد تغییرات در وضعیت برنامه ایجاد می‌کند. همچنین، این رویدادها به عنوان دنباله‌ای از رویدادها ذخیره می‌شوند تا به توسعه دهندگان کمک کنند تا ببینند کدام تغییر در چه زمانی ایجاد شده است. بنابراین با کمک این الگو می‌توان وضعیت برنامه را برای مقابله با تغییرات گذشته تنظیم کرد. همچنین پس از انتشار رویدادها می‌توان تغییرات وضعیت برنامه را در لایه ارائه مشاهده کرد.

4-3-7. الگوی طراحی Branch

الگوی طراحی میکروسرویس Branch یک الگوی طراحی است که در آن می‌توان درخواست‌ها و پاسخ‌های دو یا چند میکروسرویس مستقل را به طور همزمان پردازش کرد. بنابراین بر خلاف الگوی طراحی زنجیره‌ای، درخواست به صورت متوالی ارسال نمی‌شود، بلکه درخواست به دو یا چند زنجیره میکروسرویس منحصر به فرد ارسال می‌شود. این الگوی طراحی، الگوی طراحی Aggregator را گسترش می‌دهد و انعطاف‌پذیری را برای تولید پاسخ‌ها از زنجیره‌های چندگانه یا تک زنجیره‌ای فراهم می‌کند. به عنوان مثال، اگر یک برنامه تجارت الکترونیک را در نظر بگیریم، ممکن است لازم باشد داده ها را از چندین منبع بازیابی کرده و این داده‌ها می‌تواند خروجی مشترک داده‌ها از سرویس‌های مختلف باشد. بنابراین، می‌توان از الگوی Branch برای بازیابی داده‌ها از چندین منبع استفاده کرد.

4-3-8. الگوی طراحی CQRS

هر طراحی میکروسرویس دارای پایگاه داده اختصاصی برای سرویس‌ها یا پایگاه داده مشترک بین سرویس‌ها است. اما در مدل پایگاه داده به ازای هر سرویس نمی‌توان یک کوئری را پیاده‌سازی کرد، زیرا دسترسی به داده ها تنها به یک پایگاه داده محدود شده است. بنابراین در چنین سناریویی می‌توان از الگوی CQRS استفاده کرد. طبق این الگو، اپلیکیشن به دو بخش Command و Query تقسیم می‌شود. بخش Command تمام درخواست‌های مربوط به ایجاد، به‌روزرسانی، حذف را رسیدگی می‌‌کند در حالی که بخش Query جهت عملیاتی چون خواندن از پایگاه داده استفاده می‌شود.

4-3-9. الگوی طراحی Circuit Breaker

الگوی طراحی Circuit Breaker برای توقف فرآیند درخواست و پاسخ در صورت کار نکردن یک سرویس است. به عنوان مثال، فرض کنید یک کلاینت در حال ارسال درخواستی برای بازیابی اطلاعات از چندین سرویس است. اما به دلیل برخی مشکلات یکی از سرویس‌ها از کار افتاده است. در حال حاضر عمدتاً با دو مشکل مواجه خواهیم شد:

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

بنابراین، برای جلوگیری از چنین مشکلاتی می‌توانید از الگوی طراحی Circuit Breaker استفاده کرد. با کمک این الگو مشتری یک سرویس راه دور را از طریق یک پروکسی فراخوانی می‌کند. این پروکسی اساساً به عنوان یک فیوز قطع عمل می‌کند. بنابراین هنگامی که تعداد خرابی‌ها از عدد آستانه عبور می‌کند، قطع‌کننده مدار برای یک دوره زمانی خاص کار می‌کند. بنابراین تمام تلاش‌ها برای فراخوانی سرویس راه دور در این بازه زمانی با شکست مواجه می‌شوند. پس از اتمام دوره زمانی، قطع‌کننده مدار اجازه می‌دهد تا تعداد محدودی از آزمایش‌ها انجام شود و در صورت موفقیت آمیز بودن این درخواست‌ها، کلید مدار به حالت عادی باز می‌گردد. در غیر این صورت اگر شکستی وجود داشته باشد، دوره زمانی دوباره شروع می‌شود.

4-3-10. الگوی طراحی Decomposition

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

4-4. روش‌های استقرار میکروسرویس

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

برنامه‌های Microservice می‌توانند به شیوه‌های مختلفی اجرا شوند که هر کدام دارای ساختارها، هزینه و مبادلات متفاوتی هستند. احتمالا شیوه‌ای که برای استقرار برنامه‌های کاربردی کوچک مناسب باشد. این در حالی است که برای سیستم‌های مقیاس بزرگ کافی نخواهد بود.

به طور کلی پنج شیوه اجرا میکروسرویس‌ها از ساده تا پیچیده به شرح زیر است:

• یک ماشین، چند فرآیند: خرید یا اجاره سرور و اجرای میکروسرویس‌ها به عنوان فرآیند.
• ماشین‌های چندگانه و فرآیندهای متعدد: اضافه کردن سرورهای بیشتر و توزیع بار جهت مقیاس‌پذیری و در دسترس بودن بیشتر است.
• کانتینرها: پکیج کردن میکروسرویس‌ها در داخل یک کانتینر، استقرار و اجرای آن را همراه با سایر سرویس‌ها آسان‌تر می‌کند. همچنین اولین قدم به سمت Kubernetes است.
• ارکستراتور: ارکستراتورهایی مانند Kubernetes یا Nomad پلتفرم‌های کاملی هستند که برای اجرای هزاران کانتینر به طور همزمان طراحی شده‌اند.
• بدون سرور: به ما امکان می‌دهد تا فرآیندها، کانتینرها و سرورها را فراموش کنیم و کد را مستقیماً در فضای ابری اجرا کنیم.

4-4-1. یک ماشین و چند فرآیند

در ابتدایی‌ترین سطح می‌توان یک برنامه میکروسرویس را به عنوان چندین فرآیند روی یک ماشین اجرا کرد. هر سرویس به پورت متفاوتی گوش می‌دهد و از طریق یک رابط loopback ارتباط برقرار می‌کند.

این روش ساده مزایایی از جمله موارد زیر را به همراه دارد:

• سبک وزن. هیچ سرباری وجود ندارد زیرا تنها فرآیندها روی سرور اجرا می‌شوند.
• راحتی: یک راه عالی برای آزمایش و بررسی میکروسرویس‌ها بدون نیاز به یادگیری و استفاده از ابزارهای دیگر است.
• عیب‌یابی آسان. تمامی میکروسرویس‌ها در یک سرور قرار دارند، بنابراین در صورت بروز مشکل، یافتن یک مشکل یا بازگشت به پیکربندی اولیه کار بسیار ساده‌ای است.
• مشخص بودن هزینه‌ها. می‌دانیم هر ماه چه میزان باید هزینه بابت سرور پرداخت کنیم.
• هیچ محدودیتی در منابع وجود ندارد. هر فرآیند میکروسرویس می‌تواند هر مقدار از CPU یا حافظه را مصرف کند. اما نکته منفی ماجرا این است که می‌تواند منجر به گرسنگی سایر فرآیندها برای دسترسی به منابع اشغال شده شود.

به طور کلی این روش استقرار بهترین گزینه برای یادگیری اصول اولیه میکروسرویس‌ها است.

4-4-2. ماشین‌های چندگانه و فرآیندهای متعدد

این شیوه در واقع بهبود یافته روش قبل است. هنگامی که برنامه از ظرفیت یک سرور فراتر می‌رود، می‌توان مقیاس را افزایش داد یا به صورت جانبی سرورهای بیشتری اضافه کرد. در مورد میکروسرویس‌ها مقیاس به دو یا چند ماشین منطقی‌تر است. به طور کلی با داشتن یک setup توزیع شده، می‌توان با ارتقاء سرورها، مقیاس را افزایش داد.

با این حال مقیاس‌بندی مشکلاتی و سوالاتی را به همراه دارد از جمله اینکه:

• فرآیند عیب‌یابی بسیار پیچیده‌تر و دشوارتر می‌شود.
• چگونه لاگ فایل بین سرور‌های توزیع شده را با هم مرتبط کنیم؟
• شیوه برخورد و پاسخ‌دهی در زمان ترافیک بالا چگونه باشد؟

4-4-3. استقرار میکروسرویس‌ها با کانتینر

در حالی که اجرای میکروسرویس‌ها به عنوان فرآیند بسیار کارآمد است،‌ اما هزینه زیادی را به شرح زیر به همراه دارد.

• سرور باید به دقت با وابستگی‌ها و ابزارهای لازم نگهداری شود.
• یک فرآیند می‌تواند تمام حافظه یا CPU را مصرف کند.
• استقرار و نظارت بر میکروسرویس‌ها فرآیندی دشوار است.

همه این کاستی‌ها را می‌توان با کانتینر برطرف کرد. کانتینرها بسته‌هایی هستند که تمام نیازمندی‌های لازم برای اجرای برنامه را فراهم می‌کنند. یک Container Image یک واحد مستقل است که می‌تواند روی هر سروری بدون نیاز به نصب هیچ گونه وابستگی یا ابزاری اجرا شود.

کانتینرها فقط مجازی‌سازی کافی برای اجرای نرم افزار را به صورت مجزا فراهم می‌کنند. با استفاده از آنها می‌توان به مزایای زیر دست یافت:

• ایزوله‌سازی. هر فرآیند از سیستم عامل و سایر فرآیندها جدا می‌شود. در واقع کانتینر دارای یک سیستم فایل خصوصی است. بنابراین تداخل وابستگی غیرممکن است.
• همزمانی. می‌توان چندین نمونه از یک تصویر کانتینر را بدون تداخل اجرا کرد.
• سربار کمتر. از آنجایی که نیازی به بوت کردن کل سیستم عامل نیست، کانتینرها بسیار سبک‌تر از VM ها هستند.
• استقرار بدون نصب. برای نصب کانتینر تنها به دانلود و اجرای image نیاز است.
• کنترل منابع. می‌توان محدودیت‌های CPU و حافظه را روی کانتینرها قرار داد تا سرور را بی‌ثبات نکنند.

به طور کلی کانتینرها را به دو صورت می‌توان اجرا کرد: مستقیما روی سرورها یا از طریق یک سرویس مدیریت شده.

4-4-4. کانتینرهای بدون سرور

این روش مانند مانند AWS Fargate و Heroku امکان اجرای برنامه‌های کانتینری را بدون نیاز به سروکار داشتن با سرورها فراهم می‌کند. تنها container image را می‌توان به سرویس‌دهنده ابری ارائه کرد. سرویس‌‌دهنده بقیه موارد مانند تهیه ماشین‌های مجازی، دانلود، شروع و نظارت بر image ها را بر عهده خواهد داشت. این خدمات مدیریت شده معمولاً شامل یک loadbalancer داخلی است.

برخی از مزایای سرویس کانتینر مدیریت شده به شرح زیر است:

• نبود سرور. دیگر نیازی به نگهداری و اتصال سرورها نیست.
• استقرار آسان. تنها با ساخت یک container image به سرویس‌دهنده دستور استفاده از آن را می‌دهیم.
• مقیاس خودکار. ارائه‌دهنده ابر می‌تواند ظرفیت بیشتری را در صورت افزایش تقاضا فراهم کند یا وقتی ترافیک وجود ندارد همه کانتینرها را متوقف کند.

با این حال نکات منفی هم وجود دارد از جمله اینکه:

• منابع محدود. سرویس‌های مدیریت شده محدودیت‌های CPU و حافظه را اعمال می‌کنند که نمی‌توان از آنها اجتناب کرد.
• کنترل کمتر. در این شیوه سطح کنترلی کمتری نسبت به سایر گزینه‌ها داریم. به عنوان مثال اگر به یک functionality نیاز داشته باشیم که توسط سرویس‌دهنده ارائه نشده باشد آنگاه دچار مشکل خواهیم شد.

4-4-5. ارکستراتور

ارکستراتورها پلتفرم‌هایی هستند که در توزیع بار کاری کانتینر بر روی گروهی از سرورها به کار برده می‌شوند. مشهورترین ارکستراتور Kubernetes است، یک پروژه منبع باز که توسط گوگل ایجاد شده است. ارکستراتورها علاوه بر مدیریت کانتینر، ویژگی‌های شبکه مانند مسیریابی، امنیت، تعادل بار، و گزارش‌های متمرکز را نیز شامل می‌شوند.

کوبرنتیز توسط همه ارائه دهندگان سرویس ابری پشتیبانی می‌شود و یک پلتفرم عملی برای استقرار میکروسرویس است.

4-4-6. به کارگیری میکروسرویس‌ها به عنوان توابع بدون سرور

توابع بدون سرور از تمام مواردی که تاکنون در مورد آن صحبت کردیم فاصله دارد. به جای سرورها، فرآیندها یا کانتینرها، از کلود برای اجرای کدهای درخواستی استفاده می‌کنیم. ارائه‌های بدون سرور مانند AWS Lambda و Google Cloud Functions تمام جزئیات زیرساخت مورد نیاز برای سرویس‌های مقیاس‌پذیر و در دسترس را مدیریت می‌کنند و به توسعه دهندگان این امکان را می‌دهند تا تنها روی کد نویسی تمرکز داشته باشند.

جنبه‌های مثبت این روش شامل:

• سهولت استفاده. می‌توان توابع را بدون کامپایل یا ساختن container image اجرا کرد.
• مقیاس‌پذیری آسان. سرویس‌دهنده‌‌ی ابری منابع کافی برای مطابقت با تقاضا را فراهم می‌کند.
• پرداخت هزینه به ازای میزان استفاده از سرویس ارائه شده توسط سرویس دهنده ابری.

اما با این حال نقاط ضعفی وجود دارد که می‌تواند قابل توجه باشد و برای برخی از انواع میکروسرویس‌ها نامناسب باشد:

• منابع محدود. هر تابع دارای محدودیت حافظه و زمانی است. بنابراین نمی‌توانند برای فرآیندهایی که اجرای طولانی دارند به کار گرفته شوند.
• ممکن است سرویس‌دهنده تنها از چند زبان پشتیبانی کند. بنابراین ممکن است مجبور به استفاده و بکارگیری زبانی شویم که با آن راحت نیستیم.

بنابراین همان طور که بررسی شد بهترین روش برای استقرار و اجرای یک برنامه میکروسرویس به عوامل زیادی بستگی دارد و ما بایستی براساس نیاز و توجه به مزایا و معایب هر روش و همچنین تعداد میکروسرویس‌ها روش مناسب را انتخاب کنیم.

4-5. ویژگی‌های کیفی

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

4-5-1. ارتباط بین الگوهای طراحی معماری میکروسرویس و ویژگی‌های کیفی

امروزه الگو‌های متنوعی برای معماری میکروسرویس ارائه شده است. با این حال نگاشتی بین ویژگی‌های کیفی و الگوها مشخص نیست. به طور کلی در انتخاب معماری بایستی تعادل بین ویژگی‌های کیفی و مزایای ارائه شده توسط معماری را در نظر گرفت. در جدول 1-4 نوع معماری الگوی‌های طراحی و در جدول 2-4 نیز الگوی طراحی و مهمترین ویژگی‌های کیفی که پوشش می‌دهند بیان شده است.

5. معرفی شرکت‌های ارائه دهنده‌ی API Gateway الگوی طراحی و معماری آن

شرکت‌های مختلفی وجود دارند که خدمات API Gateway را ارائه می‌دهند در این بخش به معرفی معروف‌ترین شرکت‌های ایرانی و خارجی فعال در این حوزه می‌پردازیم :

5-1. شرکت‌های ایرانی

5-1-1. شرکت وصل

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

5-1-2. ابر درسا

سرویس API Gateway این شرکت با تخصیص یک پنل به مشتری این امکان را می‌دهد تا برای دسترسی به هر صفحه تعیین کند درخواست‌ها به کدام سرور ارسال شوند. به طور کلی ویژگی‌های محصول ارائه شده این شرکت به شرح زیر است:

• سرویس API Gateway این شرکت قادر است فارغ از اینکه سیستم تجاری مشتری در ابر درسا است یا خیر، سیستم تجاری مشتری را مدیریت کند.
• این سرویس به خوشه‌های کوبرنتیز اجازه دسترسی می‌دهد که منجر به بهبود قابلیت‌های سرویس خوشه‌های کوبرنتیز خواهد شد.

5-1-3. شرکت پلتکو

پلتفرم پلتکو راهکار و ابزاری برای اصلاح و ارتقاء سریع زیرساخت فناوری اطلاعات سازمان‌ها است. از جمله ویژگی‌های این پلتفرم به شرح زیر است:

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

5-2. شرکت‌های خارجی

در این بخش سعی داریم تا پلتفرم‌های مدیریت API ارائه شده توسط شرکت‌های خارجی را بررسی کنیم. در ادامه هر یک را نام برده و به مزایا و معایب آنها نیز اشاره می‌کنیم.

5-2-1. پلتفرم Kong Gateway

یکی دیگر از شرکت‌های معروف مدیریت حوزه API ها Kong است که یک ارکستراسیون برای API میکروسرویس‌هاست، که یک لایه انتزاعی و انعطاف پذیر جهت ارتباط ایمن بین مشتری و ارائه دهنده خدمات ارائه می‌کند. همچنین به عنوان یک API Gateway، یا یک میان افزار و یا یک سرویس مش شناخته می‌شود. از ویژگی‌های آن می‌توان به مواردی چون : سریع، مقیاس پذیر ، بوم- ابر توزیع شده، مستقل از سکو ، مدلهای لایسنس ، نسخه تجاری و نسخه منبع باز اشاره کرد.

معماری Kong از افزونه‌های مختلفی ایجاد شده است.

• افزونه‌های اصلی
• افزونه‌های سفارشی

اکثر محصولات متن باز بر پایه افزونه هستند. یعنی به جای اینکه یک محصول باشند یک اکوسیستم هستند. هسته افزونه را می‌نویسد و خود kong این‌ها را به عنوان افزونه اصلی پیاده‌سازی می‌کند و همچنین اجازه می‌دهد افراد و شرکت‌های ثالث یکسری افزونه دیگر حول افزونه اصلی بنویسند. همچنین هنگام استفاده از kong می‌توان برحسب نیازمندی‌ها افزونه‌ها‌ی مورد نیاز را که پیاده‌سازی نشده است را شناسایی و درخواست پیاده‌سازی افزونه را از شرکت kong داشت. البته شرکت استفاده کننده خود نیز د صورت امکان و پیاده‌سازی افزونه ‌می‌تواند آنرا به kong به عنوان یک افزونه اضافه کند.

ویژگی ها و امکانات اصلی kong در قالب هشت دسته افزونه :

• افزونه های احراز هویت
• افزونه های امنیت
• افزونه های کنترل ترافیک
• افزونه های معماري
• افزونه های نظارت و آنالیز
• افزونه های تبدیل
• افزونه های ورود به سیستم
• افزونه های استقرار

5-2-2. پلتفرم WSO2

یک میان افزار (middleware) که نرم افزار مدیریت API را به صورت متن باز (Open Source) ارائه می‌کند و به کاربران اجازه میدهد تا APIهای خود را در این محیط طراحی ، استقرا و نگهداری کنند. این محصول قابلیت استفاده در فضای ابری را نیز دارد. همچنین WSO2 انواع محصولات میان افزاری را برای نیازهای مختلف و ساده‌سازی محصولات تجاری دارد. سیستم‌های هر سازمان با داده‌های داخلی و خارجی زیادی سروکار دارد و از WSO2 قابلیت‌های آن برای دسترسی صحیح به داده‌ها (big data ) توسط سازمان‌ها استفاده می‌شود.

معماری WSO2 برپایه یکپارچه‌سازی پایه‌گذاری شده است و این قابلیت را در اختیار کاربران می‌گذارد تا APIهای مختلف داخلی و خارجی خود را به آسانی ادغام و از محصولات WSO2 برای توسعه و استفاده مجدد از اجزا و مدیریت یکپارچه‌سازی در فضای ابری استفاده کنند.

محصولات WSO2 به شرح زیر است:

5-2-2-1. یکپارچه‌سازی سازمانی

هسته پلتفرم wso2 است. یک محصول منبع باز برای یکپارچه سازی container-native و cloud-native که شامل contains-message و ابزارهای بصری Visual tool و مدلسازی فرآیند کسب و کار و ابزارهای تجزیه و تحلیل است. WSO2 EI به کاربران امکان انتخاب بین دو حالت گرافیکی drag-and-drop و configuration-drive را میدهد.

5-2-2-3. سرویس باس سازمانی

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

5-2-2-4. خدمات هویتی

برای مدیریت بار و دسترس‌پذیری استفاده می‌شود. مدیریت identity، امنیت، حریم خصوصی privacy، یک تجارت الکترونیک و دیجیتال را ممکن می‌سازد. همچنین بدون در نظر گرفتن استانداردها و ساختار هر پلتفرم هویت‌های مختلف را در چندین برنامه و در فضای ابری هم متصل و کنترل می‌کند. همچنین از طریق WSO2 identity server کاربران می‌توانند از مکان‌های مختلف لاگین و بهره‌وری کاربران را از سیستم افزایش داد.

5-2-2-5. مدیریت API

یک راه‌حل مدیریت API است که چرخه حیات کامل APIها را مدیریت و تولید می‌کند. همچنین دارای اپراتورهای Kubernets جهت تسهیل تبدیل میکروسرویس‌های خام به APIاست. WSO2 در هر محیط ابری مانند ابرهای خصوصی، ابرهای ترکیبی قابل اجرا است.

5-2-2-6. سرویس اینترنت اشیا

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

5-2-2-7. سرور آنالیز دیتا

به کاربران این امکان را میدهد از اطلاعات تجاری در زمان واقعی بهره‌مند شوند‌. علاوه بر این سرور تجزیه و تحلیل داده‌های WSO2، راه‌حل خود را برای ارائه تجزیه و تحلیل فرآیندهای گذشته و حال را گسترش میدهد و به کاربران اجازه میدهد تا با یادگیری از گذشته از بهبود عملیات‌های آینده بهره‌مند شوند. از طرفی به کاربران این امکان را میدهد، تا از طریق محصولات دیجیتال فرصت ایجاد منبع درآمدی جدید را فراهم کنند.

5-2-2-8. مزایای پلتفرم WSO2

• ماهیت منبع باز محصولات WSO2 موجب تسهیل توسعه و نوآوری سریع در محیط‌های مقیاس‌پذیر و قابلیت سفارشی‌سازی بدون محدودیت می‌شود.
• از آنجایی که محصولات WSO2 در فضای ابری در دسترس هستند،‌ توسعه‌دهندگان می‌توانند از این پلتفرم برای همکاری سریع در محیط‌های درخواستی استفاده کنند. در واقع این یک مزیت بزرگ برای شرکت‌ها در صنایع رقابتی محسوب می‌شود. جایی که توانایی ارائه سریع محصولات نرم افزاری به بازار می‌تواند موفقیت یا شکست بیزینس را تعیین کند.
• رویکرد منبع باز این پلتفرم تضمین می‌کند تا محصولات آنها به روز بماند و با تمام چالش‌های یکپارچه‌سازی همگام شود.
• مدل بیزینس WSO2 به مشتریان کمک می‌کند تا هزینه‌های مالکیت را به حداقل برسانند.
• پلتفرم WSO2 بروزرسانی و پشتیبانی کامل و مکرر و همچنین تست و تنظیم پیشگیرانه را جهت ارائه خدمات بهتر در نظر می‌گیرد.

5-2-3. پلتفرم apigee

یکی از محصولات قدرتمند شرکت گوگل در زمینه مدیریت API است که برای تبادل داده بین سرویس‌ها و برنامه‌های ابری استفاده می‌شود. همان طور که می‌دانید امروزه تعداد زیادی از وب سایت‌ها و خدمات از طریق API و REST ful ارائه می‌شوند. به طور کلی apigee امکان ارتباط و مدیریت API ها برای وب سایت‌ها، خدمات مختلف برای ارتقاع فناوری شبکه، مدیریت API Gateway، توسعه و استقرار برنامه‌ها را برای توسعه‌دهندگان ساده‌تر می‌کند. همچنین کمک می‌کند تا API Gateway اختصاصی خود ایجاد کنید.

5-2-3-1. مهمترین ویژگی‌های apigee

• اتصال ایمن به سکوی ابری: این نرم افزار از سکوهای ابر نظیر Google Cloud و AWS پشتیبانی می‌کند. از آنجایی که تعداد بسیاری زیادی از پروژه‌ها در فضای بیزینس از سرورهای این کمپانی‌ها استفاده می‌کنند، فراهم کردن اتصال ایمن با رابط کاربری مناسب از مزایای مهم این نرم‌ افزار تلقی می‌گردد.
• همچنین با این نرم افزار از قابلیت تشخیص به موقع تهدیدات امنیتی برخوردار است و به شما این امکان را میدهد تا API خود را در مقابل این تهدیدات ایمن نگه دارید. به عنوان مثال با کمک این نرم افزار میتوان از رخداد نقض داده‌ها جلوگیری کرد. نقض داده‌ها به نقص امنیتی گفته می‌شود که یک داده محرمانه، مهم یا محافظت شده توسط شخصی کپی، مشاهده یا منتقل می‌شود. این درحالی است که اصالت آن شخص برای دسترسی به آن داده محرز نیست یا به عبارت بهتر شخص اجازه‌ی مشاهده یا انجام چنین کاری را ندارد.
• شایان ذکر است که تجربه‌ی کاربری توسعه‌دهندگان از استفاده‌ی این سامانه بسیار مطلوب گزارش شده و این خود عامل مهمی در به کار گیری این محصول تلقی میگردد.
• همچنین این محصول با استفاده از هوش مصنوعی ویژگی را در اختیار کاربران خود قرار میدهد تا با اعمال بر داده API ها، پیش‌بینی از رفتار API ها داشته باشید و ناهنجاری‌های مرتبط با API ها را را به موقع و به سرعت تشخیص دهید. همین دلیل با استفاده از این محصول، با درصد بالایی می‌توان اطمینان حاصل کرد که تجربه‌ی کاربران نهایی در تعامل با API ها همان تجربه‌ای است که توسعه‌دهندگان از فعالیت با API ها دارند که نیازمند جمع آوری و تحلیل اطلاعات گوناگون است.

5-2-3-2. دلایل استفاده از apigee

• پروکسی‌های API را می‌توان به راحتی ایجاد کرد. همچنین قوانین مورد نیاز برای هر API را می‌توان به صورت گرافیکی و یک جریانی از API ها ایجاد و آن‌ها را پیکربندی کرد.
• قوانینی را از نظر امنیت API ها بطور مداوم اعمال و بررسی می‌کند.
• فرآیند تولید Apigee edge به صورت سه مرحله‌ای است که همین باعث می‌شود محدودیت‌های دسترسی را به صورت قابل استفاده مجدد ایحاد کنید.
• از روش‌های real-time برای تجزیه و تحلیل افزایش ترافیک، اطلاعات ترافیک API و پیگری درخواست‌های API استفاده می‌کند.
• مدل‌های نو آورانه برای ایجاد امکانات جدید، رشد API ها و امکاناتی فراتر از مدل‌های کسب‌وکار موجود ارائه می‌کند.

5-2-3-3. مزایای apigee

عملکرد و ردیابی قویی، ارائه مجموعه‌ای از ویژگی‌های امنیتی، ارائه یک پلتفرم برای همه تخصص‌ها برای ایجاد API، مقیاس پذیر بودن از جمله مهمترین ویژگی‌های آن است. همچنین سازگاری بالایی برای استقرار سریع معماری نرم افزار در بستر clod را امکان پذیر می‌کند.

5-2-3-4. معایب apigee

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

5-2-4. پلتفرم 3SCALE

این پلتفرم محصول Red Hat می‌باشد و امکاناتی به شرح زیر برای شرکت‌های بزرگ و کوچک فراهم می‌کند:

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

5-2-5. پلتفرم Akana

یک پلتفرم منبع باز که به کمک آن می‌توان APIها را طراحی، پیاده‌سازی، نظارت و منتشر کرد. برخی از مهمترین ویژگی‌های این پلتفرم به شرح زیر است:

• کمک به مدیریت ترافیک
• با شناسایی آسیب‌پذیری‌های کد امنیت برنامه را در طول زمان اجرا تضمین می‌کند.
• مدیریت میکروسرویس‌ها و DevOps
• حفاظت در مقابل تهدیدات

5-2-6. پلتفرم API Umbrella

این پلتفرم سازمان را قادر می‌سازد تا تحت یک چتر واحد با اعطای مجوز‌های مدیریتی مختلف در دامنه‌های متنوع فعالیت کنند. از جمله امکانات این پلتفرم‌:

• دسترسی به یک رابط وب مدیریتی
• کلید API
• محدودسازی نرخ دسترسی و درخواست
• کش کردن
• آنالیز بصورت لحظه‌ای

5-2-7. پلتفرم APIman

یکی از بهترین پلتفرم‌های مدیریت API که توسط شرکت Red Hat ارائه شده است. این پلتفرم یکی از گزینه‌های مناسب برای پشته فناوری برنامه است چرا که فرصت‌های زیادی را در اختیار توسعه‌دهندگان قرار می‌دهد از جمله:

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

5-2-8. پلتفرم Gravitee

یک پلتفرم منبع باز که ماهیت انعطاف‌پذیر و سبک وزن دارد. از جمله ویژگی‌های بارز این محصول می‌توان به موارد زیر اشاره کرد:

• اشتراک گذاری Cross-origin resource
• گزینه‌های plug and play
• فیلترینگ IP
• محدودسازی نرخ درخواست
• ارائه گزارش‌های دقیق جهت درک داده‌های مورد استفاده‌ی API

5-2-9. پلتفرم DreamFactory

پلتفرم DreamFactory یکی از محبوب‌ترین پلتفرم‌های منبع باز است که ویژگی‌های به شرح زیر برای توسعه‌دهنگان فراهم می‌کند:

• درخواست‌های JSON‌ را بلافاصله به SOAP تبدیل می‌کند و برعکس.
• ارائه یک REST API دقیق برای دیتابیس‌های SQL
• دسترسی به پارامتر‌های API برای صفحه‌بندی
• فیلتر‌های پیچیده و کلید‌های خارجی مجازی
• توسعه‌دهندگان را قادر می‌سازد تا هر دیتابیس SQL/NoSQL، سرویس HTTP/SOAP خارجی یا سیستم ذخیره‌سازی فایل را در محیط DreamFactory ادغام کنند.

5-3. معیارهای انتخاب یک پلتفرم API Gateway

• ترجیحا پلتفرمی انتخاب شود که پشتیبانی و انجمن بزرگی را داشته باشد. در اینصورت شانس پاسخ دهی به سوالات و بروزرسانی پلتفرم نیز بیشتر خواهد بود.
• مهمترین عامل انتخاب یک پلتفرم ویژگی‌هایی است که ارائه می‌دهد. هر پلتفرم API Gateway الزامات و محدودیت‌های پیاده‌سازی خاصی را دارد که بررسی آنها از جنبه‌های فنی و غیر فنی می‌تواند تاثیر گذار باشد.
• ترجیحا پلتفرمی انتخاب شود که پیچیدگی استقرار کمتری دارد. برخی از پلتفرم‌های API Gateway برای راه اندازی پایگاه‌ها به یک نود و برخی نیز به چندین نود نیاز دارند.

نتیجه گیری

امروزه سیستم‌های کامپیوتری بخش قابل توجهی از صنعت را تشکیل می‌دهند. این سیستم‌ها می‌توانند مزیت‌های قابل توجهی را برای ذینفعان خود ایجاد کنند. با توجه به گسترش روز افزون صنعت، نرم افزارها پیچیده‌تر می‌شوند و مدیریت آن‌ها نیازمند دانش‌های جدید است، با گذشت زمان برای بهبود عملکرد و ارتباط بین سازمان‌های مختلف بحث API ها مطرح شده است که امروزه به صورت کاملا فراگیر با پروتکل‌های مختلف در همه سازمان‌ها وجود دارد، به همین دلیل برای مدیریت بهتر ارتباطات امروزه بحث خدمات API Gateway ها بسیار اهمیت پیدا کرده است. به همین دلیل معماری آن‌ها نیز پر اهمیت می‌شود زیرا هرچه API Gateway ها ویژگی‌های کیفی بیشتری را توسط معماری را در خود جای دهند خدمات با کیفیت‌تری ارائه می‌دهند و مشتریان بیشتری را می‌توانند جذب کنند. پس API ها از جنبه تجاری نیز بسیار پر اهمیت شده‌اند و بازار کسب‌وکار جدیدی را صنعت نرم افزار ایجاد کرده‌اند که معماری بهتر API Gateway ها و ارائه ویژگی‌های بیشتر باعث ایجاد فضای رقابتی بین شرکت‌های ارائه دهنده خدمات API Gateway شده است.

مراجع

[1]D. Jacobson, D. Woods, and G. Brail. Apis: A strategy guide. O’Reilly, 2012.

[2]J. T. Zhao, S. Y. Jing, and L. Z. Jiang, “Management of api gateway based on micro-service
architecture,” Journal of Physics: Conference Series, vol.1087, p.032032, 2018.

[3]B. De. API management: An architect’s guide to developing and managing apis for your
organization. Apress, 2017.

[4] Sam Newman, Building Microservices, OREILLY, 2021.

[5]K. Brush, “What is wso2,” Dec 2019.

[6] J.A. Validivia, A. Lora-Gonzalez, X.Limon, "Patterns Related to Microservice Architecture: a
Multivocal Literature Review," Springer,pp. 594-608, 2020.

[7] Akhan Akbulut, Harry G. Perros , "Performance Analysis of Microservice Design
Patterns,"IEEE, pp. 19-27, 2019.

[8] Jose A.Valdivia, Xavier Limon, Karen Cortes-verdin "Quality attributes in patterns related to
microservice architecture: a Systematic Literature Review," IEEE, pp. 23-25, 2020.

[9] https://www.nginx.com/learn/api-gateway/

[10] https://www.redhat.com/en/topics/api/what-does-an-api-gateway-

[11] https://appinventiv.com/blog/open-source-api-management-tools/

[12] http://vasl.ir/platform/api-management/

[13] https://dorsacloud.com/

[14] Performance Analysis of Microservices Design Patterns

[15] https://wso2.com/

[16] https://microservices.io/

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»

تهیه و تدوین این مطلب با همکاری همکلاسی بنده خانم سعیده هیکلی انجام شده است .