بررسی برخی مفاهیم پایه‌ای

Domain Driven Design

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

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

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

طراحی دامنه محور، که آن را اختصارا DDD می‌نامیم، ریشه‌ی اصلی عدم موفقیت پروژه های نرم افزاری را از یک زاویه مختلف هدف گرفته است. اگر بخواهیم خیلی ساده مساله را بیان کنیم، میتوانیم بگوییم " تعاملات موثر" به عنوان Theme اصلی ابزارها و رفتار های تعریف شده در DDD شناخته شده است. طراحی دامنه محور را میتوان به دو بخش تقسیم نمود: طراحی راهبردی (strategic )، طراحی تکنیکی ( tactical ).

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

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

هر دو الگو و رفتارهای راهبردی و تکنیکی شرح داده شده، طراحی نرم افزار را با دامنه‌ی کسب‌وکار همسو می‌کند. به همین دلیل به آن طراحی دامنه محور یا (business) domain-driven (software) design می‌گوییم.

منبع :

• Learning domain-driven design by Vlad Khononov, Released October 2021,Publisher(s): O'Reilly Media, Inc.

Hexagonal architecture

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

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

پورت‌ها

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

آداپترها

آداپترها وظیفه‌ی برقراری ارتباط را بین مولفه‌های بیرونی و هسته اصلی برعهده دارند. هر پورت می‌تواند پذیرای چندین آداپتر باشد. نکته‌ی بسیار مهمی که باید به آن توجه داشت این مفهوم است که در سیستم‌های بیرونی یا خود آغاز کننده‌ی تعامل با هسته اصلی برنامه هستند ( که به آن آداپتور اصلی یا Driving Adapter گفته میشود) یا این ارتباط را از هسته اصلی برنامه دریافت می‌کنند ( که آداپتورهای ثانویه یا Driven Adapter گفته می‌شود).

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

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

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

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

منبع :

https://medium.com/ssense-tech/hexagonal-architecture-there-are-always-two-sides-to-every-story-bc0780ed7d9c

CQRS

عبارت Command and Query Responsibility Segregation که به اختصار CQRS نامیده می‌شود به الگویی گفته می‌شود که هدف اصلی آن تفکیک عملیات خواندن و نوشتن از منبع دخیره داده است. از دو مدل مختلف برای تحقق این امر استفاده می‌شود:

کوئری ها: که مسئولیت خواندن داده‌ها را برعهده دارد.

بخش Command ها: که مسئولیت به روزرسانی داده ها را بر عهده دارند.

بخش Command ها

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

بخش Query ها

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

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

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

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

منبع :

• https://henriquesd.medium.com/the-command-and-query-responsibility-segregation-cqrs-pattern-16cb7704c809

MVVM

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

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

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

مولفه View: مولفه View مسئولیت تعریف ساختار و ظاهر رابط کاربری را برعهده دارد. دقیقا همان چیزی که توسط کاربر بر روی اسکرین مشاهده میشود. تعاملات کاربر را مانند کلیک کردن موس، فشردن دکمه ی کیبورد و ... را دریافت میکند و آن را برای هندل کردن به View Model ارسال میکند.

مولفه Model: کلاس های موجود در مولفه Model را میتوان بیانگر مدل دامنه برنامه برشمرد که عمدتا علاوه بر در بر داشتن داده های برنامه، شامل منطق اعتبارسنجی و قواعد موجود در کسب و کار (که مرتبط با این ویژگی ها است) میباشد.

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

از مزایای این الگوی معماری میتوان به موارد زیر اشاره نمود:

• میتوان unit test های کامل و گوناگونی برای model و view model بدون در نظر گرفتن مولفه view نوشت.
• رابط کاربری برنامه را میتوان بدون تغییر در هسته اصلی برنامه باز طراحی کرد.
• طراحان رابط کاربری و توسعه دهندگان پروژه میتوانند به شکل کاملا مستقلی با یکدیگر به فعالیت بپردازند و به طور همزمان و متمرکز بر روی طراحی یا توسعه مولفه های خود متمرکز باشند. طراحان میتوانند تنها متمرکز بر روی مولفه View باشند، در حالیکه توسعه دهندگان میتوانند متمرکز بر مولفه ی View Model و Model باشد.

منابع :

• https://www.techtarget.com/whatis/definition/Model-View-ViewModel#:~:text=Model%2DView%2DViewModel%20(MVVM)%20is%20a%20software%20design,Ken%20Cooper%20and%20John%20Gossman.
• https://learn.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm
• https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel

Event Sourcing

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

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

به دست آوردن یک فایل log از تمامی تغییرات مهم ترین مزیت استفاده از الگوی منبع یابی رویداد میباشد. اگر چه این مزیت بزرگی محسوب نمیشود. با استفاده از این فایل log میتوانیم بهره برداری بهتر و مهمتری نیز انجام داد که در ادامه به ذکر دو مورد میپردازیم:

• بازساخت دوباره: از آنجایی که تمامی رویداد های ثبت شده در فایل log با در نظر گرفتن توالی رخداد ثبت شده اند، میتوان با کنار گذاشتن وضعیت فعلی سیستم و اجرای به ترتیب رویداد ها به وضعیت فعلی سیستم دست پیدا کرد.
• کوئری های زمانی: با اجرا کردن رویدادهای ذخیره شده از اولین آن تا رویداد منتشر شده در هر نقطه از زمان میتوانیم به State برنامه در آن نقطه دستیابی پیدا کنیم.
• میتوان از سیستم های کنترل ورژن به عنوان بارزترین مثال در به کارگیری از این الگو نام برد. چنین سیستم هایی برای استفاده از ورژن های قبلی به وفور از کوئری های زمانی استفاده میکنند. Subversion هایی که تولید میشوند نیز از قابلیت بازساخت دوباره بهره میجویند.

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

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

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

منبع :

• https://martinfowler.com/eaaDev/EventSourcing.html

Micro Frontends

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

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

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

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

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

منبع :

• https://martinfowler.com/articles/micro-frontends.html

Low code platforms

پلتفرم توسعه کم-کد یا low code platform به عنوان راهکار جایگزینی برای توسعه پلتفرم های نرم افزاری به شکل سنتی تلقی میشوند. چرا از واژه سنتی در این محل استفاده شده است؟ به دلیل آن که تا چند سال پیش توسعه هرگونه محصول نرم افزاری احتیاج به یک فرد فنی و آشنا به برنامه نویسی داشت. بنابراین برای افرادی که اصطلاحا دانش بسیار کمی در این حوزه داشتند، تولید یک وبسایت کار بسیار سختی تلقی میشد. به دلیل ایجاد نیاز فراوان به پلتفرمی که کاربران سطح پایین ( از نظر دانش برنامه نویسی ) بتوانند با آن اقدام به ایجاد نرم افزار یا عملیات مدنظر خود ( مثل تحلیل داده ای ساده ) نمایند با توجه و استقبال بسیار گسترده ای مواجه شد. تکامل و پیشرفت در این بخش را میتوان از تعداد استارتاپ ها و کمپانی های بسیار معتبر و بزرگ که روز به روز بر تعداد آنها افزوده میشود و در این بخش فعالیت میکنند متوجه شد. فرقی ندارد که محصول نهایی چه کاری انجام میدهد، ایا یک وب سایت را ایجاد میکند یا یک تحلیل داده ای ساده را انجام میدهد، هدف پلتفرم های توسعه کم-کد این است که کاربرانی که دانش فنی قابل قبولی در حوزه برنامه نویسی ندارند را مقدور سازد تا ایده های نرم افزاری خود را ایجاد و توسعه دهند، به گونه ای که از لحاظ منابع زمانی و مالی کمترین هزینه به آنها تحمیل شود. به عنوان مثال، به جای اینکه از یک توسعه دهنده بخواهید تا پلاگینی برای ارسال پیام کوتاه به مشتریان خود بفرستد، میتوانید با استفاده از پلتفرم های کم-کد با چند کلیک و Drag & Drop ساده این کار را انجام دهید. خصوصیات و ویژگی های این نرم افزار ها غالبا به صورت زیر تعریف میشود:

• یک محیط برنامه نویسی بصری که کاربر میتوان با آن به تعامل بپردازد. مثلا میتواند برای طراحی یک وب سایت شی button را انتخاب کرده و با Drag & Drop آن را به محل دلخواه خود بگدراد. در حالیکه یک برنامه نویس باید برای آن کد بنویسد.
• جهت سهولت استفاده غالبا شامل خاصیت Drag & Drop هستند.
• ابزار های مدل سازی بصری
• شامل قالب هایی از پیش ساخته شده هستن که میتوان آنها را انتخاب و کمترین تغییرات را اعمال کرد تا به محصول نهایی مدنظر خود برسیم.

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

ESB

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

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

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

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

منبع :

• https://medium.com/@karan99/system-design-enterprise-service-bus-esb-a7a460ed5d5c

API Gateway

امروز سازمان‌ها خدمات خود را از طریق APIها ارائه می‌دهند. اگر سازمانی باشد که تعداد APIو مخاطب کمتری داشته باشد مدیریت APIهای آن سازمان کار دشواری نیست و بدون مدیریت و پیچدگی خاصی اجرا می‌شوند.

اما به مرور زمان و گسترش تکنولوژی‌ها ارائه خدمات آنلاین سازمان‌ها و مشتری‌های آن‌ها روبه افزایش هستند و مشتری‌ها از چندین APIاستفاده می‌کنند در این صورت کنترل و مدیریت APIها دشوار خواهد شد و اگر مدیریت نشود ممکن است عملکرد سیستم‌ها دچار مشکل شود به همین دلیل نیاز به یک ابزار قدرتمند برای کنترل دقیق بر اجرای APIها به اسم API Gateway داریم که به عنوان یک جعبه سیاه بین مشتری و سرویس‌ها قرار می‌گیرد.

عملکرد API Gatewayبه این صورت است که درخواست مشتری‌ها را می‌گیرد و پاسخ مربوط را از APIمورد نظر می‌گیرد و به مشتری برمی‌گرداند.

ساختار کلی API Gatewayبه دو بخش کلی BSS سیستم پشتیانی کسب‌وکار و OSS سیستم‌های پشتیبانی عملیاتی است.

اجزا BSS

• مسیریابی (Routing)

در این بخش وظیفه API Gateway این است که درخواست کاربر را دریافت کند و به سمت سرویس مربوطه مسیریابی و هدایت کند و جواب را به همان کاربر برگرداند.

• احراز هویت و مجوز(Authentication and Authorization)

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

• مدیریت امنیت (Security Management)

هر سرویس که روی API Gateway قرار می‌گیرد باید امنیت آن ار لحاظ سطح دسترسی، حملات Dos، بررسی درخواست‌ها در تکرار نرمال و‌... برقرار باشد که API Gateway این مسئله را تضمین می‌کند.

• مدیریت ترافیک (Traffic Management)

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

• تغییر و ارکستراسیون (Transformation and Orchestration)

گاهی پروتکل درخواست‌های کاربران و پروتکل موجود در سرویس ارائه دهنده یکسان نباشد. یک سمت REST و در سمت دیگر SOAP استفاده شود و هنگام ارتباط این دو پروتکل نمی‌توانند باهم تبادل داده باشند وظیفه API Gateway تبدیل این پروتکل‌ها بهم است تا بتوانند به راحتی با یکدیگر کار کنند‌.

اجزا OSS

• پورتال (Portal)

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

• صورتحساب و CRM (CRM and Billing)

در این بخش ماژول‌هایی همچون فعال سازی و غیرفعال سازی دسترسی به API، حسابداری، مدیریت درخواست‌ها، قیمت گذاری ، محاسبه صورتحساب ، و جرایم SLA است.

• ورود به سیستم (Logging)

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

• نظارت و تجزیه و تحلیل (Monitoring and Analytics)

تعیین اینکه کدام API ها پر طرفدار هستند و کدام API را در آینده گسترش دهیم و....

ساختار API Gateway

منبع :

• J. T. Zhao, S. Y. Jing, and L. Z. Jiang, “Management of api gateway based on micro-service architecture,” Journal of Physics: Conference Series, vol.1087, p.032032, 2018.

Business Process Management Systems (BPMS)

تعریف BPMS

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

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

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

مزایای استفاده از BPMS ها

• سرعت بخشیدن به زمان ورود به بازار
• بهبود بخشیدن به سطح دسترسی خدمات و رضایتمندی مشتریان
• ساده سازی فرآیندهای تجاری
• کاهش هزینه و افزایش درآمد
• مدیریت ریسک‌های پروژه

منبع :

• https://www.creatio.com/bpms

Business Rules Management Systems (BRMS)

تعریف BRMS

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

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

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

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

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

ویژگی‌های BRMS

• ایجاد محیط‌های توسعه به‌صورت سفارشی برای ایجاد قوانین تجاری
• ایجاد موتور قوانین کسب‌وکار برای اجرای قوانین و مدیریت گردش کار فرآیندها
• ایجاد ابزارهایی برای توسعه قوانین تجاری بدون کد نویسی
• ایجاد ابزارهایی برای تایید قوانین تجاری
• استقرار قوانین تجاری در سایر پلت فرم‌ها
• ایجاد یک محیط انعطاف پذیر برای کار با خود پلت فرم
• ایجاد یک چرخه حیات برای مدیریت قوانین کسب‌وکار منبع :
• https://www.progress.com/faqs/corticon-faqs/what-is-a-business-rules-management-system

Message Queue (such as Kafka and RabbitMQ)

تعریف Message Queue

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

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

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

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

از جمله ویژگی‌های صف می‌توان به موارد زیر اشاره کرد :

• امکان برقراری ارتباط بدون کد.
• تعیین ترتیب پردازش داده‌ها در صف
• تعیین ظرفیت صف و تعداد صف‌های مورد نیاز هر سرویس.

انواع ارائه دهندگان Message Queue

• Apache Kafka
• RabbitMQ
• Celery
• Nsq
• Redisson
• Final Thoughts
  

معرفی RabbitMQ (Robust Messaging for Applications)

یک نرم افزار Message broker است، که یک پلت فرم مشترک برای ارسال و دریافت پیام‌ها بین برنامه‌ها ارائه میدهد و اطمینان میدهد که پیام انتقالی بین برنامه‌ها بدون خطا منتقل می‌شود. نرم افزار RabbitMQ منبع باز است که از بسیاری از زبان‌های برنامه نویسی پشتیبانی می‌کند. همچنین در محیط‌ Cloud و سیستم عامل‌های مختلف قابلیت اجرا دارد.

این نرم افزار قابلیت صف برای انتقال پیام را با کمک معماری MQ Telemetry و Transport(MQTT) و با استفاده از پروتکل متن محور STOMP ارائه می‌کند.

اجزا اصلی RabbitMQ

• تهیه کننده (Producer) : بر اساس نام صف پیام را به صف مورد نظر می‌فرستد.
• صف (Queue) : یک ساختار با توجه به توالی قرار گرفتن پیام‌ها ارائه میدهد که پیام ها از طریق صف بتوانند منتقل شوند.
• مشتری (Consumer) : سیستمی که پیام را برای پردازش از صف برمی‌دارد.
• تبادل (Exchange) : پیام‌ها را از فرستنده دریافت می‌کند و در صف مورد نظر قرار می‌دهد.
• بروکر (Broker) : یک Message broker داده‌های تولید شده را دخیره می‌کند تا مصرف کننده در موقع نیاز آن را بردارد.
• کانال (Chanel) : کانال‌ها از طریق یک اتصال TCP مشترک یک تصال به Broker فراهم می‌کند.

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

Reliability , Flexible Routing , Highly Available Queues, Multi-protocol, ....

منابع :

• https://www.ibm.com/docs/en/ibm-mq/9.2?topic=overview-introduction-message-queuing
• https://www.g2.com/categories/message-queue-mq
• https://aws.amazon.com/sqs/
• https://blog.rabbitmq.com/

Docker and Containerization

تعریف Containerization

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

خود Container ها برنامه‌های سبک وزنی هستند که برای اجرا نیازی به راه اندازی VM ندارند و مستقیما بر روی سیستم عامل میزبان اجرا می‌شوند. Container ها در محیط‌های ایزوله اجرا می‌شوند و تاثیری بر اجرای یکدیگر نمی‌گذارند.

خود Container ها توسعه و استقرای آسانی دارند، در سیستم عامل‌های لینوکس، ویندوز و مک قابل اجرا هستند. Container ها فضای ذخیره سازی، CPU و منابع شبکه را در سطح سیستم عامل مجازی می‌کنند و یک محیط sandbox را که از سایر برنامه‌ها جدا شده است را به توسعه دهندگان ارائه می‌کند.

به دلیل تراکم Container ها مدیریت و خودکار سازی آن‌ها دشوار است Docker قصد دارد پیچیدگی‌های آن را کم کند.

تعریف Docker

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

برای مثال هنگامی که می‌خواهید از پایگاه داده‌ای مانند PostgreSQL و یک حافظه Cache مانند Redis استفاده کنید، به جای نصب مستقیم این موارد و وابستگی‌های آن‌ها، از Container Image های هریک در داخل یک Docker استفاده و اجرا می‌کنیم.

معماری Docker

معماری Docker مبتنی بر معماری Client-server است. که Client ها با استفاده از REST API ها، Socket IO و TCP با Docker daemonدرحال اجرا بر روی میزبان Docker ارتباط برقرار کنند.

منابع :

• https://www.geeksforgeeks.org/containerization-using-docker/
• The Docker Book James Turnbull September 2, 2014 Version: v1.2.0 (fba92ef)

Container orchestration (such as Kubernetes)

تعریف Container orchestration

امروزه Container ها اهمیت خیلی بالایی پیدا کرده‌اند و سازمان‌ها از رویکرد سنتی و استفاده ز VM ها خارج شده و به سمت استفاده و استقرا Container ها آمده‌اند. به همین دلیل نیاز به مدیریت بهتر Container ها داریم.

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

ابزارهای Orchestration در همه‌ی محیط‌هایی که از Container ها استفاده شود لازم و ضروری هستند و کمک می‌کند در محیط‌های مختلف بدون نیاز به طراحی مجدد، Container ها را با امنیت بهتری اجرا کنید. مدیریت Container ها با استفاده از ابزارهای Orchestration و تیم DevOps است. از جمله ابزارهی معروف این حوزه می‌توان به Docker Swarm و Kubernetes اشاره کرد.

تعریف Kubernetes

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

ویژگی‌های اصلی Kubernetes :

• Automatic Binpacking

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

• Service Discovery & Load balancing

همچنین این پلت فرم شبکه و ارتباطات Container ها را مدیریت می‌کند و به طور خودکار به هر Container یک IP و یک DNS برای مجموعه‌ای از Container ها اختصاص می‌دهد و ترافیک را در هر خوشه کنترل می‌کند‌.

• Storage Orchestration

با Kubernetes می‌توانید فضای ذخیره سازی مورد نظر را نصب و راه اندازی کنید. می‌توانید از فضاهای ذخیره سازی محلی و یا از فضای ابری مانند AWS و یا از فضای ذخیره سازی مشترک مانند NFS استفاده کنید.

• Self-Healing

یکی از برترین ویژگی‌های Kubernatese این مورد است به این صورت عمل می‌کند که اگر در حین اجرا Container خراب شود را مجدد راه اندازی می‌کنند و Container هایی را که به تعریف استاندارد کاربر نباشند را حذف می‌کند و اگر خود Container ها از بین بروند برای اجرای مجدد آن‌ها برنامه ریزی می‌کند.

• Secret & Configuration Management

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

• Batch Execution

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

• Horizontal Scaling

همچنین این پلت فرم قابلیت بزرگ و کوچک‌تر کردن سایز Container ها را دارد.

• Automatic Rollbacks & Rollouts

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

منابع :

• https://www.vmware.com/topics/glossary/content/container-orchestration.html
• https://www.edureka.co/blog/what-is-kubernetes-container-orchestration
• https://kubernetes.io/

Log Management Tools

در سال‌های اخیر، مطالعات تحقیقاتی زیادی بر روی تحلیل خودکار Logتمرکز کردند. در همین حال، تعدادی از ابزارهای مدیریت Logبرای تسهیل چالش‌های دنیای واقعی در صنعت توسعه داده شده است. در این بخش، ابزارها و مجموعه داده‌های متن باز موجود را برای تحلیل خودکار Logمرور می‌کنیم. این ابزارهای Syslog- ، Prometheus ، Logalyze ، Logstash ، Fluentd ، GoAccess ، GrayLog از عبارتند Log تحلیل ng ، وLogAPI .به طور معمول، این ابزار ها از ویژگی های مهم مانند جمع آوری Log، جستجو، مسیریابی، تجزیه، تصویر سازی ،هشدار دهی و تحلیل خودکار پشتیبانی می کنند.

در این بخش به معرفی ابزار splunk می‌پردازیم :

تعریف splunk :

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

هدایت کننده (Forwarder) :

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

• شاخص گذار:

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

• سر جست‌وجو (Search head) :

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

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

سازمان‌ها و شرکت‌هایی که از splunk استفاده می‌کنند :

Adobe, Visa, Cisco, Walmart, Facebook, Motorola, IBM, Adidas

معماری splunk :

منابع :

• K. Subramanian. Practical Splunk Search Processing Language: A Guide for Mastering SPL Commands for Maximum Efficiency and Outcome. Apress, 2020.
• M. Cinque, D. Cotroneo, and A. Pecchia, “Event logs for the analysis of software failures: A rule-based approach,” IEEE Transactions on Software Engineering, vol.39, no.6, pp.806– 821, 2012.
• A. S. I. INDIA, A. S. INDIA, and Author:, “Splunk vs elk: Comparing two powerful log management solutions,” Oct 2021.

Monitoring tools

در این پست قصد داریم یکی از ابزارهای قدرتمند Monitoring را معرفی کنیم که این ابزار چه امکاناتی را در اختیار کاربران خود قرار می‌دهد و از چه معماری پشتیبانی می‌کند. ابتدا لازم است یک مفهوام اولیه از Monitoring را رائه کنیم تا درک ابزار مورد نظر برای ما بهتر باشد.

تعریف Monitoring

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

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

راهکارهای Monitoring میزان موفقیت یک پروژه را مشخص می‌کند و بدون Monitoring نمی‌توان مشکلات را درک و یا تشخیص داد.

عملکرد کلی ابزارهای Monitoring

• نظارت (Monitoring)

نظارت بر چند دستگاه، نظارت سرورهای چندگانه، نظارت بر شبکه‌ها ، کنترل و نظارت از راه دور.

• گزارش (Reporting)

گزارش از تغییرات داده‌ها، گزارش عملکردی‌های اصلی سیستم، گزارش تحلیل ریسک‌ها احتمالی.

• امنیت (Security)

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

• مدیریت (Management)

مدیریت بر نرم افزار و سخت افزارسیستم، مدیریت پیکربندی سرویس‎‌ها و مدیریت سیاست‌های سیستم.

معرفی Prometheus

ابزار Prometheus منبع باز و رایگان است که اتفاقات یک سیستم را با توجه به زمان رویداد آن‌ها را ثبت می‌کند.
همچنین برای ارائه نظارت بر میکرو سرویس‌ها، خدمات و برنامه‌های کاربردی مبتنی بر ابر و کانتینرها فراهم شده است.

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

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

معماری Prometheus

معایب Prometheus

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

منابع :

• Monitoring With Prometheus James Turnbull June 12, 2018 Version: v1.0.0 (427b8e9)
• https://prometheus.io

Static Code Analysis (such as SonarQube)

مفهوم کلی تحلیل کد استاتیک :

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

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

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

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

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

این ابزار قابلیت اطمینان کد، امنیت برنامه، کاهش نقص فنی را با حفظ پایگاه داده را تضمین می‌کند و همچنین از ۲۷ زبان مختلف مانند C, python, php ... پشتیبانی می‌کند و یکپارچه سازی ci/cd را نیز فراهم می‌کند.

منابع :

• https://owasp.org/www-community/controls/Static_Code_Analysis
• https://en.wikipedia.org/wiki/Static_program_analysis
• https://en.wikipedia.org/wiki/SonarQube

Continuous Delivery

تعریف Continuous Delivery

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

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

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

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

هدف اولیه تحویل مستمر ابن است که نرم افزار را با ریسک و خطر کمتری بتوان ارائه کرد همچنین بتوان با توجه به درخواست‌ها تغییرات لازم‌‌ را در زمان لازم اعمال کرد.

مزیت‌های تحویل مستمر

• ریسک انتشار را کم می‌کند
• سرعت بخشیدن به زمان بازیابی
• بالابردن کیفیت
• کاهش هزینه‌ها
• تولید محصولات بهتر منبع :
• https://aws.amazon.com/devops/continuous-delivery/

Single Sign on (SSO) and Identity Management

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

ورود به سیستم (SSO) یک سرویس احراز هویت برای کاربران است، که این قابلیت را رائه می‌کند که با یکبار ورود به یک سیستم بتوان به چندین اپلیکیشن و یا وب سایت دسترسی داشت. مثلا Facebook و اپلیکیشن‌های وابسته به آن مانند اینستاگرام.

در SSO احراز هویت و اطلاعات بصورت توکن‌هایی که حاوی اطلاعات مربوط به کاربر است مانند ایمیل و یا نام کاربری است، هنگامی که یک کاربر بخواهد به یک سرویس دسترسی پیدا کند ارائه دهنده سرویس یک درخواست جهت احراز هویت کاربر به SSO ارسال می‌کندد و پس از دریافت تایید به کاربر اجازه دسترسی و ورود به سیستم مورد نظر را پیدا می‌کند. سرویس‌های SSO از پروتکل‌هایی مانند Kerberos و یا Security Assertion Markup Language(SAML)استفاده می‌کنند.

مراحل SSO به شرح زیر است :

• کاربر اپلیکیشن و سایت مورد نظر خود را جست‌وجو می‌کند و درخواست ورود می‌دهد.
• ارائه دهنده خدمات، توکن‌هایی که حاوی اطلاعات کاربر است (نام کاربری و یا ایمیل کاربر) را برای SSO جهت احراز هویت ارسال می‌کند.
• ابتدا SSO بررسی می‌کند که این کاربر در سیستم وجود دارد و اینکه از قبل حراز هویت شده است یا خیر؟ اگر کاربر وجود داشت SSO یک رمز تایید برای ارائه دهنده خدمات جهت تایید کاربر ارسال می‌کند و سپس کاربر می‌تواند وارد سیستم شود.
• اگر کاربر در سیستم وجود نداشت و از قبل احراز هویت نشده باشد از کاربر درخواست می‌شود که اینکار را انجام دهد، که با گرفتن یک نام کاربری و یک رمز عبور(که می‌تواند رمزعبور یکبار مصرف OTP باشد) کاربر را ثبت کند.
• پس از تایید کاربر از سمت SSO رمزی را جهت تایید کاربر به ارائه دهنده خدمات به کاربر ارسال می‌کند.
• این توکن‌ها از طریق مرورگر به ارائه دهنده خدمات به کاربر ارسال می‌شود.
• رمزی که توسط ارائه دهنده خدمات دریافت می‌شود اعتبار سنجی می‌شود.
• در نهایت مجوز دسترسی کاربر به سیستم صادر می‌شود.
  منابع :
• https://www.tripwire.com/state-of-security/understanding-single-sign-identity-access-management
• https://www.techtarget.com/searchsecurity/definition/single-sign-on
• https://www.onelogin.com/learn/how-single-sign-on-works

Service Mesh

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

تعریف Service Mesh

با استفاده از Service Meshیک زیر ساخت ارتباطی برای ایجاد ارتباط غیرمستقیم میکروسرویس‌ها با یکدیگر می‌توان ایجاد کرد به این صورت که دیگر نیاز نیست میکروسرویس‌ها به‌طور مستقیم با هم ارتباط باشند، بلکه تمام ارتباطات سرویس‌ها با یکدیگر به یک لایه نرم افزاری به نام Service Meshیا پراکسی Sidecar منتقل می‌شود. Service Meshیک لایه نرم افزاری در همان VM میکروسرویس‌ها قرار دارد و ارتباط بین میکروسرویس‌ها را کنترل می‌کند.

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

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

منبع :

• Microservices for the Enterprise Designing, Developing, and Deploying Kasun Indrasiri Prabath Siriwardena

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