https://virgool.ir/feed/@alirezarashnouskfa2026-11-11 10:03:42https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@alirezarashnouskhttps://virgool.ir/@alirezarashnousk/مروری-بر-مفهوم-api-gateway-و-معماری-نرم-افزار-آن-vsge3zzuqq9cچکیدهامروزه به دلیل رشد روز افزون سامانه‌های نرم افزاری و افزایش خدمات الکترونیک در سازمان‌های مختلف، سامانه‌های نرم افزاری مورد توجه و استفاده عموم مردم قرار گرفته است. گاهی برای ارائه یک خدمت لازم است دو یا چند سامانه نرم افزاری با یک دیگر به‌صورت یکپارچه در ارتباط باشند تا در نهایت یک خدمت متناسب را به کاربران خود ارائه دهند. در جهت بالا رفتن کیفیت ارتباطات بین سامانه‌های نرم افزاری مفهوم 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 در جهت ارتباط سیستم با سیستم است. همچنین هردو برای محصورسازی منطق و پیچیدگی‌های یک سیستم می‌باشند. یکی دیگر از ویژگی‌های 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‌ها و کاربران قرار می‌گیرد و ارتباط بین آن‌ها را مدیریت می‌کند.API Gateway3. معرفی معماری داخلی 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 در صورت تغییر هر میکروسرویس یا API4. معماری میکروسرویسدر این بخش ابتدا به تعریف معماری میکروسرویس و سپس کاربرد این معماری در پیاده‌سازی API Gateway‌ها و در نهایت هم به روش‌هایی جهت پیاده سازی بهتر این سبک از معماری می‌پردازیم :ساختار معماری میکروسرویس4-1. تعریف معماری میکروسرویسامروزه یکی از معماری‌های رایج و پرکاربرد معماری میکروسرویس است. این معماری در جهت شکستن سیستم به بخش‌های کوچک و هر بخش در قالب یک سرویس تعریف و پیاده‌سازی می‌شود. معماری میکروسرویس متشکل از مجموعه‌ای از خدمات کوچک است که هر سرویس صرفا یک کار واحد را انجام می‌دهد. همچنین یک سبک معماری معروف برای ساخت برنامه‌هایی که نیاز به انعطاف پذیری، مقیاس پذیری، استقلال در استقرار دارند بسیار پر کاربرد است. سرویس‌ها را می‌توان بصورت توزیع شده، پیاده‌سازی و مستقر کرد. همچنین هریک از آن‌ها می‌توانند پایگاه داده مخصوص به خود را داشته باشند. همچنین هریک از سرویس‌ها از طریق API می‌توانند باهم ارتباط برقرار کنند. به همین دلیل خاطر پیاده‌سازی آن‌ها از سایر سرویس‌ها پنهان می‌ماند.با توجه به اینکه میکروسرویس بر پایه API کار می‌کند می‌توان نتیجه گرفت که تنها معماری مورد استفاده در API Gateway‌ها معماری میکروسرویس است. اما می‌توان معماری میکروسرویس را با روش‌هایی که در ادامه معرفی می‌کنیم جهت رسیدن به نتیجه مطلوب با توجه به نیازمندی مطرح شده، بهبود داد.از جمله ویژگی‌های برتر معماری میکروسرویس می‌توان به موارد زیر اشاره کرد :چابکی : همانطور که گفتیم میکروسرویس‌ها را می‌توان به صورت مستقل مستقر کرد. به همین دلیل خطایابی و رفع خطاهای سرویس‌ها به راحتی انجام می‌شود همچنین بروزرسانی و نگهداری از آن‌ها نیز بهتر می‌شود. هنگام بروز خطا در سیستم فقط سرویس دچار خرابی متوقف می‌شود و دیگر نیاز نیست کل سیستم متوقف شود.وجود تیم‌های کوچک و متمرکز : میکروسرویس‌ها می‌توانند توسط تیم‌های مجزا و کوچیک طراحی، تولید و تست شوند. گاهی کوچک بودن تیم باعث می‌شود تیم منسجم‌تر باشد و بازدهی بیشتری داشته باشند. از طرفی هرچه تیم‌ها بزرگتر باشند مدیریت و ارتباط همه افراد هزینه‌بر و سخت‌تر می‌شود.پایه اصلی کدها کوچک و سبک است : در یک برنامه یکپارچه به مرور زمان سرویس‌ها نیاز به تغییر و یا ادغام با سایر سرویس‌ها را دارند این سبک معماری وابستگی بین کدها را به حداقل می‌رساند و باعث می‌شود هنگام تغییرات، فقط بخش کوچکی از کد را تغییر داد‌‌.استفاده از فناوری‌های مختلف : تیم‌ها می‌توانند با توجه به فناوری‌های موجود با توجه به شرایط سرویس بهترین فناوری را جهت ارائه بهتر خدمات انتخاب و استفاده کنند.مقیاس پذیری : سرویس‌ها را می‌توان به صورت مستقل مقیاس‌بندی کرد. به این صورت که اگر یک سرویس نیاز به منابع بیشتری داشت فقط منابع همان سرویس را افزایش داد. زیرا اگر منابع کل سیستم افزایش یابد ممکن است حجم زیادی از آن بدون استفاده باقی بماند.در بخش بعد اصول طراحی و نکات پیاده‌سازی معماری میکروسرویس‌ را بررسی می‌کنیم.4-2. اصول طراحی و نکات پیاده‌سازی معماری میکروسرویس به طور کلی قبل از پیاده‌سازی معماری میکروسرویس برای جلوگیری از یکسری مشکلات ابتدا به یکسری اصول طراحی و نکات پیاده‌سازی توجه کرد. توجه به نکات پیاده‌سازی تا حدی در انتخاب تکنولوژی‌های مورد استفاده تاثیر گذار است. در ادامه هر یک از موارد مطرح شده را بررسی می‌کنیم.به طور کلی برای پیاده‌سازی میکروسرویس ها باید چند نکته را به شرح زیر در نظر گرفت: ارتباط بین سرویس‌ها synchronize یا asynchronize باشد. در ارتباط asynchronize از مواردی چون پروتکل mqtt و صف پیام استفاده می‌شود تا سرویس‌ها بتوانند در زمان مناسب پیام‌های خود را بردارند. اما در ارتباط synchronize از پروتکل‌هایی مانند rest استفاده می‌شود.رابطه بین میکروسرویس‌ها چند به چند باشد؟ به عنوان مثال سرویس گزارش‌گیری رابطه یک به n است. زیرا یک سرویس از n سرویس دیگر باید گزارش بگیرد. همچنین ارتباط بین سرویس‌ها و دیتابیس‌ها نیز باید تعیین شود.از طرفی انتخاب تکنولوژی تا حد خیلی زیادی به ارتباط بین میکروسرویس‌ها بستگی دارد.همچنین برای استفاده از معماری میکروسرویس در توسعه‌ی یک نرم افزار باید به یک سری اصول طراحی به شرح زیر توجه داشته باشیم:خدمات مستقل و خود مختارمقیاس پذیریتمرکززداییخدمات انعطاف پذیربالانس کردن load در زمان واقعیتحویل مستمر با استفاده از DevOpsیکپارچه سازی API و پایش مستمرایزوله کردن از Failurها4-3. الگوهای طراحی میکروسرویسامروزه میکروسرویس‌ها به راه حلی رایج برای ساخت اپلیکیشن تبدیل شده‌اند. معماری‌های میکروسرویس برای حل چالش‌های مختلف شناخته شده‌ا‌ند. با این حال متخصصان ماهر اغلب در هنگام استفاده از این معماری با چالش هایی مواجه می‌شوند. بنابراین در عوض، توسعه‌دهندگان می‌توانند مشکلات رایج الگوها را کشف کنند و راه‌حل‌های قابل استفاده مجدد برای بهبود عملکرد برنامه ایجاد کنند. در ادامه اصول مورد استفاده برای طراحی معماری میکروسرویس و الگوهای طراحی میکروسرویس‌ها را بررسی می‌کنیم.به طور کلی الگوی‌های طراحی معماری میکروسرویس‌ها را می‌توان به چندین روش به شرح زیر تقسیم کرد. در ادامه هر یک از موارد زیر با جزئیات بیشتری بررسی خواهم کرد.AggregatorAPI GatewayChained or Chain of ResponsibilityAsynchronous MessagingDatabase or Shared DataEvent SourcingBranchCommand Query ResponsibilitySegregatorCircuit BreakerDecomposition4-3-1. الگوی Aggregatorدر الگوهای میکروسرویس , اگرگیتور یک صفحه وب پایه است که خدمات مختلفی را برای کسب اطلاعات مورد نیاز و یا دستیابی به قابلیت‌های مورد نیاز را فرا می‌خواند. به طور کلی الگوی اگرگیتور زمانی استفاده می‌شود که ترکیبی از داده‌های چندین سرویس برای خروجی نیاز باشد.بنابراین، اگر ما دو سرویس داشته باشیم که هر کدام دارای پایگاه اطلاعاتی خود باشند، آنگاه یک اگرگیتور با شناسه تراکنش منحصر به فرد، داده‌ها را از هر یک از میکروسرویس‌ها جمع‌آوری می‌کند، منطق کسب‌وکار را بکار می‌برد و در نهایت آن را به عنوان نقطه پایانی REST منتشر می‌کند. سپس داده‌های جمع‌آوری‌شده را می‌توان با توجه به خدمات مربوطه استفاده کرد. این الگوی کلی طراحی براساس اصل DRY است. براساس این اصل، می‌توان منطق را در میکروسرویس‌های مرکب خلاصه کرد و منطق کسب‌وکار خاص را در یک سرویس قرار داد.بنابراین،‌ برای مثال اگر دو سرویس a و b را در نظر بگیریم، می‌توان به طور جداگانه این سرویس‌ها را با ارائه داده به میکروسرویس ترکیبی مقیاس کرد.Aggregatorالگوی معماری 4-3-2. الگوی طراحی API Gatewayزمانی که یک برنامه به سرویس‌های مستقل کوچک شکسته می‌شود، ممکن است مشکلاتی به شرح زیر برای توسعه‌دهنگان برنامه به همراه داشته باشد.زمانی که ارتباط بین سرویس‌ها زیاد شود مدیریت آنها کار ساده‌ای نیست.چگونه می‌توان از چند میکروسرویس درخواست اطلاعات کرد؟چگونه پروتکل‌های درخواست‌های مختلف هندل شود؟با کمک الگوی طراحی API Gateway می‌توان مسئولیت‌های زیر را بر عهده گرفت:مسئولیت authentication/authorization میکروسرویس‌هاترجمه پروتکلامنیتمانیتورینگاولویت‌بندی کاربرانبنابراین، هنگامی که مشتری درخواستی را ارسال می‌کند، این درخواست‌ها به API Gateway ارسال می‌شود که به عنوان یک نقطه ورودی برای ارسال درخواست‌های مشتری به میکروسرویس‌های مناسب عمل می‌کند. سپس با کمک لودبالانسر، بار درخواست رسیدگی شده و درخواست به سرویس‌های مربوطه ارسال می‌شود. میکروسرویس‌ها از Service Discovery استفاده می‌کنند که به عنوان راهنما برای یافتن مسیر ارتباط بین هر یک از آنها عمل می‌کند. سپس میکروسرویس‌ها از طریق گذرگاه درخواست/پیام HTTP با یکدیگر ارتباط برقرار می‌کنند.الگوی طراحی API Gateway4-3-3. الگوی طراحی Chainاین الگو در واقع زنجیره‌ای از میکروسرویس‌ها است که با دریافت یک ورودی از کاربر یک خروجی واحد را تولید می‌کند. تمام سرویس‌ها در الگوی زنجیره‌ای از پروتکل HTTP برای تبادل پیام با یکدیگر استفاده می‌کنند. به عنوان مثال اگر سه سرویس به صورت زنجیره‌ای وجود داشته باشیم، ابتدا درخواست مشتری توسط سرویس A دریافت می‌شود. سپس این سرویس با سرویس بعدی یعنی B ارتباط برقرار می‌کند و داده‌ها را جمع‌آوری می‌کند. در نهایت سرویس دوم با سرویس سوم برای تولید خروجی تلفیقی ارتباط برقرار می‌کند. تا زمانی که درخواست از تمام سرویس‌ها عبور نکند و پاسخ‌های مربوطه ایجاد نشود، مشتری هیچ خروجی دریافت نمی‌کند. بنابراین در الگو همواره توصیه می‌شود که از زنجیره‌های بلند جهت جلوگیری از افزایش انتظار کاربر برای پاسخ‌دهی سیستم جلوگیری شود.الگوی طراحی Chain4-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 برای بازیابی داده‌ها از چندین منبع استفاده کرد.الگوی طراحی Branch4-3-8. الگوی طراحی CQRSهر طراحی میکروسرویس دارای پایگاه داده اختصاصی برای سرویس‌ها یا پایگاه داده مشترک بین سرویس‌ها است. اما در مدل پایگاه داده به ازای هر سرویس نمی‌توان یک کوئری را پیاده‌سازی کرد، زیرا دسترسی به داده ها تنها به یک پایگاه داده محدود شده است. بنابراین در چنین سناریویی می‌توان از الگوی CQRS استفاده کرد. طبق این الگو، اپلیکیشن به دو بخش Command و Query تقسیم می‌شود. بخش Command تمام درخواست‌های مربوط به ایجاد، به‌روزرسانی، حذف را رسیدگی می‌‌کند در حالی که بخش Query جهت عملیاتی چون خواندن از پایگاه داده استفاده می‌شود.الگوی طراحی CQRS4-3-9. الگوی طراحی Circuit Breakerالگوی طراحی 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 نیز الگوی طراحی و مهمترین ویژگی‌های کیفی که پوشش می‌دهند بیان شده است.جدول2-4 الگوی طراحی و ویژگی کیفی پوشش داده شده // جدول 1-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 در قالب هشت دسته افزونه : افزونه های احراز هویت افزونه های امنیت افزونه های کنترل ترافیکافزونه های معماريافزونه های نظارت و آنالیز افزونه های تبدیل افزونه های ورود به سیستم افزونه های استقرار معماری Kong5-2-2. پلتفرم WSO2یک میان افزار (middleware) که نرم افزار مدیریت API را به صورت متن باز (Open Source) ارائه می‌کند و به کاربران اجازه میدهد تا APIهای خود را در این محیط طراحی ، استقرا و نگهداری کنند. این محصول قابلیت استفاده در فضای ابری را نیز دارد. همچنین WSO2 انواع محصولات میان افزاری را برای نیازهای مختلف و ساده‌سازی محصولات تجاری دارد. سیستم‌های هر سازمان با داده‌های داخلی و خارجی زیادی سروکار دارد و از WSO2 قابلیت‌های آن برای دسترسی صحیح به داده‌ها (big data ) توسط سازمان‌ها استفاده می‌شود.معماری WSO2معماری WSO2 برپایه یکپارچه‌سازی پایه‌گذاری شده است و این قابلیت را در اختیار کاربران می‌گذارد تا APIهای مختلف داخلی و خارجی خود را به آسانی ادغام و از محصولات WSO2 برای توسعه و استفاده مجدد از اجزا و مدیریت یکپارچه‌سازی در فضای ابری استفاده کنند.محصولات 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 فشرده است یعنی راه اندازی آن نسبتا هزینه بر است.apigee5-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محدودسازی نرخ درخواستارائه گزارش‌های دقیق جهت درک داده‌های مورد استفاده‌ی API5-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 or�ganization. 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/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»تهیه و تدوین این مطلب با همکاری همکلاسی بنده خانم سعیده هیکلی انجام شده است .علیرضا رشنوعلیرضا رشنوWed, 08 Feb 2023 12:47:10 +0330https://virgool.ir/@alirezarashnousk/مفهوم-api-gateway-taway18tt96qدر این پست قصد داریم ابتدا با مفهوم و کاربردهای API Gateway آشنا شویم. سپس پلتفرم‌های معروف و در نهایت شرکت‌های ایرانی فعال ارائه دهنده API Gateway را بررسی می‌کنیم.مقدمهفناوری API gateway یک ابزار مدیریتی API است که بین یک کلاینت و مجموعه‌ای از سرویس‌های پایانی (endpoint) قرار می گیرد. API gateway به عنوان یک پروکسی معکوس عمل می‌کند تا تمام فراخوانی‌های رابط برنامه نویسی برنامه (API) را بپذیرد، سرویس‌های مختلف مورد نیاز برای انجام آنها را جمع آوری کند و نتیجه مناسب را برگرداند.ابزار API gateway درخواست‌های API را از یک کلاینت می‌پذیرد، آنها را به سمت سرویس‌های مناسب هدایت می‌کند و نتایج را در قالب یک تجربه سنکرون برای کاربر ارسال می‌کند.منظور از API gateway چیست؟پلتفرم API gateway همه‌ی فراخوانی‌های API را از کلاینت‌ها می‌گیرد، سپس آنها را با مسیریابی درخواست، ترکیب و ترجمه پروتکل به میکروسرویس مناسب هدایت می‌کند. API gateway معمولاً یک درخواست را با فراخوانی چندین میکروسرویس و جمع‌آوری نتایج برای تعیین بهترین مسیر انجام می‌دهد. API gateway بین پروتکل‌های وب و پروتکل‌های web‑unfriendly که به صورت داخلی مورد استفاده قرار می‌گیرند، عمل ترجمه را انجام می‌دهد.یک سایت در حوزه‌ی تجارت الکترونیک ممکن است از یک API gateway برای ارائه نقطه پایانی (endpoint) به مشتریان تلفن همراه برای بازیابی تمام جزئیات محصول با یک درخواست واحد استفاده کند. به این صورت که خدمات مختلفی مانند اطلاعات محصول و بررسی‌ها را فراخوانی کرده و نتایج را با هم ترکیب می‌کند.چرا باید از API gateway استفاده کرد؟اکثر API های سازمانی از طریق API gateway مستقر می‌شوند. برای API gateway ها انجام وظایف مشترک در یک سیستم که از سرویس‌های API استفاده می‌کند، مانند احراز هویت کاربر، محدود کردن نرخ و آمار، امر رایجی است. در ابتدایی‌ترین حالت، سرویس API یک درخواست راه دور را می‌پذیرد و یک پاسخ را برمی‌گرداند. اما در عمل به این سادگی نیست چرا که دغدغه‌های مختلف را هنگام میزبانی API در مقیاس بزرگ بایستی در نظر گرفت:برای محافظت از API ها در مقابل استفاده بیش از حد بایستی از یک سرویس احراز هویت و محدودیت نرخ استفاده شود.برای مدیریت و بررسی نحوه استفاده مردم از APIهای سامانه بایستی از ابزارهای تجزیه و تحلیل و نظارت استفاده شود.اگر از API های درآمدزا استفاده می‌شود، باید به یک سیستم صورتحساب متصل شد.در صورت استفاده از معماری میکروسرویس گاهی یک درخواست می‌تواند نیازمند فراخوانی ده‌ها برنامه متفاوت باشد.با گذشت زمان، برخی از سرویس‌های API جدید را اضافه و برخی دیگر حذف می شوند، با این حال مشتریان همچنان می‌خواهند همه‌ی سرویس‌ها را یکجا داشته باشند.در نتیجه چالش ارائه یک تجربه ساده و قابل اعتماد در برابر این همه پیچیدگی به مشتریان می‌باشد. API gateway راهی برای جدا کردن رابط مشتری از پیاده‌سازی نقطه‌ی پایانی (backend) است. هنگامی که یک کلاینت درخواستی ارائه می‌دهد، API gateway آن را به چندین درخواست تقسیم کرده و به مکان‌های مناسب هدایت می‌کند، پاسخی تولید و سپس همه چیز پیگیری می‌شود.نقش API gateway در مدیریت APIپلتفرم API gateway بخشی از سیستم مدیریت API است. API gateway تمام درخواست‌های دریافتی را رهگیری می‌کند و آنها را از طریق سیستم مدیریت API که انواع فانکشنالیتی‌های ضروری را مدیریت می‌کند، ارسال می‌نماید. کاری که API gateway انجام می‌دهد از یک اجرا به اجرای دیگر متفاوت است. برخی از فانکشنالیتی‌های رایج عبارتند از احراز هویت، مسیریابی، محدود کردن نرخ، صورتحساب، نظارت، تجزیه و تحلیل، خط‌مشی‌ها، هشدارها و امنیت.چگونه یک API gateway از DevOps و محیط‌های بدون سرور پشتیبانی می‌کند؟در سازمان‌هایی که از رویکرد DevOps پیروی می‌کنند، توسعه‌دهندگان از میکروسرویس‌ها برای ساخت و استقرار برنامه‌ها به روشی سریع و تکراری استفاده می‌کنند. API ها یکی از رایج‌ترین راه‌های ارتباطی میکروسرویس‌ها هستند. علاوه بر این، توسعه‌ی مدرن ابر، از جمله مدل بدون سرور، به APIها برای تامین زیرساخت بستگی دارد. می‌توان توابع بدون سرور را مستقر و با استفاده از API gateway مدیریت کرد.به طور کلی، همانطور که یکپارچگی و اتصال به یکدیگر ، اهمیت می‌یابند، API‌ها نیز اهمیت بیشتری پیدا می‌کنند. به این ترتیب با افزایش پیچیدگی API و افزایش کاربرد، ارزش API gateway نیز افزایش می‌یابد.ساخت میکروسرویس با استفاده از API gatewayبرای اکثر برنامه‌های کاربردی مبتنی بر میکروسرویس، پیاده‌سازی یک API gateway منطقی است، زیرا به عنوان یک نقطه ورودی واحد به سیستم عمل می‌کند. API gateway مسئول مسیریابی درخواست، ترکیب و ترجمه پروتکل است و می‌تواند سیستم را ساده کند. بوسیله‌ی API gateway، هر یک از کلاینت‌های برنامه می‌توانند یک API سفارشی دریافت کنند. API gateway برخی از درخواست‌ها را به سادگی با مسیریابی آنها به سرویس پایانی مناسب (backend) مدیریت می‌کند و با فراخوانی چندین سرویس پشتیبان و جمع‌آوری نتایج، سایر سرویس‌ها را مدیریت می‌کند. اگر در سرویس‌های پایانی شکست وجود داشته باشد، API gateway می‌تواند با برگرداندن داده‌های ذخیره‌شده یا پیش‌فرض، آن‌ها را پوشش دهد.نقش API gateway در معماری میکروسرویس‌هاپلتفرم API gateway کانداکتوری است که درخواست‌های پردازش شده توسط معماری میکروسرویس‌ها را سازماندهی می‌کند تا تجربه‌ای ساده برای کاربر ایجاد نماید. این کانداکتور نقش یک مترجم را ایفا می‌کند که بسیاری از درخواست‌های کلاینت را می‌پذیرد و آنها را تنها به یک درخواست تبدیل می‌کند تا تعداد رفت‌وآمدهای بین کلاینت و برنامه را کاهش دهد. API gateway در مقابل میکروسرویس‌ها راه اندازی می‌شود و به نقطه ورود هر درخواست جدیدی که توسط برنامه اجرا می شود تبدیل می‌گردد. در نتیجه اجرای کلاینت و اپلیکیشن میکروسرویس را ساده می‌کند.مزایای استفاده از API Gatewayدر این بخش مزایای دیگر استفاده از مولفه API Gateway را بررسی می‌کنیم. از جمله این مزایا می‌توان به موارد زیر اشاره کرد.به جای اینکه هر سرویس برای ارائه خدماتش به کاربر عملیات احراز هویت را انجام دهد می‌توان این وظیفه را به API Gateway موکول کرد.با استفاده از API Gateway می‌توانیم با کش کردن درخواست‌های ارسال شده به سرویس‌های مختلف سرعت پاسخ‌دهی به کاربران سامانه را افزایش دهیم.تغییرپذیری قسمت‌های داخلی سیستم از کاربر می‌تواند مخفی بماند. به عنوان مثال تغییر پروتکل ارتباطی بین میکروسرویس‌ها می‌تواند از دید کاربر مخفی بماند زیرا کاربر با همان شیوه قبل با سیستم از طریق API Gateway می‌تواند ارتباط بگیرد.به نوعی می‌توان با استفاده از API Gateway میکروسرویس‌های سامانه را پایش و وضعیت‌شان را تحلیل کرد. با توجه به تعداد درخواست‌های میکروسرویس‌های مختلف در خصوص تعداد مولفه‌های تصمیم گیری هوشمندانه‌ای داشته باشیم.بخاطر قرار گیری مولفه API Gateway بین مایکروسرویس‌ها،‌ می‌تواند به عنوان یک مانع امنیتی عمل کند تا API های مهم در معرض دید قرار نگیرند. همچنین در برابر حملات مخربی چون حملات DOS و SQL Injection و موارد مشابه از API مایکروسرویس‌ها محافظت می‌کند.با استفاده از API Gateway نیازی به تبدیل فرمت‌های مختلف داده به یکدیگر نیست. مسیریابی APIها و درک منطق آنها از روی دوش کاربران برداشته و به API Gateway سپرده می‌شود.معایت استفاده از API Gatewayدر این بخش معایب استفاده از API Gateway را بررسی می‌کنیم. از جمله این معایب می‌توان به موارد زیر اشاره کرد.بخاطر نیازمندی مایکروسرویس‌ها به API Gateway، در صورت تغییر هر مایکروسرویس یا API بایستی متناسب با تغییرات API Gateway نیز مجدد تنظیم شود. درخواست‌های کاربران بصورت مستقیم به مایکروسرویس‌ها نمی‌رسند بلکه ابتدا وارد مولفه اضافه شده به سیستم یعنی API Gateway می‌شوند. به همین دلیل در شرایطی ممکن است API Gateway به گلوگاهی برای سیستم تبدیل شود.نگهداری و دسترس‌پذیری بالایی برای API Gateway نیاز است. زیرا کارکرد سیستم به این مولفه وابسته است و در صورتی که دچار مشکل شود کلیه کارکرد سیستم نیز مختل خواهد شد.معرفی چند نمونه ابزار Open Source در زمینه‌ی API gateway1. ابزار API Umbrellaپلتفرم API Umbrella یک پلتفرم مدیریت API منبع باز پیشرو برای مدیریت API ها و میکروسرویس‌ها می‌باشد. API Umbrella سازمان‌ها را قادر می‌سازد تا تحت یک چتر واحد با اعطای مجوزهای مدیریتی مختلف به دامنه‌های متنوع، فعالیت کنند. این پلتفرم امکاناتی مانند Rate limiting، API key ها، حافظه پنهان (caching)، real-time analytics و دسترسی پذیری یک رابط وب مدیریتی (availability of an admin web interface) را فراهم می‌کند.2. ابزار Gravitee.ioپلتفرم Gravitee.io یک پلتفرم منبع باز برای مدیریت API ها است که ماهیتی انعطاف‌پذیر و سبک وزن دارد. از جمله ویژگی‌های این پلتفرم می‌توان به Rate limiting، فیلترینگ IP، اشتراک‌گذاری Cross-origin resource، گزینه‌های plug-and-play، پورتال توسعه‌دهنده API منبع باز با خط‌مشی‌های OAuth2 و JSON web token‌ها، متعادل‌سازی بار و موارد دیگر اشاره کرد.با این حال، توانایی این پلتفرم در ایجاد گزارش‌های دقیق جهت درک داده‌های مورد استفاده‌ی API، مهم‌ترین ویژگی این ابزار مدیریتی به شمار می‌رود.3. ابزار APIman.ioپلتفرم APIman.io که توسط شرکت Red Hat معرفی شده است، یکی از بهترین پلتفرم‌های مدیریت API می‌باشد که باید هنگام انتخاب بهترین پشته‌ی فناوری برای برنامه خود، آن را در نظر گرفت. این پلتفرم که به راحتی در مخزن GitHub در دسترس است، فرصت‌های فراوانی را در اختیار توسعه دهندگان در مرحله توسعه backend قرار می‌دهد. این فرصت‌ها شامل موارد زیر:زمان‌های اجرا سریعحاکمیت مبتنی بر سیاست با موتور خط مشی جداشدنیقابلیت آسنکرونصورتحساب و گزینه‌های تجزیه و تحلیل پیشرفتهدر دسترس بودن یک REST API برای مدیریتموضوع Rate limiting 4. ابزار WSO2 API Managerپلتفرم WSO2 API Manager یک پلتفرم مدیریت API چرخه حیات کامل است که می‌تواند در هر مکان و زمانی اجرا شود. این پلتفرم توسعه دهندگان را قادر می‌سازد تا از امکان توزیع و استقرار API هم در فضای ابری داخلی و هم خصوصی استفاده کنند. این پلتفرم همچنین فرصت‌های مختلف دیگری را نیز برای توسعه دهندگان فراهم می‌کند که تعدادی از آنها عبارتند از:قابلیت سفارشی‌سازی در سطحی بالاترسهولت سیاست‌های حاکمیتیامکان طراحی و پروتوتایپینگ برای SOAP یا RESTful APIکنترل دسترسی بهتر و امکانات مربوط به کسب درآمد5. ابزار Kong Enterpriseپلتفرم Kong یکی از ابزارهای API میکروسرویس منبع باز است که به صورت گسترده مورد پذیرش واقع شده و به توسعه دهندگان امکان مدیریت سریع، آسان و ایمن همه چیز را می‌دهد. نسخه‌ی سازمانی آن دارای ویژگی‌ها و قابلیت‌هایی شامل موارد زیر است:در دسترس بودن پلاگین‌های منبع بازسهولت انجام عملیات تنها با یک کلیکقابلیت زیرساخت زبان مشترکتجسم عالی برای نظارتنرم افزار بررسی منظم سلامت6. پلتفرم Tyk.ioپلتفرم Tyk.io که به زبان برنامه نویسی Go نوشته شده است، یک API gateway منبع باز شناخته شده می‌باشد. این پلتفرم به کمک یک پورتال توسعه‌دهنده API منبع باز، مستندات دقیق، داشبورد تجزیه و تحلیل API، محدود کردن نرخ APIها، احراز هویت، و مشخصات مختلف دیگری از این دست به سازمان‌ها کمک می‌کند تا روی محیط‌های میکروسرویس خود و کانتینری‌سازی تمرکز کنند.با این حال، خدمات تجاری محور این پلتفرم تنها برای نسخه‌های پولی موجود است.7. پلتفرم Fusioپلتفرم Fusio یکی از محبوب‌ترین ابزارهای مدیریت API منبع باز است که به توسعه دهندگان اجازه می‌دهد API های REST را از انواع داده‌های مختلف ایجاد و نگهداری کنند. این پلتفرم دارای ویژگی‌های مدیریت چرخه عمر کارآمد مانند داشبورد backend برای کنترل ادمین، مستندات دقیق، اعتبارسنجی JSON برای درخواست‌های ورودی، و مدیریت محدوده برای برآورده کردن مجوزهای کاربر است.علاوه بر این، این پلتفرم به طور خودکار نیازمندی‌های OAI و RAML را ایجاد می‌کند و یک SDK سفارشی مشتری را مطابق طرح تعریف شده ایجاد می‌نماید.8. پلتفرم API Axleیکدیگر از پروکسی‌های منبع باز‌، ساده و سبک است که مزایای فراوانی را برای توسعه‌ دهنگان فراهم می‌کند. از جمله این مزایا می‌توان به موارد زیر اشاره کرد:تجزیه و تحلیل زمان واقعیاحراز هویت قوی ثبت ترافیک API برای آمار و گزارش‌گیریسهولت ایجاد و مدیریت کلیدهای APIپشتیبانی از طراحی REST API و استفاده از کتابخانه های PHP, Go و Node.js 9. پلتفرم Snap Logicیک پلتفرم یکپارچه است که به عنوان یک سرویس به سازمان‌ها در حفظ و رشد مشتریان پایه کمک می‌کند. ویژگی‌هایی که این پلتفرم فراهم می‌کند عبارتند از:سریع است و دارای گزینه‌ای برای رسیدگی به نیاز‌های یکپارچه‌سازی داده‌های برنامه‌های گروهی و بلادرنگ است.این پلتفرم دارای یک معماری مقیاس‌پذیر است و مانند وب سرورها عمل می‌کند، اما گزینه‌ای برای پذیرش تطبیق‌پذیری نیز ارائه می‌دهد.10. پلتفرم DreamFactoryیکی از بهترین پلتفرم‌های رایگان منبع باز است که از جمله دلایل محبوبیت آن می‌توان به موارد زیر اشاره کرد:به توسعه‌دهنگان این امکان را می‌دهد تا از API های کدگذاری دستی برای توسعه برنامه‌های تحت موبایل رها شوند. همچنین توسعه‌دهنگان را قادر می‌سازد تا هر دیتابیس SQL/NoSQL،‌ سرویس HTTP/SOAP خارجی یا سیستم ذخیره سازی فایل را در محیط DreanFactory ادغام کنند و بصورت خودکار یک REST API جامعتو انعطاف‌پذیر را برای استفاده دریافت کنند.یکی دیگر از ویژگی‌های ممتاز این پلتفرم این است که درخواست‌های JSON را بلافاصله به SOAP تبدیل می‌کند و بالعکس.این پلتفرم علاوه بر دسترسی به پارامترهای API برای صفحه‌بندی، فیلترهای پیچیده و کلیدهای خارجی مجازی، یک REST API دقیق برای دیتابیس‌های SQL ارائه می‌دهد.11. پلتفرم 3SCALEیک پلتفرم مدیریت API متعلق به Red Hat است که به شرکت‌های بزرگ و کوچک امکاناتی با ویژگی‌های زیر را ارائه می‌دهد:از آنجایی که این پلتفرم روی یک لایه ابر توزیع شده میزبانی می‌کند،‌استفاده از آن بسیار انعطاف‌پذیر و مقیاس‌پذیر است.این پلتفرم برای توسعه‌دهنگان امکان برنامه‌ریزی، طراحی، مدیریت،‌ تجزیه و تحلیل و بهینه‌سازی API فراهم می‌کند.این قدرت را دارد تا داده‌ها، خدمات و محتوای سازمان را از طریق وب یا برنامه‌های تحت موبایل به راحتی به اشتراک بگذارد.مهمتر از همه پلتفرم مذکور فرصتی را برای طیف گسترده‌ای از پروتکل‌های رمز‌گذاری، احراز هویت در محیط توسعه فراهم می‌کند.12. پلتفرم Gloo Edgeیک API Gateway ابری است که از برنامه‌های قدیمی،‌ مایکروسرویس‌ها و همچنین بدون سرور پشتیبانی می‌کند. با محیط یکپارچه می‌شود و امکان انتخاب ابزارهای مورد علاقه را برای برنامه‌ریزی،‌ تداوم و امنیت برای کاربران خود فراهم می‌کند. همچنین این پلتفرم از پروژه‌های منبع باز چون NATS, Open Tracing, GraphQL, gRPC برای ارائه ویژگی‌های با کیفیت بالا استفاده می‌کند.13. پلتفرم Akanaپلتفرم Akana یکی دیگر از پلتفرم‌های منبع باز API Gateway است. با استفاده از این پلتفرم می‌توان API ها را طراحی،‌ ایمن،‌ پیاده‌سازی، نظارت و انتشار داد. همچنین می‌توان آن را در فضای ابری مستقر کرد. برخی از ویژگی‌های این پلتفرم می‌توان به موارد زیر اشاره کرد:حافظت در مقابل تهدیداتیک پلتفرم منبع بازمدیریت مایکروسرویس‌ها و DevOpsکمک به مدیریت ترافیکامنیت برنامه را با شناسایی آسیب‌پذیریها در کد یا در طول زمان اجرا فراهم می‌کند.تمامی ابزارهای معرفی شده در بالا منبع باز هستند و آماده اضافه شدن به پشته فناوری هستند. اما برای اطمینان از انتخاب مناسب برای نیازهای برنامه تجاری در ادامه نکاتی را در خصوص انتخاب ابزارهای مدیریت API بیان می‌کنیم. معیارهای انتخاب یک پلتفرم مدیریت API منبع باز1- ویژگی‌هابرای پاسخ دهی به سوال " چگونه بهترین ابزار مدیریت API را انتخاب کنم؟" مهمترین عاملی که باید در نظر گرفت ویژگی‌های پلتفرم‌های مدیریت API است. هر ابزار مدیریت API منبع باز دارای الزامات و محدودیت‌های پیاده‌سازی خاصی است. بنابراین مقایسه پلتفرم‌های مدیریت API با توجه به نیازهای فنی و غیرفنی می‌تواند واقعا مفید واقع شود.2- پیچیدگی استقرار زمانی که صحبت از استقرار به میان می‌آید، برخی از Gateway ها به یک node و برخی دیگر به چندین node برای راه‌اندازی دیتابیس نیاز دارند. علاوه بر این برخی از Gateway ها با دیتابیس‌های زیادی کار می‌کنند که می‌تواند یک مورد پیچیده برای مدیریت باشد. بنابراین توجه به پیچیدگی استقرار نیز می‌تواند در انتخاب پلتفرم مناسب منبع باز مدیریت API نیز کمک کند.3- هاست cloud و on-Premiseهاست‌های نوع On-Premise در محوطه فیزیکی یک شرکت قرار دارند. بنابراین می‌تواند زمان بیشتری را به فرآیند استقرار و نگهداری اضافه کرد. اما هاست ابری، ابزارهای منبع باز مدیریت API در یک مکان مجازی قرار دارند و خدمات آن از طریق محاسبات ابری در دسترس است. بنابراین استفاده از خدمات هاست ابری می‌تواند تاخیر بیشتری را ایجاد کند و دسترس‌پذیری سرویس را کاهش دهد.بنابراین تجزیه و تحلیل مزایا و معایت هر دو گزینه برای تعیین اینکه کدام ابزار مدیریت API منبع باز انتخاب شود می‌تواند ایده‌ی سودآوری باشد.4- حمایت‌ انجمنیداشتن پشتیبانی و انجمنی بزرگ از استفاده کنندگان از پلتفرم منبع باز مدیریت API شانس بروزرسانی و پاسخ به سوالات گوناگون مرتبط با پلتفرم مورد استفاده را نیز افزایش می‌دهد.در ادامه تعدادی از شرکت‌های ارائه‌ دهنده API Gateway ایرانی را بررسی می‌کنیم.معرفی شرکت‌های ایرانی ارائه دهنده‌ی API gatewayشرکت پلتکوپلتفرم Platco API Management راهکار و ابزاری برای اصلاح و ارتقاء سریع زیرساخت فناوری اطلاعات سازمان‌ها می‌باشد که آنها در موارد زیر کمک می کند:دستیابی به استانداردسازی، تلفیق، سامان‌دهی معماری فناوری اطلاعات سازمانبه روزرسانی ساده و بی دردسر خدمات و سرویس‌های سازمان‌هاارتقا یا بهینه‌سازی سرویس‌ها با هزینه‌ای کمتربه حداقل رساندن تاخیرهای پیاده‌سازی معمول جهت به روزرسانیجلوگیری از تاثیر منفی به روزرسانی بر روی سایر قسمت‌های سیستماتصال آسان سرویس‌ها و سامانه‌های مختلفاعطای ابزارهای لازم توسط مدیریت وب ‌سرویس جهت دستیابی به چابکی، مقرون به صرفه بودن، مقیاس‌پذیری، قابلیت اطمینان و امنیت بیشتر هنگام توسعه برنامه‌ها و سیستم‌های تجاری به سازمان‌ها.شرکت وصلپلتفرم مدیریت API سورنا مربوط به شرکت وصل توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی مرتبط با سامانه‌های داخلی سازمان/سرویس‌دهنده طراحی و پیاده‌سازی نمایند. API ها در تکنولوژی‌های مختلف نظیر اینترنت اشیا، رایانش ابری و داده‌های حجیم نقشی کلیدی را ایفا می‌نماید. پلتفرم مدیریت API سورنا پایداری، امنیت و پشتیبانی ویژه‌ای ارائه می‌کند تا شرکت‌های ثالث، همکاران، شرکا و حتی توسعه‌دهندگان آزاد بتوانند با آسودگی خیال و اطمینان از آنها استفاده نمایند. طراحی سریع، سادگی پیاده سازی، تست دقیق از ویژگی‌های محصول ارائه شده توسط این شرکت است. پلتفرم مدیریت API سورنا با نظارت، تجزیه و تحلیل داده‌ها، کنترل دسترسی‌ها و محافظت از اطلاعات حساس سازمان‌ها با سیاست‏‌های امنیتی خود موفقیت سازمان‌ها را تضمین می‌کند و به آنها کمک می‌کند در نبرد با متجاوزان دنیای دیجیتال عملکرد مطمئنی داشته باشند.ابر درسایکی از خدمات این شرکت ارائه سرویس API Gateway است. این سرویس با تخصیص یک پنل به مشتری این امکان را می دهد تا تعیین کند برای دسترسی به هر صفحه به کدام سرور درخواست ارسال شود. به طور کلی سرویس API Gateway این شرکت قابلیت‌های زیر را دارا است.سرویس ابری API Gateway اجازه دسترسی به خوشه‌های برنامه کوبرنتیز را می‌دهد که باعث بهبود قابلیت‌های سرویس خوشه‌های کوبرنتیز می‌شود. پشتیبانی از محیط‌های ناهمگن شبکه. صرف نظر از اینکه سیستم تجاری مشتری در ابر درسا باشد یا در مرکز داده دیگر، سرویس API Gateway شرکت درسا قادر به مدیریت سیستم تجاری خواهد بود. این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع:https://www.nginx.com/learn/api-gateway/https://www.redhat.com/en/topics/api/what-does-an-api-gateway-dohttps://appinventiv.com/blog/open-source-api-management-tools/http://vasl.ir/platform/api-management/https://dorsacloud.comعلیرضا رشنوعلیرضا رشنوMon, 19 Dec 2022 22:07:04 +0330https://virgool.ir/@alirezarashnousk/معماری-ها-الگوها-ابزارها-و-مفاهیم-رایج-در-معماری-نرم-افزار-gbvelin3dzscدر این پست قصد داریم تعدادی از معماری ها، الگوها، ابزارها و مفاهیم رایج در معماری نرم افزار را به شرح زیر بررسی کنیم. Domain Driven DesignHexagonal architectureCQRSMVVMEvent SourcingMicro FrontendsLow code platformsESBAPI GatewayBusiness Process Management Systems (BPMS)Business Rules Management Systems (BRMS)Message Queue (such as Kafka and RabbitMQ)Docker and ContainerizationContainer orchestration (such as Kubernetes)Log Management Tools (such as ELK)Monitoring tools (such as Prometheus)Static Code Analysis (such as SonarQube)Continuous DeliverySingle Sign on (SSO) and Identity ManagementService Meshدر ابتدا سعی می شود هر یک از موارد مطرح شده را مختصرا توضیح دهیم و سپس نقاط ضعف، قدرت، مزایا و معایب هر یک را بررسی کنیم. 1.مفهوم Domain Driven DesignDomain Driven Design(DDD)رویکرد دامنه محور(Domain Driven Design) یا به اختصار DDD، رویکردی برای توسعه نرم افزار برای نیازهای پیچیده با اتصالات عمیق پیاده سازی به یک مدل در حال تکامل است. استفاده از این رویکرد به ساده تر شدن پیچیدگی های موجود در نرم افزار کمک می کند. 1.1 تعریف Domainبه طور خلاصه دامنه مجموعه ای از اجزای است که یک محصول را در کنار هم تشکیل می دهد. به عنوان مثال ماشین یک دامنه است که شامل چرخ، موتور، صندلی و... است. اجزا در دامنه به طور مفهومی با هم در ارتباط هستند. گاهی یک محصول می تواند شامل چندین دامنه مستقل از هم نیز باشد به عنوان مثال می توان به بخش های فروش، تعمیرات و... اشاره کرد. به طور کلی الگوهای DDD به درک پیچیدگی دامنه ها کمک می کند. 1.2 مزایای Domain Driven Designبه طور کلی برای تغییر انعطاف پذیری بالایی دارد زیرا این الگو برای مدلسازی حوزه کسب و کار ساخته شده استبه کمک DDD می توان به کاهش پیچیدگی در نرم افزار کمک کرد زیرا DDD در واقع به آسان تر شدن ارتباط بین تیم توسعه و ذینفعان پروژه کمک می کند. 1.3 معایت Domain Driven Designاستفاده از DDD به خاطر طولانی تر کردن روند توسعه نرم افزار موجب افزایش هزینه می شود.برای استفاده از DDD نیاز به نیروی متخصص در حوزه ی دامنه است.در صورت استفاده از DDD نیاز است که هماهنگی ها و ارتباطات لازم بین مختصص حوزه دامنه و تیم توسعه برقرار شود.به طور کلی DDD شامل اصول و قواعدی است که فرایند تصمیم گیری در حوزه های تجاری را تسهیل می کند. همان طور که اشاره شد DDD هزینه بر است به همین دلیل برای پروژه هایی که پیچیدگی دامنه بالایی دارند مناسب است. همچنین DDD با پنهان کردن قواعد پیچیده به افراد فنی(تیم توسعه) و افراد غیر فنی(ذینفعان) کمک می کند تا به راحتی با یکدیگر ارتباط برقرار کنند. 2.معماری شش ضلعی(Hexagonal architecture)معماری شش ضلعی یا روش پورت، آداپتور نوعی طراحی معماری است که اجازه می دهد یک برنامه توسط تست خودکار، کاربران و اسکریپت های نوشته شده مورد استفاده قرار بگیرد. برنامه ای که از معماری شش ضلعی استفاده می کند قابلیت تست و توسعه مستقل از محیط نهایی اجرایی دارد. در این طرح معماری می توان هسته بیزینس را از برنامه جدا کرد و رفتار برنامه را بصورت مستقل از موارد دیگر تست کرد. معماری شش ضلعی شامل یکسری قواعد به شرح زیر است:در این طرح معماری بخش های کاربر، سرور و منطق های بیزینس از یکدیگر تفکیک می شوند. این تفکیک مزایای را به همراه دارد از جمله اینکه بخش های مختلف مستقل از یکدیگر را می توان تغییر و توسعه دهیم. همچنین در این طرح و روش تفکیک منطق بیزینس اصل قرار گرفته شده است. از موارد مطرح شده جهت تفکیک تنها سرور و کاربر به بخش منطق بیزینس وابسته است.مرز بین موارد تفکیک شده با استفاده از پورت و آداپتور فراهم می شود.در بخش کاربری، پیاده سازی های مربوط به تعامل کاربر، سامانه های خارجی و ارتباطاتی از این دست در این بخش قرار می گیرند. بخش منطق های بیزینس، شامل تمام پیاده سازی های مربوط به منطق بیزینس است. همچنین بخش های کاربر و سرور وابسته به بخش منطق بیزینس هستند.بخش سرور نیز شامل تمامی نیازمندی های لازم برای قابلیت اجرایی برنامه است. همچنین معماری شش ضلعی از اصل وارونگی وابستگی پیروی می کند. بنابراین در معماری شش ضلعی ماژول های سطح بالا و انتزاعات به ترتیب به ماژول های سطح پایین و جزییات وابسته نیستند.3.الگوی CQRSالگوی CQRSالگوی Command and Query Responsibility Segregation یا به اختصار CQRS یکی از پر کاربردترین الگوهای معماری است. الگوی CQRS هدفش تفکیک عملیات های کوئری و کامند است. به طور خلاصه دستوراتی که تغییری در دیتابیس سیستم ایجاد نمی کنند در دسته کوئری(Query) و دستوراتی که باعث ایجاد تغییرات در دیتابیس می شوند و مقداری را بر نمی گردانند در دسته کامند(Command) قرار می گیرند.به طور کلی دستورات پایگاه داده را میتوانیم در 4 دسته Create, Read, Update,Delete تقسیم بندی کرد. از میان دستورات مطرح شده Read در دسته کوئری و Create, Update, Delete در دسته Command قرار می گیرند. الگوی معماری CQRS تاکید به جداسازی دستوراتی دارد که در دو دسته Command و Query قرار می گیرند. در نسخه های جدیدتر CQRS از دو دیتابیس یکی برای دستورات از نوع Command یکی برای دستورات از نوع Query استفاده می شود. همچنین برای ایجاد هماهنگی بین دو دیتابیس از Replication و Message Broker استفاده می شود.3.1 مزایای CQRSدر نسخه های جدید به خاطر استفاده از دو دیتابیس برای دو دسته کوئری و کامند میزان بهره وری افزایش می یابد. در الگوی CQRS به خاطر تفکیک دستورات مربوط به دیتابیس، توسعه کد آسان تر می شود.3.2 معایب CQRSلزوم آشنایی تمام اعضای تیم با الگوی مطرح شده.افزایش حجم کد برنامه در برخی مواقع به خاطر کد تکراری ناشی از الگوی CQRS.4. الگوی معماری MVVMالگوی معماری MVVM یک الگوی سه لایه متشکل از Model-View-ViewModel است که جهت حل مشکلات الگوهای معماری MVP و MVC ارائه شده است. الگوی پیشنهادی یک الگوی شناخته شده در برنامه نویسی اندروید است. در ادامه هر یک از لایه های الگوی MVVP را بررسی می کنیم. لایه Model: این لایه مربوط به داده و جداول پایگاه داده است. همچنین این لایه بی اطلاع از لایه های View و ViewModel است و بصورت مستقل کار می کند. لایه View: لایه ای از معماری که کاربر می بیند و با سیستم ارتباط برقرار می کند. به عبارت دیگر این لایه جهت اطلاع رسانی عملکرد کاربر به ViewModel در نظر گرفته شده است.لایه ViewModel: این لایه یک انتزاع از View است به بیان ساده تر می توان گفت که ViewModel یک تبدیل کننده اطلاعات است که اطلاعات را همان طور که View و Model می خواهند به آنها تحویل می دهد.از جمله فریم ورک هایی که از الگوی MVVM استفاده می کنند می توان به MicroModels, Caliburn Micro و Prism اشاره کرد.4.1 مزایای الگوی MVVM:این الگو، معماری را به سه لایه تقسیم می کند و این تفکیک به قابلیت نگهداری کدهای هر لایه محصول نرم افزاری کمک می کند. همچنین بخاطر تفکیک لایه ها در این الگو، می توان گفت که توسعه پذیری یکی دیگر از ویژگی های مثبت این الگوی معماری است.4.2 معایب الگوی MVVM: اشکال زدایی و طراحی ViewModel در الگوی MVVM گاهی دشوار است.5. الگوی Event Sourcingالگوی منبع کردن رویداد(Event Sourcing)، الگویی جهت ذخیره سازی جزییات تغییرات اعمال شده بر روی موجودیت های دیتابیس است. هر event روی هر موجودیت که رخ می دهد در لیست رخدادها با نام event store ذخیره می شود. با بررسی event store می توان وضعیت فعلی هر موجودیت را در سیستم بررسی کرد. در event store در هر سطر اطلاعاتی از قبیل event id, event type, entity type, entity id, event data و مواردی از این دست برای هر رخداد روی هر موجودیت ثبت می شود. به طور کلی در event store مواردی چون بروز رسانی موجودیت ها، حذف و اضافه شدن موجودیت ها ذخیره می شود. گاهی یک سیستم منتظر بروز یکسری تغییرات در سیستم دیگر است تا واکنش متناسب با آنها را از خود نشان دهد. در این چنین مواردی استفاده از Event Sourcing بسیار کمک کننده است. بنابراین یکی از کاربردهای این الگو می توان به استفاده در معماری میکروسرویس اشاره کرد.5.1 مزایای الگوی Event Sourcing:به کمک Event Sourcing می توان رفتار سیستم را در طول زمان تحلیل و بررسی کرد.در صورت بروز تغییر غلط مقادیر متغییرها می توان با بررسی event store حالت درست و عامل بروز خطا را شناسایی کرد.همان طور که پیش تر گفته شد به کمک event store می توان تغییرات ناشی از event ها روی موجودیت ها را ثبت کرد. بنابراین به کمک event store می توان در صورت نیاز برای عملیات بازیابی اطلاعات استفاده کرد.5.2 معایب Event Sourcing: ذخیره سازی اطلاعات ناشی از تغییرات روی موجودیت ها در طول زمان باعث مصرف حافظه زیادی می شود. اگر برای یک موجودیت اطلاعاتی در event store ذخیره شده باشد و در آینده نیاز باشد یک ویژگی جدید به موجودیت اضافه شود یا از آن حذف شود آنگاه بروز رسانی جدول event store دشوار است.6. الگوی معماری Micro FrontendsMicro Frontendsمعماری Micro Frontends تعمیم یافته معماری میکروسرویس است که برای توسعه برنامه های تحت وب در Frontend کاربرد دارد و به کمک آن می توان Frontend های انعطاف پذیر و ماژولار ساخت. معمولا از این معماری در برنامه های تحت وب برای ساخت و پیاده سازی واسط های کاربری قوی و سنگین استفاده می شود. قبل از استفاده از معماری Micro Frontend رایج ترین شیوه توسعه برنامه های تحت وب استفاده از یک رابط کاربری یکپارچه بود که در بالای لایه میکروسرویس قرار می گرفت. رابط کاربری یکپارچه در معماری میکروسرویس در Backend باعث بروز مشکلات و پیچیدگی هایی می شود. به عنوان مثال در صورت ارتقا یک میکروسرویس آنگاه Frontend به تغییرات زیادی نیاز دارد و گاهی این وضعیت از کنترل خارج می شود. بنابراین به کمک این معماری می توانیم برای هر میکروسرویس توسط تیم Frontend یک رابط کاربری مستقل از بقیه توسعه دهیم. 6.1 مزایای استفاده از Micro Frontendاین معماری به تیم های Frontend امکان آزادی بیشتر را می دهد و کمک می کند تا چرخه توسعه نرم افزار سریع تر پیش برود.معماری Micro Frontend کمک می کند تا نرم افزار تولید انعطاف پذیر باشد. به عنوان مثال در صورت بروز بروز مشکل در یکی از میکروسرویس ها سایر رابط های کاربری دچار مشکل نمی شوند. معماری پیشنهادی ویژگی مقیاس پذیری را برای محصول به همراه دارد.به کمک معماری Micro Frontend می توان از ویژگی استقرار مستقل استفاده کرد. این ویژگی تکامل صحیح هر سیستم در حال رشد را تضمین می کند. 7. پلتفرم توسعه کم کد (Low-code platform)پلتفرم های توسعه کم کد یک برنامه است که با استفاده از یک رابط گرافیکی این امکان را برای توسعه دهنگان فراهم می کند تا با سرعت بیشتر و خط کد کمتر فرایند توسعه نرم افزار را پیش ببرند. علاوه بر افزایش سرعت کد نویسی با خط کد کمتر، این پلتفرم ها در راه اندازی و استقرار سریع تر نیز به توسعه دهنگان کمک می کنند. در این پلتفرم های نیازی به کد نویسی خط به خط نیست. در واقع این پلتفرم ها به توسعه دهنگان این امکان را می دهند تا با ترسیم یک فلوچارت کد خود را در زمان سریع تر و با خط کد کمتر تولید کنند. 7.1 مزایای پلتفرم های توسعه کم کدبهره وری بالاکاهش هزینه بخاطر تولید و توسعه در زمان کوتاه ترمشارکت بیشتر افراد در فرآیند توسعهبهبود چابکی سازمان هاکاهش پیچیدگی فرآیند توسعه برنامهاز جمله پلتفرم های توسعه کم کد می توان به Visual LANSA, Retool, Quixy, Creatio, GeneXus, Zoho Creator, Appian, Kissflow, OutSystems اشاره کرد. در ادامه پلتفرم LANSA مورد را بررسی می کنیم. 7.2 پلتفرم LANSAپلتفرم LANSA به توسعه دهنگان اجازه می دهد تا در زمان سریع تر و با کنترلی بالاتر کدنویسی برنامه ها را نسبت به روش های سنتی پیش ببرند. از جمله امکانات این پلتفرم می توان به موارد زیر اشاره کرد.امکان استفاده برای ایجاد برنامه های تحت وب، موبایل و دسکتاپآزمایش گسترده، استقرار و کنترل های یکپارچه سازی امکان نوشتن کد در داخل IDEتوسعه سریع تر برنامه با هزینه کمتر نسبت به روش های سنتی 8. معماری ESBگذرگاه سرویس سازمانی(Enterprise Service Bus) یا به اختصار ESB مجموعه ای از قوانین است که ارتباط بین چندین سیستم با زبان های متفاوت را ممکن می کند. به بیان دیگر معماری ESB این امکان را فراهم می کند تا برنامه های مختلف با قرار گیری روی یک گذرگاه بصورت مستقل و بدون وابستگی به سیستم های دیگر با سایر سیستم ها ارتباط برقرار کند.فرمت داده هایی که روی گذرگاه جا به جا می شوند معمولا XML هستند. همچنین بین هر برنامه کاربردی و گذرگاه یک آداپتور قرار می گیرد. آداپتور مسئولیت هایی چون ترجمه مکالمه و تبدیل داده ها بین برنامه کاربردی و گذرگاه، امنیت، نظارت و... را به عهده دارد. بنابراین معماری ESB این امکان را برای سازمان ها فراهم می کند تا سرویس های قدیمی خود را به شکل استاندار و بدون نیاز به توسعه سامانه های قدیمی در اختیار سرویس گیرندگان قرار دهند.8.1 مزایای معماری ESBمعماری ESB امکان اتصال به انواع وب سرویس ها را فراهم می کند.معماری ESB هزینه های توسعه را کاهش و توسعه پذیری را افزایش می دهد.معماری ESB از تعداد زیاد کاربر بصورت همزمان پشتیبانی می کند.9. فناوری API Gateway یک API Gateway این فناوری جهت مدیریت API (رابط برنامه نویسی کاربردی) بین کاربران و مجموعه ای از سرویس ها قرار می گیرد. معمولا از فناوری API Gateway در اکثر برنامه های مبتنی بر میکروسرویس استفاده می شود. فناوری API Gateway در واقع از کاربران تمام فراخوانی های API را می گیرد و در نهایت هر یک را با مسیریابی درخواست و ترجمه پروتکل به میکروسرویس مناسب هدایت می کند. از جمله قابلیت های API Gateway می توان به مسیریابی، نظارت، احزار هویت، امنیت، تجزیه و تحلیل اشاره کرد. معمولا از API Gateway زمانی استفاده می شود که ارتباط بین سیستم های مختلف پیچیده می شود. 9.1 مزایای API Gatewayمی توان برای هر دسته از کاربران یک API خاص ارائه داد.پشتیبانی از DevOpsکاربر به جای فراخوانی سرویس بصورت مستقیم با API Gateway صحبت می کند.9.2 معایب API Gatewayامکان بروز پیچیدگی بخاطر ازدیاد قوانین API در یک مکاننیاز به قوانین مسیریابی10. سیستم مدیریت فرآیند کسب و کار(BPMS)فرآیند کسب و کار مجموعه ای از فعالیت های تکراری در یک سازمان است و BPM نیز روشی جهت کنترل، مدیریت و بررسی فرآیندها در یک سازمان برای اطمینان از درستی و تحلیل آنها است. بنابراین BPM جهت پیشرفت و افزایش میزان بهره وری کارها در یک سازمان استفاده می شود.در سازمان ها جهت محاسبه خطای انسانی از شاخصی با نام ضریب نفوذ مکانیزسیون فعالیت های سازمانی استفاده می شود. یک راه حل اساسی جهت افزایش این شاخص در یک سازمان، سیستمی کردن فرآیندهای یک سازمان است. در صورت عدم اتوماسیون تمام این فرآیندها(کارهای تکراری) نیاز است بصورت فیزیکی توسط افراد انجام شود. با استفاده از سیستم پیاده سازی شده برای سازمان روزانه می توانیم بر عملکرد افراد نظارت داشته باشیم و همچنین می توان گلوگاه های سیستم را بررسی کرد و حتی پس از مدتی فرآیندهای سازمان را تحلیل کرد. بنابراین با سیستمی کردن فرآیندهای یک سازمان می توان به مدیریت و بهبود فرآیندها کمک کرد. 10.1 فواید استفاده از BPMSبا خودکار کردن تمام یا بخشی از فرآیندهای یک سازمان می توان حجم کار را بصورت چشم گیری کاهش داد. استفاده از BPMS منجر به تحلیل و شفاف سازی فرآیندها می شود بنابراین می تواند به نوعی باعث کاهش تخلف در سازمان شود.11 سیستم مدیریت قوانین کسب و کارقوانین کسب و کار در یک سازمان جهت کنترل و تاثیر گذاری بر رفتار کسب و کار سازمان تعریف می شوند. این قوانین همچنین تعاریف و محدودیت هایی را که برای یک سازمان اعمال می شود، توصیف می کند. پس از تعریف قوانین کسب و کار برای استفاده از منابع کمتر و دستیابی به اهداف نیاز است مدیریت این قوانین خودکار شود. بنابراین سازمان ها از پلتفرم BRMS برای حفظ قوانین کسب و کار خود استفاده می کنند. سیستم مدیریت قوانین کسب و کار (Business Rules Management Systems) یک پلتفرم برای مدیران یک سازمان جهت توسعه، ذخیره سازی و ویرایش قوانین کسب و کار است. همچنین به کمک این پلتفرم می توان سریع تر و آسان تر گلوگاه ها و حفره ها را بررسی و پیدا کرد. 11.1 فواید استفاده از BRMSبهبود ارائه خدمات به مشتریان سازمان بهبود و افزایش کارایی بخاطر خودکار سازی تصمیم گیری هااطمینان از رعایت و اجرای قوانین کسب و کار12. صف پیام (Message Queue)Message Queueصف پیام (Message Queue) ابزاری جهت نگهداری پیام هایی است که بین سرویس های مختلف رد و بدل می شود. صف پیام در واقع نقش یک صندوق پستی را دارد که یک سرویس پیام خود را در آن قرار می دهد و سرویس دیگر پیام را در زمان مناسب از صف بر می دارد. از این ابزار معمولا در معماری میکروسرویس استفاده می شود. همان طور که گفته شد سرویس ها برای برقراری ارتباط و رد و بدل کردن پیام می توانند از صف پیام استفاده کنند، بنابراین در صورت بروز مشکل برای صف پیام باعث عدم ارتباط سرویس ها و بروز مشکلات در سیستم می شود و این یک عیب محسوب می شود. فرستنده پیام نقش تولید کننده و دریافت کننده پیام نقش مصرف کننده را دارد. لازم به ذکر است که لزوما تولید کننده و مصرف کننده پیام سرعت یکسانی در ارسال و دریافت پیام ندارند و صف پیام در چنین حالاتی می تواند به عنوان یک بافر مشکل را حل کند. Kafka و RabbitMQ دو مورد از ابزارهای معروف Message Queue هستند.12.1 ربیت ام کیو (RabbitMQ)همان طور که که گفته شد RabbitMQ یکی از ابزارهای معروف صف پیام است. در معماری RabbitMQ تولید کننده پیام، پیام ها را بصورت مستقیم در صف قرار نمی دهد، بلکه پیام هر تولید کننده توسط Exchange دریافت و سپس به صف مناسب هدایت می شود. بنابراین تولید کننده از صف مقصد پیام تولیدی خود اطلاعی ندارند. همچنین Exchange می تواند برخی از پیام های ارسال شده توسط تولید کننده ها را براساس یکسری قوانین تعیین شده فیلتر کند. در RabbitMQ پیام ارسال شده توسط تولید کننده تا زمانی که مصرف کننده آنرا نخواند در صف حفظ می شود و پس از خواندن پیام توسط مصرف کننده، پیام از صف پاک می شود. همچنین براساس معماری RabbitMQ می توان مصرف کننده ها را دسته بندی کرد به گونه ای که مصرف کننده های هر دسته بصورت رقابتی پیام های یک صف را پردازش کنند. در شکل زیر می توان ساختار معماری RabbitMQ را مشاهده کرد.RabbitMQ12.2 کافکا (Kafka)لایه ذخیره سازی کافکا برخلاف RabbitMQ که براساس صف و Exchange پیاده سازی شده است، براساس Partitioned transaction log پیاده سازی شده است. همچنین کافکا بصورت real-time با استفاده از Streams API امکان پردازش Stream ها را فراهم می کند. کافکا پیام های تولید شده توسط تولیده کننده ها را در دسته بندی هایی با نام topics ذخیره می کند. به ازای هر تاپیک، در کافکا تعدادی پارتیشن جهت نگهداری پیام ها وجود دارد. در پارتیشن ها ترتیب دریافت و پردازش پیام های دریافتی از تولید کننده ها کنترل و رعایت می شود و پیام های هر تولید کننده را می تواند یک پارتیشن مپ کرد. در کافکا هر مصرف کننده می تواند با داشتن index پارتیشن ها، از آنها پیام بخواند. در کافکا همچون RabbitMQ نیز می توان مصرف کننده ها را دسته بندی کرد. در شکل زیر معماری کافکا را می توان مشاهده کرد.Kafka producers and consumers 12.3 تفاوت بین RabbitMQ و Kafkaتفاوت های مختلفی بین دو پلتفرم Kafka و RabbitMQ وجود دارد که در ادامه آنها را بررسی می کنیم. ترتیب پیام. در Kafka مصرف کننده ها پیام ها را با همان ترتیبی که تولید کننده ها ارسال می کنند، پردازش می کنند. در حالی که در RabbitMQ توجه زیادی به ترتیب پیام های ارسال شده به صف و Exchange ندارند.مسیریابی پیام. RabbitMQ قابلیت و انعطاف پذیری بیشتری در مسیریابی و فیلتر کردن پیام ها برای مصرف کننده ها نسبت به Kafka دارد. زمان سنجی پیام. RabbitMQ قابلیت دادن تاخیر در ارسال پیام تولیده کننده و قرار گیری آن در صف را دارد. این درحالی است که Kafka از همچین قابلیتی پشتیبانی نمی کند.نگهداری پیام. RabbitMQ هر پیامی را بلافاصله پس از پردازش توسط مصرف کننده از صف خارج می کند. در حالی که Kafka هر پیامی مستقل از اینکه پردازش شده است یا خیر، می تواند تا مدتی بسته به تنظیمات در تاپیک نگهداری کند.مقیاس پذیری. Kafka بخاطر استفاده ی از Sequential disk I/O دارای performance بهتری نسبت به RabbitMQ است. بنابراین بسته به شرایط و تفاوت های بیان شده می توان انتخاب درستی بین دو پلتفرم داشت.12.4 مزایای استفاده از Message Queueاستفاده از صف پیام منجر به کاهش وابستگی میان سرویس ها می شود. بنابراین تفاوت سرعت سرویس ها باعث بروز مشکل نمی شود.عدم ارتباط مستقیم سرویس ها با یکدیگر باعث حل مشکلات ناشی از تفاوت سرعت سرویس ها می شود. 13. داکر و کانتینر (Docker and Containerization)داکر ابزاری برای توسعه دهندگان جهت ایجاد، توسعه و اجرای نرم افزار است. این امکانات به کمک کانتینر توسط داکر برای توسعه دهندگان فراهم می شود. در واقع کانتینر این امکان را برای توسعه دهندگان فراهم می کند تا تمام نیازمندی های لازم نرم افزار در حال تولید را از قبیل زیر ساخت و کتابخانه ها در یک محیط ایزوله داشته باشند. با توجه به تفاوت های احتمالی سیستم های میزبان، کانتینر این اطمینان را می دهد که نرم افزار به شکل مشابه و یکسانی اجرا خواهد شد. همچنین از آنجایی که کانتینرها مستقل از هم هستند، این امکان را فراهم می کنند تا در صورت بروز اختلال در یک کانتینر سایرین به کار خود ادامه دهند. منظور از مجازی سازی کانتینر، استفاده از سخت افزار یک سیستم عامل است. در شکل زیر می توان رابطه بین سیستم عامل و کانتینر ها را مشاهده کرد. مهم ترین تفاوت ماشین مجازی و داکر در این است که در ماشین مجازی هر ماشین سیستم عامل خود را دارد که می تواند متفاوت از بقیه باشد و این در حالی است که کانتینرها از لایه سیستم عاملی که روی سخت افزار قرار گرفته است استفاده می کنند.همچنین داکر برخلاف ماشین مجازی که سخت افزار سیستم را به طور دائم تقسیم می کند، به تناسب هر کانتینر و به صورت موقت امکانات سخت افزاری سیستم را تقسیم می کند. در واقع برخلاف ماشین های مجازی که مجازی سازی را در سطح سخت افزار انجام می دهند، کانتینرها در لایه برنامه مجازی سازی می شوند و می توانند سیستم عامل را مجازی کنند تا فرایندهای جداگانه را اجرا کنند.14. ارکستراسیون کانتینر (Container orchestration)نرم افزارهای با ابعاد بزرگ مثل نرم افزارهای با معماری میکروسرویس گاها دارای هزاران کانتینر هستند. مدیریت، کنترل و استقرار این تعداد بالا از کانتینر در یک برنامه کار ساده ای نیست. بنابراین برای سادگی در مدیریت و کنترل، ارکستراسیون کانتینر (Container orchestration) ارائه شده است. از جمله کاربردهای ارکستراسیون کانتینر می توان به موارد زیر اشاره کرد.مدیریت کانتینرهاانعطاف پذیر کردن سیستم در برابر خطا با راه اندازی مجدد کانتینری که دچار مشکل شده است بررسی وجود مشکل در کانتینرهابرقراری Load balancing میان کانتینرهاتخصیص منابع بین کانتینرها14.1 کوبرنتیزکوبرنتیز یک پلتفرم ارکستراسیون کانتینر است که با استفاده از آن می توان مجموعه هاست های کنتینرهای لینوکس را کلاستربندی کرده و به آسانی مدیریت کرد. همچنین کلاسترهای کوبرنتیز، هاست ها را در سراسر محیط ابری عمومی، داخلی، خصوصی و ترکیبی پوشش می دهند. گوگل در هفته چندین میلیارد کانتینر را دیپلوی می کند بنابراین برای مدیریت و کنترل این حجم از کانتینر، گوگل کوبرنتیز را طراحی و توسعه داد. استفاده از کوبرنتیز، مخصوصا در فضای ابری این است که بستری برای اجرای کانتینرها را بر روی کالاسترهای کوبرنتیز می دهد. به طور خلاصه با استفاده از کوبرنتیز می توان:استفاده بهینه از ظرفیت منابع سخت افزاری سازمانیکنترل و خودکارسازی دیپلوی و به روزرسانی برنامه هاارکستر کانتینرها در میان چندین هاستافزایش سرعت اجرای برنامه های کانتینر شده بهبود کنترل سلامت و خودترمیمی برنامه را بهبود می دهد.14.1.2 اصلاحات مربوط به کوبرنتیزدر این بخش اطلاحات رایج کوبرنتیز را بررسی می کنیم.مرکز کنترل. مجموعه ای از فرآیندهایی که نودهای کوبرنتیز را کنترل می کنند.نودها. مجموعه ای از ماشین ها که وظایف درخواستی تعیین شده توسط مرکز کنترل را اجرا می کنند.پاد. مجموعه یک یا چند کانتینر که روی یک نود مستقر شده اند. کنترلر رپلیکیشن. به کمک این قابلیت تعداد نسخه های کپی شده یک پاد کنترل می شود.سرویس. سرویس پراکسی های کوبرنتیز به طور خودکار سرویس ریکوئست ها را به پاد مناسب می فرستند.کوبلت. با اجرای این سرویس بر روی نودها، می توان مانیفست های کانتینر را خواند و از راه اندازی و اجرای کانتینرهای تعریف شده اطمینان حاصل کرد.کوبکتل. ابزاری برای پیکربندی خط فرمان در کوبرنتیز15. ابزارهای مدیریت لاگ (Log Management Tools)لاگ فایل، فایلی برای ثبت خودکار رویدادهای سیستم ها و نرم افزارها است. همچنین از لاگ فایل ها در مدیریت دیتابیس، سرور، شبکه، سیستم عامل و... استفاده می شود. به طور کلی هر گونه اطلاعات مهم جهت کنترل و پیگیری بصورت لحظه و با ثبت زمان رویداد در لاگ فایل ثبت می شود. 15.1 مدیریت لاگمنظور از مدیریت لاگ در واقع ذخیره، پردازش و تجزیه و تحلیل داده های جمع آوری شده ی برنامه و یا سیستم جهت بهبود عملکرد، مدیریت، شناسایی مشکلات و تقویت امنیت است. به طور کلی مدیریت لاگ را می توان به شش بخش تقسیم کرد که در ادامه هر یک را بررسی می کنیم. مجموعه لاگ. داده ها از بخش های مختلف جمع آوری می شوند بنابراین در وهله اول نیاز است تا نوع اطلاعات و نحوه ی جمع آوری و ذخیره سازی این داده ها مشخص شود.تجمیع لاگ متمرکز. فرآیند جمع آوری لاگ ها از منابع مختلف و تجمیع آنها در یک فایل مشکلاتی چون فرمت های متفاوت، سرعت تولید داده ها از چندین منبع مختلف و صحت سنجی داده های جمع آوری شده است که باید مدیریت شود.ذخیره سازی و نگهداری لاگ در طولانی مدت. با توجه به ذخیره لحظه ای داده ها در طول زمان، نگهداری این داده ها در طول زمان نیاز به حجم زیادی از حافظه دارد که در طولانی مدت به نوعی خیلی سخت و غیر ممکن می شود. بنابراین نیاز است تا با وضع قوانینی داده های قدیمی غیر قابل استفاده حذف شوند.تجزیه و تحلیل لاگ فایل. یکی از مهمترین وظایف مدیریت لاگ، تجزیه و تحلیل خودکار داده های موجود در لاگ فایل و ارائه گزارش حاصل از تجزیه و تحلیل در قالب نمودار ها جهت شناسایی مشکلات است. اما کشف و شناسایی مشکلات در میان حجم انبوهی از داده ها که لحظه به لحظه افزایش می یابد کار ساده ای نیست. بنابراین مدیریت لاگ بایستی با تجهیز به ابزارهایی این مشکل را حل کند.مدیریت لاگ فایل مزایایی را به همراه دارد که در ادامه بررسی می کنیم.نظارت بر داده های لاگ فایل در طول زمان و کمک در بهبود امنیتتحلیل رفتار مشتری به کمک لاگ و مدلسازی پیش بینیذخیره سازی یکپارچه داده هاعیب یابی سریع تراز جمله ابزارهای معروف در حوزه مدیریت لاگ فایل می توان به ELK, Sematex Logs, Sumo Logic اشاره کرد. پشته ELK دارای ابزارهایی به شرح زیر است: کمک به تجزیه و تحلیل قبل از indexingیک موتور جستجوی سریع و مقیاس پذیر بنام Elasticsearchارسال کننده لاگ بنام Logstashیک رابط کاربری برای جستجوی لاگ ها بنام Kibana16. ابزارهای مانیتورینگ (Monitoring tools)ابزارهای مانیتوریتنگ در وهله اول نوعی ابزار نظارتی و امنیتی هستند که روی سیستم یا شبکه ی یک سازمان نصب می شوند. ابزارهای مانیتورینگ سیستم، امکان پایش و بررسی مواردی چون پایداری سرویس ها، میزان استفاده از RAM، فرکانس CPU، میزان فضای خالی دیسک و مواردی از این دست را برای سازمان ها فراهم می کند. اما در این بخش هدف ما بررسی ابزارهای مانیتورینگ نرم افزار است. به طور کلی ابزارهای مانیتورینگ امکان نظارت پیوسته، مدیریت و بررسی میزان عملکرد و دسترس پذیری سیستم را فراهم می کنند. همچنین این ابزارها امکان بهبود رضایتمندی مشتری، پاسخگویی سریع تر، یافتن علت اصلی مشکل عملکردی و بهینه سازی برنامه های نرم افزاری و تحلیل رفتار کاربران در جهت ارائه خدمات بهتر را فراهم می کنند. از جمله ابزارهای مانیتورینگ می توان به Prometheus, EG Innovations, Zabbix, NinjaOne اشاره کرد. در ادامه پرومتئوس را بررسی می کنیم. 16.1 پرومتئوس (Prometheus)یک ابزار مانیتورینگ منبع باز است که در وهله اول به جمع آوری و تجزیه و تحلیل داده می پردازد. همچنین پرومتئوس یک ابزار مانیتورینگ مناسب برای محیط های کانتینری است که با استفاده از پینگ های SNMP می تواند چندین معیار را روی کوبرنت ها، سرورها و دستگاه های مختلف جمع آوری و میزان پهنای باند مصرفی توسط سرویس ها و دستگاه های مختلف را بررسی کند. پرومتئوس را می توان با Grafana جهت تجسم معیارها ادغام کرد.17. تحلیل کد استاتیک (Static Code Analysis)تحلیل و بازبینی کد در کشف خطا، یافتن کد مرده، نقض دستورالعمل های سبک کد، کشف مشکلات امنیتی، مشخص شدن مشکلات کد برنامه و تولید کدهای با کیفیت تر بسیار کمک می کند. به طور کلی بازبینی کد برنامه در اوایل توسعه و قبل از شروع تست انجام میشود. این بازبینی توسط عامل انسانی می تواند انجام شود، اما دقت پایین فرد، نیاز به پیدا کردن فرد متخصص به زبان پیاده سازی برنامه باعث می شود تا برای تحلیل و بازبینی کد برنامه از ابزارهای تحلیل ایستای کد استفاده شود. ابزارهای تحلیل ایستای کد می توانند بصورت خودکار و با دقت بالا اشتباهات و مشکلات امنیتی در سورس کد برنامه را کشف کنند. این ابزارها بدون نیاز به اجرای کد برنامه و تنها با بررسی کدها، می توانند عملیات بازبینی کد را انجام دهند. هر یک از ابزارهای تحلیل ایستای کد هزاران قوانین مختلف را برای زبان های برنامه نویسی مختلف شامل می شوند. همچنین در این ابزارها امکان شخصی سازی قوانین جهت هماهنگی با استانداردهای تعیین شده نیز وجود دارد. همچنین در چرخه DevOps امکان استفاده از ابزارهای تحلیل ایستای کد جهت دادن بازخورد به برنامه نویسان وجود دارد. از جمله ابزارهای تحلیل ایستای کد که امروزه استفاده می شوند می توان به SonarQube, SonarCloud, Checkmarx SAST CxSAST, Synopsis Coverity, Codacy و StyleCop اشاره کرد که در ادامه سونارکیوب را بررسی می کنیم. 17.1 سونارکیوبیکی از معروف ترین ابزارهای تحلیل ایستای کد است که بیش از 20 زبان برنامه نویسی را پشتیبانی می کند. به طور کلی سونارکیوب می توان گزارش هایی در مورد پیچیدگی کد، باگ ها، مشکلات امنیتی، استاندارد کد نویسی و کدهای تکراری را ارائه کند. سونارکیوب از دو بخش سرور و کلاینت تشکیل شده است. سمت کلاینت با استفاده از gradle کدها را اسکن و نتایج را به سرور سونارکیوب ارسال می کند. سمت سرور سونارکیوب وظیفه نگهداری اطلاعات کد و زمان اسکن ها را دارد. 17.2 نقاط قوت ابزارهای تحلیل ایستای کدبررسی و پوشش کامل سورس کد برنامه و کشف مشکلات موجود در سورس کد برنامهمقیاس پذیری بازبینی کد بصورت مستقل از کامپایلرافزایش سرعت و دقت بازبینی کد نسبت به عامل انسانی 17.3 نقاط ضعف ابزارهای تحلیل ایستای کدخطاهای False Positive. خطاهایی که ابزار به دلیل پیچیدگی کد گزارش می دهد.عدم کشف برخی از خطا مانند خطای کدهای همروند.اثبات آسیب پذیری مشکل امنیتی کشف شده دشوار است.18. تحویل مستمر (Continuous delivery)طبق تعریف کتاب Continuous Delivery، تحویل مستمر (Continuous Delivery) یا به اختصار CD، عملی برای اطمینان از اینکه نرم افزار همیشه آماده استقرار است. در واقع هدف CD خودکارسازی فرآیند استقرار و تحویل یک Artifact است. همچنین تحویل مستمر بخشی از CI/CD است. CI/CD یک روش جهت خودکارسازی برخی از مراحل توسعه برنامه است که در آن CI به ادغام پیوسته اشاره دارد. از جمله مسئولیت های CD می توان به استقرار Artifact ها، مدیریت و نظارت بر تغییرات و تهیه زیرساخت اشاره کرد. همان طور که گفته شد CD قصد دارد تا یک Artifact را آماده استقرار کند. یک Artifact برای اینکه استقرار یابد به چندین مولفه نیاز دارد. هر یک از این مولفه طبق pipline به شرح زیر هستند: دسترسی به محیط ابری تامین زیرساختمدیریت تغییرات استفاده از یک استراتژی برای استقراربررسی Performanceتعریف یک استراتژی بازگشتبنابراین هدف یک piplint از CD، خودکارسازی 6 فعالیت بالا جهت استقرار Artifact است. از جمله ابزارهای CD می توان به CircleCI, Jenkins, Argo CD, Harness, GitLab اشاره کرد. 18.1 مزایای CDکمک CD به تسریع ارائه نسخه های جدید نرم افزار به کاربراناستفاده توسعه دهنگان از ابزارهایی که برخی از فرآیندها را خودکارسازی می کنند موجب اطمینان از کیفیت محصول تولید شده می شود.افزایش سطح رضایتمندی مشتری از محصول کشف سریع تر اشکلات موجود تحویل مستمر باعث تسریع زمان ارائه محصول در بازار می شود.18.2 چالش های CDبروزرسانی های پی در پی موجب رضایت مندی برخی از کاربران نمی شود.تحویل پی در پی نرم افزار نیاز به تست و تایید دارد. بصورت کامل نمی توان آزمایش ها را خودکار کرد.19. احراز هویت یکپارچه (Single Sign On)Single Sign Onروش احراز هویت یکپارچه (SSO) یک روش احراز هویت است که به کاربران این امکان را می دهد تا به کمک مجموعه ای از اعتبارنامه ها (نام کاربری و رمز عبور) در چندین برنامه بصورت ایمن احراز هویت شوند. این شیوه از احراز هویت این امکان را به کاربران می دهد تا برای چند برنامه نیاز به ثبت نام و ثبت اطلاعات مجدد نداشته باشند. همچنین از دیدگاه امنیتی به دلیل کاهش تعداد اعتبارنامه های کاربر در SSO امکان سرقت اطلاعات کاهش می یابد. در واقع روش SSO براساس رابطه اعتماد بین یک ارائه کننده هویت و برنامه ها تنظیم شده است. 19.1 نحوه کار روش احراز هویت یکپارچهدر این روش احراز هویت ورود کاربران به برنامه ها متکی به یک سرویس مرکزی است. در این رویکرد هنگام مراجعه کاربر به برنامه اگر قبلا احراز هویت نشده باشد، یک درخواست احراز هویت را به برنامه می دهد و برنامه مورد نظر نیز کاربر را به سرویس مرکزی هدایت می کند. در سرویس مرکزی کاربر پس از احراز هویت به برنامه ای که درخواست احراز هویت داده بود هدایت می شود. این احراز هویت کاربر توسط سرویس مرکزی به کاربر پس از احراز هویت یک session اختصاص می دهد. این Session به کابران این امکان را می دهد تا نیازی به احراز هویت مجدد در سایر برنامه های متکی به سرویس مرکزی نباشد. 19.2 مزایای احراز هویت یکپارچهدر این روش کاربران دیگر نیازی تنظیم مجدد و تکرار رمز عبور برای احراز هویت در سامانه ها و برنامه های مختلف ندارند.به خاطر کاهش تعداد رمزهای عبور کاربران در برنامه های مختلف، امکان سرقت اطلاعات کاهش می یابد. روش احراز هویت یکپارچه امکان احراز هویت چند عاملی را برای کاربران فراهم می کنند. احراز هویت یک پارچه امکان تسریع بازیابی رمز را به کاربران می دهد. کاربران به جای اینکه رمز عبور خود را در برنامه های مختلف بازنشانی کنند می توانند تنها از طریق سیستم مرکزی این بازنشانی را انجام دهند.از جمله ابزارهای احراز هویت یکپارچه می توان به KeyCloak و Authelia اشاره کرد.20. سرویس مش (Service Mesh)Service Meshسرویس مش یک لایه زیرساختی برای برنامه محسوب می شود که مستنداتی از نحوه ارتباط بخش های مختلف سیستم را ارائه می دهد. بنابراین سرویس مش جهت بهینه سازی ارتباط بین بخش های مختلف سیستم و همچنین جلوگیری از قطعی در برنامه مخصوصا در برنامه های بزرگ می تواند مفید باشد. در معماری های مایکروسرویس اهمیت سرویس مش بیشتر نمایان می شود. در معماری مایکروسرویس هر سرویس خدماتی را ارائه می دهد و ممکن است در طول اجرا یک یا چندین سرویس دیگر را فراخوانی کند. همچنین در حین اجرای سرویس ها امکان بررسی و شناسایی بخش های پرکاربرد سیستم جهت ارائه خدمات بهتر به کاربران سیستم کار راحتی نیست. بنابراین سرویس ها بدون سرویس مش نیز قابل اجرا هستند اما در زمان هایی که سناریو پیچیده تر می شود سرویس مش اهمیت خود را نشان می دهد.در صورت استفاده از سرویس مش کدی به برنامه اضافه نمی شود و سرویس ها گویی بصورت مستقیم با سایرین در ارتباط هستند. اما در زیر ساخت شبکه قوانینی جهت دسترسی سرویس های مختلف به یکدیگر بررسی و تعیین می شود. به همین دلیل یک سرویس مش برای هر سرویس پروکسی ارائه می دهد. سرویس مش با دریافت درخواست یک سرویس برای اتصال به سرویس دیگر، بار ترافیکی مربوط به سرویس مقصد را بررسی می کند و درخواست را به مسیر و نود کم ترافیک تر هدایت می کند. پروکسی ها بصورت جداگانه در کنار سرویس ها قرار می گیرند و شبکه ای از مش را تشکیل می دهند که به آن سرویس مش می گویند. بدون سرویس مش هر سرویس منطق ارتباط با سایر سرویس ها را بایستی در خود داشته باشد. بنابراین توسعه دهنگان به جای تمرکز روی منطق برنامه درگیر چالش چگونگی ارتباط سرویس ها با یکدیگر می شوند. 21. Reference----------1----------https://www.infoq.com/articles/ddd-in-practicehttps://en.wikipedia.org/wiki/Domain-driven_designhttps://www.lucidchart.com/blog/domain-driven-design-introduction----------2-----------Hexagonal Architecture: three principles and an implementation exampleHexagonal Architecture, there are always two sides to every story----------3-----------https://microservices.io/patterns/data/cqrs.htmlhttps://en.wikipedia.org/wiki/Command%E2%80%93query_separationhttps://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs---------4----------Model–view–viewmodel - WikipediaIntroduction to Model View View Model (MVVM) - GeeksforGeeksMVVM – Introduction (tutorialspoint.com)----------5------------https://www.eventstore.com/blog/event-sourcing-and-cqrshttps://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcinghttps://eventuate.io/whyeventsourcing.htmlhttps://microservices.io/patterns/data/event-sourcing.html----------6----------Micro Frontends - extending the microservice idea to frontend development (micro-frontends.org)What is Micro-frontend Architecture? How To Implement It. (linkedin.com)Micro-frontend architecture: Principles, implementations and challenges (simform.com)----------7---------10 Best Low-Code Development Platforms in 2022 (softwaretestinghelp.com)----------8--------https://www.mulesoft.com/resources/esb/what-esbhttps://www.hcltech.com/blogs/everything-you-need-know-about-enterprise-service-bus-esb----------9---------https://www.nginx.com/learn/api-gateway/https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do----------10---------https://www.irandnn.ir/mag/what-is-bpms/https://bpmtraining.net/1398/01/19/bpms-%DA%86%DB%8C%D8%B3%D8%AA%D8%9F/---------11---------https://www.bptrends.com/business-rule-solutions-obligations-are-business-rules/https://en.wikipedia.org/wiki/Business_rule_management_system--------12--------https://www.instaclustr.com/blog/rabbitmq-vs-kafka/https://medium.com/tech-sauce/introduction-to-message-queuing-4a7ab8968b59https://betterprogramming.pub/introduction-to-message-queue-with-rabbitmq-python-639e397cb668RabbitMQ vs. Kafka. An architect’s dilemma | by Eran Stiller | Better ProgrammingRabbitMQ vs. Kafka: Head-To-Head | Better Programming---------13-----------داکر - ویکی‌پدیا، دانشنامهٔ آزاد (wikipedia.org)تفاوت داکر image و کانتینر (Docker Image and Container) | خواندنی های ابر آراز (arazcloud.com)---------------------------14----------------------------What Is Container Orchestration? | New RelicWhat Is Container Orchestration? A Newbie-Friendly Guide (cloudzero.com)----------15-----------https://www.graylog.org/post/what-is-log-management-a-complete-logging-guidehttps://www.humio.com/glossary/log-management/https://sematext.com/blog/best-log-management-tools/https://sematext.com/blog/best-log-management-tools/---------16--------------https://www.softwaretestinghelp.com/system-monitoring-software/https://www.dynatrace.com/monitoring/resources/monitoring-software/?https://www.techopedia.com/definition/4313/monitoring-softwarehttps://devopscube.com/best-opensource-monitoring-tools/-----------17--------------https://en.wikipedia.org/wiki/Static_program_analysishttps://www.appknox.com/blog/static-code-analysis https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysishttps://docs.sonarqube.org/latest/https://en.wikipedia.org/wiki/SonarQube-----------18-------------https://continuousdelivery.com/https://www.redhat.com/en/topics/devops/what-is-continuous-deliveryhttps://aws.amazon.com/devops/continuous-delivery/https://devops.com/the-state-of-continuous-delivery-in-2021/https://en.wikipedia.org/wiki/Continuous_delivery-----------19-------------https://authin.ir/single-sign-on/https://auth0.com/intro-to-iam/what-is-single-sign-on-sso/ https://www.onelogin.com/learn/how-single-sign-on-workshttps://www.miniorange.com/single-sign-on-sso-----------20-------------What's a service mesh? (redhat.com)علیرضا رشنوعلیرضا رشنوTue, 22 Nov 2022 15:56:30 +0330