https://virgool.ir/feed/@m_75137245fa2026-11-12 16:33:36https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@m_75137245https://virgool.ir/@m_75137245/بررسی-معماریھای-مبتنی-بر-میکروسرویس-و-کانتینرها-esrxt2oys9yjمقدمهدر این مطلب تلاش شده به سوالاتی در خصوص معماری میکروسرویس پاسخ داده شود. این سوالات بعضا از جنس معماری و بعضا برسی ابزار های مختلف که به پیاده سازی این معماری کمک میکند هستند.در بخش اول ابتدا تعریفی از معماری میکروسرویس ارائه میشود. سپس به برسی تفاوت های معماری میکروسرویس و monolithic پرداخته میشود همچنین نقاط قوت و ضعف هرکدام برسی شده و اصولی برای مهاجرت از معماری monolithic به میکروسرویس ارائه میشود.در بخش بعدی به برسی اصولی پرداخته می شود که رعایت آن در معماری میکروسرویس باعث بهبود برخی از شاخص های کیفی معماری نرم افزار میشود.در بخش بعد به برسی نحوه ارتباط سرویس ها با هم در معماری میکروسرویس همچنین روش های به حداقل رساندن این ارتباط و ابزار هایی که برای این ارتباط ها استفاده میشود میپردازیم.بخش آخر به برسی ابزار ها و نکات مهم در فرآیند دیپلویمنت مرتبط به این معماری پرداخته میشود و برخی از این ابزار ها با هم مقایسه میشوند.تاریخچه معماری میکروسرویسنیاز به وجود نرم افزاری که اجزای آن به صورت کاملا مستقل قابل قابل استقرار باشند در بین سال های ۱۹۹۰ تا ۲۰۰۰ برای حس شد.ابتدا این مشکل توسط معماری سرویس محور در همان سال ها برطرف شد. به این صورت که ماژول های مختلف که وابستگی کمی از هم داشتند به صورت مستقل از هم استقرار میافتند.در آن سال ها استاندارد ارتباط سرویس ها با هم از طریق پروتکل پیامرسانی SOAP انجام میشد. ولی بین سال های ۲۰۰۸ تا ۲۰۱۰ استاندارد REST معرفی شد که از طریق پروتکل HTTP پیام رسانی را انجام میداد و این موضوع باعث راحتی ارتباط بین سرویس های مختلف شد.تولد معماری میکروسرویس بین سال های ۲۰۱۱ تا ۲۰۱۲ اتفاق افتاد زمانی که گروهی متشکل از James Lewis و Martin Fowler یک معماری را طراحی کردند که در آن سرویس های تا حد زیادی کوچک توسط یک سیستم پیام رسانی سبک مانند api های در بستر HTTP با هم ارتباط داشتند.معماری میکروسرویس چیست؟معماری ماکروسرویس به معنی تقسیم نرم افزار به واحد های کوچک که به صورت مستقل قابل طراحی ، پیاده سازی و استقرار است. به این واحد های کوچک سرویس میگوییم. این سرویس ها لازم است که به صورت کامل کپسوله شده باشند به این شکل که نحوه پیاده سازی آن از بیرون از سرویس مشخص نبوده و تنها نحوه ارتباط با آن سرویس مشخص باشد.این ارتباط معمولا از طریق API ها یا message broker ها انجام میشود که در فصل پنجم بیشتر به این موضوع پرداخته میشود.یکپارچگی و دوگانگی در میکروسرویس هادر طراحی این معماری لازم است دو نکته مهم مدنظر قرار بگیرد:۱) یکپارچگی: اجزای یک سرویس (ماژول ها، کلاس ها و …) لازم است که کاملا یکپارچه باشند. به عنوان مثال اگر سرویسی شامل دو ماژول است که با هم هیچ ارتباطی ندارند این دو ماژول میتوانند به دو سرویس مجزا تقسیم شوند.۲) دوگانگی: در صورتی که دو سرویس به هم وابسته باشند اگر یکی از این سرویس ها تغییر کرد سرویس دیگر هم لازم است که تغییر کند. پس ارتباط بین سرویس ها باید تا حد ممکن کم باشد و تنها در موارد ضروری این ارتباط ایجاد شود.به صورت کلی باید تا جای ممکن میزان یکپارچگی در میکروسرویس ها بالا و دوگانگی کم باشد. در این صورت سرویس ها قابلیت نگهداری ، توسعه و تست بالا دارند و پرفرمنس آن ها هم تا حد زیادی مطلوب میشود.یک مثال عملی - معماری نرم افزار spotifyاسپاتیفای یک نرم افزار استریم موسیقی میباشد. میلیون ها کاربر به طور همزمان از این نرم افزار برای شنیدن موسیقی استفاده میکنند. پس لازم است که زیرساخت لازم برای مدیریت حجم بالای درخواست ها را داشته باشد.برای مدیریت بیشتر این نرم افزار از معماری میکروسرویس استفاده میکند که در اینجا به نحوه پیاده سازی این معماری در نرم افزار اسپاتیفای میپردازیم.تعدادی از نیازمندی های این نرم افزاراین نرم افزار باید قابلیت سرویس دهی به میلیون ها کاربر را داشته باشد.این نرم افزار باید در پلتفرم های متفاوت مثل گوشی های موبایل ، سیستم عامل های مختلف و … قابل استفاده باشد.این نرم افزار باید قوانین پیچیده کسب و کاری را پیاده سازی کند.این نرم افزار باید بتواند قابلیت های جدید را به سرعت اضافه کند.یک نکته مهم در مورد این نرم افزار این است که بر خلاف بیشتر نرم افزار ها که کاربران ساعات کمی را در آن صرف میکندد در این نرم افزار ممکن ساعت های زیادی گاها تا ۸ ساعت در روز را صرف کنند. در این صورت تنها مشکل تعداد بالای کاربران نیستند بلکه ساعت بالای استفاده هم یکی از مشکلات و نیازمندی های این نرم افزار است.راه حلبرای برطرف کردن این نیازمندی ها این نرم افزار اجزای مختلف را به قسمت های کوچک تر تقسیم کرده و این تقسیم حتی در سطح تیم ها نیز اعمال شده به این شکل که هر تیم مسئول بخش کوچکی از نیازمندی ها میباشد. هر تیم شامل توسعه دهنده های فرانت اند و بک اند ، نیروی تست و … میباشد. این مدل از تقسیم بندی باعث میشود که هر تیم کاملا مستقل بوده ، آزادانه کار کند و به تیم های دیگر وابسته نباشد.در صورت نیاز به افزودن قابلیت جدید هم دقیقا مشخص است که کدام تیم باید این قابلیت را اضافه کند. در نتیجه اسپاتیفای تقسیم سرویس ها را از سطح تیم ها شروع کرده است.خدماتی که پلتفرم اسپاتیفای ارائه میدهد به هفت دسته بندی تقسیم میشوند از جمله‌:یافتن موسیقی و پیشنهاد موسیقی به کاربرانمدیریت لیست پخشویژگی هایی مانند شبکه های اجتماعی (اشتراک گذاری لیست پخش)احراز هویت و امنیت کاربرانمدیریت داده هامدیریت زیر ساخت هابرای پیاده سازی این زیرساخت ها اسپاتیفای از تعداد زیادی سرویس های کوچک استفاده میکند. در نوامبر ۲۰۲۳ اسپاتیفای دارای ۱۶۰۰ سرویس مختلف بوده است. همچنین به طور متوسط هر ماه حدودا ۱۰۰ سرویس جدید به این تعداد افزوده میشود.نقاط قوت معماری میکروسرویساین معماری روند توسعه نرم افزار را سریع تر و آسان تر میکند. از آنجایی که هر سرویس به صورت مجزا توسعه داده میشود پس تیم هایی که وظیفه توسعه این سرویس ها را دارند تنها کافی است نگران کارکرد درست سرویس مورد نظر باشند و نیاز نیست که کارکرد صحیح کل سیستم را برسی کنند.از آنجایی که این در این معماری هر سرویس به صورت مجزا دیپلوی و نگهداری میشود. پس availability بالایی را میتوان از این معماری انتظار داشت. زیرا در صورت از کار افتادن یک سرویس ، بقیه سرویس ها بدون مشکل کار میکنند، همچنین فرآیند شناسایی خطا ، مانیتورینگ و برطرف کردن مشکل در این معماری راحت تر است.هر سرویس در این معماری میتواند به صورت مجزا استقرار پیدا کرده و اجرا شود. در این صورت با افزایش تعداد کاربران به راحتی میتوان سرویس هایی که مشکل پرفرمنس دارند را شناسایی و مشکلشان را برطرف کرد.نقاط ضعف معماری میکروسرویساولین مشکل این معماری مشکل پرفرمنس است. از آنجایی که در این معماری سرویس ها با یک واسط مانند REST api یا صف ها با هم در ارتباط هستند، این ارتباط بار بیشتری در حالتی که ماژول ها به صورت programmatically هم دیگر را صدا میزنند روی سیستم میگذارد می گذارد.مشکل بعدی مشکل وابستگی سرویس ها به یکدیگر است. در تعریف میکروسرویس ذکر شد که سرویس ها باید تا جای ممکن از هم مستقل باشند، ولی این استقلال در عمل تا حد زیادی امری محال است. سرویس های مختلف برای انجام عملیات خود به دیتاها و عملیات هایی از سرویس های دیگر وابسته هستند و اگر این ارتباط از حدی بیشتر شود مشکل پروفرمنیس رخ میدهد. همچنین در صورت از کار افتادن سرویسی که سرویس های دیگر به آن وابسته هستند، سرویس های وابسته نیز از کار می افتند.نرم افزار پیاده سازی شده با معماری میکروسرویس به منابع سخت افزاری بیشتری نسبت به معماری های دیگر نیاز دارد زیرا هر سرویس به صورت مجزا اجرا شده و نبازمندی های خود را دارند. همچنین ارتباط این سرویس ها با هم بار مضاعف روی سخت افزار میگذارد.در طراحی ماکروسرویس ها، طراحان معمولا تاخیر و قطعی شبکه را صفر در نظر میگیرند. در حالی که در یک شبکه کامپیوتری هرچقدر که شبکه پایدار و مطمئن باشد باز هم امکان قطعی یا کاهش پهنای باند وجود دارد. در این صورت سرویس ها نمیتوانند به درستی با هم ارتباط داشته باشند و سیستم دچار اختلال میشود.انواع مختلف الگو های طراحی بر پایه معماری میکروسرویسدر این بخش به بررسی تعدادی از الگو های طراحی ماکروسرویس ها پرداخته میشود و برسی میکنیم که این الگو ها کدام مشکل در این معماری را برطرف میکند.Back-end for front-endدر معماری میکروسرویس client (نرم افزار فرانت اند یا اپ موبایل و …) نیاز دارد تا با تعداد زیادی از سرویس ها در ارتباط باشد. این ارتباط باعث پیچیدگی و سختی کار این client ها میشود از این رو برای حل این مشکل یک سرویس واسط پیاده سازی میشود که به آن back-end for front-end یا BFF میگویند. این سرویس از طرفی با دیگر سرویس ها در ارتباط است و از طرف دیگر برخی از دیتاهای مورد نیاز client که احتیاج به عملیات خاصی ندارند و فقط یک عملیات CRUD ساده روی دیتابیس است را انجام میدهد. و عملیات های پیچیده تر را به سرویس های دیگر میسپارد.Circuit Breakerدر پیاده سازی نرم افزار با معماری میکروسرویس بسیار ممکن است که یک سرویس به دلیل مشکلات داخلی یا خارجی از سرویس دهی و پاسخگویی به درخواست ها باز بماند. در این صورت هر درخواست جدید که به این سرویس برسد یک بار اضافی روی منایع ایجاد کرده در حالی که بدیهی است جوابی دریافت نمیکند. در این روش وقتی تعداد درخواست های با خطا مواجه شده در یک سرویس زیاد میشود این سرویس از مدار خارج شده و هیچ درخواستی تا یک مدت مشخص به آن ارسال نمیشود. بعد از طی زمان یک درخواست تستی به سرویس ارسال شده اگر سرویس پاسخ درست را برگرداند سرویس مجددا به مدار بازمیگردد در غیر این صورت زمان تمدید شده و مجدد درخواستی به سرور ارسال نمیشود.Database per serviceهر سرویس نیاز دارد بخشی از داده های مورد نیاز خود را از دیتابیس بخواند و بنویسد. از آنجایی که سرویس ها باید کاملا از هم مستقل باشند این الگو پیشنهاد میکند که هر سرویس دیتابیس خصوصی مخصوص خود را داشته و دسترسی به این دیتابیس ها تنها از طریق API هایی که سرویس فرآهم میکند باشد. در واقع دیتابیس نیز مانند پیاده سازی سرویس باید از بیرون از سرویس غیر قابل دسترسی باشد. این الگو مشابه اصل encapsolation در طراحی شی گرا است ولی در سطح سرویس ها.Command Query Responsibility Segregationدر اصل قبلی بیان شد که دیتا های هر سرویس باید داخل سرویس به صورت خصوصی باشند و از خارج سرویس دسترسی به آنها ممکن نباشد. در این صورت امکان اجرای کوئری هایی که چند جدول از دیتابیس که جداول در سرویس های مختلف هستند وجود ندارد، این الگو مشکل فوق را حل میکند. برای حل این مشکل یک دیتابیس read only ایجاد شده و دیتاهای مورد نیاز درون آن قرار میگیرند. با هر تغییری که در دیتابیس سرویس ها انجام میشود این دیتابیس نیز تغییر میکند و برای اجرای کوئری های چند جدولی روی این دیتابیس کوئری اجرا میشود.میکروسرویس یا monolithic ؟یکی از مهم ترین تصمیماتی که یک معمار در ابتدا یا اواسط توسعه یک نرم افزار باید بگیرد انتخاب میان معماری بر پایه سرویس یا معماری monolithic است. رویه کلی این انتخاب به این شکل است که نرم افزار هایی که تیم توسعه کوچک، معماری ساده یا بودجه کمی برای توسعه دارند معماری monolithic را انتخاب کرده و نرم افزار های پیچیده تر معماری بر پایه سرویس را انتخاب میکنند. البته این موضوع مطلق نبوده و موضوعی نسبی است. در این فصل به برسی رویه کامل تری از این انتخاب و trade-off بین این دو معماری، همچنین روش های مهاجرت از معماری monolithic به معماری میکروسرویس پرداخته میشود.در ابتدا یک تعریف از معماری monolithic ارائه میشود و انواع آن برسی میشود.معماری monolithicبهترین تعریف که برای معماری monolthic میتوان بیان کرد نرم افزاری است که تمام اجزای آن باید در کنار هم deploy شوند. البته این تعریف شامل طیف بزرگی از نرم افزار ها میشود اما به طور کلی نرم افزار های پیاده سازی شده با این معماری را میتوان به سه دسته کلی تقسیم کرد:The Single-Process Monolith :‌ در این نوع از معماری تمام پیاده سازی نرم افزار در یک مجموعه انجام میشود. البته دیتابیس از این مجموعه خارج است. بیشتر معماری های لایه ای مانند معماری MVC از این دست هستند.The Modular Monolith : در این نوع از معماری هر بخش از نرم افزار که اجزای آن عملکرد مشابه هم دارند در یک ماژول قرار گرفته و ماژول ها می توانند از هم مستقل باشند ولی باز هم تمام ماژول ها همزمان و در کنار هم deploy میشوند.The Distributed Monolith‌: این نوع از معماری مشابه معماری میکروسرویس است ولی تمام سرویس ها باید در کنار هم و روی یک سرویس دیپلوی شوند. به طور کلی استفاده از این معماری اکیدا توصیه نمیشود زیرا هم معایب معماری monolthic و هم معایب معماری میکروسرویس را در کنار هم دارد.انتخاب بین این دو معماریبا برسی نقاط قوت و ضعف این دو معماری میتوان نتیجه گرفت که تحت چه شرایطی از کدام یک از این معماری ها استفاده کرد. به طور کلی از آنجایی که در معماری Monolith روند توسعه ، تست و دیپلویمنت راحت تر است در پروژه هایی که تیم توسعه کوچک یا کم تجربه دارند انتخاب این معماری مناسب تر است. زیرا در معماری میکروسرویس لازم است که تیم ها به ازای هر سرویس از هم مستقل باشند.فارغ از بحث ساختار تیم ها تفاوت این دو معماری را میتوان از منظر قابلیت های هرکدام همچنین ویژگی های کیفی و موارد دیگر نیز برسی کرد.در بحث performance هیچ یک از این دو معماری برتری نسبت به یکدیگر ندارند. البته پیاده سازی نرم افزار با معماری Monolith به دلیل این که ارتباط بین ماژول ها با سرعت بالا و زمان کم انجام میشود مزیت نسبی برای ویژگی پرفرمنس ایجاد میکند ولی این مزیت مطلق نیست. در معماری میکروسرویس میتوان با استفاده از تکنیک هایی مانند صف ها ، load balancer ها ، caching و … به پرفرمنس بالاتری دست پیدا کرد البته امکان استفاده از برخی از این ابزار ها در معماری Monolith نیز وجود دارد ولی معماری ماکروسرویس استفاده از این ابزار ها را راحت تر و کارامد تر میکند. همچنین در صورتی که کاربران نرم افزار به طور گسترده ای رشد کنند امکان توسعه مقیاس نرم افزار در معماری میکروسرویس بیشتر است پس scalability معماری میکروسرویس بالاتر میباشد.موضوع بعدی بحث maintenance میباشد در این ویژگی کیفی معماری میکروسرویس مزیت مطلق نسبت به معماری Monolith دارد. زیرا هر سرویس به طور جداگانه توسعه داده شده و نگهداری و عیب یابی در یک سرویس کوچک بسیار ، بسیار راحت تر از یک نرم افزار Monolith نسبتا بزرگ میباشد.معیار بعدی راحتی توسعه نرم افزار میباشد در این معیار چون معماری Monolith ساختار ساده تری دارد فرآیند توسعه آن راحت تر بوده پس در این معیار معماری Monolith مزیت دارد.در موضوع Availability معماری میکروسرویس وضعیت بهتری دارد زیرا سرویس های آن به صورت مجزا deploy شده و این مزیت را ایجاد میکند که deploy های سبک تر با تغییرات کمتر انجام شود همچنین در صورت کار نکردن یک سرویس در محیط پروداکشن تمام نرم افزار از کار نیوفتاده و بقیه سرویس ها به فعالیت خود ادامه میدهند البته این موضوع باعث برتری ویژگی Reliability در معماری میکروسرویس نیز میشود.میتوان نتیجه گرفت که در نرم افزار هایی که توسعه سریع و راحت مورد نظر است و ویژگی های Availability, Reliability ، scalability مورد نظر نمیباشد استفاده از معماری Monolith مزیت بیشتری دارد و در نرم افزار هایی که این موارد اهمیت دارند معماری میکروسرویس انتخاب بهتری میباشد.مهاجرت از معماری Monolith به معماری میکروسرویسممکن است یک نرم افزار در مراحل ابتدایی توسعه خود به دلیل نیاز به توسعه سریع با معماری Monolith پیاده سازی شده باشد ولی در طول زمان با بزرگتر و پیچیده تر شدن نرم افزار نیاز باشد که هر ماژول آن توسط یک سرویس جدا پیاده سازی شده و توسط تیم مستقلی نگه داری شود پس نیاز است راهکار هایی معرفی شود که این فرآیند معاجرت را ساختارمند تر و ساده تر کند. به طور کلی برای مهاجرت از معماری monolith به ماکروسرویس نیاز نیست که تمام نرم افزار از اول تولید شود بلکه با روش هایی میتوان نرم افزار موجود را به سرویس های مختلف تقسیم کرد. عملیات این مهاجرت عملیاتی زمان بر میباشد که ممکن است ماه ها یا سال ها به طول انجامد. در طول این مهاجرت به احتمال زیاد نیاز است که قابلیت های جدیدی که از سمت کسب و کار یا تیم محصول یا کاربران تعیین میشوند به نرم افزار قبلی اضافه شود و فرآیند مهاجرت نیز به صورت موازی پیش رود. برای این منظور لازم است که در یک خط زمانی به صورت تدریجی سرویس ها از نرم افزار اصلی جدا شده و به صورت یک سرویس مستقل درآیند و نرم افزار monolith نیز در طول زمان کوچک تر و کوچک تر شده تا جایی که نرم افزار به مجموعه ای از سرویس ها تبدیل شود.برای این پیاده سازی این استراتژی از سه راه حل میتوان استفاده کرد.هر قابلیت جدید را به شکل یک سرویس جدید اضافه کرده یا به سرویس موجود اضافه میکنیم. این راه حل از این جهت دارای اهمیت است که جلوی بزرگتر شدن نرم افزار monolith را میگیرد و قسمت monolith این نرم افزار از وضعیت موجود بزرگتر نمیشود. یک روش خوب برای مدیریت درخواست ها به نرم افزار استفاده از API gateway میباشد به این شکل که درخواست هایی که مربوط به نرم افزار قدیمی میباشد به سمت آن نرم افزار مسیر یابی شود و درخواست هایی که مربوط به سرویس های جدید هستن به سمت سرویس های جدید.جدا سازی ظاهر نرم افزار از کسب و کار. در این راه حل لایه کسب و کار به طور کلی از لایه ظاهری نرم افزار جدا شده و این دو از طریق API ها یا روش های مشابه با هم ارتباط برقرار میکنند. البته بیشتر نرم افزار های monolith امروزی به دو بخش front-end و back-end تقسیم میشوند که این دو معمولا دو نرم افزار مجزا میباشند. در این صورت نیازی به این راه حل برای مهاجرت از معماری monolith به ماکروسرویس نداریم.یکی دیگر از راه حل ها جداسازی و تقسیم قسمت های مختلف معماری monolith موجود به سرویس های جدید میباشد. یک روش خوب برای این کار این است که domain های مختلف کسب و کار شناسایی شده و به ازای هر domain یک سرویس جدید ایجاد شود. با این کار به مرور قسمت monolith نرم افزار کوچک تر شده تا زمانی که تمام قسمت ها به سرویس تبدیل شوند.با انجام این سه روش میتوان یک مهاجرت خوب و پایدار از معماری monolith به ماکروسرویس داشت.نحوه کوچک تر شدن monolith و افزودن به سرویس ها در طول زمانبرسی تکنیک های بهبود ویژگی های کیفی در معماری میکروسرویسبه طور کلی پیاده سازی نرم افزار با معماری ماکروسرویس باعث بهبود برخی از ویژگی های کیفی و افت عملکرد برخی دیگر از ویژگی های کیفی میشود. در این فصل تکنیک هایی معرفی میشود که تا جای ممکن از افت ویژگی های کیفی در معماری میکروسرویس جلوگیری شود یا حداقل وضعیت کمی بهتر شود همچنین برخی از این ویژگی ها که به شکل ذاتی توسط معماری میکروسرویس وضعیت آن بهتر میشود ، وضعیت بهتر آن حفظ شده یا بهبود های جزئی داشته باشند.کاراییدر بحث کارایی همانطور که پیشتر اشاره شد معماری ماکروسرویس ضعیف تر از معماری های monolith عمل میکند. این به این دلیل است که اجزای این معماری از روش پیچیده تری برای ارتباط با هم استفاده میکنند. تکنیک بهبود پرفرمنس در این معماری حول محور روش هایی برای بهبود این ارتباط ها میباشد زیرا عدم کارایی در هر سرویس ارتباطی با معماری ماکروسرویس نداشته و باید تکنیک هایی برای بهبود آن سرویس محقق شود. به طور کلی دو دسته ارتباط در معماری ماکروسرویس وجود دارد، ارتباط همزمان و غیرهمزمان. در صورت استفاده از روش ارتباط هم زمان مشکل اصلی این است که در صورتی که یک سرویس به سرویس دیگر وابسته باشد سرویس وابسته بعد از درخواست باید منتظر جواب سرویس دیگر بماند و همین موضوع موجب کاهش پرفرمنس میشود. به عنوان مثال یک نرم افزار بانکی را در نظر بگیرید فرض کنید که در این نرم افزار دو سرویس وجود دارد که یک سرویس مربوط به انتقال وجه و سرویس دیگر لاگ های این انتقال را در یک دیتابیس سیو میکند. شیوه کار این سرویس ها به این شکل میباشد که ابتدا انتقال وجه انجام شده و سپس سرویس مربوط به ذخیره لاگ توسط سرویس انتقال وجه صدا زده میشود. در صورتی که این ارتباط از روش هم زمان استفاده کند سرویس انتقال وجه باید منتظر بازگشت درخواست سیو لاگ بماند و در صورتی که سرویس لاگ یا دیتابیسی که لاگ در آن ذخیره میشود زیر بار باشد و نتواند به سرعت نتیجه ذخیره لاگ را به سرویس انتقال بازگرداند، کارایی سرویس انتقال وجه نیز افت میکند. ولی با استفاده از روش غیر هم زمان پس از فراخوانی سرویس لاگ عملیات میتواند ادامه پیدا کند و نتیجه انتقال به کاربر نمایش داده شده و لاگ بعدا ذخیره شود.روش های ارتباط سرویس ها در معماری ماکروسرویس به صورت مفصل در بخش آینده برسی میشود.امنیتبحث امنیت در معماری ماکروسرویس بسیار پیچیده تر از معماری monolith میباشد. از این جهت که اولا باید به امنیت تمام سرویس ها به صورت مجزا توجه شده و در معماری کلی هم لحاظ شود. یکی از بخش هایی که ممکن است بسیار مورد توجه حمله کننده ها قرار بگیرد بخش هایی از سرویس است که پروتکل ارتباط با سرویس های دیگر را فرآهم میکند. از این جهت که این ارتباط فقط باید از طریق سرویس دیگر برقرار شود ولی شخص حمله کننده ممکن است خود را جای آن سرویس جا زده و اطلاعات را سرقت کند یا اختلالی در عملکرد سرویس های دیگر ایجاد کند. همچنین امنیت هر سرویس به صورت مستقل توسط تیم توسعه آن سرویس باید فرآهم شود. یکی از راه هایی که به بهبود این ویژگی کیفی در معماری ماکروسرویس کمک میکند این است که اهمیت به امنیت در تمام لایه های توسعه (طراحی ، توسعه و تست) مورد توجه قرار گیرد. همچنین یکی دیگر از تکنیک ها اضافه کردن احراز هویت چند مرحله ای و یک سرویس برای مدیریت دسترسی ها و احراز هویت میباشد.از دیگر تکنیک های مهم استفاده از API gateway برای ارتباط با سرویس ها است به گونه ای که تمام ترافیک مربوط به فراخوانی API ها از این درگاه گذشته و با فرآهم کردن امنیت این درگاه میتوان تا حد زیادی ارتباط امن تری را تجربه کرد.تستدر معماری ماکروسرویس هر سرویس میتواند به صورت جداگانه دارای unit test برای تست کلاس ها ، متد ها و غیره و integration test برای تست ارتباط میان ماژول های درون سرویس باشد. در این حالت دو مشکل اصلی وجود دارد مشکل اول این است که ممکن است یک ماژول از یک سرویس برای کار کردن نیاز به ماژولی از سرویس دیگر داشته باشد در این صورت لازم است که یک دیتای تستی برای نمونه ای از خروجی سرویس دوم برای تست سرویس اول فرآهم شود. مشکل بعدی این است که در این حالت covarage تست بالایی در هر سرویس وجود دارد ولی covarage تست برای ارتباط بین سرویس ها صفر میباشد. برای حل این مشکل میتوان سناریو های ارتباط سرویس ها با یکدیگر را استخراج کرد سپس برای تستی را توسعه داد که این سناریو را اجرا میکند. به عنوان مثال در یک تراکنش بانکی که چندین سرویس در ارتباط هستند میتوان با داده های تستی یک تراکنش تستی ایجاد کرد به طوری که تمام سرویس های مرتبط به طور کامل پوشش داده شوند.برسی نحوه ارتباط سرویس ها با هم و ابزار های مرتبطدر معماری ماکروسرویس سرویس ها باید برای دریافت داده ها یا پیام ها با هم در ارتباط باشند. هرچند معماری بهتر به شکلی است که سرویس ها حداقل ارتباط را با هم داشته باشند ولی در برخی موارد این ارتباط اجتناب ناپذیر میباشد. به این ارتباط ، ارتباط سرویس با سرویس یا service-to-service communication یا S2S میگویند.به طور کلی در نوع ارتباط در معماری ماکروسرویس وجود دارد. ارتباط همزمان و غیرهمزمان. ارتباط همزمان معمولا توسط پروتکل HTTP انجام شده و نتیجه مورد نظر در طول مدتی که ارتباط TCP برقرار است بازمیگردد. ولی در ارتباط غیر همزمان درخواست ها در یک صف قرار گرفته و به نوبت پردازش میشودند در این صورت هیچ درخواستی نادیده گرفته نشده و به همه درخواست ها پاسخ داده میشود.به طور کلی در بیشتر کیس ها از ارتباط غیر همزمان استفاده میشود به جز موارد زیر.از آنجا که در ارتباط همزمان امکان چک کردن موارد امنیتی و اعتبار سنجی در این پروتکل در لحظه انجام شده پس این روش برای شرایطی که به امنیت بالا احتیاج است مناسب تر است.زمانی که به جواب یک درخواست در همان لحظه نیاز داریم.به طور کلی کار با پروتکل HTTP ساده تر از ارتباط غیر همزمان میباشد پس این روش برای تیم هایی با تجربه کمتر مناسب است.message queueابزار هایی هستند که یک محیط صف را برای ارتباط غیر همزمان سرویس ها فرآهم می کنند. به طور کلی به دو دسته تقسیم میشوند.Point-to-point یا P2Pدر این روش ارسال کننده پیام خود را دقیقا برای یک گیرنده مشخص ارسال میکند. این روش برای زمانی مناسب است که احتیاج به توان عملیاتی بالا و تاخیر کم میباشد ولی مشکل این روش این است که نمیتوان پیام را هم زمان به چند سرویس متفاوت ارسال کرد.Publish-Subscribe یا Pub/Subاین روش به ارسال کننده پیام اجازه میدهد پیام را هم زمان به چند سرویس متفاوت ارسال کند. به عنوان مثال هنگام ثبت نام کاربر در یک نرم افزار بر پایه ماکروسرویس ممکن است نیاز باشد که همزمان اطلاعات کاربر به یک سرویس مربوط به ذخیره اطلاعات کاربر در دیتابیس و یک سرویس مربوط به ذخیره لاگ ها ارسال شود. در این روش میتوان به صورت هم زمان این عملیات را انجام داد.مقایسه دو ابزار message brokerدر ابزار اصلی که به عنوان message broker استفاده میشوند kafka و rabbitmq میباشد. در جدول زیر این دو ابزار برسی شده اند.رنگ قرمز به معنی عملکرد ضعیف و رنگ سبز به معنی عملکرد بهتر میباشد. این بنچمارد پس از کار با دو ابزار و همچنین برسی داکیومنت آنها تهییه شده است.برسی ابزار های مدیریت سرویس های معماری میکروسرویسدر معماری ماکروسرویس مدیریت سرویس ها از اهمیت بالایی برخوردار میباشد. به عنوان مثال در یک نرم افزار با ۲۰ سرویس متفاوت نیاز است که هر سرویس به صورت مستقل دیپلوی شود، لاگ های سیستم به ازای هر سرویس جمع آوری و تحلیل شود و همچنین منشا مشکلات سیستم مشخص شود. به این منظور از ابزار های متفاوتی میتوان استفاده کرد.ابزار های ساخت کانتینرکانتینر ها ساختاری هستند که تمام موارد مورد نیاز برای اجرای یک سرویس (زیر ساخت سیستم عاملی ، محیط زبان برنامه نویسی و غیره) را برای اجرا در هر محیطی دارا میباشد. در معماری میکروسرویس برای راحتی مدیریت سرویس ها نیاز است که هر سرویس در یک کانتینر مجزا اجرا شود. همچنین دیگر نیازمندی های این معماری مانند دیتابیس ها ، صف ها و غیره نیز هر یک در یک کانتینر اجرا میشود.Dockerیکی از مورد استفاده ترین ابزار ها برای ساخت کانتینر ابزار متن باز docker میباشد. شیوه کار این نرم افزار به این صورت است که داخل یک یا چند کانتینر فرآیند کامپایل شدن و اجرا شدن کد را به صورت خودکار انجام میدهد. خوبی استفاده از داکر در معماری ماکروسرویس این است که در صورتی که هر سرویس از تکلونوژی ها و زبان های برنامه نویسی متفاوتی استفاده کند داکر میتواند تمام این سرویس ها را بدون نیاز به پیاده سازی فرآیند نصب سرویس ها و به صورت خودکار انجام داده و در زمان و هزینه صرفه جویی کند.فرآیند CI/CDداکر میتواند فرآیند اجرای سرویس ها را برای توسعه دهندگان خودکار کند. ولی در روند deployment نیاز است که یک سری از عملیات های دیگر نیز خودکار شود این عملیات ها شامل استقرار سرویس روی سرور پرداکشن ، اجرای تست های اتوماتیک ، اجرای تغییرات روی دیتابیس ها و موارد دیگر میباشد. این کار توسط ابزار هایی با طراحی پایپ لاین انجام میشود. این پایپ لاین ها شامل چندین مرحله یا stage میباشند که هر stage وظیفه خواست خود را دارد. به عنوان مثال در یک پایپ لاین در مرحله اول کد با آخرین نسخه آپدیت شده ، در مرحله بعدی تست های اتماتیک اجرا شده و در مرحله آخر کانتینر آپدیت شده سرویس به جای کانتینر قبلی روی سرور قرار میگیرد و نسخه جدید آن سرویس را ارائه میکند.ابزار های CI/CDبرای فرآیند ci/cd ابزار های متنوعی استفاده میشود در اینجا دو ابزار را برسی میکنیمGitlab-ciاین ابزار متن باز مربوط به شرکت gitlab میباشد و ارتباط خوبی با ریپازیتوری هایی که بر بستر gitlab میباشند برقرار میکند. برای اجرای این نرم افزار کافی است worker مربوط به آن را روی یک سرور اجرا کرده و ارتباط آن را با سروری که gitlab روی آن قرار دارد برقرار کنیم. سپس میتوانیم به کمک یک فایل تنظیمات مربوط به مراحل آن را پیاده سازی کرده و اجرا نماییم.Jenkinsیک ابزار متن باز برای انجام فرآیند ci/cd مباشد که دارای پلاگین های زیادی است و ارتباط خوبی با تمام ابزار های کنترل ورژن دارد.مقایسه این دو ابزارمدیریت لاگ ها در معماری ماکروسرویسمدیریت لاگ ها در معماری ماکروسرویس از اهمیت بالایی برخوردار میباشد. از این جهت که در صورت بروز مشکلی در سیستم باید به سرعت تشخیص داده شود که مشکل حاصل از کدام سرویس میباشد تا آن سرویس به سرعت دیباگ شده و مشکلاتش برسی شود به همین جهت نیاز به یک سرویس مجزا برای مدیریت لاگ میباشد. یکی از ابزار های کاربردی برای این کار نرم افزار elastic میباشد. این سرویس از سه نرم افزار مجزا تشکیل شده که هر سه نرم افزار کاملا با هم هماهنگ میباشند. این سه شامل elastic ، kibana و log stash میباشد که به طور مختصر به آن ELK میگویند.Logstash:این ابزار لاگ های ورودی را مرتب کرده و به یک فرمت استاندارد تبدیل میکند.Elastic:این ابزار لاگ ها را در یک دیتابیس ذخیره میکند.Kibana:این ابزار لاگ ها را نمایش داده و توسط نمودار هایی تحلیل آن را راحت تر میکند.منابعمقالات وبThe History of Microservices: From Thought Experiment to Industry Standard, Muaath Bin Ali, 2023https://microservices.ioThe Basics of Service-to-Service Communication: A Beginner’s GuideMessage Queues: A Key Concept in Microservices Architecturehttps://www.styra.com/blog/microservices-security-fundamentals-and-best-practices/https://martinfowler.com/articles/microservice-testing/#conclusion-test-pyramidhttps://kafka.apache.org/documentation/https://rabbitmq.com/https://www.docker.com/https://docs.gitlab.com/ee/ci/https://www.jenkins.io/https://www.elastic.co/elastic-stackمقالات آکادمیکThe Comparison of Microservice and Monolithic Architecture, Wojciech Zabierowski , 2022کتاب هاEdition Building Microservices Designing Fine-Grained Systems second edition, o’reillyMicroservices Patterns: With examples in Java First Edition, Chris Richardsonکنفرانس هاMicroservices at Spotify Kevin Goldsmith GOTOاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.sina mohammadisina mohammadiFri, 02 Feb 2024 02:07:56 +0330https://virgool.ir/@m_75137245/برسی-چند-موضوع-کلی-در-معماری-نرم-افزار-egafdvfegchyهدف از این مطلب معرفی چند مفهوم مرتبط با معماری نرم افزار میباشد.Modular Monolithic:این سبک از معماری به ما کمک میکند که هر منطق از نرم افزار را در module جداگانه پیاده سازی کنیم. در نتیجه میتوانیم تا حد زیادی نگرانی ها در توسعه نرم افزار را از هم جدا کرده و برای هم module به صورت جداگانه منطقی که مورد نظر میباشد را پباده سازی کنیم. در این معماری بهتر است هر module تا حد امکان مستقل بوده و module ها کمترین ارتباط را با هم داشته باشند. در این معماری دیپلوی شدن کل نرم افزار به صورت یکجا انجام میشود پس با هم تغییر باید کل نرم افزار مجدد دیپلوی شود.AWS:مخفف amazon web service میباشد. یک ابزار متعلق به شرکت amazon برای مدیریت خودکار دیپلوی نرم افزار همچنین محاسبات ابری و فرآیند های ci/cd میباشد. این ابزار به کسب و کار های مختلف این امکان را میدهد که بخشی از کار های مرتبط با استقرار نرم افزار را خودکار کرده و تمرکز خود را روی توسعه کسب و کار خود بگذارند. همچنین در بحث قیمت گذاری به کاربران اجازه میدهد که به اندازه نیازشان منابع سخت افزاری تهییه کنند و هزینه بالایی برای این منابع پرداخت نکنند. همچنین به دلیل استفاده از سرور های قدرتمند شرکت آمازون down time نزدیک به صفر را تجربه کنند.API-first Approach:این روش بیان میکند که توسعه api ها که نیاز کسب و کار را فراهم میکنند باید در اولویت اول قرار گیرد. در روش معمول نرم افزار توسعه داده شده و بر اساس نیاز نرم افزار (معمولا نیاز بخش front-end) یک دسته از api ها توسعه داده میشوند که تنها رابطی بین دیتابیس و بخش ظاهری نرم افزار میباشند. ولی این روش بیان میکند که api ها مهم ترین بخش نرم افزار هستند و توسعه آن ها باید مستقلا صورت بگیرد.NoSQL Databases:مخفف Not Only Sql میباشد این نوع از پایگاه های داده داده های را به شکلی به جز جداولی که با هم رابطه دارند (پایگاه های داده sql) نگه داری میکنند. این دیتابیس ها انواع مختلفی دارند و طیف بزرگی را شامل میشوند مانند دیتابیس های Document-oriented ، دیتابیس های مبتنی بر گراف ، دیتابیس هایی با ساختار key-value و … . در این دیتابیس ها نمیتوان از مزایای دیتابیس های sql تا حد زیادی استفاده کرد ولی هر کدام از انواع آن مزایایی دارند و برای مصارف خاص خود مناسب هستند.Serverless Architecture:این نوع معماری روشی را معرفی میکند که فرآیند تولید نرم افزار بدون نیاز به انجام کار های زیرساختی سمت سرور انجام شود. معمولا از ابزار هایی مانند AWS , google cloude و … برای اتماتیک کردن فرآیند های دیپلویمنت استفاده میشود. مزیت این روش این است که میتوان زمان بیشتری روی توسعه خود نرم افزار و قابلیت های مورد نیاز آن صرف کرد و نیاز نیست بخشی از زمان به فرآهم کردن زیرساخت مناسب برای استقرار نرم افزار صرف شود. البته عیب اصلی این نوع معماری این است که امکان شخصی سازی کامل مسائل مربوط به زیرساخت در آن وجود ندارد.Domain Driven Design:در این روش معماری ماژول ها و اجزای نرم افزار دقیقا مشابه اجزای کسب و کاری که نرم افزار آن را مدل میکند پیاده سازی میکند. هر ماژول یک domain نامیده میشود که معرف یکی از اجزای کسب و کار است. به عنوان مثال در یک نرم افزار بانکی تمام موارد مربوط به وام دهی در یک ماژول جدا پیاده سازی میشود.Hexagonal architecture:هدف از این روش معماری این است که اجزای نرم افزار تا حد ممکن کمترین وابستگی و ارتباط را با هم داشته باشند. در این روش تمام اجزایی که کار مشابه میکنند یا به هم وابستگی دارند در کنار هم پیاده سازی میشوند. هر کدام از این اجزا مانند یک ضلع چند ضلعی پیاده سازی میشوند. اضلاع این چند ضلعی با هم در ارتباط نبوده و تمام این اضلاع در کنار هم نیاز کسب و کاری مورد نیاز را رفع میکنند.Event Sourcing:زمانی که نیاز داریم یک تغییری در پایگاه داده ایجاد کرده و نتیجه آن را به یک سرویس message broker ارسال کنیم میتوانیم از این تکنیک استفاده کنیم. از آنجایی که بعضی از تغییر ها در پایگاه داده میتواند زمان بر باشد پس این فرآیند ایجاد تغییر و ارسال نتیجه میتواند اتوماتیک بوده و توسط این پترن انجام شود. این پترن به این شکل کار میکند که هر زمان state پایگاه داده تغییر کرد ( در داده ها تغییری ایجاد شد‌ ) یک پیام به message broker ارسال میکند و این تغییر state را اطلاع میدهد. این روش معمولا در کنار معماری CQRS استفاده میشود.Low code platforms:این نوع پلتفرم ها امکان طراحی و توسعه نرم افزار ها را توسط یک محیط گرافیکی فرآهم میکنند. معمولا در این پبتفرم ها نیاز به نوشتن کمی کد برای تنظیمات خاص میباشد و بقیه موارد توسط خود پلتفرم انجام میشود. خوبی این پلتفرم ها این است که افراد بدون دانش فنی میتوانند با آن کار کنند. از معروف ترین این پلتفرم ها میتوان به Appian ، Mendix ، OutSystems و … اشاره کرد.Business Process Management Systems:این سیستم ابزار هایی را فرآهم میکند که میتوان با آن فرآیند های مرتبط با کسب و کار را بهتر میدیریت کرد. این فرآیند ها شامل مواردی مثل طراحی ، مدل سازی ، اجرای فرآیند ، نظارت بر فرآیند ، بهینه‌ سازی و طراحی مجدد میباشد. این سیستم برخی از این فرآیند ها را خودکار کرده و با این کار اتلاف زمان و انرژی را به حداقل میرساند. این سیستم در بخش های مختلف یک کسب و کار مانند منابع انسانی ، امور مالی ، قسمت فروش و … کاربرد دارد. تعداد زیادی از نرم افزار های متن باز وجود دارد که این سیستم را پیاده سازی کرده اند.Message Queue:این ابزار ها یک صف را پیاده سازی میکنند. کاربرد این صف ها برای ارتباط بین سرویس ها معمولا در معماری میکروسرویس میباشد. از آنجایی که یک سرویس ممکن است امکان پاسخ گویی به تعداد زیادی درخواست در آن واحد را نداشته باشد به یک سیستم واسط نیاز است که درخواست ها در یک ساختار داده مانند صف قرار بگیرند و به نوبت به آنها رسیدگی شود. از ابزار های مرسوم برای این کار میتوان به RabbitMQ و kafka اشاره کرد که در اکثر نرم افزار های مبتنی بر سرویس از این دو استفاده میشود.Container orchestration:هنگام کانترنرایز کردن یک نرم افزار به ابزاری نیاز است که مدیریت این کانتینر ها را راحت تر کند. این کار باعث میشود که نیاز به تعداد زیادی از افراد برای مدیریت کانتینر ها نباشد و فرآیند ها تا حد زیادی خودکار شوند. از جمله مواری که این نرم افزار ها مدیریت میکنند میتوان به لود بالانسینگ ، دیپلویمنت و تمام مواردی که مربوط به life cycle کانتینر ها میباشد. از جمله نرم افزار هایی که برای این منظور استفاده میشود میتوان به kubernetes اشاره کرد.Log Management Tools:مدیریت لاگ ها در سیستم هایی که از چند سرویس مجزا تشکیل شده اند کار دشواری است، همچنین برای این سیستم ها نیاز است که در صورت وجود اشکال با برسی لاگ های سیستم مشخص شود که اشکال اصلی از کدام سرویس میباشد. به این منظور به ابزار هایی نیاز است که مدیریت لاگ ها در اینگونه سیستم ها را تا حد زیادی خودکار کرده و به شکل قابل فهمی نمایش دهد. این ابزار ها به این هدف تولید شده اند. از معروف ترین این ابزار ها میتوان به سه ابزار elastic , kibana و logstash اشاره کرد که معمولا این سه در کنار هم استفاده میشوند.Monitoring tools:با بیشتر شدن استفاده از نرم افزار های cloud native نیاز به ابزاری که بتواند سرور های نرم افزار را به درستی برسی و مانیتورینگ کند بیشتر احساس میشود. این نرم افزار ها باید تا حد زیادی قابل اعتماد باشند که بتوان از آن ها اطلاعات درستی در مورد سرور ها به دست آورد. از معروف ترین این ابزار ها میتوان به prometheus اشاره کرد. این ابزار به طور منظم داده های مرتبط با پرفرمنس سیستم را جمع آوری کرده و در یک دیتابیس مبتنی بر زمان (time-series database) ذخیره کرده و میتوان از این داده ها جهت عیب یابی سرور ها استفاده کرد.Static Code Analysis:این نرم افزار ها بخشی از فرآیند code review را خودکار کرده و میتواند ایرادات بیشتر ظاهری کد را شناسایی و پیش از اجرای کد برطرف کند. همچنین معمولا در فرآیند های CI/CD اولین stage مربوط به این بخش میباشد. از ابزار های مناسب برای این کار میتوان به sonarQube اشاره کرد.sina mohammadisina mohammadiThu, 23 Nov 2023 11:48:22 +0330https://virgool.ir/@m_75137245/خلاصه-فصل-ها-۱۵-تا-۲۹-کتاب-clean-architecture-ykz6ghdlunc7معماری چیستبه طور کلی ارائه تعریف کلی و دقیق برای معماری نرم افزار غیر ممکن است. به طور کلی معماری خوب یک نرم افزار باعث میشود نرم افزار قابل توسعه ، قابل درک و قابل نگهداری باشد. به طور کلی معماری خوب خلاقیت توسعه دهنده ها را افزایش داده و هزینه نگهداری سیستم را کاهش میدهد. یک معمار خوب سعی میکند که تا جایی که امکان دارد کمترین تصمیمات را بگیرد زیرا هرچقدر دیرتر تصمیمات گرفته شود امکان این که تصمیمات انطباق بیشتری با نظر تیم محصول یا نیازمندی های کاربر داشته باشد.استقلالدر معماری چهار مورد مهم وجود دارد که باید به آن توجه کرد:عملکرد کلی سیستم و کاری که باید انجام دهدقابلیت نگهداری سیستمقابلیت توسعه سیستمقابلیت deployدر معماری خوب به این چهار مورد به صورت مستقل توجه میشود و هر کدام از این موارد در لایه های جدا به صورت مستقل توسعه داده میشوند.به عنوان مثال یک سیستم نرم افزاری ممکن است عملکرد های متفاوتی داشته باشد اگر هر عملکرد در لایه ای مجزا پیاده سازی شود در صورت تغییر یک عملکرد تنها کافی است که لایه مورد نظر تغییر کند. همچنین امکان اضافه کردن لایه های جدید به راحتی وجود دارد. این مورد مانند اصل single responsibility ولی برای لایه های مختلف نرم افزار است.حسن دیگر استفاده از این ساختار این است که هر لایه با توجه به کاربرد میتواند در سروری مجزا اجرا شود و هر بخش پهنای باند بیشتری داشته باشد.مورد دیگر این است که هر لایه میتواند توست تیمی مجزا توسعه داده شود و هر تیم لزومی ندارد که تمام موارد مربوط به کسب و کار و کارکرد دقیق لایه های دیگر را بشناسد.این جدا سازی لایه ها میتواند راه های مختلفی داشته باشد از جمله: جدا سازی کد ها از یکدیگر، جدا سازی فایل های اجرایی و جدا سازی سرویس هایک معماری خوب اجازه میدهد که یک پروژه ابتدا به صورت monolithic توسعه داده شود سپس در صورت نیاز با بزرگتر شدن پروژه به سمت جدا سازی سرویس ها برود و در نهایت به سمت معماری micro-service حرکت کند. ولی در هر زمان امکان برگشت به معماری monolithic سابق را داشته باشد.مرزهانکته بسیار مهم در معماری یک سیستم رعایت مرز بندی بین اجزا مختلف (به عنوان مثال بین UI , دیتابیس ، موارد مربوط به بیزینس و ،،،) میباشد. همچنین علاوه بر این که این موارد باید از هم مجزا باشند ، خیلی مهم است که به جز موارد موبوط به بیزینس پروژه بقیه نصمیمات زود گرفته تشود به عنوان مثال از چه دیتابیسی استفاده شود یا چه نوع وب سرویسی باید استفاده شود.قوانین و سطح هایک برنامه کامپیوتری در اصل یک سری قوانین و دستورالعمل ها را پیاده سازی میکند. در برنامه های بزرگ که تعداد زیادی از قوانین را پیاده سازی میکنند بهتر است این قوانین به صورت مجزا و در لایه مجزا پیاده سازی شوند. به طور کلی قوانین سطح پایین به قوانین سطح بالا وابسته هستند.قوانین کسب و کارییک سری از قوانین کسب و کار حیاتی هستند و حتی اگر هیچ سیستم کامپیوتری وجود نداشت باز هم این قوانین ثابت بودند (مانند نرخ بهره در بانک ها). این قوانین قابل تغییر نیستند و باید به شکل کامل پیاده سازی شوند. داده های این بخش از کسب و کار نیز حیاتی است و حتی اگر سیستم کامپیوتری وجود نداشت این داده ها موجود بود.به ابجکت های که این اطلاعات را نگهداری میکنند Entity میگوییم. Entity ها داده ها و قوانین مربوط به کسب و کار را کنار هم جمع میکنند. البته تمام قوانین کسب و کار entity محسوب نمیشوند.معماری ترس!معماری نرم افزار نباید وابسته به فریم ورک باشد و به طور کلی باید نشان دهنده قوانین کسب و کاری باشد. به عنوان مثال وقتی به سطح بالای معماری یک نرم افزار بانکی نگاه میکنیم باید متوجه شویم که این معماری مربوط به یک نرم افزار بانکی است نه این که فقط متوجه فریم ورک مورد استفاده بشویم.به طور کلی یک معماری نباید وابسته به فریم ورک , دیتابیس و ،،، باشد.معماری تمیزدر طول سال ها معماری های مختلفی برای نرم افزار مطرح شد. این معماری ها در چند موضوع مشترک بودند. اول این که مستقل از فریم ورک یا ابزار مورد استفاده بودند. دوم این که قابل تست شدن بودند و به طور کلی مستقل از دیتابیس ، UI و قوانین بیزینس بودند.تستیک معماری خوب باید قابل تست کردم باشد به این منظور بهتر است بخش های که unit test نوشتن برای آسان است از بهش هایی که توسعه unit test برایشان سخت است مستقل باشند به عنوان مثال نوشتن تست برای بخش UI سخت و چالش برانگیز است پس بهتر است بخش UI از بخش رفتار نرم افزار مجزا باشد.sina mohammadisina mohammadiWed, 18 Oct 2023 10:14:59 +0330