https://virgool.io/feed/@marybarkhi1996 دانش آموخته مهندسی نرم افزار دانشگاه شهید بهشتی|توسعه دهنده نرم افزار در شرکت داتین fa 2026-06-16 21:39:41 https://files.virgool.io/upload/users/2274/avatar/nLvvFr.jpeg?height=120&width=120 https://virgool.io/@marybarkhi1996 https://virgool.io/@marybarkhi1996/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D9%85%D9%81%D9%87%D9%88%D9%85-api-gateway-wub7bi875tmx درگاه API، یک ابزار مدیریت API بین کلاینت ها و مجموعه ای از سرویس های بک اند است. API یا همان Application programming interface در سازمان ها عملا توسط درگاه های API پیاده سازی می شوند. معمولا هر درگاه کارهای خاصی را انجام می دهد، برای مثال احراز هویت از درگاه های خاصی انجام می شود. سازمان ها یک gateway در ورودی سازمان خود دارند؛ یعنی هر سرویسی که می خواهد وارد سازمان شود و ورود هر نوع داده یا اطلاعاتی در آن بررسی می شود اما موضوعی که در این پست به آن می پردازیم، بحث ارتباط بین میکروسرویس های داخلی یک سازمان است که مدیریت ارتباطات بین میکروسرویس های مختلف را بر عهده دارد.اصولا API ها به این منظور طراحی شده اند که ریکوئستی را دریافت کرده و پاسخ آن را بدهند؛ اما در واقعیت بحث های بسیاری در این امر وجود دارد از جمله:باید جلوی صدا زدن زیاد یک API خاص گرفته شود و مبدا آن مشخص باشد، زیرا ممکن است این یک حمله باشد.گاهی نیاز است، استفاده از API ها توسط کاربران برای انجام کارهای آماری پایش شود، مثلا زمانی که لود روی سیستم بالاست مشخص شود و یا اینکه از کدام API ها بیشتر استفاده می شود.اگر معماری آن سیستم مبتنی بر میکروسرویس باشد، یک کامپوننت می تواند صدها API دیگر را صدا بزند که همین امر ضرورت مدیریت یکپارچه API ها را نشان می دهد.گاهی API های جدید اضافه می شوند و تعدادی حذف می شوند، اما کلاینت ها باید همچنان بتوانند به سرویس های قبلی دسترسی داشته باشند.درگاه مدیریت API ، ریکوئست ها را دریافت می کند و بر طبق دسته بندی آن را به سمت یک سرویس خاص میفرستد. در سازمان هایی که بر پایه ی Deployment های سریع و مداوم کار می کنند، عموما معماری بر اساس میکرو سرویس است و اساسا یکی از مزایای استفاده از معماری میکروسرویس، قابلیت deploy سریع است. در معماری میکرو سرویس، راه ارتباطی میان میکروسرویس ها با کلاینت ها، API ها هستند. چون در معماری میکرو سرویس بر خلاف monolithic تنها یک Endpoint وجود ندارد و چند دریافت کننده وجود دارد.همچنین در معماری های در بستر cloud نیز،API ها از اهمیت بالایی برخوردار هستند.چون در معماری میکروسرویس، هر بخش از برنامه می تواند روی یک سرویس بالا آمده باشد، ممکن است برای لود شدن یک صفحه به عنوان مثال در یک وب اپلیکیشن به صدا زدن چند سرویس نیاز باشد. درگاه API مثل الگوی طراحی facade است. یعنی پیچیدگی صدا زدن چندین API از دید کاربر پنهان می ماند و از دید کاربر تنها یک API صدا زده می شود.زمانی که در یک سیستم مونولیت، کلاینت درخواستی را ارسال می کند، این درخواست صرفا یک REST CALL به سمت اپلیکیشن است. در ادامه ماژولی مثل load balancer این درخواست را به یکی از instanceهای برنامه هدایت می کند. این instance ها همگی مشابه هستند زیرا سیستم یکپارچه است. حالا از هر instance ی می تواند روی دیتابیس های مختلفی کوئری زده شود و نتیجه یکجا شده و به سمت کاربر ارسال شود.اما زمانی که اپلیکیشن با سبک معماری میکروسرویس توسعه داده شده باشد، برای مثال در یک صفحه وب یک اپلیکیشن فروشگاه اینترنتی، اطلاعات از چندین میکروسرویس مجزا آمده است. در تئوری، شاید به نظر برسد هر کلاینت می تواند به هر کدام از این میکروسرویس ها در ارتباط باشد و با هر میکروسرویس مثل یک سیستم مونولیت برخورد شود که endpoint ی برای برقراری ارتباط با بیرون را دارد؛ اما در عمل اینگونه نیست. مثلا در همان مثال فروشگاه اینترنتی اگر فروشگاه آنلاین بزرگی مثل آمازون را در نظر بگیریم، در پشت هر صفحه ممکن است نیاز باشد صدها سرویس فراخوانی شوند و اگر همه این درخواست ها بخواهند جدا جدا از طریق شبکه به سرویس مقصد خود متصل شوند، هم مشکل پیچیدگی استفاده و مدیریت فراخوانی ها به وجود می آید و در سمت کلاینت باید کدهای زیادی دولوپ شود و هم شبکه بسیار اشغال می شود. همچنین در بحث توسعه میکروسرویس ها مبحثی به نام خودمختاری هر میکروسرویس وجود دارد. یعنی تکنولوژی مورد استفاده در یک میکروسرویس می تواند مستقل از سایر میکروسرویس ها و پلتفرم ها و صرفا بر اساس نیاز های آن میکروسرویس انتخاب شود. پس ممکن است بعضی میکروسرویس ها امکان داشتن endpointی برای اتصال در محیط وب را به عنوان مثال نداشته باشند و نیاز باشد از این میکروسرویس در وب اپلیکیشن استفاده شود. پس نتیجه می شود، نحوه برخورد و برقراری ارتباط با میکروسرویس ها کاملا متفاوت از سیستم های مونولیت است. این همان جایی است که اهمیت استفاه از API Gateway خود را نشان می دهد. این درگاه باعث می شود از دید کلاینت ها سیستم طوری به نظر برسد که فقط یک درگاه ورودی دارد و همچنین از دید میکروسرویس های داخل سیستم راه ارتباطی بین یکدیگر تنها واسطی به نام API Gateway است. سازو کار این درگاه به سنگینی ESB که در معماری سرویس گرا نیست، مثلا وظیفه orchestration، چیزی که در معماری سرویس گرا بسیار رایج بود را ندارد، اما واسطی سبک وزن برای مدیریت است.مزایا و معایبمهم ترین مزیت استفاده ازAPI Gateway که تا به اینجا بیان شد، یکپارچه بودن محل اتصال به سیستمی است که با معماری میکروسرویس توسعه داده شده است. اما معایبی مانند اضافه شدن یک کامپوننت جدید به سیستم وجود دارد، به هر حال این کاموننت پیچیدگی هایی مختص به خود برای توسعه، استقرار و مدیریت دارد. همچنین این ریسک به وجود می آید که اگر رخنه امنیتی در این درگاه وجود داشته باشد، می تواند بین تمام میکروسرویس ها و به خارج از سیستم منتشر شود. پس توسعه دهندگان همواره باید ابزارهای استفاده شده در آن را آپدیت کنند و به نگهداری این کامپوننت بسیار اهمیت بدهند. استفاده از معماری میکروسرویس و کامپوننت های مورد استفاده اش در هر صورت یک trade off برای تصمیم گیرندگان آن پروژه است. چون در کنار مزایای بسیار زیاد، معایبی نیز با خود دارد.نکات تکمیلیملاحظاتی که باید در طراحی API Gateway در نظر گرفته شود:کارآیی و مقیاس پذیری(performance and scalability)شاید همه اپلیکشن ها مثل آمازون یا نتفلیکس نیاز به مدیریت میلیون ها کاربر در ثانیه را نداشته باشند اما چیزی که مهم است در طراحی این گذرگاه باید این دید وجود داشته باشد که در ادامه ممکن است نیاز به افزایش مقیاس سیستم باشد و گذرگاه باید این قابلیت را داشته باشد و همچنان کارآیی خود را حفظ کند. پس این کامپوننت باید درگاه ورودی خروجی آسنکرون داشته باشد تا بتواند حجم زیاد درخواست ها را مدیریت کند. برای مثال اگر قرار باشد API Gateway با جاوا پیاده سازی شود، می توان در JVM از فریمورک های NON Blocking I/O مثل Netty , Vertx , Spring Reactor یا JBoss استفاده کرد. گزینه دیگر استفاده ازNGINX plus است که شامل سرور وب و پروکسی است که هم کارایی بالایی دارد و هم مقیاس پذیر است. همچنین امکانات دیگری مثل احراز هویت، کنترل سطح دسترسی،توزیع بار، کش کردن درخواست ها و مانیتور کردن وضعیت سیستم را نیز دارد.استفاده از مدل های تعاملی(Using a reactive programming mode)کار API Gateway هم ارسال درخواست های بیرونی به سرویس مقصد و هم مدیریت ارتباطات بین سرویسی برای تجمیع پاسخ های آن ها در داخل سیستم است. برای اینکه این زمان نهایی دریافت پاسخ توسط کلاینت کاهش یابد، نیاز است که این ارتباطات درون سیتسمی به صورت همروند اجرا شوند؛ اما به هر حال زمان هایی وجود دارد که بین این درخواست های رد و بدل شده، وابستگی هایی وجود دارد. مثلا اول از همه همیشه نیاز است که سرویس اعتبارسنجی پاسخ خود را بدهد و اگر درخواست معتبر بود در ادامه سرویس های دیگر اجرا شوند. در اینجا صرفا مدیریت آسنکرون درخواست ها کمک کننده نخواهد بود. راه حل بهتر که از پیچیده شدن کد نیز جلوگیری می کند، استفاده از زبان های Declarative است مانند Scala. همچنین در جاوا اکستنشن هایی وجود دارد مثل Rxjava .این ابزارها برای ساده سازی کد این گذرگاه و کارا بودن آن بسیار مفید است.فراخوانی سرویس ها(Service invocation)سیستمی که معماری میکروسرویس دارد، عموما یک سیستم توزیع شده است و باید مکانیزم ارتباطی بین اجزای داخلی آن وجود داشته باشد. دو مدل ارتباطی وجود دارد: یکی استفاده از مکانیزمی های آسنکرون بر پایه ارسال پیام. برای این منظور بعضی از سیستم ها از message broker هایی مثل JMS یا AMPQ استفاده می کنند. نوع دیگر استفاده از مکانیزم های سنکرون مثل http یا thrift است. یک پیاده سازی از API Gateway لازم است که از چندین مکانیزم ارتباطی مثل سنکرون و آسنکرون پشتیبانی کند.کشف سرویس ها (Service discovery)لازم است که API Gateway محل هر میکروسرویس را بدانند تا بتوانند به آن آدرس دهی کنند. اما در زیرساختی هایی که امروزه استفاده می شود مثل Cloud این موضوع خیلی بدیهی نیست. چرا که ممکن است نیاز باشد محل یک میکروسرویس در طول زمان تغییر کند. پس این درگاه نیاز دارد از مکانیزم هایی استفاده کند که به طور پویا از محل قرارگیری هر میکروسرویس اطلاع داشته باشد. Service Registry دیتابیسی است که محل قرار گیری هر میکروسرویس در آن ذخیره میشود.مدیریت خرابی های جزئی(Handling partial failure)اگر زمانی که سرویسی سرویس دیگری را فراخوانی می کند، سرویس مقصد به هر دلیلی در دسترس نباشد یا زمان ارسال پاسخ آن طول بکشد، باید مکانیزمی در API Gateway فراهم باشد تا این درخواست گم نشود. مثلا گذرگاه می تواند اطلاعات کش شده ای که در رابطه با این درخواست از قبل داشت، به عنوان پاسخ آن ارسال کند یا اطلاعات دیفالتی را به عنوان پاسخ بر گرداند که سیستم کرش نکند و همچنین کاربر تجربه کاربری بهتری داشته باشد.معرفی بعضی ابزارهای API gateway managementIBM API ManagementAkanaمنابعhttps://www.redhat.com/en/topics/api/what-does-an-api-gateway-do#:~:text=An%20API%20gateway%20is%20an,and%20return%20the%20appropriate%20resulthttps://www.softwaretestinghelp.com/api-management-tools/https://nikamooz.com/api-gateway/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» مرضیه برخی مرضیه برخی Fri, 24 Dec 2021 22:10:17 +0330 https://virgool.io/@marybarkhi1996/%D8%B5%D9%81-%D9%BE%DB%8C%D8%A7%D9%85-message-queue-%D9%88-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF-%D9%87%D8%A7%DB%8C-%D8%A2%D9%86-zxc5dxbs0kxp تعاریفصف پیام، راه حلی برای ارتباط از طریق سرویس بین برنامه های کاربردی است صرف نظر از این که هر برنامه یا داده های مربوط به آن در چه محیطی عملیاتی شده اند. به عنوان مثال راه ارتباطی بین برنامه هایی که روی یک سرور قرار دارند، روی سرورهای مختلف توزیع شده ولی با معماری یکسان و یا حتی روی سرورهای متفاوت با الگوهای معماری متفاوت هستند، می تواند باشد. در این مکانیزم، پیام ها در صف هایی ارسال و دریافت می شوند. صف پیام یک لایه ارتباطی برای انتقال پیام بین برنامه های مختلف ایجاد می کند که در طول انتقال پیام محتوای داخل آن مشخص نیست و زمانی که هر پیام به مقصد رسید، گیرنده از آن برای ارتباط با لایه بیزینس، دیتابیس و غیره می تواند استفاده کند. صف پیام برای انتقال پیام ها از API هایی استفاده می کند که قابلیت تعامل بین برنامه های کاربردی مختلف با زبان های برنامه نویسی مختلف و در پلتفرم های مختلف را دارد.کاربرد اصلی صف پیام را می توان زمانی در نظر گرفت که نرخ ارسال اطلاعات از سمت تولید کننده پیام با نرخ دریاف پیام در سمت مصرف کننده یکسان نباشد، پس به یک میانجی نیاز است تا این حجم پیام های ورودی را به صورت توزیع شده در اختیار مصرف کننده قرار دهد تا هم سرعت پردازش بالا رود و هم حجم داده ورودی به سمت مصرف کننده کاهش پیدا کند.مثالی از message queueاما در ادامه ابزارهای message broker معرفی شدند که به منظور هدایت پیام ها، از محتوای داخل هر پیام نیز مطلع هستند و برای هر پیامی با توجه به محتوای آن می توانند، عملیاتی مختص به آن را تعریف کنند. منبع این پیام ها می تواند انواع مختلفی داشته باشد، مثلا java message services (jms) یا فایل های متنی و غیره. این عملکرد، به منزله ی ایجاد یک مسیر مجزا بین مبدا و مقصد هر پیام بر حسب محتوای آن می باشد.در غالب سیستم های نرم افزاری امروزی، معماری برنامه ها به گونه است که هر بخش به صورت واحدهای جداگانه و مستقل طراحی، پیاده سازی و عملیاتی می شود و ارتباط و ارسال پیام بین هر کدام از این واحد ها به صورت ناهمگام توسط صف پیام صورت می گیرد. این پیام ها معمولا سبک هستند؛ مثلا درخواست ارسال شده و پاسخ دریافت شده از یک سرویس یا متن خطایی که رخ داده است. برای ارسال پیام، تولید کننده، پیام را به صف میفرستد و این پیام تا زمانی که مصرف کننده از سر صف پیام ها را بردارد و نوبت به آن برسد، در صف باقی می ماند.ساختار message queueمعرفی چند نمونه ابزار صف پیامActiveMQیک پروتکل متن باز به زبان جاوا است که توسط آپاچی به عنوان یک میان افزار برای ارسال پیام، توسعه داده شده است و از قالب های مختلف پیام مثل JMS پشتیبانی می کند. activeMQ می تواند همزمان چند کلاینت و سرور را به هم متصل کند تا به صورت همزمان به یکدیگر پیام ارسال کنند. حتی اگر یک برنامه به طور موقت از کار بیفتد، پیام رسانی همچنان به طور موازی انجام خواهد شد و مثلا پیام خطا از سمت آن دریافت می شود.Kafkaیک پلتفرم متن باز است که توسط لینکداین به زبان اسکالا و جاوا توسعه داده شده و سپس در اختیار آپاچی قرار گرفته است. kafka مزایایی دارد از جمله: امکان مقیاس پذیری مصرف کننده ها، تولید کننده ها، پردازنده ها و اتصالات برای ارسال و دریافت پیام را تا حد بالایی ایجاد می کند.با حجم بالایی از داده ها به راحتی کار بکند.کارآیی بالایی دارد، زیرا برای مدیریت صف های پیام در داخل خود از چند پارتیشن به طور موازی استفاده می کند و این نکته مزیت kafka نسبت به ابزارهای مدیریت پیام قدیمی تر مثل activeMQ یا rabbitMQ است. تحمل خطای مناسبی دارد و در صورت از کار افتادن موقتی مبدا و مقصد همچنان می تواند به کار خود ادامه دهد.ساختار kafkaمنابعhttps://git.ir/kafka/https://www.extrahop.com/resources/protocols/activemq/http://javaresolutions.blogspot.com/2014/08/messagequeue-vs-message-broker.html«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» مرضیه برخی مرضیه برخی Fri, 24 Dec 2021 20:37:52 +0330 https://virgool.io/@marybarkhi1996/%D8%AC%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D9%88-%D8%B9%D9%85%D9%84%DA%A9%D8%B1%D8%AF-esb-%D8%AF%D8%B1-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-%D9%87%D8%A7-bhk92qjsu09f مفهوم ESBهر چقدر یک سازمان نرم افزاری بزرگ تر باشد و پروژه های آن مربوط به بیزینس های بزرگ و پیچیده تری باشد، یا بخواهد در لحظه به تعداد زیادی از کاربران خدمات ارائه دهد، این خدمات را در قالب سرویس هایی ارائه می کند که قابلیت دسترسی هم از طریق بخش های دیگری درون سازمان مهیا باشد، هم از خارج سازمان بتوان به آن ها داشت. به عنوان مثال اگر یک سازمان توسعه دهنده خدمات بانکی را در نظر بگیرید، درون سازمان تیم های مختلفی روی بخش های متفاوتی از سامانه های بانکی کار می کنند که نیاز دارند از یکدیگر سرویس بگیرند، مثلا برای افتتاح حساب، نیاز است که اطلاعات هویتی مشتری از تیم دیگری دریافت شود؛ همچنین سرویس هایی مثل همین اطلاعات هویتی مشتری می تواند از خارج از سازمان در شعب بانک ها صدا زده شود و ارتباط لزوما دیگر محدود به داخل سازمان نباشد. حال که اهمیت وجود این سرویس های داخلی و خارجی مشخص شد، باید روش برای ایجاد این ارتباط درون و برون سازمانی در نظر گرفته شود؛ مسلما اگر این ارتباط بخواهد نقطه به نقطه باشد، عدم وجود یک زبان مشترک، مشکل ساز خواهد شد. زیرا لزوما این سرویس ها یکسان پیاده سازی نشده اند و برای فهم هر کدام توسط مقصد، باید یک واسطی جهت ترجمه و یکسان سازی وجود داشته باشد. این نقطه جایی است که Enterprise service bus یا گذرگاه سرویس سازمانی اهمیت خود را نشان می دهد. گذرگاه سرویس سازمانی یک گذرگاه مشترک برای تمام وب سرویس های یک سازمان است که ممکن است با پروتکل های مختلفی بخواهند با هم ارتباط برقرار کنند و کار این گذرگاه ترجمه پیام از سمت مبدا و انتقال آن به مقصد خواهد بود.در ادامه ضرورت وجود گذرگاه سرویس سازمانی، می توان به امکان متعادل سازی بار در شبکه، ارسال ناهمگام پیام ها و تبدیل پروتکل های ارتباطی به هم اشاره کرد. زیرا اگر این ارتباط بین بخش های مختلف در هر زمانی که هر کدام نیاز به سرویس داشته باشند، بخواهد نقطه به نقطه به یکدیگر متصل شوند، حتی اگر از پروتکل های ارتباطی یکسانی استفاده کنند، بار در شبکه خیلی زیاد خواهد شد و ممکن است سرویس دهنده نتواند به درخواست پاسخ دهد. همچنین مدیریت این سرویس ها اگر به صورت یکپارچه نباشد، زمینه ساز بروز مشکلات امنیتی و ساختاری فراوان خواهد شد. اگر همان سیستم بانکی را در نظر بگیرید که روزانه حجم زیادی تراکنش توسط سرویس ها در آن انجام می شود که مدیریت آن ها صرفا از طریق یک گذرگاه مشترک امکان پذیر خواهد بود. همچنین اگر یک یا چند وب سرویس در یک سازمان تغییر کند، با وجود یک گذرگاه مدیریتی مشترک، نیاز به اطلاع رسانی به تک تک سرویس گیرنده ها نخواهد بود.انواع ESBطبق توضیحات کلی که تا الان داده شد، این گذرگاه ابزاری برای یکپارچه سازی مدیریت بین وب سرویس هاست اما در حقیقت در سطوح مختلفی می توان از ابزار های ESB استفاده کرد. زیرا گذرگاه یک مفهموم انتزاعی است و در هر کاری با توجه به نیاز باید از سطح مختلفی استفاده کرد.Integration framework انتقال داده از یک گذرگاه مشترک همان مفهموم یکپارچه سازی است و ابزارهایی مثل apache camel، spring integration برای پیاده سازی آن ها در زبان جاوا مناسب هستند.Enterprise service busدر این سطح علاوه بر دستیابی به هدف یکپارچه سازی تعاملات برنامه ها، ابزارهای مفیدی برای انتشار و مدیریت و پایش نیز وجود داردIntegration suiteتا الان وجود گذرگاه های مشترک بین برنامه های کاربردی مطرح بود اما اگر این گذرگاه ها بخواهد در سطح سازمان پیاده شود، یعنی یکپارچگی بین تمام عناصر موجود در سازمان، از جمله افراد و فرآیند ها و نقش ها نیز انجام شود، لازم است از سیستم های مدیریت کسب و کار مثل BPM نیز در کنار سیستم های یکپارچه سازی سرویس ها استفاده شود که به آن یک مجموعه برای مدیریت یکپارچگی گفته می شود. در شکل زیر مثالی از آن در یک سیستم حسابداری آمده است.معرفی چند ابزار متن باز برای پیاده سازی ESBMuleEsbاین ابزار هم امکان Integration و هم esb را فراهم می کند که در سال 2003 توسعه داده شد.Wso2یک نرم افزار بر پایه معماری سرویس گرا است که توسط کارمندان سابق شرکت آی بی ام در سال 2005 توسعه داده شد. چند شرکت ها ایرانی که روی این موضوع کار می کنند.گروه مهندسی ICANشرکت platcoشرکت داده پرداز پویای شریفنرم افزار یکپارچه سازی توسعه داده شده توسط این شرکت ها، ارتباط بین نرم افزارها و سرویس های داخلی و خارجی یک سازمان را فراهم می کند و امکان مدیریت پیام های بین نرم افزاری، پایش و اعمال سطوح دسترسی مختلف در آن وجود دارد.منابعhttps://www.innovativearchitects.com/KnowledgeCenter/business-connectivity/ESB-EAI-SOA.aspxhttps://platco.ir/tag/esb-software/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» مرضیه برخی مرضیه برخی Fri, 24 Dec 2021 17:08:21 +0330 https://virgool.io/@marybarkhi1996/%D8%A7%D8%AD%D8%B1%D8%A7%D8%B2-%D9%87%D9%88%DB%8C%D8%AA-%D8%A8%D8%A7-%D9%85%DA%A9%D8%A7%D9%86%DB%8C%D8%B2%D9%85-sso-rvcl9kii4goi نرم افزارهای احراز هویت های یکباره یا single sign on، امکان ورود یک باره به سیستم را برای کاربران فراهم می کند. برای مثال اگر محصولات گوگل را در نظر بگیریم، با یک بار ورود و احراز هویت شدن در هر کدام از آن ها مثلا جیمیل، امکان ورود به سایر برنامه های کاربردی نیز وجود خواهد داشت، بدون آن که نیاز به احراز هویت مجدد باشد. در حقیقت این فرآیند احراز هویت در پشت صحنه می شود، اما از دیدگاه کاربرا این کار تنها یک بار انجام شده است. همین امر باعث بهبود تجربه کاربری می شود، زیرا کاربر می داند که چندین نرم افزار متعلق به یک مجموعه هستند، پس اگر بتواند با یک بار احراز هویت، از تمامی آن ها استفاده کند، بسیار برایش رضایت بخش خواهد بود.شاید اولین سوالی که پیرامون این موضوع به ذهن برسد این است که این فرآیند احراز هویت یکباره، آیا باعث کاهش امنیت می شود؟ زیرا کاربری که تنها یکبار احراز هویت شده است، امکان دسترسی به برنامه های دیگر را خواهد داشت و اگر مهاجمی بتواند به سرور sso دسترسی پیدا کند، امنیت تمام برنامه هایی که از آن استفاده کردند، تحت الشعاع قرار می گیرد. پس لازم است که مکانیزم های سخت گیرانه ای مانند استفاده از رمز عبور دو مرحله ای2FA در همان فرآیند احراز هویت انجام شود. زیرا همان طور که این روش مزایایی دارد، ریسک ها و سختی هایی نیز در آن وجود دارد که در ادامه به برخی از آن ها اشاره می کنیم.مزایای روش SSOیکپارچه سازی فرآیند احراز هویت مزایایی دارد که استفاده از آن را در نهایت سودمند می کند، زیرا دیگر نیاز به وجود سربار برای پیاده سازی پروتکل های امنیتی در هر برنامه کاربردی نیست و تمام دسترسی ها یکجا می توانند کنترل شوند. مثلا خطر حمله fishing کمتر می شود، چون بخش احراز هویت یکسان است و صفحات مختلفی برای آن وجود ندارد و امکان مانیتور کردن آن ساده تر است. همچنین رضایت کاربران نیز بسیار بیشتر می شود، چون تعداد گذرواژه هایی که برای ورود به هر برنامه باید به خاطر داشته باشند کمتر شده است. اگر تعداد برنامه هایی که کاربر از آن ها استفاده می کند زیاد باشد و هر کدام اطلاعات جداگانه ای برای ثبت نام بخواهند، احتمال این که کاربر در تمام آن ها اطلاعات درستی را وارد کند، کم است؛ اطلاعاتی مثل نام،ایمیل و غیره. پس اگر این اطلاعات یکبار از کاربر دریافت شود، احتمال صحت آن ها نیز بیشتر خواهد بود.معایب روش SSOاگر نیاز باشد هر برنامه کاربردی سطح امنیتی متفاوتی برای احراز هویت داشته باشد، نمی توان آن را در SSO پیاده سازی کرد؛ چون همگی یکسان مدیریت می شوند. همچنین حفط امنیت و نگهداری سرور SSO بسیار حائز اهمیت است، چون در دسترس نبودن یا در معرض حمله قرار گرفتن آن می تواند موجب آسیب به برنامه های کاربردی دیگر شود.تعاریفی پیرامون انواع SSO و پروتکل های ارتباطی آن هاSocial SSOاین نوع احراز هویت توسط حساب یکی از سرویس های شبکه های اجتماعی افراد انجام می شود. مثلا شخصی یکبار در فیسبوک احراز هویت می شود و پس از آن اگر بخواهد وارد حساب لینکدین خود شود، می تواند همان روش احراز هویت فیسبوک را انتخاب کرده و وارد شود.Enterprise SSO اگر سازمانی را در نظر بگیرید که سرویس های مختلفی را به کارمندان خود ارائه می دهد، مثلا در شرکت نرم افزاری، سیستم های مدیریت کارکرد، کانفلوئنس، جیرا و غیره. اگر برای ورود به هر کدام از آن ها، کاربر را ملزم به ورود نام کاربری و گذرواژه کند، بسیار برای کارمندان ناخوشایند است؛ اما استفاده از SSO سازمانی برای سرویس های یک سازمان راه حل این مشکل خواهد بود.LDAPیک پروتکل در لایه اپلیکیشن برای ارتباط با سرویس دایرکتوری ها است که هر بخش در دایرکتوری می تواند سیستم عامل و ساختار متفاوت مربوط به خود را داشته باشد.SAMLزبان ارتباطی بین سرور SSO و برنامه های کاربردی بر پایه ی xml است.معرفی چند ابزار متن باز برای ارائه سرویس SSOKeyCloakاین نرم افزار قابلیت SSO را در برنامه های در بستر وب فراهم می کند. زبان آن saml2.0 است و از طریق LDAP ارتباط بین اکتیو دایرکتوری و سرور احراز هویت را فراهم می کند. یک واسط کاربری دارد که کاربران می توانند نقش ها، دسترسی ها و اندازه سشن ها را در آن تعریف کنند. برنامه های مقصد در آن می توانند به زبان های مختلفی مثل جاوا، سی شارپ و جاوا اسکریپت نوشته شده باشند. سورس کد آن برای استفاده در گیت هاب موجود است.Autheliaیک نرم افزار با قابلیت های زیاد است و امکان استفاده در مقیاس های بزرگ را دارد. از LDAP و ارتباط با اکتیو دایرکتوری ها پشتیبانی می کند. برای انجام احراز هویت از فرآیند رمز یکبار مصرف گوگل استفاده می کند و به زبان Go نوشته شده است و سورس آن در گیت هاب موجود است.معرفی چند شرکت ارائه دهنده خدمات SSO در ایرانشرکت هویتا: سرویسی به نام pars sso ارائه می دهد که یک سامانه احراز هویت تمرکز و امضای دیجیتال است.شرکت پارسومنابعhttps://blog.containerize.com/2021/01/29/top-5-open-source-single-sign-on-software-in-the-year-2021/https://www.techtarget.com/searchsecurity/definition/single-sign-onhttps://authin.ir/single-sign-on-blog/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» مرضیه برخی مرضیه برخی Fri, 24 Dec 2021 13:51:41 +0330 https://virgool.io/@marybarkhi1996/%D9%85%D8%B3%D8%AA%D9%86%D8%AF-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%DB%8C%DA%A9-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%DB%8C%D8%A7-%D8%A7%D9%84%D8%B2%D8%A7%D9%85-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%A8%D8%A7-%D9%85%D8%AF%D9%84-c4-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%B1%D8%A7-%D9%85%D8%B3%D8%AA%D9%86%D8%AF-%DA%A9%D9%86%DB%8C%D9%85-crvj2pdyhgk4 توسعه و نگهداری سیستم های نرم افزاری بزرگ، اغلب کار زمانبری است و سال ها می تواند طول بکشد. حال در این میان اگر نیازمندی های جدید به وجود بیاید شاید معماری و ساختار تغییر کند و تمام ذینفعان در پروژه، باید هر کدام با یک سطحی از انتزاع از این تصمیمات و نحوه اجرای آن، مطلع شوند. اکثر اوقات در تیم توسعه نرم افزار، معمار یا راهبر فنی که تصمیمات معماری را گرفته است، همه توسعه دهندگان را دور هم جمع می کند و روی یک تخته، با کشیدن یک سری اشکال هندسی و اسامی مخفف و وصل کردن آن ها به هم، ساختار جدید را برای تیم توضیح می دهد؛ اما آیا این روش ارائه برای نرم افزار که بسیار پیچیدگی دارد و از جنبه های مختلفی باید بررسی شود کافی است؟ می توان همین طراحی ساده مصور را به سهامداران یا معاونت یک سازمان ارائه داد و آن ها را توجیه کرد که چرا این تخمین زمانی را برای پروژه داده ایم؟ و آیا این طراحی قابل ارزیابی و اتکا است و در طول زمان قابلیت بهبود دارد؟مسلما پاسخ سوالات بالا "خیر" است و اصولا یک طراحی و دانش ذهنی تا مستند نشود، قابلیت ارائه ندارد و نمیتوان توقع داشت افراد آن را درک کنند و در سازمان ماندگار باشد.حال در پروژه های نرم افزاری که با متودولوژی اجایل پیش می روند، این سوال مطرح است که اصولا زمانی برای مستند سازی های گسترده به خصوص برای معماری که در سطح کلان، ساختار نرم افزار را توصیف می کند، وجود ندارد؛ اما باید به این نکته توجه کرد که ضررهای مستند نکردن معماری و بدهی فنی که به پروژه تحمیل می کند، در گذر زمان می تواند بسیار بیش تر از زمانی باشد که باید در طول فرآیند، به مستند سازی اختصاص داده می شد. پس یک مستند متناسب و استاندارد نیاز است.روش C4 که در ادامه به معرفی مختصری از آن می پردازیم، یکی از روش های مستند سازی معماری است که در در چهار سطح معماری را مدل می کند و مخاطب هر کدام از این سطوح، گروهی از ذینفعان پروژه می توانند باشند. از این روش هم پیش از شروع فرآیند توسعه می توان استفاده کرد و هم با وجود کد می توان نگاشتی از مدل را برای آن ایجاد کرد.یک سیستم نرم افزاری شامل اجزای زیر است.Contextاین جنبه از نرم افزار به جزئیات توجهی ندارد و اجزای کلیدی را بیان می کند، مثلا نرم افزاری در حوزه بانکی که در دسترس تمام افرادی است که از خدمات آن بانک استفاده می کنند.Containersبه محض این که فضای مسئله مشخص شد، باید تعیین کرد که این نرم افزار، در چه قالب هایی می تواند ارائه شود، مثلا یک برنامه کاربردی در بستر وب یا موبایل. در این گام به توصیف ریزدانه تری از نرم افزار می رسیم و اجزای آن را که به طور مستقل می توانند عملیاتی شوند، نشان می دهیم. این اجزای مستقل، معمولا با API ها با هم در ارتباط هستند. مثلا نرم افزارهای در بستر موبایل با واحد core یک سیستم بانکی در ارتباط هستند و از آن سرویس میگیرند و مستقل از نرم افزارهای در بستر وب کار می کنند.Componentsحال با یک نگاه عمیق و فنی تر، می توان اجزای هر کانتینر را بررسی کرد. برای مثال تکنولوژی های مورد نیاز برای پیاده سازی یک برنامه کاربری موبایل. واضح است که دانستن این جزئیات مربوط به افرادی است که دانش فنی بالایی در حوزه تولید نرم افزار دارند و تکنیک ها و ابزار ها و محدودیت ها را می شناسند و با مشورت و همفکری بهترین حالت ها را انتخاب می کنندCodeوقتی ساختار درون کامپوننت ها مشخص شد، دیگر باید به جزئیات و نحوه ی پیاده سازی پرداخت و روابط بین اشیا و کلاس ها و غیره را با استفاده از UML بر اساس ساختار یا رفتار آن ها مدلسازی کرد.روش های رسم نمودار ها در مدل C4، مانند هر نمودار دیگری می تواند باشد، صرفا ماهیت مواردی که در هر سطح باید وجود داشته باشد، در این مدل اهمیت دارد. یکی از ساده و در دسترس ترین روش ها استفاده از سایت draw.io یا بعضی افزونه های موجود در گیت هاب می باشد.و در پایاندر تمام گام های تولید نرم افزار به خصوص معماری نرم افزار، باید اهمیت داشتن مستند درک شود و تا جای امکان باید با استفاده از تکنیک های مورد قبول متخصصان این حوزه، مستنداتی صریح، جامع و متناسب با دید ذینفعان پروژه تهیه کرد.منابعhttps://www.aparat.com/v/6Rvzohttps://c4model.com/https://en.wikipedia.org/wiki/C4_model«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» مرضیه برخی مرضیه برخی Fri, 19 Nov 2021 22:39:24 +0330