مرور برخی مفاهیم معماری نرم افزار

Modular Monolithic

معماری Modular Monolithic معماری نرم‌افزاری است که مزایای طراحی modular را با سادگی یک معماری مونولیتیک ترکیب می‌کند. علت شهرت این معماری، سادگی و قابلیت نگه‌داری (maintainability) بالای آن است. در این رویکرد از یک codebase بزرگ استفاده می‌شود که می‌توان آن را به بخش‌های مجزا تقسیم کرد و هر بخش می‌تواند در صورت لزوم منطق کسب‌وکاری خود را داشته باشد. در این صورت هر یک از این بخش‌ها به صورت مستقل قابلیت توسعه، تست و نگهداری دارند. این جداسازی به گونه‌ای است که ارتباطات بین ماژول‌ها بسیار کم یا به عبارتی loosely coupled باشند.

در معماری Modular Monolithic، ما هنوز برنامه و نرم‌افزار یک کل واحد است که توسعه داده شده و مستقر می‌شود. اما این کد به ماژول‌های مستقل برای هر یک از ویژگی‌های مورد نیاز در برنامه شکسته می‌شود. در هر ماژول ویژگی‌های مرتبط با هم از دامنه مسئله دسته‌بندی می‌شوند و به این طریق، وابستگی‌های ماژول‌ها کاهش می‌یابد و یک ماژول را بدون نیاز به تغییر در سایر ماژول‌ها توسعه داده یا اصلاح کرد.

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

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

AWS

وب سرویس آمازون (AWS) یک پلتفرم جامع برای رایانش ابری است که توسط آمازون ارائه شده و شامل ترکیبی از سرویس‌های مختلف IaaS، PaaS و SaaSرا ارائه می‌دهد. آمازون اولین وب سرویس خود را در سال 2002 برای کسب‌وکار فروش آنلاین خود ارائه داد. در سال 2006 نیز زیرساخت را به عنوان یکی سرویس (IaaS) ارائه داد. همچنین یکی از اولین شرکت‌ها ارائه دهنده خدمات ابری با پرداخت هزینه بود.

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

• سرویس EC2 (Elastic Compute Cloud): این سرویس سرورهای مجازی را برای افزایش ظرفیت محاسبات به کاربران ارائه می‌دهد.
• سرویس S3 (Simple Storage Service): این سرویس امکان ذخیره سازی داده را فراهم می‌کند. در واقع این سرویس کمک می‌کند تا توسعه‌دهنگان به جای تمرکز روی نحوه ذخیره سازی داده به خود داده‌ها توجه کنند.

API-first Approach

برای استفاده از رویکرد API-first باید APIها را اولویت بندی کنیم. را اتخاذ کند، باید API ها را اولویت بندی کند، نقش API های عمومی، خصوصی و شریک در سازمان ها را بشناسد و چرخه عمر API و ابزار مورد نیاز برای تبدیل شدن به API اول را درک کند.

Hexagonal architecture

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

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

Event Sourcing

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

Business Process Management Systems (BPMS)

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

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

Message Queue (such as Kafka and RabbitMQ)

اغلب با بزرگتر شدن سیستم و برای جلوگیری از شکست، به جای معماری یکپارچه قدیمی از معماری میکروسرویس استفاده می‌شود. با تقسیم برنامه به واحدهای مستقل کوچکتر نیز، تعداد تعامل بین هر واحد به طور قابل توجهی افزایش می یابد. صف پیام(Messaging queue) یکی از روش های برقراری ارتباط و هماهنگی آسنکرون در واحد های جدا شده ارائه داده و در عین حال عملکرد، قابلیت اطمینان و مقیاس پذیری را بهبود می دهد.
در این ساختار ارائه شده، مؤلفه ای که پیام را به صف اضافه می کند تولید کننده و مؤلفه ای که پیام را بازیابی و پردازش می کند مصرف کننده نامیده می شود. مصرف کننده و تولیدکننده مستقیماً با هم تعامل ندارند و از واسطی به نام broker که معمولا صف را مدیریت می کند، با هم در ارتباط هستند.

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

کافکا آپاچی(Apache Kafka) و RabbitMQ نمونه‌هایی از صف پیام هستند.

Container orchestration (such as Kubernetes)

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

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

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

ابزارهای هم‌نواسازی برای Kubernetes شامل ویژگی های زیر است:

• استقرار و تکرار خودکار کانتینرها
• مقیاس آنلاین یا کوچک کردن خوشه های کانتینر
• متعادل کننده بار گروه های کانتینر
• برنامه ریزی مجدد خودکار کانتینرهای ناموفق
• در معرض قرار گرفتن کنترل شده پورت های شبکه به سیستم های خارج از خوشه

Log Management Tools (such as ELK)

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

در ادامه به برخی از عناصر مختلف چنین ابزارهایی اشاره شده است:

• عوامل(agent) لاگ به سیستم که لاگ ها را جمع می کنند
• موتور نمایه سازی که لاگ ها را نمایه می کند
• سرور مدیریت لاگ که درخواست کاربران را برای گزارش ها پردازش می کند
• موتور استقرار که برای نصب عوامل لاگ استفاده می شود

Monitoring tools (such as Prometheus)

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

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

Static Code Analysis (such as SonarQube)

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

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

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