خواندن ۳۱ دقیقه·۲ سال پیش

معماری ها، الگوها، ابزارها و مفاهیم رایج در معماری نرم افزار

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

Domain Driven Design
Hexagonal architecture
CQRS
MVVM
Event Sourcing
Micro Frontends
Low code platforms
ESB
API Gateway
Business Process Management Systems (BPMS)
Business Rules Management Systems (BRMS)
Message Queue (such as Kafka and RabbitMQ)
Docker and Containerization
Container orchestration (such as Kubernetes)
Log Management Tools (such as ELK)
Monitoring tools (such as Prometheus)
Static Code Analysis (such as SonarQube)
Continuous Delivery
Single Sign on (SSO) and Identity Management
Service Mesh

در ابتدا سعی می شود هر یک از موارد مطرح شده را مختصرا توضیح دهیم و سپس نقاط ضعف، قدرت، مزایا و معایب هر یک را بررسی کنیم.

1.مفهوم Domain Driven Design

رویکرد دامنه محور(Domain Driven Design) یا به اختصار DDD، رویکردی برای توسعه نرم افزار برای نیازهای پیچیده با اتصالات عمیق پیاده سازی به یک مدل در حال تکامل است. استفاده از این رویکرد به ساده تر شدن پیچیدگی های موجود در نرم افزار کمک می کند.

1.1 تعریف Domain

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

1.2 مزایای Domain Driven Design

به طور کلی برای تغییر انعطاف پذیری بالایی دارد زیرا این الگو برای مدلسازی حوزه کسب و کار ساخته شده است
به کمک DDD می توان به کاهش پیچیدگی در نرم افزار کمک کرد زیرا DDD در واقع به آسان تر شدن ارتباط بین تیم توسعه و ذینفعان پروژه کمک می کند.

1.3 معایت Domain Driven Design

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

به طور کلی DDD شامل اصول و قواعدی است که فرایند تصمیم گیری در حوزه های تجاری را تسهیل می کند. همان طور که اشاره شد DDD هزینه بر است به همین دلیل برای پروژه هایی که پیچیدگی دامنه بالایی دارند مناسب است. همچنین DDD با پنهان کردن قواعد پیچیده به افراد فنی(تیم توسعه) و افراد غیر فنی(ذینفعان) کمک می کند تا به راحتی با یکدیگر ارتباط برقرار کنند.

2.معماری شش ضلعی(Hexagonal architecture)

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

معماری شش ضلعی شامل یکسری قواعد به شرح زیر است:

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

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

3.الگوی CQRS

الگوی Command and Query Responsibility Segregation یا به اختصار CQRS یکی از پر کاربردترین الگوهای معماری است. الگوی CQRS هدفش تفکیک عملیات های کوئری و کامند است. به طور خلاصه دستوراتی که تغییری در دیتابیس سیستم ایجاد نمی کنند در دسته کوئری(Query) و دستوراتی که باعث ایجاد تغییرات در دیتابیس می شوند و مقداری را بر نمی گردانند در دسته کامند(Command) قرار می گیرند.

به طور کلی دستورات پایگاه داده را میتوانیم در 4 دسته Create, Read, Update,Delete تقسیم بندی کرد. از میان دستورات مطرح شده Read در دسته کوئری و Create, Update, Delete در دسته Command قرار می گیرند. الگوی معماری CQRS تاکید به جداسازی دستوراتی دارد که در دو دسته Command و Query قرار می گیرند. در نسخه های جدیدتر CQRS از دو دیتابیس یکی برای دستورات از نوع Command یکی برای دستورات از نوع Query استفاده می شود. همچنین برای ایجاد هماهنگی بین دو دیتابیس از Replication و Message Broker استفاده می شود.
3.1 مزایای CQRS

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

3.2 معایب CQRS

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

4. الگوی معماری MVVM

الگوی معماری MVVM یک الگوی سه لایه متشکل از Model-View-ViewModel است که جهت حل مشکلات الگوهای معماری MVP و MVC ارائه شده است. الگوی پیشنهادی یک الگوی شناخته شده در برنامه نویسی اندروید است. در ادامه هر یک از لایه های الگوی MVVP را بررسی می کنیم.

لایه Model: این لایه مربوط به داده و جداول پایگاه داده است. همچنین این لایه بی اطلاع از لایه های View و ViewModel است و بصورت مستقل کار می کند.
لایه View: لایه ای از معماری که کاربر می بیند و با سیستم ارتباط برقرار می کند. به عبارت دیگر این لایه جهت اطلاع رسانی عملکرد کاربر به ViewModel در نظر گرفته شده است.
لایه ViewModel: این لایه یک انتزاع از View است به بیان ساده تر می توان گفت که ViewModel یک تبدیل کننده اطلاعات است که اطلاعات را همان طور که View و Model می خواهند به آنها تحویل می دهد.

از جمله فریم ورک هایی که از الگوی MVVM استفاده می کنند می توان به MicroModels, Caliburn Micro و Prism اشاره کرد.

4.1 مزایای الگوی MVVM:

این الگو، معماری را به سه لایه تقسیم می کند و این تفکیک به قابلیت نگهداری کدهای هر لایه محصول نرم افزاری کمک می کند. همچنین بخاطر تفکیک لایه ها در این الگو، می توان گفت که توسعه پذیری یکی دیگر از ویژگی های مثبت این الگوی معماری است.

4.2 معایب الگوی MVVM:

اشکال زدایی و طراحی ViewModel در الگوی MVVM گاهی دشوار است.

5. الگوی Event Sourcing

الگوی منبع کردن رویداد(Event Sourcing)، الگویی جهت ذخیره سازی جزییات تغییرات اعمال شده بر روی موجودیت های دیتابیس است. هر event روی هر موجودیت که رخ می دهد در لیست رخدادها با نام event store ذخیره می شود. با بررسی event store می توان وضعیت فعلی هر موجودیت را در سیستم بررسی کرد. در event store در هر سطر اطلاعاتی از قبیل event id, event type, entity type, entity id, event data و مواردی از این دست برای هر رخداد روی هر موجودیت ثبت می شود. به طور کلی در event store مواردی چون بروز رسانی موجودیت ها، حذف و اضافه شدن موجودیت ها ذخیره می شود.

گاهی یک سیستم منتظر بروز یکسری تغییرات در سیستم دیگر است تا واکنش متناسب با آنها را از خود نشان دهد. در این چنین مواردی استفاده از Event Sourcing بسیار کمک کننده است. بنابراین یکی از کاربردهای این الگو می توان به استفاده در معماری میکروسرویس اشاره کرد.

5.1 مزایای الگوی Event Sourcing:

به کمک Event Sourcing می توان رفتار سیستم را در طول زمان تحلیل و بررسی کرد.
در صورت بروز تغییر غلط مقادیر متغییرها می توان با بررسی event store حالت درست و عامل بروز خطا را شناسایی کرد.
همان طور که پیش تر گفته شد به کمک event store می توان تغییرات ناشی از event ها روی موجودیت ها را ثبت کرد. بنابراین به کمک event store می توان در صورت نیاز برای عملیات بازیابی اطلاعات استفاده کرد.

5.2 معایب Event Sourcing:

ذخیره سازی اطلاعات ناشی از تغییرات روی موجودیت ها در طول زمان باعث مصرف حافظه زیادی می شود.
اگر برای یک موجودیت اطلاعاتی در event store ذخیره شده باشد و در آینده نیاز باشد یک ویژگی جدید به موجودیت اضافه شود یا از آن حذف شود آنگاه بروز رسانی جدول event store دشوار است.

6. الگوی معماری Micro Frontends

معماری Micro Frontends تعمیم یافته معماری میکروسرویس است که برای توسعه برنامه های تحت وب در Frontend کاربرد دارد و به کمک آن می توان Frontend های انعطاف پذیر و ماژولار ساخت. معمولا از این معماری در برنامه های تحت وب برای ساخت و پیاده سازی واسط های کاربری قوی و سنگین استفاده می شود. قبل از استفاده از معماری Micro Frontend رایج ترین شیوه توسعه برنامه های تحت وب استفاده از یک رابط کاربری یکپارچه بود که در بالای لایه میکروسرویس قرار می گرفت. رابط کاربری یکپارچه در معماری میکروسرویس در Backend باعث بروز مشکلات و پیچیدگی هایی می شود. به عنوان مثال در صورت ارتقا یک میکروسرویس آنگاه Frontend به تغییرات زیادی نیاز دارد و گاهی این وضعیت از کنترل خارج می شود. بنابراین به کمک این معماری می توانیم برای هر میکروسرویس توسط تیم Frontend یک رابط کاربری مستقل از بقیه توسعه دهیم.

6.1 مزایای استفاده از Micro Frontend

این معماری به تیم های Frontend امکان آزادی بیشتر را می دهد و کمک می کند تا چرخه توسعه نرم افزار سریع تر پیش برود.
معماری Micro Frontend کمک می کند تا نرم افزار تولید انعطاف پذیر باشد. به عنوان مثال در صورت بروز بروز مشکل در یکی از میکروسرویس ها سایر رابط های کاربری دچار مشکل نمی شوند.
معماری پیشنهادی ویژگی مقیاس پذیری را برای محصول به همراه دارد.
به کمک معماری Micro Frontend می توان از ویژگی استقرار مستقل استفاده کرد. این ویژگی تکامل صحیح هر سیستم در حال رشد را تضمین می کند.

7. پلتفرم توسعه کم کد (Low-code platform)

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

7.1 مزایای پلتفرم های توسعه کم کد

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

از جمله پلتفرم های توسعه کم کد می توان به Visual LANSA, Retool, Quixy, Creatio, GeneXus, Zoho Creator, Appian, Kissflow, OutSystems اشاره کرد. در ادامه پلتفرم LANSA مورد را بررسی می کنیم.

7.2 پلتفرم LANSA

پلتفرم LANSA به توسعه دهنگان اجازه می دهد تا در زمان سریع تر و با کنترلی بالاتر کدنویسی برنامه ها را نسبت به روش های سنتی پیش ببرند. از جمله امکانات این پلتفرم می توان به موارد زیر اشاره کرد.

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

8. معماری ESB

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

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

8.1 مزایای معماری ESB

معماری ESB امکان اتصال به انواع وب سرویس ها را فراهم می کند.
معماری ESB هزینه های توسعه را کاهش و توسعه پذیری را افزایش می دهد.
معماری ESB از تعداد زیاد کاربر بصورت همزمان پشتیبانی می کند.

9. فناوری API Gateway

این فناوری جهت مدیریت API (رابط برنامه نویسی کاربردی) بین کاربران و مجموعه ای از سرویس ها قرار می گیرد. معمولا از فناوری API Gateway در اکثر برنامه های مبتنی بر میکروسرویس استفاده می شود. فناوری API Gateway در واقع از کاربران تمام فراخوانی های API را می گیرد و در نهایت هر یک را با مسیریابی درخواست و ترجمه پروتکل به میکروسرویس مناسب هدایت می کند. از جمله قابلیت های API Gateway می توان به مسیریابی، نظارت، احزار هویت، امنیت، تجزیه و تحلیل اشاره کرد. معمولا از API Gateway زمانی استفاده می شود که ارتباط بین سیستم های مختلف پیچیده می شود.

9.1 مزایای API Gateway

می توان برای هر دسته از کاربران یک API خاص ارائه داد.
پشتیبانی از DevOps
کاربر به جای فراخوانی سرویس بصورت مستقیم با API Gateway صحبت می کند.

9.2 معایب API Gateway

امکان بروز پیچیدگی بخاطر ازدیاد قوانین API در یک مکان
نیاز به قوانین مسیریابی

10. سیستم مدیریت فرآیند کسب و کار(BPMS)

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

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

10.1 فواید استفاده از BPMS

با خودکار کردن تمام یا بخشی از فرآیندهای یک سازمان می توان حجم کار را بصورت چشم گیری کاهش داد.
استفاده از BPMS منجر به تحلیل و شفاف سازی فرآیندها می شود بنابراین می تواند به نوعی باعث کاهش تخلف در سازمان شود.

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

قوانین کسب و کار در یک سازمان جهت کنترل و تاثیر گذاری بر رفتار کسب و کار سازمان تعریف می شوند. این قوانین همچنین تعاریف و محدودیت هایی را که برای یک سازمان اعمال می شود، توصیف می کند. پس از تعریف قوانین کسب و کار برای استفاده از منابع کمتر و دستیابی به اهداف نیاز است مدیریت این قوانین خودکار شود. بنابراین سازمان ها از پلتفرم BRMS برای حفظ قوانین کسب و کار خود استفاده می کنند. سیستم مدیریت قوانین کسب و کار (Business Rules Management Systems) یک پلتفرم برای مدیران یک سازمان جهت توسعه، ذخیره سازی و ویرایش قوانین کسب و کار است. همچنین به کمک این پلتفرم می توان سریع تر و آسان تر گلوگاه ها و حفره ها را بررسی و پیدا کرد.

11.1 فواید استفاده از BRMS

بهبود ارائه خدمات به مشتریان سازمان
بهبود و افزایش کارایی بخاطر خودکار سازی تصمیم گیری ها
اطمینان از رعایت و اجرای قوانین کسب و کار

12. صف پیام (Message Queue)

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

همان طور که گفته شد سرویس ها برای برقراری ارتباط و رد و بدل کردن پیام می توانند از صف پیام استفاده کنند، بنابراین در صورت بروز مشکل برای صف پیام باعث عدم ارتباط سرویس ها و بروز مشکلات در سیستم می شود و این یک عیب محسوب می شود. فرستنده پیام نقش تولید کننده و دریافت کننده پیام نقش مصرف کننده را دارد. لازم به ذکر است که لزوما تولید کننده و مصرف کننده پیام سرعت یکسانی در ارسال و دریافت پیام ندارند و صف پیام در چنین حالاتی می تواند به عنوان یک بافر مشکل را حل کند. Kafka و RabbitMQ دو مورد از ابزارهای معروف Message Queue هستند.

12.1 ربیت ام کیو (RabbitMQ)

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

12.2 کافکا (Kafka)

لایه ذخیره سازی کافکا برخلاف RabbitMQ که براساس صف و Exchange پیاده سازی شده است، براساس Partitioned transaction log پیاده سازی شده است. همچنین کافکا بصورت real-time با استفاده از Streams API امکان پردازش Stream ها را فراهم می کند.

کافکا پیام های تولید شده توسط تولیده کننده ها را در دسته بندی هایی با نام topics ذخیره می کند. به ازای هر تاپیک، در کافکا تعدادی پارتیشن جهت نگهداری پیام ها وجود دارد. در پارتیشن ها ترتیب دریافت و پردازش پیام های دریافتی از تولید کننده ها کنترل و رعایت می شود و پیام های هر تولید کننده را می تواند یک پارتیشن مپ کرد. در کافکا هر مصرف کننده می تواند با داشتن index پارتیشن ها، از آنها پیام بخواند. در کافکا همچون RabbitMQ نیز می توان مصرف کننده ها را دسته بندی کرد. در شکل زیر معماری کافکا را می توان مشاهده کرد.

12.3 تفاوت بین RabbitMQ و Kafka

تفاوت های مختلفی بین دو پلتفرم Kafka و RabbitMQ وجود دارد که در ادامه آنها را بررسی می کنیم.

ترتیب پیام. در Kafka مصرف کننده ها پیام ها را با همان ترتیبی که تولید کننده ها ارسال می کنند، پردازش می کنند. در حالی که در RabbitMQ توجه زیادی به ترتیب پیام های ارسال شده به صف و Exchange ندارند.
مسیریابی پیام. RabbitMQ قابلیت و انعطاف پذیری بیشتری در مسیریابی و فیلتر کردن پیام ها برای مصرف کننده ها نسبت به Kafka دارد.
زمان سنجی پیام. RabbitMQ قابلیت دادن تاخیر در ارسال پیام تولیده کننده و قرار گیری آن در صف را دارد. این درحالی است که Kafka از همچین قابلیتی پشتیبانی نمی کند.
نگهداری پیام. RabbitMQ هر پیامی را بلافاصله پس از پردازش توسط مصرف کننده از صف خارج می کند. در حالی که Kafka هر پیامی مستقل از اینکه پردازش شده است یا خیر، می تواند تا مدتی بسته به تنظیمات در تاپیک نگهداری کند.
مقیاس پذیری. Kafka بخاطر استفاده ی از Sequential disk I/O دارای performance بهتری نسبت به RabbitMQ است.

بنابراین بسته به شرایط و تفاوت های بیان شده می توان انتخاب درستی بین دو پلتفرم داشت.

12.4 مزایای استفاده از Message Queue

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

13. داکر و کانتینر (Docker and Containerization)

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

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

14. ارکستراسیون کانتینر (Container orchestration)

نرم افزارهای با ابعاد بزرگ مثل نرم افزارهای با معماری میکروسرویس گاها دارای هزاران کانتینر هستند. مدیریت، کنترل و استقرار این تعداد بالا از کانتینر در یک برنامه کار ساده ای نیست. بنابراین برای سادگی در مدیریت و کنترل، ارکستراسیون کانتینر (Container orchestration) ارائه شده است. از جمله کاربردهای ارکستراسیون کانتینر می توان به موارد زیر اشاره کرد.

مدیریت کانتینرها
انعطاف پذیر کردن سیستم در برابر خطا با راه اندازی مجدد کانتینری که دچار مشکل شده است
بررسی وجود مشکل در کانتینرها
برقراری Load balancing میان کانتینرها
تخصیص منابع بین کانتینرها

14.1 کوبرنتیز

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

استفاده بهینه از ظرفیت منابع سخت افزاری سازمانی
کنترل و خودکارسازی دیپلوی و به روزرسانی برنامه ها
ارکستر کانتینرها در میان چندین هاست
افزایش سرعت اجرای برنامه های کانتینر شده
بهبود کنترل سلامت و خودترمیمی برنامه را بهبود می دهد.

14.1.2 اصلاحات مربوط به کوبرنتیز

در این بخش اطلاحات رایج کوبرنتیز را بررسی می کنیم.

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

15. ابزارهای مدیریت لاگ (Log Management Tools)

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

15.1 مدیریت لاگ

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

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

از جمله ابزارهای معروف در حوزه مدیریت لاگ فایل می توان به ELK, Sematex Logs, Sumo Logic اشاره کرد. پشته ELK دارای ابزارهایی به شرح زیر است:

کمک به تجزیه و تحلیل قبل از indexing
یک موتور جستجوی سریع و مقیاس پذیر بنام Elasticsearch
ارسال کننده لاگ بنام Logstash
یک رابط کاربری برای جستجوی لاگ ها بنام Kibana

16. ابزارهای مانیتورینگ (Monitoring tools)

ابزارهای مانیتوریتنگ در وهله اول نوعی ابزار نظارتی و امنیتی هستند که روی سیستم یا شبکه ی یک سازمان نصب می شوند. ابزارهای مانیتورینگ سیستم، امکان پایش و بررسی مواردی چون پایداری سرویس ها، میزان استفاده از RAM، فرکانس CPU، میزان فضای خالی دیسک و مواردی از این دست را برای سازمان ها فراهم می کند. اما در این بخش هدف ما بررسی ابزارهای مانیتورینگ نرم افزار است. به طور کلی ابزارهای مانیتورینگ امکان نظارت پیوسته، مدیریت و بررسی میزان عملکرد و دسترس پذیری سیستم را فراهم می کنند. همچنین این ابزارها امکان بهبود رضایتمندی مشتری، پاسخگویی سریع تر، یافتن علت اصلی مشکل عملکردی و بهینه سازی برنامه های نرم افزاری و تحلیل رفتار کاربران در جهت ارائه خدمات بهتر را فراهم می کنند.

از جمله ابزارهای مانیتورینگ می توان به Prometheus, EG Innovations, Zabbix, NinjaOne اشاره کرد. در ادامه پرومتئوس را بررسی می کنیم.

16.1 پرومتئوس (Prometheus)

یک ابزار مانیتورینگ منبع باز است که در وهله اول به جمع آوری و تجزیه و تحلیل داده می پردازد. همچنین پرومتئوس یک ابزار مانیتورینگ مناسب برای محیط های کانتینری است که با استفاده از پینگ های SNMP می تواند چندین معیار را روی کوبرنت ها، سرورها و دستگاه های مختلف جمع آوری و میزان پهنای باند مصرفی توسط سرویس ها و دستگاه های مختلف را بررسی کند. پرومتئوس را می توان با Grafana جهت تجسم معیارها ادغام کرد.

17. تحلیل کد استاتیک (Static Code Analysis)

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

ابزارهای تحلیل ایستای کد می توانند بصورت خودکار و با دقت بالا اشتباهات و مشکلات امنیتی در سورس کد برنامه را کشف کنند. این ابزارها بدون نیاز به اجرای کد برنامه و تنها با بررسی کدها، می توانند عملیات بازبینی کد را انجام دهند. هر یک از ابزارهای تحلیل ایستای کد هزاران قوانین مختلف را برای زبان های برنامه نویسی مختلف شامل می شوند. همچنین در این ابزارها امکان شخصی سازی قوانین جهت هماهنگی با استانداردهای تعیین شده نیز وجود دارد. همچنین در چرخه DevOps امکان استفاده از ابزارهای تحلیل ایستای کد جهت دادن بازخورد به برنامه نویسان وجود دارد. از جمله ابزارهای تحلیل ایستای کد که امروزه استفاده می شوند می توان به SonarQube, SonarCloud, Checkmarx SAST CxSAST, Synopsis Coverity, Codacy و StyleCop اشاره کرد که در ادامه سونارکیوب را بررسی می کنیم.

17.1 سونارکیوب

یکی از معروف ترین ابزارهای تحلیل ایستای کد است که بیش از 20 زبان برنامه نویسی را پشتیبانی می کند. به طور کلی سونارکیوب می توان گزارش هایی در مورد پیچیدگی کد، باگ ها، مشکلات امنیتی، استاندارد کد نویسی و کدهای تکراری را ارائه کند. سونارکیوب از دو بخش سرور و کلاینت تشکیل شده است. سمت کلاینت با استفاده از gradle کدها را اسکن و نتایج را به سرور سونارکیوب ارسال می کند. سمت سرور سونارکیوب وظیفه نگهداری اطلاعات کد و زمان اسکن ها را دارد.

17.2 نقاط قوت ابزارهای تحلیل ایستای کد

بررسی و پوشش کامل سورس کد برنامه و کشف مشکلات موجود در سورس کد برنامه
مقیاس پذیری
بازبینی کد بصورت مستقل از کامپایلر
افزایش سرعت و دقت بازبینی کد نسبت به عامل انسانی

17.3 نقاط ضعف ابزارهای تحلیل ایستای کد

خطاهای False Positive. خطاهایی که ابزار به دلیل پیچیدگی کد گزارش می دهد.
عدم کشف برخی از خطا مانند خطای کدهای همروند.
اثبات آسیب پذیری مشکل امنیتی کشف شده دشوار است.

18. تحویل مستمر (Continuous delivery)

طبق تعریف کتاب Continuous Delivery، تحویل مستمر (Continuous Delivery) یا به اختصار CD، عملی برای اطمینان از اینکه نرم افزار همیشه آماده استقرار است. در واقع هدف CD خودکارسازی فرآیند استقرار و تحویل یک Artifact است. همچنین تحویل مستمر بخشی از CI/CD است. CI/CD یک روش جهت خودکارسازی برخی از مراحل توسعه برنامه است که در آن CI به ادغام پیوسته اشاره دارد. از جمله مسئولیت های CD می توان به استقرار Artifact ها، مدیریت و نظارت بر تغییرات و تهیه زیرساخت اشاره کرد.

همان طور که گفته شد CD قصد دارد تا یک Artifact را آماده استقرار کند. یک Artifact برای اینکه استقرار یابد به چندین مولفه نیاز دارد. هر یک از این مولفه طبق pipline به شرح زیر هستند:

دسترسی به محیط ابری
تامین زیرساخت
مدیریت تغییرات
استفاده از یک استراتژی برای استقرار
بررسی Performance
تعریف یک استراتژی بازگشت

بنابراین هدف یک piplint از CD، خودکارسازی 6 فعالیت بالا جهت استقرار Artifact است.

از جمله ابزارهای CD می توان به CircleCI, Jenkins, Argo CD, Harness, GitLab اشاره کرد.

18.1 مزایای CD

کمک CD به تسریع ارائه نسخه های جدید نرم افزار به کاربران
استفاده توسعه دهنگان از ابزارهایی که برخی از فرآیندها را خودکارسازی می کنند موجب اطمینان از کیفیت محصول تولید شده می شود.
افزایش سطح رضایتمندی مشتری از محصول
کشف سریع تر اشکلات موجود
تحویل مستمر باعث تسریع زمان ارائه محصول در بازار می شود.

18.2 چالش های CD

بروزرسانی های پی در پی موجب رضایت مندی برخی از کاربران نمی شود.
تحویل پی در پی نرم افزار نیاز به تست و تایید دارد.
بصورت کامل نمی توان آزمایش ها را خودکار کرد.

19. احراز هویت یکپارچه (Single Sign On)

روش احراز هویت یکپارچه (SSO) یک روش احراز هویت است که به کاربران این امکان را می دهد تا به کمک مجموعه ای از اعتبارنامه ها (نام کاربری و رمز عبور) در چندین برنامه بصورت ایمن احراز هویت شوند. این شیوه از احراز هویت این امکان را به کاربران می دهد تا برای چند برنامه نیاز به ثبت نام و ثبت اطلاعات مجدد نداشته باشند. همچنین از دیدگاه امنیتی به دلیل کاهش تعداد اعتبارنامه های کاربر در SSO امکان سرقت اطلاعات کاهش می یابد. در واقع روش SSO براساس رابطه اعتماد بین یک ارائه کننده هویت و برنامه ها تنظیم شده است.

19.1 نحوه کار روش احراز هویت یکپارچه

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

19.2 مزایای احراز هویت یکپارچه

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

از جمله ابزارهای احراز هویت یکپارچه می توان به KeyCloak و Authelia اشاره کرد.

20. سرویس مش (Service Mesh)

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

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

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

بدون سرویس مش هر سرویس منطق ارتباط با سایر سرویس ها را بایستی در خود داشته باشد. بنابراین توسعه دهنگان به جای تمرکز روی منطق برنامه درگیر چالش چگونگی ارتباط سرویس ها با یکدیگر می شوند.