توضیح کوتاه برای 20 موضوع در مهندسی نرم افزار

  Domain Driven Design(DDD) 

طراحی دامنه محور یه رویکرد توسعۀ نرم افزار هست، یا میشه گفت یک نوع تفکره که برای توسعه و تولید نرم افزارهای بزرگ و پیچیده استفاده میشه و به ما کمک می کنه به نیازهای پیچیده ای که داریم متمرکز شیم و تلاشمون رو برای هیچ چیز غیرضروری و بی فایده ای هدر ندهیم. همچنین این رویکرد، پیاده سازی سیستم رو به یک مدل که به طور مداوم در حال تکامل و توسعه هست، تبدیل می کنه و جزئیات نامرتبط مثل زیرساخت ها، زبان‌های برنامه نویسی و فناوری های غیره رو در نظر نمی گیره، در واقع به سیستم دید کلی داره. دلیل اینکه فقط تو پروژه های بزرگ و پیچیده مناسبه اینه که استفاده از اون تو پروژه‌های کوچک و ساده یا پروژه‌هایی که صرفا نیاز به ذخیره و خواندن اطلاعات دارن، ممکنه فقط زمان و هزینه پروژه رو افزایش بده و مزیت خاصی هم به همراه نداشته باشه. کار اصلی ddd اینه که مثل مغز انسان همه چیز را بشکنه و به بخش های کوچکتر تقسیم کنه، تا برخورد با اون ها ساده‌تر باشد و راحت تر بشه برای آنها راه حل را پیدا کرد. مثل شکستن دامنه به چندین زیردامنه یاSubDomain یا ارائه راهکارهایی برای تقسیم نرم‌افزار به بخش‌های جدا و مستقل از هم و بیان ارتباط این بخش‌ها با همدیگه.این کار باعث توسعه نرم افزار به صورت موازی بین چند تیم و استفاده از معماری ها و تکنولوژی های مختلف تو هر تیم یا بخش میشه. زیر دامنه یا SubDomainها شامل 2 دسته هستند: دامنه اصلی: کلید موفقیت پروژه است و بیشترین هزینه و زمان و نیرو برای این بخش استفاده میشه. دامنه عمومی یا پشتیبان: اصل کسب و کار نیست اما وجودشون برای انجام کار اصلی دامنه ضروری هست. یکی از قدرت‌های DDD استفاده از زبان مشترک در مورد مفاهیم Domain هست.

  Hexagonal architecture 

معماری Hexagonal یا ساختار ports and adapters یه الگوی معماریه که مبتنی بر یوزکیس هست. تاکید این معماری بر روی تست پذیری سیستم بدون وابستگی به اکتورها و همچنین تغییرپذیری بیشتر آن هست. اگر ماژول های نرم افزار شما قادر باشن به راحتی به دیگر ماژول ها متصل بشن، در واقع وابستگی خاصی نداشته باشن، در این صورت می گیم که ماژول مورد نظر Loose Coupling با ماژول های دیگه داره و سیستم بسیار منعطف هست، یکی از اهداف این معماری هم طراحی سیستم به صورت Loosely coupled هست. به این معماری، معماری پورت ها و آداپتورها هم میگن، چون این معماری یک حالت انتزاعی داره که هستۀ اصلی برنامه را از فناوری ها و ابزارهای بیرونی جدا می کنه و در واقع مرزهای سیستم رو هم مشخص می کنه. تو این معماری دامین آبجکت ها و یوزکیس ها و پورت های ورودی و خروجی، هستۀ اصلی نرم افزار رو توصیف می‌کنن. Domain داخلی هیچ وابستگی‌ای به خارج نداره و تغییرات لایه های دیگر هیچ تاثیری روی آن نمیگذارن، قوانین و سیاست های بیزینس در اینجا قرار دارن. همون طور که مشخص هست این معماری به DDD مرتبط هست و میتونه یک روش خوب برای پیاده سازی و بکارگیری اون باشه.

CQRS  

مخفف Command and Query Responsibility Segregation هست که یعنی جدا کردن وظیفه Commandها و Queryها از همدیگه! اینکه دلیل اینکار چیه و چرا باید استفاده شه را در ادامه با یک مثال توضیح میدم. فرض کنید تو سایت سازمان سنجش و تو آخرین زمان های ثبت نام آزمون ها که لود سیستم بالاست و ممکنه افراد زیادی وارد سایت شن و اقدام به ثبت نام کنن، همزمان از سمت دیگه مدیران سیستم میخوان درصد مشارکت در آزمونها یا تحلیل رده سنی شرکت در آزمون رو بررسی کنند، مشکلی که در اینجا وجود داره اینه که ممکنه چون چندین کار همزمان قراره توی پایگاه داده و برای مثال تو یک جدول مشخص انجام شه، کندی زیادی وجود داشته باشه و کار ما را مختل کنه! برای این مشکل شاید راه حل‌های زیادی وجود داشته باشه و اینکه سیستم‌ها با توجه به حجم اطلاعات، اهمیت کاری که انجام میدن و تعداد کاربران یا تراکنش‌های هم زمانی که دارن، با همدیگه کاملا متفاوت هستن اما یکی از این راه حل ها یا الگوها، CQRS هست. به این صورت که ثبت نام ها رو در یک جدول انجام بدیم و از جدول دیگه ای اطلاعات را تحلیل کنیم، پس کلاس‌هایی که مسئولیت یا وظیفۀ read و write دارن، از هم جدا می شن.(مرتبط با قضیۀ event sourcing) در واقع CQRS بیان میکنه، خواندن و نوشتن 2 مسئولیت جدا و متفاوت هستن و نباید باعث ایجاد کندی و تاخیر در همدیگه باشن.

MVVM

مخفف Model-View-Viewmodel هست. میدونیم که الگوهای مختلفی وجود دارن که هر کدوم در جاهای مختلف کاربرد دارن و میخوان فرایند توسعه و نگهداری نرم افزار رو راحت تر و کم هزینه تر کنند. همونطور که از اسمش مشخص هست این الگو شامل 3 بخش هست که از همدیگه جدا هستند و میتونن به صورت موازی توسعه داده بشن. هر بخش رو به طور جداگانه توضیح میدم: مدل(Model): مدل اطلاعات برنامه مارو نگه میداره و فقط هم شامل همین اطلاعات و داده هاست و وظیفه دیگری نداره. برای مثال اطلاعات کاربری که میخواد در سایت ثبت نام کنه مثل ایمیل و نام و رمزعبور.

ویو (view): اون چیزی که کاربرد یا یوزرنهایی میبینه رو بهش میگن ویو! در واقع اون پوسته ای که کاربر باهاش در ارتباط و تعامل هست. این اطلاعاتی که در مدل هست چطوری و به چه شکلی نشان داده بشه و در چه فرمی قرار بگیره یا چه رنگی داشته باشه در این قسمت تعیین میشه برای مثال فرم ثبت نام کاربری که میخواد در سایت ثبت نام کنه.

ویومدل(view model) : ویومدل در واقع نقش واسط بین ویو و مدل رو ایفا میکنه. ویومدل اطلاعات مدل رو طبق چیزی که ویو میخواد اماده میکنه و تحویلش میده و همچنین برعکس یعنی اطلاعات رو از ویو میگیره و طبق چیزی که مدل میخواد اماده میکنه برای مثال ممکنه تاریخ رو از کاربر به صورت روز و ماه و سال بگیره (ویو) و بعد اینها رو بهم بچسبونه و به عنوان یک داده string به مدل بده! پس واسط هست و تقریبا مثل controller در mvc عمل میکنه.

Event Sourcing

همونطور که از اسمش مشخص هست منبع رویدادهای سیستم هست، یعنی ما فقط اخرین وضعیت سیستم رو نگه نداریم بلکه از ابتدا هر رویدادی که در سیستم اتفاق میفته رو ثبت و ضبط کنیم! در واقع رفتار و عملکرد سیستم رو در طول زمان میتونیم بدست بیاریم و اگر رفتار اشتباهی رو سیستم انجام بده، به راحتی میشه فهمید اون مشکل از کجا شروع شده و چه اتفاقی افتاده یعنی دیباگ کردن و fault localization راحتتری خواهیم داشت.در بعضی از سیستم ها این مورد ضروری هست مثل سیستم های مالی و بانکی و محاسباتی. جایی که کل این رویدادها ثبت میشن رو event store میگن که مثل یک منبع یا مخزن عمل میکنه، برای استفاده از این مخزن ما باید از CQRS استفاده کنیم که ممکنه سیستممون رو پیچیده تر کنه!

Micro Frontends

میدونیم که برای اینکه توسعه نرم افزار به درستی و راحت تر انجام بشه باید نرم افزار به بخش های مختلف شکسته بشه! حالا این شکسته شدن میتونه به صورت افقی باشه به این شکل که یک تیم backend، یک تیم frontend، یک تیم DB و ... داشته باشیم و هر بخش کار مربوط به خودش رو انجام بده. ممکنه فکرکنید اینطور شکستن ایده آل هست و افراد که تجربه و تخصص مشترک دارند میتونن با هم کار و تعامل کنند و مشکلات رو برطرف کنند و به نتیجه مطلوب برسند، اما اینطور نیست چون تیم ها از عملکرد تیم های دیگر به طور کامل آگاه نیستند برای مثال تیم فرانت اند از عملکرد درست تیم بکند مطمئن نیست و آگاهی کامل نداره پس توسعه نرم افزار رو به صورت عمودی میشکنیم، بدین شکل که هر یک از بخش های پروژه رو به یک تیم میسپاریم که خود اون تیم شامل بخش های مختلف هست و خود اون تیم کاملا خودمختاره یعنی روند توسعه هر تیم کاملا مجزا از تیم های دیگه هست و از پایگاه داده تا یوزراینترفیس جداگانه ای دارند پس هیچ اجباری برای انتخاب ابزارها و یا فریمورک های مشترک نیست و هر تیم بر حسب علاقه یا سلیقه یا متناسب با آن بخش که مسئولش هست، برای مثال فریمورک خودشو انتخاب میکنه! و در نهایت همه این بخش باید با هم ترکیب بشن و ساختار نهایی صفحات و نرم‌افزار را ایجاد کنند. تصویر زیر درک بهتری از این بخش رو بهتون میده.

Low code platforms

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

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

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

ESB

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

API Gateway

برای توضیح API Gateway اول باید خود API رو بشناسیم. API برای تبادل داده بین client و server به کار میره و همچنین برای ارتباط نرم افزار های مختلف هم ازش استفاده میشه. حالا ما به 2 روش یا معماری میتونیم اینکارو انجام بدیم، اولی استفاده از معماری Monolithic هست به این شکل که فرض کنید برای مثال وقتی وارد یک صفحه در یک سایت فروش کتاب میشین، کل اطلاعات اون صفحه، به طور یکجا و همزمان از سرور به وسیلۀ API و برای مثال ID کتاب موردنظری که روش کلیک کردین، دریافت میشه و به شما نمایش داده میشه، این روش یا معماری خیلی راحت هست ولی ممکنه وقتی تعداد کاربرای سایت بیشتر شه و تعداد درخواست همزمان بالاتر بره دیگه خوب کار نکنه و کند بشه، پس از معماری Microservice استفاده می کنیم به این شکل که برای مثال هریک از بخش های این صفحه که قراره اطلاعات یک کتاب رو نشون بده، به صورت یک Microserviceجداگانه باشه و یک وظیفۀ مخصوص داشته باشه مثلا بخش نظرات راجع به این کتاب، بخش کتاب های مشابه و ... هرکدوم جدا باشن و درخواست جداگانه ای به سرور بفرستن. خب حالا این معماری یا روش دوم هم مشکلاتی داره که باید رفع بشه، اولین مشکل بزرگش تعداد درخواست های زیاد اونم فقط برای یک صفحه هست حالا در نظر بگیرین کلی کاربر وجود داره و این سایت کلی صفحه دیگه هم میتونه داشته باشه، و یا اینکه اگر هرکدوم از این بخش های صفحات، درخواست بفرستن ممکنه Rest APIای که دارن، امنیتش به خطر بیفته و دیگران هم بتونن اونو ببینن! و ... پس از API Gateway استفاده می کنیم. حالا دیگه کلاینت ها درخواستشون رو فقط به API Gateway میفرستن و اون هم به عنوان یک واسط تشخیص میده برای جواب دادن به اون کلاینت به کدوم سرویس ها درخواست بده و جواب رو چطوری برگردونه، پس امنیت حفظ میشه و هر کلاینت در یک زمان متناسب میتونه جوابش رو بگیره. داخل API Gateway همچنین میتونیم دسترسی هارو کنترل کنیم و یک سری تحلیل و حتی نمودار از درخواست ها و پاسخ ها بدست بیاریم و یا حتی محدودیت هایی رو اعمال کنیم بدون اینکه پروتکل هایی که کلاینت و سرور ازش استفاده می کنند مهم باشه!

Business Process Management Systems (BPMS)

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

Business Rules Management Systems (BRMS)

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

Message Queue (such as Kafka and RabbitMQ)

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

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

خب RabbitMQ و Kafka 2 ابزار برای Message Queue هستند، RabbitMQ یک ابزار رایگان و قابل توسعه ست، یکی از مزایای دیگه اون داشتن UI تحت وب هست که اقدامات زیادی براش تعریف شده و میشه پیام هارو راحتتر نظارت و مدیریت کرد، یا اینکه آمار درستی از پیام هارو بدست آورد و دسته بندی و تحلیل کرد و همچنین اینکه برای انواع سیستم عامل ها هم قابل دسترس هست. Kafkaهم متن باز و رایگانه، یکی از مزیت های اصلیش توانایی کنترل حجم زیاد پیام هاست(بیگ دیتا)، تو پلتفرم های stream برای کنترل realtime بودنشون استفاده میشه و میتونه پاسخ رو سریع تولید بکنه و گذردهی بالایی داشته باشه حتی با وجود تعداد محدودی منابع! البته شروع کار و یادگیری Kafkaسخت تر هست.

Docker and Containerization

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

Container orchestration (such as Kubernetes)

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

 Log Management Tools (such as ELK) 

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

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

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

یکی از ابزارهای مدیریت لاگ ابزار ELK یا Elastic stack هست که یکی از پرکاربردترین ابزارهاست که خودش شامل Elastic search(یک موتور جستجوی متن باز)، Kibana(ابزار تجسم و تصویرسازی داده ها)، Beats(ذخیرۀ مستمر لاگ ها در یک مخزن داده)، Logstash(مخزن داده که عملیات روی فایلهای لاگ انجام میشه)

Monitoring tools (such as Prometheus)

اولین چیزی که توضیح میدم این هست که مانیتورینگ چیه؟ مانیتورینگ به این معنا هست که تمام ترافیک های ورودی و خروجی یک برنامه، تمام فعالیت های کاربران و برنامه رو لاگ کنیم یعنی هم فعالیت های معمولی و هم غیر معمولی رو ثبت کنیم و همواره با قوانین سیستم یا حالت عادی سیستم بررسی کنیم، تا به محض اینکه متوجه مشکلی شدیم مثلا ادمین سیستم رو مطلع کنیم. حالا این مانیتورینگ میتونه به شکل یک نرم افزار کامل باشه، یا یک کاربر یا حتی فایروال های نرم افزاری یا سخت افزاری. سیستم های مانیتورینگ برای پیگیری منابع سیستم(مقدار استفادۀ Ram، Cpu و ...)، اطلاعات شبکه(نرخ بار روی سیستم، خنک سازی سیستم و ...)، اتوماسیون سیستم ها و... استفاده میشه، در واقع امروزه مانیتورینگ یک بخش مهم و اصلی تو همۀ سازمان ها هست، به خصوص سازمان های بزرگ مثل خودروسازی، پتروشیمی و ...

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

Static Code Analysis (such as SonarQube)

تحلیل استاتیک کد یا تحلیل سورس کد یعنی اینکه ما کدهای برنامه رو بازبینی کنیم، یعنی بدون اینکه کد رو اجرا کنیم سعی کنیم ساختار کد رو درک کنیم و خطاهایی که ممکنه برنامه نویس کرده باشه رو پیدا کنیم، به این تحلیل، تحلیل جعبه سفید هم میگن چون مستقیما به کدها نگاه میکنیم و دنبال ایراد در کد هستیم. پس به این شکل هست که خط به خط کدهارو نگاه می کنیم تا خطاهای احتمالی رو پیدا کنیم یا اینکه آیا طبق استاندارد نوشته شده یا نه رو چک کنیم. حالا این تحلیل استاتیک به 2 شکل میتونه انجام بشه، یک حالت به صورت دستی(Mannual Review) هست یعنی اول خود برنامه نویس شروع کنه کدهاش رو از اول بررسی کنه تا ببینه خطایی وجود داره که سهوا انجام شده باشه یا نه، بعدش میتونه این کدهارو برای اینکه همکارانش چک کنند به اونها بده اگر این گام انجام شه خیلی بهتره چون از نگاه شخص دیگه ممکنه مشکلاتی دیده بشه که خود برنامه نویس متوجه نشده. نکته مهم این هست که این فاز قبل از تست نرم افزاره و در مراحل اولیه ست یا میشه گفت در مراحل پیاده سازی نرم افزار. اما مهم ترین مشکلی که تحلیل به صورت دستی داره زمانبر بودن اون هست پس ما باید از روش های اتوماتیک استفاده کنیم، روش های اتوماتیک سریعتر هستند و میتونن برنامه هارو به دفعات بیشتری بررسی کنن، نکات خوب و دقیقی رو از باگ های پیچیده تر پیدا کنن، بیشتر به دنبال الگوهای ثابتی از قوانین تو کدها هستن، میتونن نقص های امنیتی و backdoorها رو با احتمال درستی زیادی کشف کنن، پیشنهادهایی برای فرمت کد بدن و همچنین محاسبه متریکی برای کیفیت کد مورد نظر به ما بدن. یکی از این ابزارها که برای زبان های مختلف قابل بررسی هست SonarQube نام داره، که برای بیشتر از 20 زبان برنامه نویسی قابل استفاده ست و اگر مشکلی تو کیفیت یا امنیت کد باشه به صورت خودکار میتونه هشدار بده و همچنین اینکه رایگانه و باعث دهای تمیزتر و ایمن تر میشه.البته نکته مهمی که وجود داره اینه که خروجی ابزارهای تحلیل ایستا هنوز نیاز به ارزیابی انسانی دارن، بنابراین هیچ راهی برای اجتناب از مطالعه خروجی و قضاوت در مورد اینکه کدام مسائل باید برطرف شوند و کدام یک سطح قابل قبولی از برنامه نویسی رو نشان میدن وجود نداره.

Continuous Delivery

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

Single Sign on (SSO) and Identity Management

همونطور که از اسمش مشخصه یک روش احراز هویت هست، که به کاربران این اجازه رو میده که تنها با یک بار لاگین کردن بتونن به سرویس های مختلف اون سازمان دسترسی داشته باشن و دیگه احتیاجی به احراز هویت نباشه! برای مثال شرکت گوگل رو در نظر بگیرید، کاربر با وارد شدن به حساب گوگل، می‌تواند به سرویس‌های متعددی از این شرکت دسترسی پیدا کنه. در واقع با استفاده از SSO به جای چندین رمز عبور فقط به یک رمز عبور نیاز خواهید داشت. SSO به دوران به خاطر سپردن و وارد کردن چندین رمز عبور پایان میده و مشکلاتreset کردن پسوردهای فراموش شده را از بین میبره . پس کاربران می‌توانند به تعداد زیادی اپلیکیشن و پلتفرم دسترسی داشته باشند بدون این که لازم باشد هر بارlog in کنند. درواقع وقتی که یک کاربر توسط یک سیستم مورد اعتماد قرار می گیره، به طور خودکار به سایر سیستم‌هایی که رابطه قابل اعتماد با آن برقرار کردن دسترسی پیدا می کنه. وقتی کاربر وارد میشه یه توکن احراز هویت براش ایجاد میشه و تو مرورگر کاربر یا داخل سرورهای SSO ذخیره میشه و بعدا برای تایید هویتش بررسی میشه، این روش کارکرد SSO هست. SSO و Identity Management اغلب با هم استفاده میشن. SSO تو یک دامنه واحد دسترسی رو ممکن میکنه اما Identity Management ورود یکباره به برنامه های کاربردی رو در چندین دامنه یا سازمان ممکن میکنه.

Service Mesh

مش سرویس یک لایه زیرساخت اختصاصی هست که ارتباطات سرویس به سرویس رو روی یک شبکه کنترل می کنه. مش سرویس ها میتونن ارتباط سرویس به سرویس را سریع، قابل اعتماد و ایمن کنن. این روش میتونه باعث بشه بخش های مختلف یک برنامه با همدیگه ارتیاط برقرار کنن و معمولا تو برنامه هایی که از کانتینر و میکروسرویس استفاده میکنن، ظاهر میشن.مش سرویس برای تعادل بار، بازیابی مشکلات و خرابی ها، قابل اطمینان کردن ارتباطات کانتینری و میکروسرویسی، رمزگذاری ارتباطات و تعیین خط مشی های امنیتی به صورت خودکار(روش هایی مثل احراز هویت) میتونه استفاده بشه.اما از معایب مش سرویس میشه به افزایش زمان اجرا و پیچیدگی پیکربندی و ادغام اون اشاره کرد. برخی از ابزارهای مش سرویس: Istio، Linkerd، Tetrate، Kuma و ...

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»