مفاهیمی متنوع و پراکنده از معماری نرم‌افزار

طراحی مبتنی بر دامنه:

این مفهوم اولین بار توسط آقای اریک اوانز مطرح شده است. طراحی مبتنی بر دامنه (Domain Driven Design = DDD) یک رویکرد طراحی است که با استفاده از آن نرم‌افزار به گونه‌ای طراحی می‌شود که با یک دامنه به خصوص همخوانی داشته باشد. منظور از دامنه موضوعی از کسب‌وکار است که می‌تواند بصورت بسیار محدود (نرم‌افزار یک بیمارستان به خصوص) یا بسیار گسترده (نرم‌افزار مورد استفاده در شبکه بهداشت و درمان یک کشور) تعریف شده باشد.

دامنه از طریق نیازمندی‌های مشترک، مجموعه واژگان مشترک و کارکرد تعریف می‌شود. ساختار و زبان مورد استفاده (بطور مثال اسامی کلاس‌ها، متدها، نام متغییرها و غیره) باید به گونه‌ای باشد که با دامنه آن کسب‌وکار همخوانی داشته باشد. بطور مثال اگر دامنه صنعت بانکداری باشد می‌توان کلاس LoanApplication را تعریف کرد. هدف DDD تمرکز بر دامنه و منطق اصلی کسب‌وکار، مدیریت پیچیدگی، و همکاری بین متخصصین فنی حوزه نرم‌افزار با متخصصین آن دامنه به خصوص است. شرکت مایکروسافت DDD را برای دامنه‌های پیچیده کسب‌وکار توصیه می‌کند. اگرچه خود DDD مستقل از هر نوع ابزار و چارچوبی است اما بطور مثال می‌توان به ActifSource به عنوان افزونه‌ای برای eclipse، و OpenMDX و RestfulObjects به عنوان چارچوب و ابزار اشاره کرد.

معماری شش‌ضلعی:

این الگوی معماری توسط آقای کاکبرن و به منظور اجتناب از ضدالگوهای ساختاری در طراحی شی‌گرا ابداع شده است. معماری شش‌ضلعی (Hexagonal Architecture) را معماری پورت و آداپتور نیز می‌‌گویند. هدف آن ایجاد مولفه‌های نرم‌افزاری با اتصال شل (loose coupling همراهی آزادانه نیز ترجمه شده است (?)) و اتصال ساده به به محیط نرم‌افزار از طریق پورت‌ها و آداپتورها است. استفاده از این معماری به رعایت اصولی مانند REP، CCP، و CRP را تسهیل می‌کند(با تشکر از عمو باب ).

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

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

مخفف CQRS کوتاه شده عبارت Command and Query Responsibility Segregation است و برای جداسازی عملیات‌های نوشتن و خواندن در انبارداده به کار می‌رود. هدف استفاده از این الگو افزایش عملکرد، مقیاس‌پذیری، امنیت، انعطاف‌پذیری، جلوگیری از دستورات مخل در merge در سطح دامنه و غیره است.

در پایگاه داده‌های سنتی از مدل داده یکسانی برای پرس‌جو و به روزرسانی پایگاه داده استفاده می‌شود که مناسب عملیات اولیه CRUD است. در نرم‌افزارهای پیچیده این طور نیست. بطور مثال در زمان خواندن، پرس‌جوها ممکن است اشیای انتقال داده‌هایی (DTO) را بازگرداند که نگاشت شی آن‌ها پیچیده باشد. در زمان نوشتن ممکن است مدل از اعتبارسنجی و منطق کسب‌وکار پیچیده‌ای استفاده کند. CQRS خواندن و نوشتن را به مدل‌های متفاوت جدا می‌کند؛ از دستورات برای به‌روزرسانی داده و از پرس‌جو برای خواندن داده پایگاه استفاده می‌کند.

یکی از معایب این روش آن است که کد را نمی‌توان بصورت خودکار از شمای پایگاه داده با استفاده ازمکانیزم‌هایی مانند ابزار O/RM تولید کرد. بعضی از پیاده‌سازی‌های CQRS از الگوی Event Sourcing استفاده می‌کنند. در این صورت، حالت نرم‌افزار در قالب دنباله‌ای از رویدادها ذخیره می‌شود. هر رویداد نشان دهنده تغییرات در داده است.

چه زمانی باید از این الگو استفاده کرد؟ در دامنه‌هایی که کاربران بصورت موازی به یک داده دسترسی دارند، واسط کاربری وظیفه محور باشد، در سناریوهایی که سیستم در طول زمان تکامل می‌یابد.

چه زمانی نباید از این الگو استفاده کرد؟ دامنه یا قوانین کسب‌وکار ساده باشد، استفاده از واسط‌های ساده مبتنی بر CRUD کافی باشد استفاده از این الگو پیشنهاد نمی‌شود.

الگوی MVVM

با تغییر و رشد نرم‌افزار، مشکلات نگهداری بیشتری روی می‌دهند. از جمله این مشکلات می‌توان به اتصال سخت بین کنترل‌های UI و منطق کسب‌وکار نام برد که سبب هزینه زیاد تغییر و سختی در تست واحدها می‌شود. الگوی مدل-دید-دیدمدل (Model-View-ViewModel) منطق کسب‌وکار و ارائه نرم‌افزار را از واسط کاربری آن جدا می‌سازد. این موضوع به مدیریت بسیاری از چالش‌های توسعه، تست و نگهداشت و تکامل نرم‌افزار کمک می‌کند و فرصت استفاده مجدد از کد را بهبود می‌بخشد. همچنین امکان همکاری بهتر تیم توسعه و طراحی UI را فراهم می‌آورد. (معماری تمیز، عمو باب)

شکل زیر مولفه‌های تشکیل دهنده این الگو را نشان می‌دهد.

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

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

الگوی Event Sourcing

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

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

الگوی Micro-Frontend

معماری مایکروسرویس با سرویس‌های مستقلی که هر یک بر یک عملکرد مشخص کسب‌وکار تمرکز دارند و خود کفا (self-contained) هستند و توسط تیم‌های کوچک نگهداری می‌شوند، شناخته می‌شود. معماری مایکروفرانت‌اند در واقع استفاده از اصول توسعه مایکروسرویس در فرانت‌اند است. در معماری مایکروفرانت‌اند بصورت مستقل نرم‌افزارهای فرانت‌اند فرزند را می‌سازند و پیاده‌سازی می‌کنند. سپس این نرم‌افزارها توسط یک نرم‌افزار فرانت‌اند پدر که نقش یک کانتینر را برای بازیابی، نمایش و یکپارچه‌سازی فرانت‌اندهای فرزند، باز می‌کند، ترکیب می‌شوند. کاربری که با چنین نرم‌افزاری تعامل دارد، متوجه مایکروفرانت‌اندها نیست. آقای مارتین فاولر و همکاران مایکروفرانت‌اند را بصورت زیر تعریف می‌کنند:

«نوعی (استایلی) از معماری است که در آن نرم‌افزارهای فرانت‌اند که امکان انتشار مستقل آن‌ها وجود دارد، در قالب یک کل بزرگتر، حول هم گرد می‌آیند.»

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

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

سکوی توسعه کم کد

سکوی توسعه کم کد (Low Code Development Platform) محیطی برای توسعه نرم‌افزار از طریق واسط گرافیکی است اما ممکن است در جاهایی نیاز به نوشتن کد باشد. از مزایای توسعه بدون کد یا کم کد می‌توان به کاهش هزینه‌های توسعه، تحویل سریع، مشارکت افراد بیشتر در امر توسعه، هزینه و آموزش اولیه کمتر و نگهداشت آسانتر نرم‌افزار اشاره کرد. ریشه این سکوها به زبان‌های نسل چهارم و ابزارهای توسعه سریع نرم‌افزار دهه نود میلادی باز می‌گردد و بر مبنای طراحی مبتنی بر مدل، تولید کد خودکار و برنامه‌نویسی بصری برمی‌گردد. اصطلاح بدون کد ابتدا توسط موسسه تحلیلگر صنعت نرم‌افزار Forrest Research در ژوئن 2014 مطرح شد.

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

گذرگاه سرویس‌های سازمان

گذرگاه سرویس‌های سازمان (Enterprise Service Bus) که به اختصار ESB گفته می‌شود، یک الگوی معماری است که در آن یک نرم‌افزار مرکزی، یکپارچه‌سازی بین نرم‌افزارها را انجام می‌دهد. ESB تبدیل مدل‌های داده، مدیریت اتصال، مسیریابی پیام‌ها، تبدیل پروتکل‌های ارتباطی و مدیریت درخواست‌های مختلف را انجام می‌دهد. ESB این تبدیل‌ها و یکپارچه‌سازی‌ها را در قالب واسط سرویس به منظور ایجاد امکان استفاده مجدد توسط سایر نرم‌افزارها فراهم می‌آورد.

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

در تئوری ESB پتانسیل لازم را برای استانداردسازی، تسهیل ارتباطات و تبادل پیام، و یکپارچه‌سازی سرویس‌های یک سازمان را داراست. نرم‌افزارها به سادگی به ESB متصل می‌شوند و کار تبدیل پروتکل، مسیریابی پیام‌ها و تبدیل داده را به ESB می‌سپارند.

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

دروازه API

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

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

سیستم مدیریت فرایندهای کسب‌وکار

سیستم مدیریت فرایندهای کسب‌وکار (Business Process Management System) که به اختصار BPMS نامیده می‌شود، سیستمی برای مدل‌سازی، طراحی، اجرا و نگهداشت فرایندهای سازمان است. هدف از چنین سیستمی بهبود فرایندهای سازمان از طریق شناسایی، مدل‌سازی، خودکارسازی و تحلیل و ارزیابی عملکرد است. مزیت اصلی چنین سیستمی آن است که کاربران فرصت مشارکت فعال در بهبود فرایندها از طریق این ابزارها را دارند. در نرم‌افزارهای سازمانی، مفهوم مدیریت فرایندهای کسب‌وکار اهمیت بسیار ویژه‌ای دارد.

سیستم مدیریت فرایندهای کسب‌وکار سه مولفه اصلی دارد: 1. ابزار ساخت فرایند، 2. سکوی اجرای فرایند، 3. ابزار پایش فرایند.

سیستم مدیریت فرایند چگونه کار می‌کند؟

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

چرخه عمر یک فرایند: 1. طراحی، 2. مدلسازی، 3. اجرا، 4. پایش، 5. بهبود، 6. بازمهندسی.

سیستم مدیریت قوانین کسب‌وکار

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

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

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

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

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

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

صف پیام

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

پارادایم صف پیام، هم‌خانواده الگو ناشر/مشترک (Publisher/Subscriber) است و معمولا بخشی از یک سیستم واسط‌‌افزار پیام‌محور بزرگتر است. بسیاری از سیستم‌های پیام از هر دو الگوی ناشر/مشترک و صف پیام در APIهای خود پشتیبانی می‌کنند. دو سیستم معروف آپاچی کافکا و ربیت ام کیو را می‌توان  مثال زد.

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

1) انتشار (نوشتن) و اشتراک (خواندن) جریان‌هایی از رویداد، شامل وارد کردن/خارج کردن پیوسته داده از سایر سیستم‌ها،

2) ذخیره‌سازی جریان‌هایی از رویدادها بصورت پایدار و مورد اعتماد،

3) پردازش جریان‌هایی از رویدادها بصورت بلادرنگ یا غیر بلادرنگ.

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

داکر، کانتینر، کوبرنتیز

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

داکر و کانتینر

از داکر برای ساخت، اشتراک و اجرای نرم‌افزارها استفاده می‌شود. کانتنر یک واحد استاندارد از نرم‌افزار (تجریدی از در لایه نرم‌افزار) است که کد و واستگی‌های آن را بسته‌بندی نموده تا بتوان نرم‌افزار را در محیط‌های گوناگون رایانش، به سرعت و قابل اعتماد اجرا کرد. داکر یک بسته سبک، مستقل و اجرایی است و شامل تمام چیزهایی است که یک نرم‌افزار برای اجرا شدن به آن‌ها نیاز دارد: کد، ران‌تایم، ابزارهای سیستمی، کتابخانه و غیره. کانتینر نرم‌افزار را از محیط مستقل می‌سازد و تضمین می‌کند که نرم‌افزار صرفنظر از تفاوت instanceهای توسعه و staging، به درستی کار کند.

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

کوبرنتیز

کوبرنتیز (Kubernetes) یک سیستم همنواساز متن باز برای کانتینرها است. از آن برای توسعه نرم‌افزار، مقیاس‌پذیری و مدیریت استفاده می‌شود. در ابتدا گوگل طراحی این پروژه را انجام داد اما بعدتر Cloud Native Computing Fundation نگهداشت آن را بر عهده گرفت. کوبرنتیز با داکر، containerd، و CRI-O کار می‌کند، اما در گذشته منحصرا برای داکر بود.

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

گره اصلی کوبرنتیز (Kubernetes Master Node)  مدیریت کلاسترها و بارکاری، و هدایت ارتباطات را در کل سیستم برعهده دارد. گره یا کارگر یا مینیون ماشینی است که کانتینرها در آن استقرار یافته‌اند.

ابزارهای مدیریت لاگ

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

سیستم مدیریت لاگی موثر است که نمایی بلادرنگ از سلامت و عملیات سیستم ارائه کند. ویژگی‌ها زیر در میان سیستم‌های مدیریت لاگ موثر، دیده می‌شود:

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

یکی از ابزارهای مدیریت لاگ ELK است. ELK مخفف سه پروژه متن باز Elasticsearch و Logstash و  Kibana است. Elasticsearch یک موتور جستجو و تحلیل داده است که می‌توان از آن برای جستجوی متن، عدد، شکل، داده‌های ساختارمند و بدون ساختار استفاده کرد. Logstash یک خط لوله پردازش داده سبک وزن در سمت سرور است که امکان جمع‌آوری داده از منابع گوناگون را فراهم می‌آورد. Kibaba نیز یک داشبورد مصورسازی برای Elasticsearch است. به مجموع این ابزارها در کنار یکدیگر ELK Stack نیز گفته می‌شود.

پایش رویداد

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

از ویژگی‌های آن می‌توان به مدل داده چند بعدی، استفاده از PromQl، عدم اتکا به ذخیره‌سازی توزیع شده، استفاده از pull روی HTTP برای جمع‌آوری داده اشاره کرد. مولفه‌های اصلی آن عبارتند از سرور، کتابخانه‌های سمت کلاینت، دروازه push، صادرکننده، مدیریت هشدار و ابزارهای پشتیبان دیگر. این ابزار برای ثبت سری زمانی‌های کاملا عددی بسیار مناسب است. اما برای مواردی که به دقت صد درصدی نیاز است ابزار مناسبی نیست. زیرا داده‌هایی که جمع‌آوری می‌کند دارای جزئیات کافی و کامل نیستند.

سونار کیوب

سونار کیوب SonarQube یک ابزار متن باز برای بررسی کیفیت کد، شناسایی باگ‌ها و کدهای بودار در 29 زبان برنامه‌نویسی مختلف است. این ابزار تحلیل ایستای برنامه را انجام می‌دهد یعنی برنامه را برای تحلیل اجرا نمی‌کند. سونار کیوب گزارش‌هایی در خصوص کدهای تکراری، استانداردها کد، پیچیدگی کد و همچنین توصیه‌های امنیتی ارائه می‌کند. سونارکیوب سوابق متریک‌ها را ذخیره کرده و گراف‌های تکامل برنامه را رسم می‌کند. از جمله مزیت‌های سونار کیوب آن است که تحلیل کاملا خودکار ارائه می‌کند و می‌توان آن را با ابزارهای CI/CD مانند Maven یکپارچه کرد. بطور کلی برای انتخاب ابزارهای تحلیل ایستای برنامه مانند سونار کیوب باید معیارهای زیر را در نظر گرفت:

• پشتیبانی از زبان برنامه‌نویسی مورد نظر،
• قابلیت تشخیص آسیب‌پذیری بر مبنای معیارها و استاندارد مشخص،
• دقت،
• درک کتابخانه‌های مورد استفاده،
• قابلیت اضافه شدن به IDE توسعه،
• قابلیت اضافه شدن به ابزارهای CI/CD،
• هزینه لایسنس،
• و نوع خروجی.
  

تحویل پیوسته

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

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

مدیریت هویت و دسترسی

مدیریت هویت و دسترسی Identity and Access Management که به اختصار IAM نیز گفته می‌شود، شاخه‌ای از امنیت است که به موجودیت‌های مناسب، در زمان لازم، بدون دخالت و با هر وسیله‌ای که باشند، اجازه دسترسی به منابع مناسب را می‌دهد. مدیریت هویت و دسترسی، زمانی تنها برای کارکنان یک سازمان استفاده می‌شد. اما امروز برای شرکا، پیمانکاران، کاربران دورکار، مشتریان و غیر نیز استفاده می‌شود. زیرا سازمان باید دسترسی امن به منابع سازمان را نیز برای آنان تامین کند. از آنجایی که این مولفه بین کاربران و ارزشمندترین و حیاتی‌ترین دارایی سازمان، یعنی داده قرار می‌گیرد، برای هر سازمانی حیاتی‌ترین مولفه است و در برنامه امنیت به آن توجه ویژه‌ای می‌شود. پیاده‌سازی درست این مولفه علاوه بر امنیت به بهره‌وری و عملکرد بدون اصطکاک سیستم‌های دیجیتال کمک می‌کند.

راهکار Single Sign On با استفاده از یک مجموعه credential بطور مثال نام‌کاربری و گذر واژه یا اثر انگشت، که تنها یکبار وارد می‌شود، به کاربر اجازه می‌دهد که به چندین نرم‌افزار یا سرویس دسترسی داشته باشد. SSO امکان کنترل دسترسی متمرکز، احراز هویت، ایجاد سیاست‌های مختلف برای منابع مختلف، و امکان استفاده از منابع مختلف احراز هویت را فراهم می‌آورد.

سرویس مش

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

منابع:

https://learn.microsoft.com

https://aws.amazon.com/

https://www.ibm.com

https://martinfowler.com

https://www.rabbitmq.com/

https://kafka.apache.org/

https://www.docker.com/

https://kubernetes.io/

https://www.elastic.co/

https://prometheus.io/

https://www.sonarsource.com/

https://istio.io

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