نوشته های احسان رزازیان

علل مهاجرت از معماری یکنواخت به معماری میکروسرویس و چالش های آن

احسان رزازیان — Sat, 12 Feb 2022 21:07:30 +0330

چکیدهدر سالیان اخیر استفاده از معماری میکروسرویس بسیار رواج پیدا کرده است. مهاجرت یک سیستم نرم افزاری که به کمک معماری یکنواخت توسعه داده شده به به معماری میکروسرویس چالش هایی را به همراه دارد. در این تحقیق قصد داریم تا ابتدا علل مهاجرت به معماری میکروسرویس را به طور کامل بررسی و دسته بندی کنیم. سپس چالش هایی که در فرآیند مهاجرت از معماری یکنواخت به معماری میکروسرویس وجود دارد را به صورت شفاف بیان کرده و در نهایت 12 معیار برای اینکه آیا مهاجرت به معماری میکروسرویس به صرفه و منطقی است یا خیر را ارائه کنیم تا معمار نرم افزار بتواند به کمک پاسخ دادن به این سوالات یک تصمیم درست و با دید باز برای مهاجرت به معماری میکروسرویس بگیرد.کلمات کلیدی: معماری نرم افزار ، میکروسرویس ، معماری یکنواخت ، مهاجرت به میکروسرویس1. مقدمهامروزه با بزرگتر شدن مقیاس نرم افزار ها استفاده از معماری میکروسرویس برای توسعه نرم افزار بسیار رایج شده است که این معماری مزایا و چالش های مختص خودش را دارد. از طرف دیگر برخی سیستم های نرم افزاری وجود دارند که از ابتدا، فرآیند توسعه نرم افزار را با معماری یکنواخت انجام داده اند و به دلایل مختلفی، از جمله مقیاس پذیری و سرعت توسعه بیشتر، قصد دارند تا به معماری میکروسرویس مهاجرت کنند. باید به این نکته توجه داشت که مهاجر به معماری میکروسرویس همیشه تصمیم درستی نیز و اگر قبل از مهاجرت یک سری تحقیق و تخمین از مشکلات پیش رو وجود نداشته باشد، نه تنها مهاجرت کمکی به بهبود نرم افزار نخواهد کرد، بلکه باعث هدر رفتن زمان و انرژی نیز خواهد شد.این تحقیق از 3 بخش عمده تشکیل شده است. در بخش اول سعی کرده ایم تا به کمک مقالات موجود علل مهاجرت را بررسی کنیم. در این بخش خواهیم دید که چه عواملی باعث می شوند تا یک معمار نرم افزار تصمیم بگیرد که سیستم نرم افزاری را به سوی معماری میکروسرویس سوق دهد. در بخش دوم چالش هایی که معماری نرم افزار و توسعه دهندگان و حتی ذی النفعان با آن درگیر می شوند را بیان خواهیم کرد و نهایتا در بخش آخر، به توجه به این اطلاعات، یک سری معیار برای مهاجرت تعریف می کنیم. هر کدام این این معیار ها در واقع یک سوال هستند که معمار نرم افزار می تواند به آن ها پاسخ بدهد. پس از آن که این سوالات پاسخ داده شدند، یک شاخص یا امتیاز به دست خواهد آمد که پاسخ این سوال است: "مهاجرت یک سیستم نرم افزاری از معماری یکنواخت به معماری میکروسرویس، یه چه میزان منطقی و تصمیمی درست است؟"2. کارهای مرتبطتاکنون تحقیق ها زیادی بر روی علل مهاجرت به معماری میکروسرویس صورت گرفته است. در مرجع [1]، 20 تکنیک برای مهاجرت به معماری میکروسرویس بیان شده و گفته شده که مهم ترین چالش هنگام مهاجرت به معماری میکروسرویس، چالش های مربوط به پایگاه داده است. در مرجع [2] به انگیزه مدیران پروژه برای مهاجرت به معماری میکروسرویس اشاره شده و هم چالش هایی که در مهاجرت به معماری میکروسرویس وجود دارد معرفی شده است. در مرجع [3] به 2 سوال پاسخ داده شده است، سوال اول اینکه برای مهاجرت به معماری میکروسرویس چه اقداماتی باید انجام داد و سوال دوم اینکه چه چالش هایی هنگام مهاجرت به معماری میکروسرویس وجود دارد. همچنین در این مقاله نیز علل مهاجرت سیستم ها به معماری میکروسرویس بیان شده است. در مرجع [7]، مهاجرت به معماری میکروسرویس از جنبه های مختلف مورد بررسی قرار گرفته است و راهکار هایی در هر زمینه ارائه شده است. در مرجع [14] نیز ایتدا معماری میکروسرویس و اقدامات لازم برای نگهاری آن عنوان شده و سپس نحوه استقرار میکروسرویس ها به کمک Cloud و VM و Container ها ذکر شده و در نهایت مزایا و معایب روش های معروف موجود برای مهاجرت به معماری میکروسرویس به طور مفصل بیان شده است.3. علل مهاجرت به معماری میکروسرویسمهاجرت به معماری میکروسرویس علل و انگیزه های مختلفی دارد. این علل را می توان از جنبه های مختلفی بررسی کرد. اما به طور کلی با جمع بندی از مقالات موجود و بررسی یک پروژه عملی، علل زیر به دست آمد (به ترتیب از مهم ترین):3.1: افزایش سرعت توسعه: هنگامی که مقیاس یک پروژه نرم افزاری که با معماری یکنواخت توسعه داده شده بزرگ می شود، ایجاد تغییر نیز به همان نسبت سخت تر می شود. چون وقتی می خواهیم یک تغییر را در پروژه به وجود بیاوریم، باید به جنبه های مختلف آن پروژه نگاه کنیم و از تعداد زیادی از افراد تایید بگیریم که این یک فرآیند زمان گیر است. اما وقتی این سیستم به چند سیستم کوچک تر یا اصطلاحا میکروسرویس تقسیم می شود، توسعه دهندگان می توانند به صورت تیم های جدا از هم و بر روی بخش های کوچک تری از پروژه کار کنند که این به فرآیند توسعه نرم افزار سرعت می بخشد و همچنین در این حالت شاهد اختلافات و دعوا های کمتری میان توسعه دهندگان هستیم.3.2: امکان خلاقیت بیشتر: وقتی از معماری یکنواخت استفاده می کنیم، کل پروژه با یک زبان خاص نوشته شده است، اما در معماری میکروسرویس می توان از چندین زبان و تکنولوژی در یک زمان بهره برد. به عنوان مثال یک پروژه نرم افزاری را در نظر بگیرید که با زبان Java نوشته شده و از پایگاه داده Oracle استفاده می کند. مدیران فنی این پروژه پس از مدتی تصمیم می گیرند که برای قسمتی از پروژه شان از هوش مصنوعی استفاده کنند. طبیعتا استفاده از هوش مصنوعی به کمک پایتون بسیار رایج تر و منطقی تر است، لذا یک میکروسرویس به وجود می آید که به زبان پایتون نوشته شده است و عملیات مربوط به هوش مصنوعی را انجام می دهد و با این سیستم اولیه در ارتباط خواهد بود. به طور کلی وقتی از معماری میکروسرویس استفاده می کنیم، به یک زبان یا تکنولوژی خاص محدود نمی شویم. مثلا یک میکروسرویس با Java و یکی با C# و یکی دیگر با Python توسعه داده شده (ولی در عین حال نیز به کمک پروتکل هایی مانند صف یا REST با هم در ارتباط هستند). این امر باعث می شود تا توسعه دهندگان در هر تیم بتوانند خلاقیت بیشتری در آن زبان و تکنولوژی از خودشان داشته باشند و از مزایای تمام زبان های برنامه نویسی بهره ببرند، چرا که به صورت تخصصی با آن زبان و تکنولوژی آشنایی دارند.3.3: افزایش مقیاس پذیری: مقیاس پذیری به این معناست که یک سیستم نرم افزاری چه میزان توانایی دارد که خودش را با نیاز های جدید مطرح شده از جمله درخواست کارآیی یا منابع بیشتر وفق دهد. وقتی به معماری میکروسرویس مهاجرت می کنیم، امکان استفاده از فضای ابری و استقرار میکروسرویس ها بر بستر ابر یا VM معنای بیشتری پیدا می کند. به این صورت راحت تر می توان منابع را مدیریت کرد. به عنوان مثال وقتی از معماری یکنواخت استفاده می کردیم، اگر یک قسمت از برنامه تعداد درخواست زیادی داشت مجبور بودیم تا کل سرور را ارتقا دهیم، ولی وقتی به همعماری میکروسرویس مهاجرت کنیم، می توانیم به صورت On Demand هر لحظه که اراده کنیم منابع ابری را برای هر میکروسرویسی کم یا زیاد کنیم. به این صورت اگر مثلا تعداد کاربران یک سامانه زیاد شود، منابع مروبط به میکروسرویس منابع انسانی را ارتقا می بخشیم. به طور کلی وقتی به معماری میکروسرویس مهاجرت می کنیم چون از منابع به صورت اشتراکی استفاده نمی شود، کارآیی بیشتر خواهد بود.3.4: کاهش قطعی کل سیستم: تصور کنید که یک نرم افزار با معماری یکنواخت نوشته شده است و میخواهیم تغییر کوچکی در یکی از بخش های آن ایجاد کنیم. اگر این پروژه شامل حجم زیادی از کد ها و کتابخانه ها باشد، build گرفتن از آن و سپس استقرار و جایگزینی آن با نسخه قبلی بسیار زمان بر خواهد بود که در این مدت زمان سیستم قطع خواهد شد. ولی وقتی به معماری میکروسرویس مهاجرت می کنیم، این به روز رسانی ها در داخل هر کدام از میکروسرویس ها که حاوی حجم کمتری کد و کتابخانه هستند اتفاق می افتد و می توان سریع تر عملیات استقرار را انجام داد. همچنین اگر در معماری یکنواخت بخشی از سیستم دچار خرابی شود، آن خرابی به کل سیستم سرایت کرده و باعث می شود تا کل سیستم دچار قطعی شود، اما در معماری میکروسرویس اگر یک میکروسرویس دچار خرابی بشود سایر میکروسرویس ها می توانند به فعالیت خود ادامه بدهند.3.5: عیب یابی آسان تر: در بسیاری از پروژه های نرم افزاری، بودجه هایی برای بخش آزمون و اشکال زدایی نرم افزار تخصیص داده می شود. وقتی از معماری یکنواخت برای توسعه نرم افزار استفاده شده است، گاها حتی این بودجه کم هم می آید و پاسخگوی تمام نیاز ها در این حوزه نیست. لذا مدیران پروژه تصمیم می گیرند تا یک بار و یک هزینه کلی را صرف مهاجرت به معماری میکروسرویس انجام دهند تا پس از آن فرآیند آزمون و اشکل زدایی سریع تر و ارزان تر بشود. از آن جا که در معماری میکروسرویس نقش هر میکروسرویس کاملا مشخص است و میکروسرویس ها به صورت مستقل از هم فعالیت می کنند، عیب یابی کار راحت تری است و همچنین آزمون نرم افزار نیز می تواند به صورت همزمان بر روی میکروسرویس های متخلف در آن واحد انجام بگیرد.3.6: مستند سازی شفاف تر: در برخی از متدلوژی های توسعه نرم افزار مانند RUP، مستندات مختلف مانند SAD یا SRS یا ... دارای ارزش بسیار بالایی هستند. وقتی از معماری یکنواخت استفاده می شود، معمولا مستند سازی بخش های مختلف را یک نفر انجام می دهد و نهایتا نیز یک مستند طولانی از بخش های مختلف یک پروژه واحد حاصل می شود. این امر باعث می شود تا برخی از مدیران به فکر بیوفتند که به معماری میکروسرویس مهاجرت کنند تا پس از مهاجرت بتوانند آرشیوی از مستندات کامل تر و تمیز تر در بخش های مختلف نرم افزار یا همان میکروسرویس ها داشته باشند. در واقع به جای یک مستند طولانب و خسته کننده، هر میکروسرویس یک مستند مختصر و مفید خواهد داشت که در آن فقط خودش را توصیف می کند. ذکر این نکته نیز حائز اهمیت است که اکثر سامانه هایی که با معماری یکنواخت توسعه داده می شودند اصلا مستند ندارند.علت هایی که ذکر شدند را می توان از مهم ترین علت ها مهاجرت به معماری میکروسرویس دانست، گرچه علل دیگری نیز وجود دارند اما به ذکر همین 6 علت عمده و مهم کفایت می کنیم.4. چالش های مهاجرت به معماری میکروسرویسهنگامی که تصمیم به مهاجرت به معماری میکروسرویس گرفته می شود، فرآیند مهاجرت آغاز می شود. در این فرآیند مهاجرت چالش های زیادی وجود دارد که می توان آن ها را به دو دسته ی کلی: "چالش های فنی" و "چالش های سازمانی" تقسیم کرد. هر کدام از این دو دسته شامل یک سری زیر دسته هم می شوند که در ادامه با هم خواهیم دید:4.1 چالش های فنی:در فرآیند مهاجرت به معماری میکروسرویس چالش های فنی زیادی وجود دارد که حل آن ها نیازمند افراد متخصص و دانش فنی مربوط به آن حوزه است. برخی از مهم ترین این چالش های فنی عبارت اند از:4.1.1 مهاجرت پایگاه داده: از آن جا که فلسفه معماری میکروسرویس این است که هر میکروسرویس باید پایگاه داده مختص خودش را داشته باشد و فقط خود آن میکروسرویس به آن پایگاه داده دسترسی دارد، شاید مهم ترین و سخت ترین کار در هنگام مهاجرت از معماری یکنواخت به معماری میکروسرویس، تجزیه یک پایگاه داده به چند پایگاه داده باشد. در حین مهاجرت باید به این نکته نیز توجه داشت که ممکن است چنس پایگاه داده های میکروسرویس های مختلف با هم فرق داشته باشد، در صورتی که در معماری یکنواخت فقط یک پایگاه داده داشتیم که تمام داده ها در آن ذخیره می شد. به عنوان مثال ممکن است پایگاه داده نرم افزار اولیه که با معماری یکنواخت توسعه داده شده از جنس SQL Server بوده باشد و حالا تصمیم گرفته ایم که نرم افزار اولیه را به سه میکروسرویس، که یکی با پایگاه داده MySql و دیگری با MongoDB و دیگری با Oracle کار میکند بشکنیم. به طور کلی انتقال داده ها و همچنین Sync بودن داده ها با یکدیگر و وجود جامعیت بین داده های توزیع شده در پایگاه داده های مختلف یک کار چالش برانگیز است که نیازمند دانش فنی متخصصان این حوزه است.4.1.2 خرد کردن کد اصلی برنامه: منظور از خرد کردن کد اصلی برنامه در واقع همان مشخص کردن boundary ها و شناسایی سرویس های مختلف و پیاده سازی مجدد آن ها در قالب میکروسرویس های مختلف است. یکی از بزرگترین چالش ها هنگام مهاجرت به معماری میکروسرویس، شکستن کد برنامه اصلی به چند بخش می باشد. برای این کار باید از روابط موجود میان کلاس ها و مفهوم تمام قطعه کد های برنامه اولیه آگاه باشیم. حتی در شرایطی ممکن است هنگام مهاجرت تبدیل زبان نیز داشته باشیم، یعنی به عنوان مثال نرم افزار اولیه که با معماری یکنواخت توسعه داده شده است با زبان #C نوشته شده است اما یکی از میکروسرویس ها قرار است با زبان پایتون کار کند، در این حالت باید آن کد #C را به پایتون تبدیل کنیم که خود امری چالش برانگیز است.4.1.3 ارتباط میان میکروسرویس ها: پس از مهاجرت به معماری میکروسرویس، چندین پروژه نرم افزاری با مقیاس کوچک تر به وجود می آیند که قبلا در قالب یک پروژه بزرگ با یکدیگر در ارتباط بودند. ارتباط آن ها در یک پروژه واحد به سادگی پیاده سازی شده بود، مثلا کلاس های مختلف یکدیگر را صدا می زند، و یا داده ای را در پایگاه داده مشترک بینشان ذخیره یا به روز رسانی می کردند. اما سوال که به وجود می آید این است که پس از مهاجرت به معماری میکروسرویس، این میکروسرویس ها چگونه باید با یکدیگر ارتباط برقرار کنند؟ در پاسخ باید گفت که برای این منظور را ههای مختلفی از جمله استفاده از پروتکل هایی مانند REST یا SOAP و یا پروتکل های پیام رسانی وجود دارد. این که میکروسرویس ها باید از کدام یک از این پروتکل ها استفاده کنند تصمیمی است که معمار نرم افزار با توجه به شرایط موجود می گیرد. اما به طور کلی اگر فراخوانی بین میکروسرویس ها خیلی زیاد باشد بهتر است تا از پروتکل های مبتنی بر صف و فناوری های مربوط به آن حوزه استفاده کرد تا کارآیی کم نشود.4.1.4 مدیریت منابع: هنگامی که از معماری یکنواخت استفاده می شد، تمام قسمت های مختلف برنامه از یک سری منابع اشتراکی محدود و واحد استفاده می کردند. اما وقتی تصمیم می گیریم که به معماری میکروسرویس مهاجرت کنیم، منابع باید یه نوعی بین میکروسرویس ها پخش شوند تا همه میکروسرویس ها در بستر آن منابع بتوانند بهترین عملکرد خودشان را داشته باشند. برای این بخش استفاده از فضاهای ابری که می توان منابع را به صورت نرم افزاری مدیریت کرد پیشنهاد می شود.4.1.5 مشکلات امنیتی: وقتی میکروسرویس ها به صورت توزیع شده و جدا از هم کار می کنند و با هم از طریق پروتکل های مختلف در ارتباط هستند، یک سری مشکلات امنیتی به وجود می آید که از قبل وجود نداشت. اغلب این مشکلات امنیتی هنگام برقراری ارتباط بین میکروسرویس ها است. بسیاری از سازمان ها به این موضوع توجه نمی کنند و سطوح دسترسی مشخصی را برای اعضا و تیم ها تعریف نمی کنند و هر کس می تواند از هر گونه API ای استفاده کند که این باعث پیدایش رخنه امنیتی در سیستم می شود.4.2 چالش های سازمانی:جدای از مسائل فنی در مهاجرت به معماری میکروسرویس، یک سری مشکلات در سطح سازمان وجود دارد که به آن ها می پردازیم.4.2.1 تغییر تفکر سازمانی: در بسیاری از مواقع وقتی یک سازمان تصمیم می گیرد که به معماری میکروسرویس مهاجرت کند، متدلوژی توسعه نرم افزار را نیز تغییر می دهد. مثلا تا قبل از مهاجرت به معماری میکروسرویس از متدلوژی سنتی آبشاری استفاده می کرده است اما پس از مهاجرت تصمیم گرفته است تا از متدلوژی Agile که با معماری میکروسرویس همخوانی زیادی دارد استفاده کند. در این حالت تمام اعضای تیم ها باید آموزش های مربوط به متدلوژی و فرهنگ جدید را ببینند، در غیر این صورت نمی توانند نیروی کارآمدی باشند. در بسیاری از موارد، اعضای سازمان از یادگیری مفاهیم جدید خودداری می کنند و ترجیح می دهند که دیگر در آن تیم کار نکنند. در مواردی هم آموزش برخی اعضا بسیار زمان بر و فرسایشی می شود.4.2.2 تقسیم بندی وظایف: وقتی تصمیم به مهاجرت به معماری میکروسرویس گرفته می شود، اشخاص و متخصصانی که در یک تیم واحد بزرگ کار می کردند باید به تیم های کوچک و چابک تقسیم بشوند. همچنین باید یک نوع تقسیم بندی وظایف بین این افراد صورت بگیرد تا نقش هر شخص در هر تیم مشخص شود. در بسیاری از موارد در هنگام همین تقسیم بندی وظایف دعواهایی پیش می آید که باعث استعفای کارمندان نیز می شود و جایگزین کردن نیروی جدید به جای آن شخص فرآیندی زمان بر است.در این بخش سعی کردیم تا چالش هایی که هنگام مهاجرت به معماری میکروسرویس وجود دارند را بیشتر بشناسیم تا بتوانیم با دید بازتری به قسمت بعد برویم و برای مهاجرت یا عدم مهاجرت تصمیم گیری کنیم.5. معیارهای تصمیم گیری برای مهاجرتدر این بخش 12 سوال مطرح شده است که به هر کدام از این سوال ها یک پاسخ که یک عدد بین 0 تا 4 است داده می شود و در نهایت یک عدد بین 0 تا 48 به دست می آید. این فرم باید توسط معمار نرم افزار پاسخ داده شود. تفسیر نتیجه و این که آیا مهاجرت به معماری میکروسرویس به صلاح و به نفع سازمان است یا خیر در انتهای سوالات آمده است.سوال 1: پیاده سازی یک تغییر در پروژه فعلی چقدر زمان می برد؟0: زمان بسیار کمی می برد.1: زمان نسبتا کمی می برد.2: زمان معقول و استانداردی را می برد.3: زمان نسبتا زیادی می برد.4: زمان بسیار زیادی می برد.سوال 2: پیاده سازی یک تغییر در پروژه فعلی چقدر هزینه می برد؟0: هزینه بسیار کمی می برد.1: هزینه نسبتا کمی می برد.2: هزینه معقول و استانداردی را می برد.3: هزینه نسبتا زیادی می برد.4: هزینه بسیار زیادی می برد.سوال 3: مولفه های نرم افزاری که سامانه اصلی را تشکیل می دهند چه میزان به هم وابستگی دارند؟0: بسیار کم.1: نسبتا کم.2: متوسط.3: نسبتا زیاد.4: بسیار زیاد.سوال 4: دانش فنی اعضای تیم توسعه در چه سطحی قرار دارد؟0: بسیار خوب.1: نسبتا خوب.2: متوسط.3: نسبتا ضعیف.4: بسیار ضعیف.سوال 5: در حال حاضر چه تعداد ویژگی جدید (یا تغییر) در حال پیاده سازی روی این سامانه است؟0: هیچ قابلیت جدیدی در حال پیاده سازی نیست.1: یک یا دو قابلیت جدید در حال پیاده سازی هستند.2: بین سه تا پنج قابلیت جدید در حال پیاده سازی هستند.3: بین شش تا ده قابلیت جدید در حال پیاده سازی هستند.4: بیش از ده قابلیت جدید در حال پیاده سازی هستند.سوال 6: آیا توسعه دهندگان و کارمندان با معماری میکروسرویس آشنایی دارند؟0: بله کاملا اشنا هستند.1: اکثر آن ها کمی با معماری میکروسرویس آشنا هستند.2: تقریبا نیمی از آن ها با معماری میکروسرویس آشنایی دارند.3: برخی از آن ها کمی با معماری میکروسرویس آشنا هستند.4: خیر هیچ گونه آشنایی ندارند و نیاز به آموزش های زیادی در این زمینه وجود دارد.سوال 7: آیا بستر های لازم برای مهاجرت وجود دارد؟ (مثلا فضای ابر تهیه شده یا ...)0: بله تمامی بستر های لازم برای مهاجرت فراهم شده اند.1: اکثر بستر ها فراهم شده و تهیه برخی بستر ها در دست اقدام می باشد.2: نیمی از بستر ها فراهم شده و تهیه نیمی دیگر در دست اقدام می باشد.3: برخی بستر ها فراهم شده و تهیه اکثر بستر ها در دست اقدام می باشد.4: خیر هیچ بستری برای مهاجرت فراهم نشده است.سوال 8: آیا نقش ها و مسوولیت تیم های مشخص شده است؟0: بله تمامی نقش ها و مسوولیت ها مشخص هستند.1: اکثر نقش ها و مسوولیت ها مشخص شده اند.2: نیمی از نقش ها و مسوولیت ها مشخص شده اند.3: برخی از نقش ها و مسوولیت ها مشخص شده اند.4: خیر هنوز تصمیمی در این باره گرفته نشده است.سوال 9: نرم افزار کنونی چقدر قدمت دارد؟0: کمتر از 2 سال.1: بین 2 تا 4 سال.2: بین 5 تا 7 سال.3: بین 8 تا 10 سال.4: بیش از 10 سال.سوال 10: آیا نوع زبان برنامه نویسی و فناوری های میکروسرویس ها امشخص شده اند؟0: بله زبان ها و فناوری های میکروسرویس ها تمام و کمال مشخص شده اند.1: چندین زبان ها و فناوری ها انتخاب شده اند و برای استفاده از آن ها اطمینان نسبی وجود دارد.2: برخی زبان ها و فناوری ها انتخاب شده اند و برای استفاده از آن ها اطمینان نسبی وجود دارد.3: تعداد کمی زبان ها و فناوری ها انتخاب شده اند و تصمیمی گرفته نشده است.4: خیر هیچ گونه تصمیم یا تحقیقی در این زمینه گرفته نشده است.سوال 11: آیا میکروسرویس ها به صورت حدودی شناسایی شده اند؟0: بله تمامی میکروسرویس ها به طور دقیق شناسایی شده اند.1: اکثر میکروسرویس ها شناسایی شده و تعداد کم باقی مانده در در حال بحث می باشند.2: تقریبا نیمی از آن ها شناسایی شده و نیمی دیگر نیز در حال بحث و مناظره می باشند.3: تعداد کمی (در حد یک یا دو) میکروسرویس شناسایی شده و عمده آن ها شناسایی نشده اند.4: خیر هیچ تحلیل و اقدامی برای شناسایی میکروسرویس ها صورت نگرفته است.سوال 12: آیا پروتکل های ارتباطی میان میکروسرویس ها (مثل REST یا صف) مشخص شده اند؟0: بله پروتکل ها به صورت دقیق و واضح مشخص شده اند.1: اکثر پروتکل ها مشخص شده اند و مابقی نیز در حال مشخص شدن هستند.2: تقریبا نیمی از پروتکل های ارتباطی مشخص شده اند.3: برخی پروتکل ها مشخص شده اند و اکثر آن ها هنوز مشخص نشده اند.4: خیر هنوز هیچ تصمیمی درباره نوع پروتکل های ارتباطی گرفته نشده است.خروجی:برای نتیجه گیری باید اعداد را با هم جمع کرد که تفسیر عدد حاصل جمع به شرح زیر است:بین 0 تا 12: مهاجرت به معماری میکروسرویس احتمالا بدون هیچ مشکل و خرج اضافه انجام خواهد شد و می توان از همین الان فرآیند مهاجرت را با در نظر داشتن چالش های احتمالی پیش رو شروع کرد.بین 13 تا 24: مهاجرت به معماری میکروسرویس با مشکلات جزیی همراه خواهد بود که وجود متخصصین ماهر در زمینه میکروسرویس ها کمک می کند تا این موانع و مشکلات در حین مهاجرت کمرنگ تر شوند. بهتر است در حین مهاجرت یک سری مرور های فنی و به صورت دوره ای انجام بگیرد.بین 25 تا 36: مهاجرت به معماری میکروسرویس با ریسک بالایی همراه است و توصیه می شود اگر سیستم کنونی مشکل خاصی ندارد با همان ادامه داده شود در غیر این صورت حتما قبل از مهاجرت باید یک تیم شامل متخصصین در حوزه میکروسرویس تشکیل شود که تمام انرژی خود را روی مهاجرت می گذارند و ریسک های مهاجرت را بررسی و پوشش می دهند.بین 37 تا 48: مهاجرت به معماری میکروسرویس در مقطع کنونی اصلا به صلاح نیست و نه تنها باعث سود نمی شود، بلکه به سازمان ضررهای عمده نیز وارد می کند. این سیستم هم اکنون توانایی تبدیل شدن به چند سرویس را ندارد و باید یک بازنگری در تصمیم در خصوص مهاجرت بشود.گرچه لازم به ذکر است که می توان دسته بندی های دیگری نیز روی عدد بدست آمده داشت اما آن چه مهم است عددی است که نهایتا به دست می آید که یک دید کلی به معمار نرم افزار می دهد.6. نتیجه گیری و کارهای آیندهدر این تحقیق سعی کردیم تا ابتدا علل مهاجرت به معماری میکروسرویس را بیان کرده و سپس چالش های موجود در فرآیند مهاجرت به معماری میکروسرویس را از جنبه های مختلف با هم بررسی کنیم. در نهایت 12 سوال ارائه کردیم که معمار نرم افزار به کمک آن سوال ها می تواند یک تصمیم درست تری برای مهارت یا عدم مهاجرت به معماری میکروسرویس بگیرد. اما برای ادامه کار نیاز است تا پروژه های عملی بیشتری مورد بررسی قرار بگیرند تا این 12 معیار پخته تر و کامل تر بشوند و جواب نهایی به واقعیت نزدیک تر باشد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابع[1] Ponce, Francisco, Gastón Márquez, and Hernán Astudillo. "Migrating from monolithic architecture to microservices: A Rapid Review." 2019 38th International Conference of the Chilean Computer Science Society (SCCC). IEEE, 2019.[2] Fritzsch, Jonas, et al. "Microservices migration in industry: intentions, strategies, and challenges." 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2019.[3] Di Francesco, Paolo, Patricia Lago, and Ivano Malavolta. "Migrating towards microservice architectures: an industrial survey." 2018 IEEE International Conference on Software Architecture (ICSA). IEEE, 2018.[4] Freire, Augusto Flávio AA, et al. "Migrating production monolithic systems to microservices using aspect oriented programming." Software: Practice and Experience 51.6 (2021): 1280-1307.[5] Agarwal, Shivali, et al. "Monolith to Microservice Candidates using Business Functionality Inference." 2021 IEEE International Conference on Web Services (ICWS). IEEE, 2021.[6] Desai, Utkarsh, Sambaran Bandyopadhyay, and Srikanth Tamilselvam. "Graph neural network to dilute outliers for refactoring monolith application." Proceedings of 35th AAAI Conference on Artificial Intelligence (AAAI’21). 2021.[7] Newman, Sam. Monolith to microservices: evolutionary patterns to transform your monolith. O'Reilly Media, 2019.[8] PoojaParnami, AmanJain, and Navneet Sharma. "From Monolith to Microservice Architecture." Journal of Network and Innovative Computing 5.2017: 020-024.[9] Krause, Alexander, et al. "Microservice decomposition via static and dynamic analysis of the monolith." 2020 IEEE International Conference on Software Architecture Companion (ICSA-C). IEEE, 2020.[10] Nunes, Luís, Nuno Santos, and António Rito Silva. "From a monolith to a microservices architecture: An approach based on transactional contexts." European Conference on Software Architecture. Springer, Cham, 2019.[11] Mendonça, Nabor C., et al. "Developing self-adaptive microservice systems: Challenges and directions." IEEE Software 38.2 (2019): 70-79.[12] Baškarada, Saša, Vivian Nguyen, and Andy Koronios. "Architecting microservices: Practical opportunities and challenges." Journal of Computer Information Systems (2018).[13] Wang, Yingying, Harshavardhan Kadiyala, and Julia Rubin. "Promises and challenges of microservices: an exploratory study." Empirical Software Engineering 26.4 (2021): 1-44.[14] Kazanavičius, Justas, and Dalius Mažeika. "Migrating legacy software to microservices architecture." 2019 Open Conference of Electrical, Electronic and Information Sciences (eStream). IEEE, 2019.[15] Bogner, Justus, et al. "Assuring the evolvability of microservices: insights into industry practices and challenges." 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2019.[16] Yarygina, Tetiana, and Anya Helene Bagge. "Overcoming security challenges in microservice architectures." 2018 IEEE Symposium on Service-Oriented System Engineering (SOSE). IEEE, 2018.

آشنایی با API Gateway

احسان رزازیان — Mon, 13 Dec 2021 21:31:50 +0330

مقدمه:در این پست قصد داریم تا با مفهوم API Gateway و کاربرد آن در صنعت نرم افزار آشنا شویم. سپس با مزایا و معایب استفاده از آن آشنا خواهیم شد و بعد از آن، ابزار های متن باز در این حوزه را معرفی خواهیم کرد. توجه داشته باشید که استفاده از API Gateway بیشتر در کنار معماری میکروسرویس رایج است، لذا اگر با معماری میکروسرویس آشنایی ندارید پیشنهاد می کنیم که ابتدا با این مفاهیم یک آشنایی اولیه پیدا کرده و سپس این پست را بخوانید.توضیح API Gateway و کاربرد آن:ابتدا لازم است تا با مفهوم API آشنا بشویم. واژه API مخفف Application Programming Interface است و برای تبادل اطلاعات از سمت Client ها با Server ها استفاده می شود و مبتنی بر Request/Response است. استفاده از API بیشتر برای توسعه اپلیکیشن های موبایلی و یا در نرم افزار هایی که با معماری سرویس گرا و یا میکروسرویس توسعه داده شده اند رایج است. این API ها می توانند با پروتکل REST یا SOAP یا سایر پروتکل ها باشند. همچنین می تواند داده ها را در قالب JSON یا XML یا سایر فرمت ها در اختیار Client ها قرار بدهند. اکثر اپلیکیشن های موبایلی و اکثر سایت هایی که Backend آن ها با معماری میکروسرویس توسعه داده شده است از API استفاده می کنند.حال فرض کنید که یک اپلیکیشن فروشگاهی داریم که Back-End آن با معماری میکروسرویس نوشته شده است. در این اپلیکیشن، صفحه مربوط به جزییات یک محصول را باز می کنیم. در صفحه جزییات محصول، اطلاعات مختلفی از جمله موارد زیر وجود دارد که هر کدام به کمک API از یک میکروسرویس دریافت می شود:عکس و قیمت محصول که از میکروسرویس اطلاعات محصولات گرفته می شود.لیست نظرات که از میکروسرویس نظرات گرفته می شود.لیستی از محصولات مشابه آن کالا که به کاربر پیشنهاد داده می شود و از میکروسرویس پیشنهاد دهنده محصولات مشابه می شود.اگر نخواهیم از API Gateway استفاده کنیم، باید سه تا Request مختلف به سه میکروسرویس مختلف که در بالا اسمشان ذکر شد بزنیم و Response هر کدام از آن میکروسرویس ها را دریافت کرده و در جایی که در صفحه جزییات محصول برای آن قسمت قرار داده شده است تعبیه کنیم. در این صورت هر کدام از Client ها باید به هر کدام از میکروسرویس ها یک درخواست مطابق شکل زیر بزنند:بدون استفاده از API Gateway همانطور که مشاهده می شود تعداد زیادی درخواست در جریان است. نکته منفی دیگری که می تواند وجود داشته باشد این است که هر کدام از این وب سرویس ها ممکن است با یک تکنولوژی خاص پیاده سازی شده باشند، مثلا ممکن است میکرسرویس اطلاعات محصول، با SOAP پیاده سازی شده باشد و داده ها را در فرمت XML خروجی بدهد و میکرسرویس نظرات با REST پیاده سازی شده باشد و داده ها را در فرمت JSON خروجی بدهد. در این صورت Client باید مدام فرمت ها را به فرمت دلخواه خودش تبدیل کند که زمان گیر و گاها سخت است.اینجاست که API Gateway کاربرد خودش را نشان می دهد. اگر از API Gateway استفاده کنیم، دیگر نیازی نیست تا سه تا API را صدا بزنیم، بلکه یک بار درخواستمان را به API Gateway می فرستیم و API Gateway خودش این موضوعات را مدیریت می کند. ساز و کار کلی API Gateway در شکل زیر مشخص است:با استفاده از API Gatewayهمانطور که در شکل فوق مشخص است، Client ها به جای اینکه هر بار سه بار به هر کدام از میکروسرویس ها Request بزنند، یک بار به API Gateway درخواست می دهند و API Gateway این درخواست ها را به سه میکروسرویس مربوطه زده و در صورتی که نیاز به تبدیل فرمت هم باشد این کار را انجام داده و خروجی را به Client ها می دهد.در این مثال سه تا Request به API های مختلف زده می شد که خودش عدد نسبتا زیادی است، اما تصور کنید که سایت یا اپلیکیشن دیگری داشته باشیم که در آن Client باید برای جمع آوری اطلاعات یک صفحه، تعدادی زیادی Request مثلا 7 یا 8 تا یا بیشتر Request بزند. (در سایت های بزرگی که از API استفاده می کنند واقعا این اتفاق می افتد و بعید نیست) در این صورت مشکلات زیادی از جمله افت کارآیی و کاهش سرعت و استفاده زیاد از منابع و سخت بودن مدیریت پاسخ های دریافتی به وجود خواهد آمد. توجه داشته باشید که می توان برای هر نوع Client یک API Gateway مخصوص خود آن Client را تعریف کرد، این کار مزیت های دیگری به همراه دارد:استفاده از چندین API Gatewayبه عنوان مثال کاربران اپلیکیشن موبایل، کاربران سامانه های تحت وب و یا سایر اپلیکیشن ها و برنامه ها از API Gateway مختص خودشان استفاده می کنند. چون ممکن است اطلاعاتی که در یک صفحه از اپلیکیشن موبایل یک فروشگاه نشان داده می شوند، با اطلاعاتی که در یک صفحه از سایت همان فروشگاه نشان داده می شود تفاوت داشته باشد.اما فرض کنید که یکی از سرویس ها در دسترس نباشد و API Gateway نتواند تمام داده های مرود نیاز را جمع آوری کند، آن وقت تکلیف چیست؟ آیا باید کلا خطا برگردانده شود؟ پاسخ "خیر" است، چنانچه یکی از سرویس ها فعال نباشد و پاخی ندهد (مثلا سرویس نظرات به درستی لیست نظرات را ندهد و دچار خطا شده باشد)، آن گاه خود API Gateway باید چاره ای بیندیشد تا این خطا را مدیریت کند. مثلا لیست خالی برگرداند و یا اعلام کند که دریافت داده های این بخش با خطا مواجه شد و در نهایت هر اطلاعاتی را که توانسته است به دست بیاورد را به Client برگرداند.به طور کلی در نرم افزار های مقیاس وسیع که با معماری میکروسرویس توسعه داده شده اند استفاده از API Gateway پیشنهاد می شود و استفاده از آن مزیت های زیادی به همراه دارد که در ادامه برخی از آن ها را با هم خواهیم دید.مزایای استفاده از API Gateway:کاهش پیچیدگی: به کمک API Gateway دیگر نیازی به تبدیل فرمت های مختلف داده به یکدیگر و یا parse کردن چند مدل فرمت داده نیست. همچنین مسیریابی API ها و درک منطق آن ها نیز از رو دوش Client ها برداشته می شود و به API Gateway سپرده می شود. همچنین فرآیند احراز هویت Client ها و روال دریافت توکن هم کوتاه تر می شود.افزایش امنیت: از آنجایی که API Gateway بین برنامه‌هاط و میکروسرویس‌ها قرار می‌گیرد، به عنوان یک مانع امنیتی عمل می‌کند و مطمئن می‌شود که API های حساس و مهم در معرض دید قرار نگیرند. همچنین از API میکروسرویس ها در برابر بردارهای حمله مخرب مانند حملات DoS و SQL Injection و چندین حمله مشابه دیگر محافظت می کند.کاهش تعداد درخواست ها: استفاده از API Gateway باعث می شود تا تعداد درخواست هایی که Client ها باید برای دریافت داده ها داشته باشند کاهش بیاید و فقط یک درخواست به API Gateway زده می شود. در صورتی که قبل از استفاده از API Gateway باید هر کدام از API های میکروسرویس ها را به صورت جداگانه صدا می زدیم.فراهم کردن امکان رصد و آنالیز: برخی از API Gateway ها با ابزارهایی برای تحلیل و نظارت دارند که به توسعه‌دهندگان کمک می‌کنند تا آسان تر اشکال‌زدایی کنند.اما استفاده از API Gateway معایبی نیز به همراه دارد که با آن ها آشنا می شویم.معایب استفاده از API Gateway:به وجود آمدن نقطه شکست: هنگامی که از API Gateway استفاده می کنیم، یک نقظه شکست یا Single Point Of Failure به وجود می آید. این به این معنی است که اگر روزی API Gateway دچار خرابی شود، آن گاه Client ها دیگر به هیچ کدام از سرویس ها دسترسی نداشته و در نتیجه کل سیستم از کار خواهد افتاد.امکان کم شدن کارآیی: همان طور که استفاده از API Gateway می تواند باعث افزایش کارآیی بشود، می تواند در برخی موارد نتیجه برعکس نیز داشته باشد. مثلا ممکن است وقتی تعداد درخواست ها زیاد می شود، API Gateway نتواند به خوبی و با سرعت درخواست ها را انتقال بدهد. به طور کلی استفاده از API Gateway یک مرحله به فرآیند Request/Response اضافه می کند. برای مواجه با این مشکل باید از API Gateway ای استفاده کنیم که قدرتمند و توانمند باشد.معرفی برخی از API Gateway های متن‌باز:ابزار Kong Gateway:ابزار Kong Gateway یک API Gateway متن باز و سبک و سریع می باشد. این ابزار با زبان Lua نوشته شده است و با کمک Nginx اجرا می شود. ابزار Kong این تضمین را به کاربردان داده است که عملکرد خوبی را برای همه برنامه‌هایی که بر پایه میکروسرویس نوشته شده اند ارائه می دهد. این ابزار با انواع RESTFUL API ها سازگار است و می تواند از طریق ماژول ها و افزونه ها گسترش نیز بیابد و با انواع تکنولوژی ها سازگار است. از مهم ترین مزیت های این ابزار می توان به داشتن Admin API اشاره کرد. به طور کلی ساز و کار Kong به شکل زیر است:امکانات ابزار Kong Gatewayهمانطور که در شکل فوق مشخص است، استفاده از Kong (قسمت سمت راست شکل) باعث شده تا قابلیت ها یک جا تجمیع شوند که این باعث کار کردن راحت تر می شود و مزایای زیادی را به همراه دارد. ابزار Kong مزیت ها و ویژگی های بسیار زیادی دارد که برخی از این ویژگی ها عبارت اند از:قابلیت استفاده از آن در محیط های مختلف از جمله Cloud و Serverlessداشتن امکان احراز هویت (Authentication)تبدیل فرمت ها و پروتکل ها (Transformations)قابلیت متعادل سازی بار (Load Balancing) به کمک الگوریتم های مختلفامکان رصد کردن آنلاین (Live Monitoring)امکان تشخیص عیب و برطرف سازی آن به صورت خود کار (Debugging)و ...ابزار Apigee:این ابزار در سال 2004 ساخته شد که بعده ها گوگل آن را خریداری کرد و هم اکنون یکی از سرویس های گوگل در حوزه API است که طرفداران زیادی دارد. استفاده از این ابزار بسیار راحت است و از لحاظ امنیت بسیار قوی است و با انواع پلتفرم ها سازگاری دارد. این ابزار مزایای زیادی دارد که برخی از آن ها عبارت اند از:امنیت بالا: به کمک این ابزار می توان دسترسی به خدمات موجود را برای جلوگیری از دسترسی غیرمجاز کنترل کرد.سازگاری: به کمک این ابزار خدمات محصولات مختلف در پلتفرم ها و دستگاه های مختلف کار خواهند کرد.قابلیت اندازه گیری: به کمک این ابزار می توان خدمات موجود را برای اطمینان از در دسترس بودن آنها نظارت کرد.ساز و کار کلی این ابزار به شکل زیر است:ساز و کار کلی Apigeeاین ابزار میان برنامه های سمت Cllient و سرویس های Backend قرار می گیرد. سرویس های Backend می توانند شامل ESB و پایگاه داده و غیره باشند. همچنین Client ها نیز می توانند دستگاه های موبایل یا کامپیوتر یا سایر مشتریان باشند.ابزار Apache APISIX:ابزار APISIX ساخت کشور چین است. معاون این پروژه بیان می کند که این ابزار چالش‌های مختلفی که سرویس‌های بومی ابری و میکروسرویس‌ها ایجاد می‌کنند را حل می‌کند. شرکت های معروف مختلفی از جمه از این ابزار استفاده می کنند. این ابزار هم مبتنی بر NGINX است و مزایای زیادی دارد که مهم ترین آن ها عبارت اند از:قابلیت مسیریابی به صورت پویا (Dynamic Routing)سازگاری با Dockerقابلیت مدیریت ترافیکقابیلت احراز هویت (Authentication)قابلیت مدیریت بار (Load Balancing)و ...البته ابزار های متن باز دیگری مانند KrakenD و Gloo Edge و WSO2 و Fusio و Apiman و ... وجود دارند که ما به معرفی سه ابزار معروف فوق اکتفا کردیم.شرکت های ایرانی ارائه دهنده خدمات در زمینه API Gateway:شرکت های درساکلاود (سیستم خبره درسا) و سورنا از جمله شرکت های ایرانی معتبر هستند که در این زمینه فعالیت می کنند. البته این مبحث تقریبا جدید است و در ایران نیز بسیار جای کار و پیشرفت دارد.جمع بندی:استفاده از API Gateway اجباری نیست و بدون آن هم نرم افزار کار می کند اما استفاده از آن مزایا و معایبی را به همراه دارد که با هم دیدیک. لذا باید دقت داشت که در هر نوع سیستم نرم افزاری ای استفاده از آن جایز نیست و تنها وقت هایی که وجود API Gateway باعث افزایش کارآیی و کاهش پیچیدگی می شود باید از آن استفاده کرد. همچنین انتخاب ابزار درست برای این کار بسیار مهم است و بهتر است تا نوسط یک شخص باتجربه انجام بگیرد. اما به طور کلی بهتر است که در مواقعی که نرم افزارمان با معماری میکروسرویس زده شده و تعداد زیادی میکروسرویس داریم از آن استفاده شود. در کل مفهوم API Gateway همچنان جدید است و جای تحقیق و ارتقای بسیار زیادی دارد. امیدواریم که این مطلب برای شما مفید بوده باشد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع:[1] https://www.nginx.com/learn/api-gateway[2] https://dashbird.io/knowledge-base/api-gateway/pros-and-cons-of-using-an-api-gateway[3] https://microservices.io/patterns/apigateway.html[4] https://geekflare.com/api-gateway/#anchor-apache-apisix[5] https://www.baeldung.com/kong[6] https://www.tecmint.com/open-source-api-gateways-and-management-tools/

ابزارهای مدیریت Log در نرم افزار

احسان رزازیان — Sat, 11 Dec 2021 21:25:24 +0330

مقدمه:امروزه بسیاری از افراد و شرکت برای هدف های مختلفی از ابزار های مدیریت Log یا همان Log Management Tool ها در صنعت نرم افزار استفاده می کنند. در این پست قصد داریم تا با کاربرد ابزار های مدیریت Log آشنا شویم و نمونه ای از این ابزار ها را معرفی کنیم. تا کنون ابزار های زیادی برای این منظور ساخته شده اند، یکی از معروف ترین ابزار ها در این حوزه ELK است که آن را به طور مفصل تر معرفی خواهیم کرد.توضیح ابزار های مدیریت Log و کاربرد آن:ابزار های مدیریت لاگ برنامه هایی هستند که داده هایی که توسط اجزا و برنامه های مختلف در یک سرور یا شبکه تولید شده اند را نگهداری و بررسی می کند. از جمله این برنامه ها که باعث تولید Log می شوند می توان به لاگ های سیستمی اعم از لاگ روترها، سوئیچ‌ها، فایروال‌ها، سرورها و پایگاه داده ها و ... اشاره کرد. به طور کلی تر می توان گفت وقتی یک سیستم روشن است، اتفاقات مهمی در سطح سیستم عامل و توسط فرآیند ها و یا برنامه ها یا غیره رخ می دهد. این داده ها توسط ابزارهای مدیریت لاگ تجزیه و تحلیل می شوند. ابزار های مدیریت لاگ مزایای زیادی دارند و برای کاربرد های مختلفی استفاده می شوند. کلیات عملکرد این ابزار ها به این گونه است که پیام هایی که توسط اجزای مختلف تولید شده اند را ذخیره و مدیریت می کنند. برخی از این ابزار امکان بیشتری کانند امکان جستجوی سریع در لاگ ها و یا تحلیل و آنالیز سیستم بر اساس لاگ ها نیز دارند. برخی از آن ها این امکان را دارند هنگامی که یک لاگ به خصوص تولید می شود، یک پیام به یک شخص ارسال می کنند. نمونه ای از لاگ های یک برنامه در شکل زیر مشخص است:نمونه لاگ های یک برنامهلاگ هایی که در این ابزار های مدیریت لاگ ذخیره می شوند، در آینده کاربرد های زیادی خواهند داشت. از جمله این کاربردها می توان به:عیب یابی سریع: اگر خطایی در سیستم رخ دهد، به سادگی با مرور Log های تولید شده می توان علت خطا و منبعی که باعث تولید آن خطا شده است را شناسایی کرد. بالا رفتن امنیت: می توان دید که چه اشخاصی از چه برنامه هایی و در چه زمان هایی استفاده کرده اند و آیا دسترسی های آنان به صورت قانونی بوده است یا خیر. تهیه گزارش از بخش های مختلف سیستم: لاگ ها نشان دهنده اطلاعات زیادی هستند و برای گزارش گیری بسیار مفید هستند. مثلا می توان گزارش گرفت که سیستم عامل کاربران برنامه چیست. مدیریت بهینه تر منابع: با رصد کردن ها می توانیم بفهمم که کدام برنامه ها بیشتر در حال اجرا هستند و نیاز به منابع بیشتری دارند و همچنین می توانیم بفهمیم که کدام برنامه ها کمتر در حال اجرا هستند و نیاز به منابع کمتری دارند. تحلیل شبکه: به کمک لاگ ها می توان ساعاتی که لاگ های بیشتری تولید می شود و شبکه شلوغ تر و پر بازدید تر است را فهمید.و غیره اشاره کرد.اکثر این ابزار ها یک داشبورد زیبا در اختیار کاربران قرار می دهند. برخی از آن ها پولی و برخی رایگان هستند. نکته این است انتخاب ابزار صحیح و مناسب برای مدیریت Log کار آسانی نیست و باید با توجه به عملکرد سیستم و همچنین اندازه سازمان و سیستم ابزار درخور را انتخاب کرد. هر چه تعداد برنامه ها و فرآیند هایی که در حال اجرا هستند بیشتر می شود، با حجم عظیم تری از لاگ ها روبرو خواهیم بود. لذا ابزاری که انتخاب می کنیم باید ظرفیت تعداد لاگ های زیاد و متنوع را داشته باشد.ابزار های متن باز (Open Source) برای مدیریت لاگ:تعداد ابزار هایی که تا کنون برای مدیریت لاگ ها ساخته شده اند بسیار زیاد است و ابزار های متنوع و گوناگونی وجود دارد. در ادامه همین پست چند مورد از آن ها را برسی خواهیم کرد:ابزار ELK:ابزار ELK در واقع ترکیبی از 3 برنامه Elasticsearch و Logstash و Kibana است که هر کدام از آن ها کاربرد خاص خودشان دارند. این ابزار یک ابزار جامع متن باز برای جمع آوری، جستجو و آنالیز لاگ ها است. در شکل زیر اجزای این ابزار نمایش داده شده اند:جزییات ابزار ELKهمانطور که در شکل فوق مشاهده می شود، ابزار ELK که یک ابزار مدیریت لاگ است به طور کلی از 4 بخش عمده تشکیل شده است. در کلمه ELK، حرف E به معنای Elasticsearch و حرف L به معنی Logstash و حرف K به معنی Kibana است که در ادامه با جزییات آن ها آشنا می شویم.بخش ابتدایی همان Log ها هستند. این لاگ ها همان لاگ های اتفاقات رخ داده در سرور هستند که باید در یک جا تجمیع شوند. در قسمت بعد، این لاگ ها به کمک Logstash (که خودش یک ابزار رایگان و منبع باز است) جمع آوری و پردازش می کند و به خروجی مورد نظر برای مرحله بعد تبدیل می کند. داده ها می توانند از سرورهای راه دور با استفاده از ابزاری به نام "beats" به Logstash ارسال شوند. به طور کلی وظیفه Logstash در اینجا جمع آوری لاگ های مختلف از جاهای مختلف سیستم است. بعد از این که داده ها توسط Logstash جمع آوری شد، همان logstash می تواند یک سری فیلتر روی لاگ ها نیز انجام بدهد و سپس خروجی را به Elasticsearch ارسال می کند. مزیت logstash این است که می تواند لاگ های مختلف با فرمت های مختلف را از منابع مختلف جمع آوری و فیلتر کند.در مرحله بعدی Elasticsearch قرار دارد. ابزار Logstash یک ابزار متن باز است که به کمک جاوا در سال 2010 و بر مبنای Restful Api توسعه داده شده است. این ابزار به نوعی یک موتور جستجو و همچنین یک آنالیزور است که می تواند هم با داده های ساختار یافته و هم با داده های غیر ساختار یافته کار کند. این ابزار قابلیت این را دارد تا جستجو روی داده ها را با سرعت زیادی انجام بدهد. به کمک Elasticsearch می توان حجم زیادی از داده ها را ذخیره کرد و روی آن ها جستجوی سریع انجام داد. در این جا داده ها همان لاگ ها هستند. در این ابزار داده ها با فرمت JSON ذخیره می شوند و می توانند به هر زبانی (انگلیسی، آلمانی یا ...) باشند.در مرحله آخر Kibana که یک داشبورد برای نمایش داده ها است قرار دارد. در Kibana انواع مختلفی از نمودار ها و دیاگرام ها و گراف های زیبا وجود دارد. در واقع Kibana یک داشبورد مدیریتی است که یک نوع front end برای Elasticsearch می باشد. نمونه ای از صفحات Kibana را در شکل زیر می بینیم:نمونه ای از صفحات Kibanaهمانطور که در شکل فوق مشخص است، Kibana آمار و آنالیز های مختلفی را به کمک Elasticsearch ارائه می دهد. به عنوان مثال نشان می دهد که چه درصدی از بازدید کنندگان دارای چه سیستم عامل هایی هستند. همچنین می توان لیست لاگ ها را نیز در این داشبورد نگاه کرد. این ابزار قابلیت های فراوانی دارد، مثلا می توان از لیست لاگ ها گزارش در قالب اکسل تهیه کرد.ابزارهای متن باز دیگری نیز برای مدیرت لاگ وجود دارند که معروف ترین آن ها عبارت اند از:ابزار Graylog: این ابزار در سال 2009 ساخته شد و از پایگاه داده MongoDB برای ذخیره سازی لاگ ها استفاده می کند. این برنامه قابلیت های زیادی برای برنامه نویسان فراهم کرده است که باعث شده تا جذاب بشود، مثلا اطلاعاتی نظیر زمان هایی که Request ها بیشتر است یا خطاهایی که رخ داده می دهد و همچنین یک سری پیشنهاد برای تغییر دادن کد جهت بالا رفتن کارآیی میدهد. از جمله معایب این ابزار می توان به این مورد اشاره کرد که در سیستم عامل ویندوز قابل نصب و استفاده نیست.ابزار Fluentd:این ابزار به زبان C نوشته شده است و مستقل از سکو است، یعنی روی تمام سیستم عامل ها از جمله ویندوز و لینوکس اجرا می شود و تحت لیسانس Apache 2.0 است. همچنین این ابزار از قالب JSON برای ساختار دادن به داده استفاده می کند. از جمله مزایای این ابزار می توان به کم حجم بودن آن و انعطاف پذیر بودن آن در تعداد کاربران استفاده کننده از آن اشاره کرد.ابزار NXlog:این ابزار این قابلیت را دارد که گزارش‌های رویدادها را از نقاط متعدد در قالب‌های مختلف از جمله Syslog جمع‌آوری کند. می‌توان NXlog را در دو نسخه دانلود کرد: نسخه Community که دانلود و استفاده از آن رایگان است و نسخه Enterprise یا سازمانی که باید برای کار کردن با آن اشتراک خرید. همچنین این ابزار قابل نصب روی سیستم عامل های معروف است و محدود به یک سیستم عامل نیست.البته ابزار های دیگری نیز وجود دارند اما معروف ترین آن ها همین ابزار هایی بود که با هم دیدیم.شرکت های ایرانی ارائه دهنده خدمات در زمینه Log Management:در سالیان اخیر شرکت هایی در ایران توانسته اند محصولات کارآمد و قوی را برای مدیریت لاگ ها بسازندو در این پست دو تا از معروف ترین این شرکت ها به همراه ابزاری که ساخته اند را معرفی خواهیم کرد:پلتکو: پلتکو یک شرکت دانش بنیان است که در زمینه های مختلفی مانند: "معماری و یکپارچه سازی"، "نظارت و کنترل" و" مستندسازی و گزارش دهی" فعالیت می کند. یکی از محصولات این شرکت ابزار مدیریت لاگ است. جزییات این ابزار را می توانید در این لینک ببینید. پلتکو درباره ضرورت استفاده از ابزار های مدیریت لاگ در سایت خود چنین گفته است:به منظور تحلیل کیفیت و نظارت دقیق‌‌تر بر فرآیند‌های سازمانی نیاز به خواندن، تفسیر و تحلیل مجموعه‌ی وسیعی از لاگ‌ها می‌باشد. این لاگ‌ها شامل لاگ سامانه‌های مختلف درون سازمان، زیرساخت‌های گوناگون و به طور ویژه لاگ‌های مربوط به چرخه زندگی وب سرویس‌ها می‌باشد.از جمله مزایای ابزار مدیریت لاگ پلتکو می توان به قابلیت هایی نظیر: عیب یابی بهتر، تجزیه فایل لاگ، سیستم هشدار، بهبود امنیت و آنالیز و تحلیل داده ها اشاره کرد.برای رفتن به صفحه اصلی سایت پلتکو کلیک کنید.کوالاتک: شرکت کوالاتک در زمینه تست اتوماتیک نرم افزار و تضمین کیفیت فعالیت دارد.جزییات ابزار مدیریت لاگ شرکت کوالاتک را می توانید در این لینک ببینید.کوالاتک درباره ضرورت استفاده از ابزار های مدیریت لاگ در سایت خود چنین گفته است:وقتی حجم نرم افزار کوچک است مشکلی نیست اما وقتی نرم افزار بزرگ و پیچیده است پیدا کردن مشکل کار بسیار سخت و زمان بری است، برای همین باید از ابزاری استفاده کرد تا در این موضوع به برنامه نویسان کمک کند که آن ابزار را مدیریت لاگ (یا Log Management) گویند.از جمله مزایای ابزار مدیریت لاگ پلتکو می توان به قابلیت هایی نظیر: تبدیل لاگ به داده، گزارش گیری، مانیتورینگ و هشدار اشاره کرد.برای رفتن به صفحه اصلی سایت کوالاتک کلیک کنید.آتین: شرکت آتیم یک شرکت دانش بنیان است که فعالیت اصلی آن ارائه خدمات احراز هویت می باشد. محصولات این شرکت اغلب بر پایه مفهوم اراز هویت کاربران است ولی یکی از محصولات آن نیز سیستم مدیریت لاگ و مانیتورینگ کاربران است.آتین درباره ضرورت استفاده از ابزار های مدیریت لاگ در سایت خود چنین گفته است:ممکن است از خود بپرسید ممیزی لاگ چیست و چطور باید از آن استفاده کرد؟ درک نحوه عملکرد ممیزی لاگ و اینکه چرا یک سرپرست سیستم ممکن است بخواهد لاگ های خود را ممیزی کند برای موفقیت در کسب و کار اهمیت زیادی دارد. درواقع مدیریت موثر لاگ و ممیزی ضامن انطباق عملکرد با قوانین و حفظ امنیت سازمان است.از جمله مزایای ابزار مدیریت لاگ پلتکو می توان به قابلیت هایی نظیر: تشخیص سریع قطع شدن شبکه و ایراد در پروتکل، کنترل دسترسی به سرور و خدمات و برنامه های کاربردی، انطباق ممیزی و انطباق با مقررات اشاره کرد. برای رفتن به صفحه اصلی سایت آتین کلیک کنید.جمع بندی:همانطور که دیدیم، ابزار های مدیریت لاگ کاربرد های زیادی دارند. وقتی اندازه یک سازمان بزرگ باشد و تعداد زیادی کاربر داشته باشد، ضرورت استفاده از ابزار های مدیریت لاگ بیشتر خودش را نشان می دهد. ابزار های زیادی، اعم از ابزار های ایرانی، خارجی، رایگان و پولی برای این کار وجود دارند که هر سازمان بهتر است بنا به نیاز خود یکی از آن ها را انتخاب کرده و با آن کار کند.منابع:[1] وبسایت https://stackify.com/best-log-management-tools[2] وبسایت https://www.softwaretestinghelp.com/log-management-software[3] وبسایت https://www.elastic.co/what-is/elk-stack[4] وبسایت https://www.guru99.com/elk-stack-tutorial.html#1[5] وبسایت http://tecmint.ir/2018/06/13/%DB%B4-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%85%D8%AA%D9%86-%D8%A8%D8%A7%D8%B2-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AF-log-%D9%87%D8%A7-%D9%88-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA/[6] وبسایت https://www.linuxhowto.net/5-most-notable-open-source-centralized-log-management-tools/[7] وبسایت https://platco.ir/services/monitoring/log-manager[8] وبسایت https://qualatech.ir/log-managementاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است

آشنایی با Message Queue ها در حوزه نرم افزار

احسان رزازیان — Fri, 10 Dec 2021 15:29:43 +0330

مقدمه:در این مقاله قصد داریم تا Message Queue های نرم افزاری را بیشتر بشناسیم. استفاده از Message Queue ها امروزه بسیار پررنگ تر شده است و نقش مهم تری پیدا کرده است. فلسفه این Message Queue ها همان مفهوم Producer و Consumer است. مهم ترین هدف Message Queue ها در صنعت نرم افزار، ایجاد ارتباط بین سیستم های نرم افزاری مختلف به صورت آسنکرون یا غیرهمزمان است. در ادامه بیشتر با جزییات آن ها آشنا می شویم.توضیح Message Queue و کاربرد آن:یادگیری مفهموم Message Queue را با ذکر یک مثال شروع می کنیم. شاید در فرودگاه ها دیده باشید که وقتی قبل از سوار شدن به هواپیما، به کانتر فرودگاه (یا همام بخشی که چمدان ها را از شما تحویل می گیرند) می روید، یک کارمند نشسته است که چمدان شما را وزن کشی کرده و یک برچسب که حاوی مقصد و زمان تحویل است روی آن گذاشته و به یک ریل در حال حرکت که مابقی کانتر ها نیز به آن دسترسی دارند می فرستد. سپس چمدان شما به یک قسمتی می رود که دیگر آن را نمی بینید!می توان حدس زد که آن طرف این ریل متحرک هم کارمندان هواپیمایی های مختلف نشسته اند که برچسب چمدان ها را نگاه می کنند و مقصد را از روی آن می خوانند و با توجه به مقصد چمدان ها، آن ها را به باربری انتقال می دهند تا به هواپیمای مربوطه برده شوند. حال ارتباط مثال فوق را با Message Queue برسی می کنیم. در مثال فوق چمدان ها حکم Message و ریلی که بین کانتر ها و کارمندان هواپیمایی ها مشترک و در جریان است Queue است و هر کدام از کانتر ها همان Application ها هستند! به همین سادگی! در نرم افزار هم ممکن است تعداد زیادی Application با هم در ارتباط باشند و بخواهند به یکدیگر پیام بفرستند. همچنین وقت نیز برای آنان ازشمند است. مثلا در مثال فوق، چرا خود مسافران نمی روند چمدان هایشان را به کارمندان هواپیمایی تحویل بدهند؟! پاسخ واضح است، چون ممکن است اگر تعداد مسافران خیلی زیاد شود وقت آن ها تلف شود و همچنین ازدحام به وجود بیاید و سردرگم بشوند. اما به کمک ریل، چمدان خود را تحویل داده و به کارهای دیگر می رسند. گرچه در همان کانتر هم باید پشت یک صف معمولا خلوت و کوتاه بایستند اما این صف کجا و آن صف کجا!پس با کاربرد Message Queue آشنا شدیم و فهمیدیم که از Message Queue ها، ایجاد و نگهداری برنامه ها را ساده می کند و باعث کاهش پیچیدگی می شود. البته استفاده از آن اجباری نیست، ولی وقتی که مقیاس نرم افزار بزرگ می شود و تعداد سیستم ها بالا می رود و زمان نیز ارزش پیدا می کند، استفاده نکردن از آن می تواند تبعاتی را در پی داشته باشد (از جمله افزایش پیچیدگی و کاهش بهره وری). مثلا وقتی می خواهیم سوار اتوبوس بشویم تا به یک شهر دیگر برویم، چمدانمان را مستقیم به راننه تحویل می دهیم! چون تعداد مسافران محدود است و کار سریع راه می افتد، اما در فرودگاه تعداد مسافران و پرواز ها زیاد است. اگر نخواهیم از صف استفاده کنیم، راه های دیگر مانند صدا زدن از راه دور (RPC) یا استفاده از پایگاه داده مشترک (Shared Database) هم وجود دارد.حال که با ضرورت Message Queue ها و کلیات نحوه کارکرد آن ها آشنا شدیم، وقت آن است که به جزییات آن بپردازیم. در صنعت نرم افزار، Message Queue های مختلفی ساخته شده اند (مثل Rabbit MQ و Kafka) که هدف اصلی تمام آن ها همین ایجاد ارتباط بین چند برنامه یا سرویس مختلف در بهینه ترین زمان ممکن است. اما اگر بخواهیم ریز تر شویم، هر کدام از آن ها یک سری قابلیت دارند که در مثال های فوق به آن ها اشاره نشد. مثلا ممکن است یک سرویس بخواهد یک پیام را به چند برنامه دیگر بفرستد (یعنی مثلا یک چمدان به چند هواپیما برود!)، این چگونه ممکن است؟ آیا Message Queue های نرم افزاری از این قابلیت ها پشتیبانی می کنند؟ پاسخ "بله" است. این مثال یکی از نمونه های قابلیت های فراوان Message Queue های نرم افزاری بود. در ادامه لازم است تا ابتدا با چند مفهوم تخصصی آشنا شویم، شرح جزییات برخی از این قابلیت های فراوان و جالب برویم. توجه داشته باشید ما Message Queue ای که به عنوان مرجع انتخاب کرده ایم، RabbitMQ است. گرچه این مفاهیم در همه Message Queue ها مشترک است، اما شاید نام هایی که برای عناوین گذاشته شده اند متفاوت باشد.ابتدا با چند مفهوم آشنا می شویم:تولید کننده (Producer): کسی که پیامی را ارسال می کند. به آن Sender هم گفته می شود. صف (Queue): جایی که پیام ها به آن جا می روند. صف حاوی پیام ها است.مصرف کننده (Consumer): کسی که پیامی را دریافت می کند. به آن Receiver هم گفته می شود.عملکرد کلی صفتوجه داشته باشید که یک برنامه، می تواند هم تولید کننده و هم مصرف کننده باشد. در شکل فوق، P یا همان Producer یک پیام را در صف یا Queue قرار داده و C یا همان Consumer، پیام را بر میدارد (مصرف می کند).همانطور که پیش تر گفته شد ممکن است Producer بخواهد 2 پیام را برای 2 تا Consumer مختلف ارسال کند. مثلا پیام شماره 1 برای C1 و پیام شماره 2 برای C2. این امر نیز به راحتی به کمک ارسال این دو پیام به صف قابل انجام است:ارسال دو پیام مختلف به دو مصرف کننده مختلفهمانطور که مشخص است، تولید کننده دو پیام به صف می فرستد و یکی از این پیام ها به C1 و یکی دیگر به C2 می رسد.حال اگر بخواهیم "یک" پیام را به چند مصرف کننده بفرستیم تکلیف چیست؟ توجه کنید که اگر یک پیام را در یک صف قرار دهیم و یک مصرف کننده آن را بردارد، آن پیام دیگر در صف موجود نخواهد بود و مصرف کننده دیگری نمی تواند به آن دسترسی داتشه باشد. در اینجاست که باید از تبادل گر یا Exchange کمک بگیریم که در ادامه با آن آشنا می شویم.تبادل گر (Exchange): یک واسط بین تولید کننده و صف است که قادر است تا پیامی که تولید کننده می دهد را بین یک تا چند صف (بسته به سیاستی که به او گفته می شود) تقسیم کند.حال به کمک Exchange، تولید کننده می تواند یک پیام را به چند مصرف کننده برساند:ارسال یک پیام به تمام مصرف کنندگاندایره آبی رنگ که با X مشخص شده همان Exchange است که نقش واسط را دارد. تولید کننده یک پیام به Exchange می فرستد و می گویید که آن را به تمام صف هایی که به آن متصل هستی ارسال کند. Exchange هم آن پیام را به دو صف قرمز رنگ ارسال کرده و این پیام هم به دست C1 و هم به دست C2 می رسد.اما ممکن است تولید کننده به جای اینکه بخواهد پیام را به تمام صف ها ارسال کند، بخواهد پیام را فقط به تعدادی از صف هایی که Exchange به آن متصل است ارسال کند. اکثر Message Queue های معتبر از این امر پشتیبانی میکنند و اصطلاحا به این کار Routing یا مسیریابی گفته می شود. مثلا تولید کننده می گوید پیام قرمز رنگ را به صف شماره 1 ارسال کن و پیام آبی رنگ را به صف شماره 2 ارسال کن. در این جا است که Exchange باید مسیریابی انجام دهد تا مسیر درست را برای هر پیام تشخیص دهد. مسیریابی چند نوع دارد که انواع آن را در ادامه بررسی می کنیم. انواع مسیریابی:ارسال به همه (type = fanout): وقتی تولید کننده پیامی را به Exchange ارسال می کند، Exchange آن پیام را در تمام صف هایی که به آن متصل هستند قرار میدهد (مانند مثال فوق)ارسال به برخی از صف ها بر اساس کلید (type = direct): پیام ها بر اساس کلید یا binding key آن ها، در صف مربوطه قرار می گیرند. با ذکر یک مثال به کمک کل زیر این مفهوم را بهتر درک می کنیم:ارسال بر اساس binding keyابتدا تولید کننده به هر پیامی که می خواهد آن را به Exchange بفرستد، یک کلید یا Routing Key اختصاص می دهد. در شکل فوق این کلید می تواند یکی از مقادیر "orange" یا "black" یا "green" را داشته باشد. سپس وقتی این پیام به Exchange می رسد، در آن جا بر اساس همان کلید به یک صف ارسال می شود. مثلا Exchange نگاه می کند که اگر کلید یک پیام برابر با "orange" باشد، آن را به صف Q1 می فرستد و اگر "black" یا "green" باشد، آن را به صف Q2 ارسال می کند.ارسال به برخی از صف ها بر اساس الگو (type = topic): در این نوع مسیریابی، پیام ها براساس الگوی شان به صف ها ارسال می شوند. برای آشنایی با الگو ها لازم است تا با دو قاعده زیر آشنا شویم:عبارت * : حرف * در متن الگو به این معنی است که * می تواند با فقط یک کلمه جایگزین شود.عبارت # : حرف # در متن الگو به این معنی است که # می تواند با یک یا بی نهایت کلمه جایگزین شود.با ذکر یک مثال با مفاهیم فوق بهتر آشنا می شویم. شکل زیر را در نظر بگیرید:ارسال پیام براساس topicبا ذکر چند مثال، شکل فوق را بهتر درک خواهیم کرد. اگر یک پیام دارای Routing Key برابر مقادیر زیر باشد، به صف هایی که جلوی آن ها نوشته شده می روند:مقدار کلید برابر quick.orange.rabbit: به Q1 و Q2 می رود. به Q1 می رود چون کلمه وسط آن orange است و به Q2 می رود چون کلمه آخر آن rabbit است.مقدار کلید برابر lazy.orange.elephant: به Q1 و Q2 می رود. به Q1 می رود چون کلمه وسط آن orange است و به Q2 می رود چون کلمه اول آن lazy است (بقیه اش مهم نیست)مقدار کلید برابر quick.orange.fox: فقط به Q1 می رود چون کلمه وسط آن orange است و شروط رفتن به Q2 را ندارد چون نه بخش آخر آن rabbit است و نه بخش اول آن Lazy است.مقدار کلید برابر lazy.brown.fox: فقط به Q2 می رود چون کلمه اول آن lazy است. شرط رفتن به Q1 را ندارد چون کلمه وسط آن orange نیست.مقدار کلید برابر quick.brown.fox: به هیچ کدام نمی رود چون شرط لازم را ندارد.مقدار کلید برابر lazy.green.rabbit: به Q2 می رود چون هر دو شرط را داراست. دقت کنید که دو بار وارد صف نمی شود و فقط یک بار در صف قرار می گیرد.همانطور که دیدیم، می توانیم بسته به سیاستی که تعریف می کنیم، یک پیام را به دست ممصرف کنندگان برسانیم. الگو های دیگری هم وجود دارند که لیست کامل جزییات آن ها در این لینک موجود است. به عنوان مثال می توان پیام ها را براساس پارامتر های مختلفی فیلتر کرد، یا می توان آن ها را رمز نگاری کرد. همچنین می توان برای پیام هایی که به هر دلیلی به گیرنده نرسیده اند (مثلا الگویشان با الگوی هیچ صفی مطابقت نداشته) استراتژی هایی تعریف کرد. می توان یک ددلاین برای رسیدن هر پیام به مقصد تعریف کرد و ... . به طور کلی 65 الگو دراجزای مختلف سیستم (نه فقط Exchange) داریم که در این مقاله با برخی از آن ها آشنا شدیم.نمای کلی این اجزا و الگوها در شکل زیر مشخص است:شمای کلی اجزا و الگو هابرای اطلاعات بیشتر به این لینک بروید.ابزار ها و فناوری های متن باز در زمینه MQ:یکی از ابزار هایی که با آن مثال ها را دیدیم ابزار RabbitMQ بود. اما ابزار های دیگر مانند Kafka هم وجود دارند که در ادامه آن ها را خواهیم دید . با جزییات هر کدام آشنا خواهیم شد:ابزار RabbitMQ:یک ابزار متن باز محبوب است. برای دیدن سایت این ابزار به این لینک بروید. این ابزار نسبتا ساده است و یادگیری مستندان آن آسان است. از معایب آن می توان به این مورد اشاره کرد که سرعت آن کمی کم است. (مخصوصا وقتی حجم پیام ها زیاد می شود).این ابزار از پروتوکل های معروف مثل AMQP و STOMP و MQTT و غیره هم پشتیبانی می کند.ابزار Kafka:ابزار Kafka را Apache توسعه داده است و یک ابزار کامل با قابلیت های بسیار زیاد است. شروع کار و یادیری مستندات آن به نسبت سخت تر است اما سرعت بهتر و قابلیت های بیشتر از جمله مزایای ان است. برای دیدن سایت این ابزار به این لینک بروید.ابزار های دیگری مانند: MuleSoft Anypoint Platform و IBM MQ و Azure Scheduler نیز وجود دارند که هر کدام مزایا و معایب خودشان را دارند.منابع:[1] وبسایت https://www.rabbitmq.com/getstarted.html[2] وبسایت https://www.cloudamqp.com/blog/what-is-message-queuing.html[3] وبسایت https://www.simplilearn.com/kafka-vs-rabbitmq-article?source=frs_left_nav_clicked[4] وبسایت https://www.instaclustr.com/blog/rabbitmq-vs-kafka[5] وبسایت https://kafka.apache.org[6] وبسایت https://en.wikipedia.org/wiki/Message_queue[7] وبسایت https://www.cloudamqp.com/blog/what-is-message-queuing.html[8] وبسایت https://aws.amazon.com/message-queue[9] وبسایت https://www.enterpriseintegrationpatterns.com/patterns/messagingاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است

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

احسان رزازیان — Thu, 09 Dec 2021 12:25:33 +0330

مقدمه:شاید تا کنون واژه BPMS را شنیده باشید و برایتان این سوال پیش آمده باشد که BPMS چیست؟ ابتدا باید بگوییم که واژه BPMS، مخفف عبارت Business Process Management Systems (یا همان سیستم مدیریت فرآیند کسب و کار) می باشد. BPMS یک نوع سیستم نرم افزاری است که برای تسهیل و بهبود کیفیت فرآیندهای کسب و کار یک سازمان استفاده می شود. در واقع BPMS یک نوع ابزار و سیستم است که به کمک آن BPM (یا همان مدیریت فرآیند کسب و کار) یک سازمان تحقق می یابد و اتوماسیون اداری راحت تر می شود. همچنین اموری مانند تحلیل، مدل سازی، پیاده سازی و نظارت بر فرآیندهای کسب و کار را آسان تر می کند. در ادامه بیشتر با جزییات BPMS آشنا می شویم.توضیح BPMS و کاربرد آن:قبل از اینکه به سراغ جزییات دقیق تر BPMS برویم، لازم است با واژه BPM که مخفف Business Process Management آشنا شویم.واژه BPM به معنی مدیریت فرآیند های کسب و کار است و یک رویکرد کلی است که شامل یک سری روش ها و تکنیک هایی است که بتوان به کمک آن ها فرایند ها را مدیریت کرد و کارآیی را در یک سیستم افزایش داد. این تکنیک‌ها و روش‌ها اغلب برای شناسایی، مدل‌سازی، تحلیل، اصلاح، بهبود و استاندارد کردن فرآیندهای کسب‌وکار استفاده می‌شوند. حال BPMS یک سیستم نرم افزاری است که این روش ها در آن پیاده سازی می شوند ئ به کمک آن، به BPM عینیت بخشیده می شود.همانطور که گفته شد BPMS یک نوع سیستم مدیریتی است که برای اهداف مختلف مورد استفاده قرار می گیرد. از جمله این امکانات می توان به امکان مدلسازی، ایجاد، ویرایش و اجرای تمام فرآیندهای کسب و کار در یک سازمان همچنین جمع آوری داده ها و تجزیه و تحلیل ها (از طریق یک پرتال و رابط کاربری که در اختیار کاربران قرار می گیرد) اشاره کرد. اشخاص و سیستم های مختلف می توانند به این سیستم ها متصل شوند و از امکانات آن استفاده کنند. شمای فنی BPMS را در شکل زیر می بینیم:شمای فنی BPMSدر شکل فوق نکات زیادی وجود دارد که آن ها را بررسی می کنیم. اشخاص و سیستم های مختلفی می توانند به یک BPMS وصل شوند، مانند: مشتریان، کارمندان فروش، ذی النفعان، کارفرمایان، مدیران، سیستم مدیریت ارتباط با مشتری (CRM)، سیستم مدیریت سیاست ها، رصد کننده فنی، رصد کننده کسب و کار و ... .نکته جالب توجه ای که در شکل فوق وجود دارد این است که خود ذی النفعان و کارفرمایان و مدیران می توانند در تعریف فرآیند های کسب و کار دخیل باشند و مشارکت کنند. همانطور که مشخص است، در داخل هسته ی BPMS کار های مختلفی از جمله همنواسازی سرویس ها، مدیریت فرآیند های کسب و کاری و یکپارچه سازی سرویس های کسب و کار از طریق یک پورتال که در اختیار کاربران قرار گرفته است صورت می گیرد. افراد فنی نیز می توانند از طرف دیگر رخداد ها را مانیتور کنند. همچنین سرویس های مختلف مانند CRM ها نیز می توانند با این سیستم تبادل اطلاعات داشته باشند. اما معمولا استفاده از این نوع ابزار ها مراحلی دارد که باید به ترتیب طی شوند تا نتیجه مطلوب تری حاصل شود. شماتیک این مراحل در شکل زیر مشخص است:ساز و کار BPMSجزییات این مراحل و اقدامات عبارت اند از: گام اول: تعریف فرآیند هافرآیند به دنباله ای از فعالیت ها گفته می شود که برای دستیابی به یک نتیجه خاص اجرا می شوند. توجه داشته باشید که فرآیند های کسب و کار (business process) را با قواعد کسب و کار (business rules) اشتباه نگیرید. فرآیند به نحوه ارتباطات و ترتیب انجام کار ها اشاره دارد اما قواعد کسب و کار یک سری قانون هستند که باید در حین انجام فرآیند ها رعایت شوند و از آن ها سرپیچی نشود. قبل از خودکارسازی گردش کار، باید برای فرآیندها مستندات تعریف کنیم. توجه داشته باشید که در مستندات باید شکل های زیادی وجود داشته باشند و مستندسازی مستلزم همکاری و برنامه ریزی بین ذینفعان است. سپس می توان جریان های فرآیند کسب و کار را در یک سیستم مدیریت فرآیند کسب و کار تعریف کرد. این جریان ها باید توسط پرسنل مربوطه بازبینی شود تا این اطمینان حاصل شود که تعریف درستی از فرآیندها شکل گرفته است.گام دوم: طراحی و توسعه فرآیند هاوقتی که مدل های فرآیندی به دست آمد، می‌توان آن ها را به روش‌ها و فرمت های مختلفی منتشر کرد. در این مرحله معمولا از فرمت های BPMN استفاده می شود. برخی از مدل‌سازهای فرآیند، حالت‌های شبیه‌سازی برای آزمایش سناریوهای فرآیند مختلف را نیز می‌شوند. معمولا ابزارهایی که برای مدلسازی فرآیندهای کسب و کار استفاده می شوند از قالب های فلوچارت و نمودار هم پشتیبانی می کنند. همچنین کاربران می توانند قبل از انتشار آن ها، نقاط ضعفشان را اصلاح کند.گام سوم: خودکارسازیحال نوبت آن رسیده تا گردش کار های تکراری خودکارسازی شوند. در این مرحله کارهایی که به صورت روزانه و تکراری در سازمان انجام می شدند خودکارسازی می شوند و تحت یک سیستم که دارای قوعد و منطق مشخص است اجرا می شوند تا از انجام کار های تکراری کاسته شود. خودکارسازی گردش کار ها به کسب و کارها کمک می کند تا فرآیندهای خود را بهتر مدیریت و بهینه کنند.گام چهارم: تجزیه و تحلیلابزارهای BPMS گزارشات مختلفی را ارائه می دهند. این گزارش ها به KPI ها (شاخص های کلیدی عملکرد) هم وابسته هستند و اطلاعاتی را را در مورد عملکرد اقدامات فردی، فرآیندها، اعضای فرآیند و ... ارائه می دهند. تجزیه و تحلیل می تواند گلوگاه های فرآیند را شناسایی کند و فرصت هایی را برای بهبود مستمر فرآیند فراهم کند.مزایا و معایب استفاده از BPMS:استفاده از هر ابزاری مزایا و عایبی را به همراه دارد. در ادامه با مزایا و معایب BPMS آشنا می شویم.مزایای BPMS:1. کاهش ریسک: محیط کسب و کار ها در داخل بسیاری از سازمان ها در حال تغییر است. از این رو سازمان ها مستعد اشتباهاتی هستند که ممکن است کارایی آن سازمان را تحت تاثیر قرار دهد. داشتن یک ابزار BPM به بخش مدیریت اجازه می دهد تا بر استفاده از منابع نظارت کند. مدیران همچنین می‌توانند افراد یا اجزای ناکارآمد را شناسایی کنند.2. کنترل سازمانی بهتر: به کمک BPMS، بخش مدیریت سازمان از اتفاقاتی که درون سازمان می افتد آگاهی بهتری دارد. این مزیت در سازمان های متوسط و بزرگ که دارای نیروی کار های زیاد و دپارتمان های متعددی هستند بیشتر به چشم می آید. برای اداره کردن این نوع سازمان ها، تنظیم فرآیندهایی که باید توسط همه کارکنان دنبال شود بسیار مهم است. یک BPMS کنترل این فرآیندها را آسان تر می کند.3. بهینه تر شدن فرآیند ها: با مرور کلی عملیاتی که در سازمان انجام شده اند، مدیران می توانند آنهایی را که ناکارآمد هستند را شناسایی کنند و اخراح کنند (یا بهشان آموزش بدهند). همچنین ویرایش خود فرآیند ها نیز آسان تر خواهد بود چرا که BPMS ها معمولا یک محیط گرافیکی در اختیار کاربران و مدیران قرا می دهند که کا با آن خیلی آسان است.4. افزایش چابکی: به کمک این ابزار ها، تنظیم و تغییر فرآیندهای تجاری بسیار آسان شده است. لذا یک سازمان راحت تر و سریع تر می تواند خودش را با تغییرات وفق دهد.5. افزایش همکاری: بسیاری از کسب و کارها در برقراری ارتباط بین بخش ها یا دپارتمان های مختلفشان با مشکلات متعددی مواجه هستند. با BPMS، فرآیندها می توانند با وضوح بیشتری ارتباط برقرار کنند، زیرا شمای آن ها برای همه در دسترس است. هر زمان که شخصی به دنبال مسئول بخش خاصی از فرآیند است، می‌تواند با جستجو در ابزار، او را بیابد.6. خودکارسازی گردش کار ها: با استفاده از ابزارهای BPM، مدیران می توانند گردش کار های مختلف را مدیریت کنند و نهایتا می توانند تصمیم بگیرند که کدام یک می تواند خودکار باشد و آن ها را خودکار کنند.7. خوشحال تر شدن کارکنان: در نهایت، اهداف، فرآیندها و مسئولیت‌های هر بخش روشن و شفاف می شود که این امر باعث می‌شود تا کارکنان شاد و راضی باشند. اعضای تیمی که در محیط‌های کاری با ساختارهای شفاف کار می‌کنند، بهره‌ورتر و شادتر هستند، زیرا وظایف محوله خود را زیر سؤال نمی‌برند. ابزارهای BPM به ایجاد فرآیندها و شفاف تر شدن اسناد کمک می کند که این به کارکنان اجازه می دهد تغییرات را در سازمان درک کنند.معایب BPMS:1. کاهش انعطاف پذیری: استفاده از BPMS باعث می شود تا ساختار های مشخصی شکل بگیرند که این امر به کارمندان اجازه نمی دهد تا مشکلات را به هر روشی که مناسب می دانند حل کنند و مجبورند از ساختار های تعریف شده تبعیت کنند. این امر خلاقیت در کارمندان و به طور کلی انعطاف پذیری سیستم را کاهش می دهد.2. امکان اتلاف زمان و منابع مالی: نرم افزار های BPMS معمولا رایگان نیستند و سازمان ها باید آن ها را خریداری کنند که قیمت بالایی هم دارند. همچنین شروع استفاده از BPMS آسان نیست و باید به کارمندان آموزش داده شود. این امر معمولاً به کمک مشاوران خارجی نیاز دارد که در مورد ابزارها اطلاعات بیشتری دارند. فرآیند آموزش اولیه ممکن است زمان بر باشد. اگر موارد فوق به خوبی انجام شوند آن زمان است که مزایا BPMS خودشان را نشان خواهند داد.معرفی ابزارهای BPMS:ابزار های زیادی برای مدیریت فرآیند های کسب و کار وجود دارند. معمولا ابزار های BPMS قیمتشان بالا است. در BPMS های متن باز و رایگان (که تعدادشان هم کم است)، قابلیت های کمتری نسبت به BPMS های پولی و شخصی سازی شده برای سازمان یافت می شود. در ادامه چند مورد از هر کدام را بیان می کنیم.ابزارهای BPMS متن باز (رایگان):نرم افزار Process Maker: این نرم افزار از معدود نرم افزار های متن باز BPMS است که برای مدیریت جریان کار و فرآیند های کسب و کار استفاده می شود. ویژگی Drag & Drop در این نرم افزار باعث شده تا کار با آن آسان باشد. بسیاری از شرکت ها در جهان از این نرم افزار استفاده می کنند. می توانید وبسایت این شرکت را در این لینک ببیند.ابزارهای BPMS غیر متن باز (پولی):همانطور که گفته شد تعداد زیادی BPMS غیر رایگان در سطح جهان وجود دارد. اگر بخواهیم از چند تا معروف ترین آن ها اشاره کنیم، میتوانیم به ابزار های: KissFlow , Bizagi , Ninetex , Oracle BPM Suite که خارجی هستند اشاره کنیم. استفاده از این ابزار ها رایگان نیست (گرچه ممکن است چند روز اول استفاده از آن ها رایگان باشد اما با اتمام دوره رایگان باید هزینه پرداخت شود، معمولا به صورت ماهیانه یا سالیانه). مواردی بوده اند که کرک شده اند اما با توجه به این که این نرم افزار ها در سازمان های معتبر و بزرگ استفاده می شوند استفاده از آن ها رایج نیس (بعضا غیرقانونی است) چرا که می تواند مشکلاتی از جمله مشکلات امنیتی و درز اطلاعات را در پی داشته باشد.شرکت های ایرانی فعال در حوزه BPMS:شرکت های بسیار کمی در ایران اقدام به تولید BPMS بومی و کاملا ایرانی کرده اند، اما شرکت هایی در ایران هستند که نسخه های خارجی نرم افزار های فوق را بومی سازی کرده اند. از جمله این شرکت ها می توان به فراگستر و ایران بیزاجی اشاره کرد. شرکت فراگستر، ابزار Process Maker که یک ابزار متن باز خارجی بوده است را بومی سازی کرده است و مشتریان بسیار زیادی نیز دارد. شرکت ایران بیزاجی نیز همانطور که از اسم آن پیداست، نرم افزار بیزاجی (Bizagi) را فارسی سازی کرده است.جمع بندی:ابزار های BPMS به خودکارسازی فرآیند ها و گردش کار یک سازمان یا ارگان بزرگ کمک زیادی می کند. این نوع پلتفرم ها به سازمان های بزرگ کمک می‌کند چرخه تحول خود را تسریع کنند و نوآوری بیشتری داشته باشند و سریع‌تر خودشان را با دنیای بیرون تطبیق دهند. همچنین این ابزار ها کمک می کنند که میزان کارآیی افرادی که عضو سیستم هستند سنجیده شود. به کمک BPMS، از بسیاری از هزینه ها و اتلاف وقت ها نیز جلوگیری می شود که چرا که تمام فرآیند های کاغذی حذف می شوند. در کل استفاده از BPMS برای سازمان هایی که فرآیندهای زیادی درون آن ها اتفاق می افتد و مدیریت آن ها به صورت کاغذی سخت است پیشنهاد می شود، مثل بانک ها.منابع:[1] وبسایت https://kissflow.com/workflow/bpm/what-is-bpms[2] وبسایت https://www.creatio.com/page/bpms[3] وبسایت https://www.integrify.com/what-is-bpms[4] وبسایت https://www.tibco.com/reference-center/what-is-bpms[5] وبسایت https://softwarehut.com/blog/business/benefits-of-bpm[6] وبسایت https://kissflow.com/workflow/case/bpm-vs-case-management[7] وبسایت https://www.faragostar.net/automation/bpms[8] وبسایت https://jaryansoft.comاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است

معرفی ESB (Enterprise Service Bus)

احسان رزازیان — Tue, 07 Dec 2021 18:52:44 +0330

مقدمه:در این مقاله می خواهیم ESB که مخفف Enterprise Service Bus است را معرفی کنیم. ESB به معنای "گذرگاه سرویس سازمانی" است. به طور کلی کاربرد ESB این است که به یکپارچه سازی برنامه ها و خدمات متنوع در یک سازمان و همچنین توزیع کار بین اجزای متصل یک برنامه کمک می کند. ESB مجموعه ای از قوانین و اصول برای ادغام برنامه های کاربردی متعدد با هم بر روی یک گذرگاه است. در واقع می توان گفت که ESB یک نوع الگوی معماری است. ESB می تواند این ادغام ها و تبدیل ها را به عنوان یک رابط سرویس برای استفاده مجدد توسط برنامه های کاربردی جدید در دسترس قرار دهد. در ادامه به طور مفصل تر ESB را تشریح خواهیم کرد.توضیح ESB و کاربرد آن:فرض کنید چندین برنامه داریم که می خواهند با یکدیگر ارتباط برقرار کنند و از امکانات یکدیگر استفاده کنند. یکی از روش ها این است که هر برنامه آن یکی را صدا بزند. این باعث شلوغی و پیچیدگی سیستم می شود. اما به کمک ESB، یک گذرگاه میان سازمانی تعریف می شود که برنامه های مختلف روی آن گذرگاه قرار می گیرند و با یکدیگر یکپارچه می شوند. سپس هر برنامه قادر می شود که با آن گذرگاه صحبت کند. مصداق این جمله را در شکل زیر می بینیم:نمای کلی ESBهمانطور که در شکل فوق مشخص است، هر برنامه با یک پروتکل که با پروتکل برنامه های دیگر متفاوت است (HTTP یا MQ یا ...) به ESB متصل است. ساز و کار کلی ESB این گونه است که سرویس گیرنده ابتدا درخواست‌هایش را به ESB که یک نوع واسط است می زند (با پروتکل های مختلف). سپس ESB درخواست‌ها را به مسوول (سرویس) مربوطه ارجاع داده و پاسخ را از آن دریافت میکند. در نهایت پاسخ دریافتی را به سرویس گیرنده ای که درخواست زده تحویل می‌دهد.به این ترتیب سیستم‌ها را از یکدیگر جدا می‌شوند و به آن‌ها اجازه داده میشود تا بدون وابستگی یا آگاهی از سیستم‌های دیگر، در گذرگاه ارتباط برقرار کنند. به این ترتیب دیگر نیازی به یکپارچه سازی ارتباطات به صورت Point to Point یا 2 به 2 نیست. لازم به ذکر است که یکپارچه سازی به روش 2 به 2 معایبی دارد که از جمله این معایب می توان به عدم قادر بودن کنترل مرکزی و افزایش پیچیدگی اشاره کرد. شاید این سوال برای شما نیز پیش آمده باشد که ESB برای چه سازمان هایی مناسب است؟ در پاسخ باید بگوییم که ESB برای سازمان های بزرگی که خدمات و وب سرویس های متعدد و گوناگونی ارائه می کنند و یا زیرشاخه های متعددی دارند مناسب است. مثلا بانک ها نمونه ای از این سازمان ها هستند که خدمات متنوعی را ارائه می کنند. اگر این سازمان ها از ارائه این وب سرویس ها کسب درآمد نیز داشته باشند آن زمان است که استفاده از ESB حیاتی تر و نقش آن پررنگ تر هم می شود.اما کاربرد ESB چیست؟ فرض کنید که یک سازمان چند وب سرویس مختلف با پروتکل ها و قالب های مختلف ارائه می دهد. دو مفهوم سرویس دهنده و سرویس گیرنده داریم که همانطور که از آن ها مشخص است، اولی یک سری خدمات و سرویس ها و اطلاعات ارائه می کند و دومی یا همان سرویس گیرنده هم از این خدمات یا اطلاعات استفاده می کند. توجه داشته باشید که سرویس گیرندگان هم می توانند داخل سازمان باشند و هم می توانند خارج از سازمان باشند. در این جا ESB به عنوان یک واسط بین وب سرویس های سازمان و سرویس گیرندگان قرار می گیرد و مزایای زیادی را به همراه می آورد. توجه داشته باشید که طیف گشترده ای از سرویس دهندگان و سرویس گیرندگان می توانند از ESB استفاده کنند:اتصال سرویس گیرندگان و سرویس دهندگان به ESBهمانطور که مشخص است، سرویس دهندگان و سرویس گیرندگان با انواع مختلفی به ESB وصل شده اند.معماری ESB یکی از کلیدی ترین اجزا در معماری سرویس گرا است و ترکیب این دو با هم نتیجه مطلوبی خواهد داشت و این دو می توانند مکمل خوبی برای هم باشند. از ESB در معماری سرویس گرا برای یکپارچه سازی استفاده می شود. از مزایای ESB می توان به موارد زیر اشاره کرد: سهولت ارتباطات: به کمک ESB در یک سازمان، ارتباطات تسهیل می شود، چرا که دیگر ارتباط 2 به 2 نداریم و سرویس گیرندگان درگیر پیچیدگی های یکپارچه سازی نمی شوند. آن ها با یکدیگر ارتباط برقرار می کنند اما نه از طریق صدا زدن مستقیم یکدیگر، بلکه از طریق ESB. همچنین وقتی یک وب سرویس تغییری در فرمت داده های خود می دهد نیازی نیست تا سایر سرویس ها در خوشان تغییری ایجاد کنند.تبدیل پروتکل های مختلف به یکدیگر: هنگامی که از ESB استفاده می کنیم میتوانیم به راحتی پروتکل های مختلف (مانند Rest و Soap) را به یکدیگر تبدیل کنیم. این نکته زمانی به چشم می آید که وب سرویس های مختلف با زبان های مختلفی نوشته شده باشند که هر کدام با پروتکل خاصی کار می کنند. آن زمان است ESB به کار می آید و در دل خود پروتکل ها را به یکدیگر تبدیل می کند.افزایش انعطاف پذیری: اضافه و کم کردن و تغییر سرویس ها در طول حیات نرم افزار به کمک ESB راحت تر خواهد بود. افزایش امنیت: وقتی از ESB استفاده می کنیم می توانیم به صورت دقیق رخداد هایی که در سیستم اتفاق افتاده است را رصد کنیم. همچنین هر کدام از سرویس ها احراز هویت شده اند و اگر ببینیم سرویس دارد خارج از چارجوب قوانین عمل می کند مدیریتش کنیم.امکان توزیع بار: به کمک ESB می توانیم Load Balancing انجام بدهیم و منابع را بنا به نیاز میان سرویس های مختلف پخش و مدیریت کنیم. مثلا اگر یک سرویس خیلی کم استفاده می شود منابعش را به سرویس که زیاد استفاده می شود بدهیم.در کنار مزایای ذکر شده، ESB معایبی نیز دارد که از جمله مهم ترین معایب ESB می توانیم به Single Point Of Failure بودن آن اشاره کنیم. این به این معنی است که اگر خطایی در دل ESB رخ دهد، همه سرویس دهندگان و حتی سرویس گیرندگان نیز دچار مشکل خواهند شد چرا که ارتباطات آن ها صرفا از طریق ESB بوده است.توجه داشته باشید که ESB یک Orchestrator نیست و منطق فرآیند ها و چیز هایی از جمله ترتیب صدا زدن ها در آن انجام نمی شود، بلکه ESB فقط یک لایه انتزاعی است و شامل منطق های کسب و کار نیست. این موارد به کمک تکنولوژی هایی مانند BPEL یا BPM انجام می پذیرد که می توان آن ها را به کمک ESB استفاده کرد. اما به کمک این ابزار های می توان روش های یکپارچه سازی ای که مد نظر داریم را انجام دهیم، (در واقع عملکرد اصلی این ابزار ها یکپارچه سازی است). جزییات روش های یکپارچه سازی را می توانید در این لینک ببینید. در ادامه با چند مورد از این ابزار ها آشنا می شویم.ابزار ها و فناوری های متن باز ESB:ابزار هایی مانند MuleSoft و WSO2 ابزار های معروف در حوزه ESB هستند که به کمک آن ها میتوان کارهای مختلفی از جمله: مسیریابی پیام ها، زمان بندی، توزیع بار، Logging، یکپارچه سازی و ... را انجام داد. به عنوان مثال در ابزار WSO2 میتوان REST API های جدید ساخت و یا API های از پیش نوشته شده را Import کرد. ( همچنین تکنولوژی های SOAP و GraphQL و WebSocket هم توسط این ابزار پشتیبانی میشود). سپس میتوان سایر افراد را تعریف و دعوت کرد و برای API ها یک Documentation نوشت. امکانات و مزایا و معایب هر کدام از ابزار های مذکور را با هم بررسی می کنیم:ابزار WSO2:شرکت WSO2 خدمات متنوعی را ارائه می کند که یکی از آن ها ESB مربوط به این شرکت است. شکل زیر صفحه اصلی این وبسایت در این لینک را نشان می دهد:سایت WSO2همانطور که مشاهده می شود در منوی این سایت گزینه ای وجود دارد به نام Enterprise Service Bus. وقتی جزییات آن را باز کنیم می بینیم که لینک دانلود این ابزار را قرار داده است. از مزایای این ابزار می توان به موارد زیر اشاره کرد:پشتیبانی از پروتکل های مختلفی مانند: HTTP و HTTPS و WebSocket و POP و IMAP و SMTP و ...پشتیبانی از فرمت های داده مختلف مانند: JSON و XML و SOAP و EDIFACT و FHIR و ISO 8583 و FIX.امکان اتصال هر نوع پایگاه داده ای به هر جنسی به آن به عنوان یک سرویس.امکان رصد و مانیتور کردن سرویس ها.مسیریابی پیشرفته براساس انواع پارامتر ها.تبدیل پیام ها با XSLT 1.0/2.0، XPath، XQuery و Smooks.و ...ابزار MuleSoft:شرکت MuleSoft نرم افزار یکپارچه سازی را برای اتصال برنامه ها، داده ها و دستگاه ها ارائه می دهد. این شرکت نیز ESB مختص خودش را دارید که در سایت آن و در این قسمت از منو قابل نمایش است:سایت MuleSoftبرخی از مزایای MuleSoft:جدا کردن منطق کسب و کار از پروتکل ها و فرمت های پیام.امکان تقسیم و فیلتر پیام‌ها بر اساس محتوا یا قوانین آن‌ها.امکان تبدیل و انتقال داده‌ها به هر قالبی در پروتکل‌های مختلف.و ...استفاده از این پلتفرم ها مزایای زیادی برای سازمان ها دارد و این سکو ها ارتباط مهندسان نرم افزار و سرویس ها و برنامه های با پلتفرم های مختلف و تعریف جریان های کاری را بر بستر اینترنت راحت تر کرده است.اما این ابزار ها معایبی نیز دارند، به عنوان مثال اگر اطلاعات مربوط به یکی از سازمان ها به سرقت برده شود آنگاه اطلاعات سایر شرکت های مرتبط نیز به خطر خواهد افتاد.برای انتخاب یک سکوی یکپارچه سازی باید فاکتور هایی مانند هزینه، امنیت، مقیاس پذیری، قابلیت استفاده و ظرفیت را در نظر گرفت. این پلتفرم ها معمولا رایگان نیستند و باید با توجه به ROI سازمان سنجید که استفاده از آن ها به صرفه است یا خیر. امنیت پلتفرمی که انتخاب میکنیم بسیار مهم است و اگر اطلاعات حیاتی در سازمان وجود دارد نباید از هر پلتفرمی استفاده کرد. بستری که انتخاب میشود باید قادر باشد تا به سرعت مقیاس یابند و کارآیی نباید قربانی وجود این پلتفرم ها در این اکوسیستم شود. پلتفرم انتخاب شده باید ساده و قابل استفاده باشد و پیچیدگی زیادی اضافه نکند و سریع بالا بیایند. این ابزار باید گنجایش داده زیاد را داشته باشد.شرکت های ایرانی ارائه دهنده خدمات در حوزه ESB:شرکت های مختلفی در ایران خدمات مرتبط با ESB ارائه می کنند که از جمله آن ها می توان به شرکت پلتکو و شرکت داده پرداز پویای شریف اشاره کرد. شرکت پلتکو یک شرکت دانش بنیان است که خدماتی از جمله ESB و ابزار های مدیریت API را ارائه می کند. پلتکو درباره پلتفرم خود در سایتش چنین نوشته است:شرکت داده کاوان تصمیم یار خدمات مختلف نرم افزاری ارائه می‌دهد که یکی از آنها “پلتکو” نام دارد که “پلتفرم یکپارچه سازی و مدیریت وب سرویس” می‌باشد.وبسایت شرکت پلتکو در این لینک موجود است.شرکت داده پرداز پویای شریف نیز یک شرکت دانش بنیان ارائه دهنده راهکار های جاممع تخصصی تحت وب و موبایل است. این شرکت درباره ESB ای که ارائهمی دهد در سایتش چنین نوشته است:پلتفرم ESB داده پرداز یکی از بهترین راهکارها برای یکپارچه سازی انواع سرویس‌ها در سازمان‌های بزرگ و مدیریت نمودن جریان اطلاعات در آنهاست. پلتفرم ESB داده‌پرداز محصولی دانش‌بنیان است که تا به امروز در سامانه‌های بزرگی همچون سامانه فروش بلیط بن ریل، اپلیکیشن خدمت در محل همراه یار، پرتال دولت الکترونیک و ... به کاربرده شده و ویژگی اصلی آن، توانایی برقراری ارتباط با ماکروسرویس‌های بزرگ و برقراری جریان امنیت اطلاعات و مدیریت آنهاست. وبسایت شرکت داده پرداز در این لینک موجود است.جمع بندی:گذرگاه سرویس سازمان یا به اختصار ESB یک تکنولوژی برای یکپارچه سازی برنامه های کاربردی است. استفاده از ESB مزایا و معایب زیادی را به همراه دارد که با توجه به مزایا و معایب آن پیشنهاد می شود که سیستم های وب سرویس های بسیار متنوع دارند و یا دارای چندین زیرمجموعه هستند از آن استفاده کنند. اما نکته ای که بسیاری از منابع از جمله این لینک به آن اشاره کرده اند این است که ESB در 5 الی 10 سال آینده رو به افول است. این امر نیز به دلیل پیدایش میکروسرویس ها است که از تکنولوژی های به روز تری استفاده می کنند. البته رو به افول بودن به این معنی نیست که به کلی از آن استفاده نشود، بلکه به این معنی است که استفاده از آن نسبت به گذشته کمتر خواهد بود.منابع:[1] وبسایت https://searchapparchitecture.techtarget.com/definition/Enterprise-Service-Bus-ESB[2] وبسایت https://www.mulesoft.com/resources/esb/what-esb[3] وبسایت https://en.wikipedia.org/wiki/Enterprise_service_bus[4] وبسایت https://wso2.com/what-is-an-esb[5] وبسایت https://www.faragostar.net/what-is-esb[6] وبسایت https://platco.ir/services/integration-web-services/enterprise-service-bus[7] وبسایت https://www.cetrixcloudservices.com/blog/enterprise-integration-pros-and-cons-of-enterprise-service-bus[8] وبسایت https://www.ibm.com/cloud/learn/esb[9] وبسایت https://www.it.ucla.edu/news/what-esb[10] وبسایت https://dzone.com/articles/is-enterprise-service-bus-esb-obsolete-after-microاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است#معماری_نرم_افزار_بهشتی

آشنایی با Domain-Driven Design (DDD)

احسان رزازیان — Sat, 04 Dec 2021 21:31:51 +0330

مقدمه:طراحی دامنه محور (DDD)رویکرد "طراحی دامنه محور" یا همان "Domain-Driven Design"، نخستین بار توسط Eric Evans در کتابی تحت همین عنوان در سال 2004 بیان شد. به طور کلی هدف کلی این رویکرد این است که بگوید ساختار و زبان کد یک نرم افزار، باید با حوزه کسب و کار آن مطابقت داشته باشد. طراحی دامنه محور (DDD) رویکردی برای توسعه نرم افزار برای نیازهای پیچیده با اتصال عمیق پیاده سازی به یک مدل در حال تکامل است. به کمک این امر باعث می شود تا پیچیدگی ای که در قلب نرم افزار وجود دارد ساده تر شوند. DDD مناسب تیم ها و نرم افزار های بزرگ است. در همین راستا Eric Evans در خصوص DDD می گوید:برای ایجاد نرم افزار خوب، باید بدانید که آن نرم افزار چیست. شما نمی توانید یک سیستم نرم افزاری بانکی ایجاد کنید مگر اینکه درک خوبی از چیستی بانکداری داشته باشید، باید حوزه بانکداری را درک کنید.در ادامه DDD را به طور مفصل معرفی خواهیم کرد.معرفی DDD:فرض کنید می خواهیم یک "معجون" درست کنیم. برای درست کردن معجون باید مواد مختلفی مانند: گردو، شیر، خرما، عسل با هم مخلوط شوند و مدتی هم در یخچال بمانند. اما این مواد به صورت مجزا هم قابل خوردن هستند. فرض کنید شخصی برای شما یک معجون می آورد و شخص دیگری یک سینی می آورد که در آن گردو، شیر، خرما و عسل به صورت تفکیک شده از هم قرار دارند. حال اضافه و کم کردن یک ماده غذایی دیگر به کدام یک از این دو راحت تر است؟ واضح است که شما نمی توانید خرما را از داخل معجون بیرون بکشید! اما می توانید خرما را از سینی بردارید و به راحتی با ماده دیگری جایگزین کنید. سینی در این مثال هر کدام از مواد غذایی حکم Domain را دارند و ظرف سینی هم همان مفهوم کلی DDD است. در این صورت اضافه یا کم کردن قطعات دیگر به آسانی انجام خواهد پذیرفت. به عنوان مثال ممکن است حوزه یک بخش از نرم افزار ارسال پیام است، یا حوزه دیگر در یک بخش دیگر از نرم افزار دریافت اطلاعات از یک سیستم دیگر است. در ادامه با مفاهیم Domain و DDD را به طور شفاف تری متوجه می شویم.برای درک تخصصی تر DDD با چند تعریف آشنا می شویم:تعریف Domain:ابتدا با مفهوم Domain یا دامنه آشنا می شویم، Domain (دامنه)، یک حوزه ای از دانش و فعالیت است که منطق برنامه در آن می چرخد. بیاید این جمله را با هم بررسی کنیم. دامنه به حوزه موضوعی اشاره دارد که برنامه در آن قسمت حول آن می چرخد و کاربر برای آن حوزه است که از آن برنامه استفاده می کند. دلمنه بیانگر حوزه کلی یک برنامه است. به عنوان مثال در دنیای واقعی، "ماشین" یک دامنه است که شامل چرخ و چراغ و موتور است. اجزای ذکر شده به طور مفهومی با یکدیگر ارتباط دارند. گاهی اوقات در یک سازمان ممکن است چندین دامنه وجود داشته باشد. به عنوان مثال، یک شرکت می تواند در فروش، حمل و نقل و تعمیرات به طور همزمان فعال باشد.تعریف Context:یک مفهوم دیگر داریم به نام Context، مفهوم Context به این صورت تعریف شده است: محیطی که در آن یک کلمه یا یک عبارت ظاهر می شود که معنای آن را تعیین می کند را Context می نامند. در واقع Context حداکثر اندازه ای است که یک مدل می تواند بدون به خطر انداختن یکپارچگی مفهومی آن گسترش یابد.تعریف Bounded Context:برای کنار آمدن با یک مدل بزرگ، می‌توان مدل را به مناطق مختلف تقسیم کرد که ما آن را Bounded Context می‌نامیم. یک سازمان را می توان به یک بخش فروش و یک بخش پشتیبانی تقسیم کرد که هر کدام در چارچوب خود عمل می کنند. با کار در یک Bounded Context کار آسان تر و بهتر سازماندهی می شود.حال بیاید یک مثال را در حوزه نرم افزار و به کمک شکل زیر به صورت تخصصی تر با هم بررسی کنیم:مثالی از bounded contextهمانطور که در شکل فوق مشخص است، دو تا Context کلی داریم: Support (پشتیبانی) و Sale (فروش). نکته ای که وجود دارد این است دور هر کدام از آن ها یک خط کشیده شده است تا از هم تفکیک شوند، لذا به همین دلیل به هر کدام از آن ها Bounded Context هم گفته می شود. اما اینطور نیست که آن ها به صورت کامل از هم جدا باشند و هیچ ارتباطی با هم نداشته باشند. در شکل فوق نیز هر کدام از Bounded Context ها تداعی گر مفهوم یک حوزه خاص (مانند پشتیبانی و فروش) هستند که در نقاط مشتری و محصول با یکدیگر ارتباط دارند.اگر با معماری SOA یا همان معماری سرویس گرا آشنایی داشته باشید، متوجه می شود که DDD یکی از عناصر کلیدی معماری سرویس گرا است چرا که به encapsulate (پنهان سازی) کردن منطق و قواعد کسب و کار در domain object (اشیا دامنه) کمک می کند. همچنین در طراحی دامنه محور، لایه دامنه، یکی از لایه های رایج در معماری چند لایه شی گرا است.تعریف Domain Model:از این رو، توسعه دهندگان یک Domain Model (مدل دامنه) می سازند: Domain Model سیستمی است از مفاهیم و انتزاع ها که جنبه های انتخابی یک دامنه را توصیف می کند و می تواند برای حل مشکلات مربوط به آن دامنه استفاده شود.مارتین فاولر درباره Domain Model این گونه می گوید:مارتین فاولر: یک Domain Model، شبکه ای از اشیاء (Objects) به هم پیوسته را ایجاد می کند، که در آن هر شی نشان دهنده یک فرد معنادار است، چه به بزرگی یک شرکت یا به کوچکی یک خط در فرم سفارش.شکل زیر مصداقی از حرف او است:مثالی از Domain Modelهمانطور که مشاهده می شود، هم رفتار و هم داده ها در بر گرفته شده اند.تعریف Domain Event:یک Domain Event (رویداد دامنه) نشان دهنده اتفاق مهمی است که از دیدگاه کسب و کار در سیستم رخ داده است. این نوع رویداد ها نمی توانند بعد از این که اتفاق افتادند حذف یا به روز بشوند. "اضافخ کردن محصول به سبد" و "حذف کردن محصول از سبد" نمونه هایی هستند که در یک دامنه قرار دارند. آن ها همچنین مبنای الگوی هایی مانند Event Sourcing هستند.تعریف Aggregate:یک DDD Aggregate مجموعه ای از اشیاء دامنه (Domain Object) است که می تواند به عنوان یک واحد در نظر گرفته شود. حواستان باشد که Aggregate را با Collection ها اشتباه نکنید! Aggregate ها مفاهیم دامنه هستند (مانند سفارش، بازدید از کلینیک، لیست پخش) در صورتی که Collection ها عمومی هستند. لذا Aggregate ها معمولا درون خود چندین Collection به همراه چند فیلد ساده دیگر دارند. مثلا یک سفارش و لیست کالا های درون آن سفارش را در نظر بگیرید. این ها از هم جدا هستند، اما بهتر است که سفارش (همراه با لیست کالاهای درون آن) به عنوان یک Aggregate در نظر گرفته شود.تعریف Ubiquitous language:هدف این جنبه‌های طراحی دامنه محور، تقویت ubiquitous language (زبان فراگیر) است، به این معنی که مدل دامنه باید زبان مشترکی را تشکیل دهد که Domain Expert ها (متخصصان دامنه) برای توصیف نیازمندی‌های سیستم، کاربران تجاری، حامیان مالی و توسعه‌دهندگان از آن استفاده کنند. ubiquitous language (زبان فراگیر) حامل جنبه هایی از طراحی است که در کد ظاهر نمی شوند ولی قابل درک هستند. در واقع زبان فراگیر یک کانال حاوی اطلاعاتی است که بین توسعه دهندگان و متخصصان دامنه و نرم افزار در جریان است و زبان مشترک بین آن ها است:زبان فراگیر یا Ubiquitous Languageهمانطور که مشاهده می شود، زبان فراگیر یک زبان مشترک میان زبان توسعه دهندگان و زبان کسب و کار است.یک مثال دیگر از زبان فراگیر ببینم تا راحت تر مفاهیم ذکر شده را درک کنیم:زبان فراگیر (Ubiquitous language)همانطور که مشاهده می شود، زبان فراگیر یا همان Ubiquitous Language یک زبان واحد است که از آن در همه جا برای بیان یک مدل استفاده می شود. همه ی اعضای تیم باید بتوانند در مورد هر اصطلاح خاص بدون ابهام توافق کنند و نیازی به ترجمه نباشد. اگر با مفهوم OOP یا همان برنامه نویسی شی گرا آشنایی داشته باشید، حتما متوجه شده اید که DDD شباهت زیادی با OOP دارد. اما آن چه DDD دارد ولی در OOP موجود نیست، همین زبان فراگیر است! چرا که این زبان فراگیر کمک می کند تا درک مساله برای تمام افراد فنی و غیر فنی راحت تر باشد اما در OOP فقط افراد فنی می توانند کدی که توسعه داده شده است را درک کنند.معماری میکروسرویس و DDD:استفاده از این دو به همراه هم رایج است. رویکردهای DDD تنها در صورتی باید اعمال شوند که در حال پیاده‌سازی میکروسرویس‌های پیچیده با قوانین کسب و کار مهم هستیم. مسئولیت‌های ساده‌تر، مانند سرویس CRUD، با رویکردهای ساده‌تر قابل مدیریت هستند. در هنگام طراحی و تعریف یک میکروسرویس، این موضوع که کجا باید مرزها را ترسیم کنیم بسیار مهم است. الگوهای DDD به درک پیچیدگی دامنه ها کمک می کند. برای مدل دامنه برای هر زمینه محدود، موجودیت‌ها، اشیاء ارزشی و تجمیع‌هایی که دامنه شما را مدل می‌کنند شناسایی و تعریف می‌کنید. در این حین یک مدل دامنه طراحی و اصلاح می شود که در محدوده ای قرار می گیرد که زمینه را مشخص کند. این موضوع در قالب یک میکروسرویس آشکار است. اجزای درون آن مرزها در نهایت به میکروسرویس ها تبدیل می شوند، اگرچه در برخی موارد یک میکروسرویس BC یا کسب و کار می تواند از چندین سرویس فیزیکی تشکیل شده باشد. DDD و میکروسرویس ها هر دو در مورد مرزها هستند.اکثر برنامه های سازمانی با پیچیدگی تجاری و فنی قابل توجه توسط چندین لایه تعریف می شوند. ( توجه داشته باشید که لایه ها یک چیز منطقی هستند و به استقرار سرویس مربوط نیستند) آنها برای کمک به توسعه دهندگان برای مدیریت پیچیدگی کد وجود دارند. لایه های مختلف (مانند لایه مدل دامنه در مقابل لایه ارائه و غیره) ممکن است انواع مختلفی داشته باشند که ترجمه بین آن انواع را الزامی می کند. به عنوان مثال، یک موجودیت می تواند از پایگاه داده بارگذاری شود. سپس بخشی از آن اطلاعات، یا مجموعه‌ای از اطلاعات شامل داده‌های اضافی از سایر نهادها، می‌تواند از طریق یک REST Web API به UI مشتری ارسال شود. نکته اینجاست که موجودیت دامنه در لایه مدل دامنه قرار دارد و نباید به مناطق دیگری که به آن تعلق ندارد مانند لایه ارائه منتشر شود. این نمات در شکل زیر وجود دارند:نمونه ای از طراحی لایه ایهمانطور که در شکل فوق مشخص است، میکروسرویس مربوط به سفارش از 3 لایه تشکیل شده است. یک لایه مربوط به API، یک لایه مربوط به دامنه و یک لایه هم برای زیر ساخت. هر کدام از این لایه ها نیز به چندین زیرلایه تقسیم شده اند. مزایای DDD:تسهیل ارتباطات: به کمک DDD، ارتباط میان توسعه دهندگان پروژه های نرم افزاری و ذی النعان پروژه (کسانی که منطق کسب و کار را تعریف می کنند) آسان تر و قابل فهم تر می شود. در واقع آنان زبان یکدیگر را راحت تر درک میکنند، همچنین خود توسعه دهندگان نیز حرف یکدیگر را بهتر درک خواهند کرد و به طور کلی پیچیدگی در نرم افزار کاهش می یابد.انعطاف پذیری: از آنجایی که این سیستم برای مدل‌سازی حوزه کسب‌وکار ساخته شده است، به طور کلی برای تغییر انعطاف‌پذیرتر خواهد بود چرا که تغییرات در نیاز های عملکردی (Functional Requirement) راحت تر خواهد بود.قابلیت نگهداری: به دلیل نحوه ساخت مدل‌های دامنه با کپسوله کردن شفافیت و تجزیه خوب مدل، سیستم‌های مبتنی بر دامنه معمولاً طبیعتاً قابل نگهداری‌تر هستند.معایب DDD: تخصص در دامنه: استفاده از DDD نیاز به تخصص قوی در حوزه دامنه و ارتباط منظم بین متخصص دامنه و توسعه دهندگان دارد.هزینه: استفاده از DDD اغلب منجر به توسعه و مدت زمان طولانی تر می شود که در نهایت به هزینه های بالاتر برای کسب و کار منجر می شود.جمع بندی:همانطور که دیدیم، DDD یک تکنولوژی نیست، بلکه یک رویکرد است که اصول و قواعدی را معرفی می کند تا تصمیم گیری در حوزه های تجاری پیچیده را آسان تر کند. استفاده از DDD باعث می شود که افراد فنی و غیر فنی حرف یکدیگر را بهتر بفهمند چرا که DDD، پیچیدگی های قواعد و منطق کسب و کار را در دل یک سری مدل پنهان می کند. اما استفاده از DDD هزینه بر است، لذا استفاده از آن برای پروژه های کوتاه مدت یا پروژه هایی که پیچیدگی دامنه بالایی ندارند مناسب نیست.منابع:[1] وبسایت https://www.infoq.com/articles/ddd-in-practice[2] وبسایت https://www.lucidchart.com/blog/domain-driven-design-introduction[3] وبسایت https://simpleprogrammer.com/importance-domain-driven-design[4] وبسایت https://en.wikipedia.org/wiki/Domain-driven_design[5] کتاب "Domain-Driven Design Tackling Complexity in the Heart of Software" اثر Eric Evans منتشر شده در سال 2003[6] وبسایت https://martinfowler.com[7] وبسایت https://domaindrivendesign.org[8] وبسایت https://codezup.com/what-is-domain-driven-design-ddd-pros-cons[9] وبسایت https://towardsdatascience.com/what-is-domain-driven-design-5ea1e98285e4[10] وبسایت https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice[11] وبسایت https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-modelاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است

آشنایی با الگوی Event Sourcing

احسان رزازیان — Fri, 03 Dec 2021 19:21:01 +0330

مقدمه:در این مقاله قصد داریم تا الگوی Event Sourcing را معرفی کرده و جزییات آن را با هم برسی کنیم. این الگو در صنعت نرم افزار کاربرد دارد و مانند هر الگوی دیگری، استفاده از آن نیز مزایا و معایبی دارد که در انتهای مقاله به آن خواهیم پرداخت. همانطور که از اسم الگوی Event Sourcing پیداست، تاکید این الگو بر روی ذخیره رویداد ها یا تغییراتی است که بر روی یک موجودیت اتفاق می افتد. در ادامه بیشتر با جزییات این الگوی جالب آشنا می شویم.معرفی الگوی Event Sourcing:این الگو بر ذخیره رخداد هایی که روی داده ها انجام شده اند تاکید دارد. هر زمان وضعیت یک موجودیت تغییر می کند، یک رخداد جدید به محل ذخیره سازی رخداد ها اضافه خواهد شد:کلیات الگوی Event Sourcingهمانطور که در شکل فوق مشخص است، هر گونه رخدادی که در سیستم اتفاق می افتد، در لیست رخدادها یا همان Event Store ذخیره می شود. سپس می توان با مرور لیست رخداد ها، وضعیت کنونی یک موجودیت را فهمید. Event Store جایی است که تمام رخدادهایی که روی هر موجودیتی در سیستم اتفاق افتاده است در آن جا ذخیره می شود. "اضافه شدن" یا "کم شدن" از لیست، مثال هایی از رخدادها هستند که در Event Store ذخیره می شوند. وقتی از این الگو استفاده می کنیم، به جای آنکه وضعیت کنونی یک موجودیت را ذخیره کنیم، لیست تاریخچه رخداد ها و اعمالی که روی آن اتفاق افتاده است را ذخیره می کنیم. سپس به کمک این لیست می توانیم به راحتی به وضعیت کنونی موجودیت نیز پی ببریم.مثال از الگوی Event Sourcing:در ادامه یک مثال از الگوی Event Sourcing می زنیم تا درک آن آسان تر شود:فرض کنید مشتری یک فروشگاه اینترنتی هستی و قصد دارید تا یک کالا را خریداری کنید. وقتی این کالا را انختاب کردید، اقدام به ثبت سفارش می کنید. پس از اینکه پرداخت موفق هم انجام دادید، سفارش شما ثبت می شود و وضعیت سفارش شما در حالت "در انتظار تایید" قرار می گیرد. در ادامه حالت های مختلفی می توانند برای خرید شما پیش بیایند، مثلا وضعیت سفارش شما به "تایید فروشنده" تبدیل می شود، و سپس پس از اینکه فروشنده کالا را ارسال کرد، وضعیت سفارش شما به "در حال ارسال" تبدیل می شود. در نهایت وقتی شما سفارشتان را تحویل گرفتید، وضعیت سفارش شما "تحویل شده" خواهد شد.برخی اوقات ما نیاز داریم که به تاریخچه تغییرات وضعیت سفارش دسترسی داشته باشیم. این تاریخچه در Event Store موجود است. به عنوان مثال شما می خواهید ببینید که در چه روزی و چه ساعتی فروشنده سفارش شما ارسال کرده است. با یک نگاه ساده به Event Store این زمان را متوجه خواهیم شد. این یک مثال ساده از زمانی بود که ما به داشتن لیست تغییرات وضعیت سفارش نیاز داریم. آنچه واضح است این است که Event Store باید دارای یک قالب و چارچوب مشخص باشد:نمونه ای از یک Event Storeهمان طور که مشاهده می شود، هر خط شامل اطلاعاتی مانند شناسه رخداد، جزییات رخداد، نوع موجودیت حاضر در رخداد و ... می باشد. به طور مفهومی، هر خط از Event Store شکل بالا می تواند بیانگر جملات زیر باشد:"سفارش ثبت شد""سفارش تایید شد""سفارش ارسال شد""سفارش تحویل شد"و ...کاربرد دیگر Event Store، اطلاع یافتن سایر سرویس ها یا سامانه ها از رخداد ها به کمک Subscribe کردن روی آن است. برای این که این امر محقق شود، هر بخش از سامانه باید اتفاقاتی که در موجودیت هایش رخ می دهد را در معرض عموم قرار دهد تا بقیه از بیرون به آن دسترسی داشته باشند. اما این اتفاق به صورت زیبا تری به کمک اضافه کردن الگوی CQRS رخ خواهد داد که در ادامه مقاله آن را خواهیم دید.در همین مثال حالتی را در نظر بگیرید که چند سرویس دیگر منتظر تغییر وضعیت سفارشات هستند تا اقدامات مربوطه را انجام بدهند. مثلا سرویس اطلاع رسانی منتظر است تا اگر وضعیت سفارش تغییر کرد، به مشتری اطلاع بدهد. در این حالت سرویس اطلاع رسانی می تواند بر روی Event Store یا همان لیست تفییرات وضعیت ها Subscribe کرده و به محض تغییر وضعیت، خودش متوجه تغییر شود و اقدامات مربوطه را انجام دهد. از جمله این اقدامات می توان به این مورد اشاره کرد که برای مشتری پیامک ارسال می شود. همچنین چندین سرویس دیگر مانند سرویس حمل و نقل و ... نیز می توانند Subscribe کنند.توجه داشته باشید که هنگامی که از الگوی Event Sourcing استفاده می کنیم، در Event Store فقط تغییرات یا همان به روز شدن ها ذخیره نمی شود. بلکه هر نوع عمل <<اضافه شدن>>، <<حذف شدن>> و <<به روز شدن>> که باعث تغییر در موجودیت ها می شوند می توانند در این منبع ذخیره شود. شباهت Event Sourcing به Log کردن:شاید تا به اینجا متوجه شده باشید که این الگو شباهت زیادی به مکانیزم های Log کردن در پایگاه داده دارد. اکثر پایگاه داده های امروزی (می توان گفت همه ی آن ها) دارای فایل Log یا همان Log File هستند که درون آن ها نیز تغییراتی که در پایگاه داده رخ داده نوشته می شود. پس تفاوت این الگو با Log چیست؟! در پاسخ باید بگوییم اولا فرمت Log های هر پایگاه داده با فرمت Log های پایگاه داده دیگر متفاوت است. ثانیا در برخی موارد Log File های یک نسخه از یک پایگاه داده، با Log File های نسخه پیشین همان پایگاه داده تفاوت هایی دارد! ثالثا ممکن است در Log File ها اطلاعاتی وجود داشته باشد که به کار نیایند و فقط باعث هدر رفت حافظه شوند. چرا که در بسیاری از پایگاه داده ها، به صورت پیش فرض Log ها فقط تا یک مدت مشخصی وجود دارند و پس از اتمام آن مدت به صورت خودگار پاک می شوند.اما از مزیت ها Log File نسبت به الگوی Event Sourcing می توان به این نکته اشاره کرد که سرعت جستجو در آن بیشتر است. به همین دلیل است که الگوی CQRS را با الگوی Event Sourcing تلفیق میکنند تا سرعت جستجو در بین رکورد ها بیشتر شود. در ادامه تلفیق این دو الگو را برسی خواهیم کرد.استفاده از Event Sourcing به همراه CQRS:استفاده از این الگو به همراه الگوی CQRS بسیار رایج است (مخصوصا در معماری میکروسرویس). اگر با الگوی CQRS آشنایی داشته باشید، می دانید که در این الگو Command ها (نوشتن، به روز کردن، حذف کردن) از Query ها (خواندن) تفکیک می شوند. فرض کنیم دو میکروسرویس داریم. هر کدام از آن ها Write DB و Read DB مخصوص خودشان را دارند. (اگر با Write DB و Read DB آشنایی ندارید حتما در مورد CQRS مطالعه کنید). پس از تلفیق این دو الگو، Write DB معادل با همان Event Store است. یعنی هر میکروسرویس یک پایگاه داده دارد که تغییرات اعمال شده بر روی موجودیت ها بر روی آن نوشته می شود و یک پایگاه داده دارد که فقط مخصوص خواندن این تغییرات است (طبق الگوی CQRS). در واقع پایگاه داده نوشتن با خواندن فرق دارد. اگر بر الگوی CQRS مسلط باشید می دانید که برای اینکه Write DB و Read DB با یکدیگر sync باشند، نیاز است تا تغییراتی که بر روی Write DB یک سامانه اتفاق می افتد، به کمک یک سیستم پیام رسانی به گوش Read DB همان سامانه هم هم برسد تا Read DB هم خودش را به روز کند. اما وقتی از الگوی Event Sourcing استفاده می کنیم، از آن جایی که تغییرات موجودیت های یک میکروسرویس می تواند برای سایر میکروسرویس ها هم ارزشمند باشد. وقتی CQRS نیز اضافه می شود، میکروسرویس ها می توانند به جای آن که از Event Store های هم دیگر Subscribe کنند، از Read Storage یا همان Read DB یکدیگر Subscribe کنند. حتی به جای این کار می توانند از یک صف که همه میکروسرویس ها Event Store خود را در آن منتشر کرده اند Subscribe کنند و یا این که یک پایگاه داده کلی داشته باشیم که از آن به عنوان view استفاده شود:تلفیق Event Sourcing و CQRS در میکروسرویساگر از الگوی Event Sourcing استفاده نمی شد، میکروسرویس ها ناچار بودند تا تغییرات را از روی Log ها یکدیگر بفهمند (که معایب خودش را به همراه داشت). و اگر از الگوی CQRS استفاده نمی شد، دیگر Read Storage نداشتیم و میکروسرویس ها باید تغییرات را از روی Event Store هم دیگر می فهمیدند که این کارآیی را کاهش می داد و سرعت سیستم کمتر می شد.مزایای الگوی Event Sourcing:الگوی Event Sourcing مزایای زیادی دارد که برخی از آن ها عبارت اند از:بازیابی راحت تر اطلاعات: به کمک الگوی Event Sourcing، ما یک لیستی از تغییرات وضعیت موجودیت ها خواهیم داشت. این امر به ما کمک می کند که اگر نیاز شد تا بخواهیم مقادیر داده ها یا رکورد ها را در یک زمان خاص به دست بیاوریم و یا متوجه شدیم که در جایی از سیستم اطلاعات مربوط به داده ها غلطط هستند، به راحتی به سراغ لیست تغییرات رفته و به وضعیت سیستم و مقادیر داده ها در یک زمان خاص پی ببریم.شفاف تر شدن سیستم: وقتی از الگوی Event Sourcing استفاده می کنیم، به راحتی می توانیم متوجه شویم که هر تغییری که در سیستم رخ داده توسط چه بخشی بوده و در چه زمانی اتفاق افتاده است. در واقع از Event Store می توان به عنوان لیستی از اسناد تغییرات استفاده کرد و از هر تغییر به عنوان یک مدرک استفاده کرد. در این حالت علت هر تغییر و وضعیت سیستم و اینکه چرا سیستم به یک حالت مشخص رسید بسیار شفاف خواهد بود.امکان آنالیز دقیق تر سیستم: در بسیاری از اوقات ما می خواهیم یه آنالیز از سیستم داشته باشیم و رفتار کاربران را شبیه سازی کنیم. به کمک الگوی Event Sourcing می توان هر گونه آمار و آنالیزی از سیستم داشته باشیم چرا که زمان هر رخداد مشخص استو مثلا می خواهیم ببینیم در چه ساعاتی از شبانه روز بیشترین ویرایش سفارش اتفاق می افتد، این امر به راحتی با مراجعه به Event Store قابل فهم خواهد بود.عیب یابی راحت تر سیستم: اگر هر خطایی در سیستم رخ بدهد و داده ها به یک state بروند که از لحاظ مفهومی غلط هستند، می توان با مراجه به لیست رخداد هایی که روی آن داده اتفاق افتاده اند علت این عیب را پیدا کرد. مثلا می توان متوجه شد که این تغییر دارد توسط که بخشی از سیستم صورت می گیرد و جلوی آن بخش را گرفت یا آن بخش را اصلاح کرد تا دیگر باعث عیب در وضعیت داده ها نشود.معایب الگوی Event Sourcing:در کنار مزایایی که الگوی Event Sourcing دارد، معایبی نیز مطرح است که برخی از آن ها عبارت اند از:به روز رسانی صفات دشوار است: تصور کنید که قصد داشته باشیم به یک موجودیت، صفاتی را اضافه یا کم کنیم. در این صورت تکلیف رخداد های قبلی چیست؟! مثلا اگر بخواهیم صفت "وضعیت" را به کلی از موجودیت "سفارش" حذف کنیم، در این صورت تعداد بسیار زیادی Event در Event Store وجود داشته اند که تغییرات "وضعیت" سفارشات را ذخیره کرده اند. تکلیف آنان چه می شود؟ شاید ساده ترین کار حذف آن ها باشد. اما ممکن است حذف کردن آنان ایرادی به وجود بیاورد. لذا باید در این خصوص مشورت و تصمیم گیری شود.استفاده زیاد از حافظه: بدیهی است که اگر بخواهیم تمام رخداد ها را ذخیره کنیم، حافظه بسیار زیادی از سیستم اشغال می شود، چرا که رخداد های زیادی بر روی موجودیت ها رخ می دهد. از طرفی باید تمام تغییرات را داشته باشیم تا بتوانیم وضعیت نهایی یک موجودیت را به دست آوریم.جمع بندی:الگوی Event Sourcing الگویی است که مبنای آن ذخیره جزییات رخداد هایی است که بر روی موجودیت ها در یک پایگاه داده اتفاق می افتد. استفاده از این الگو بیشتر در معماری میکروسرویس و به همراه الگوی CQRS رایج است. استفاده از این الگو مزایا و معایبی به همراه دارد که باید با توجه به مزایا و معایب آن دید که استفاده از آن به صرفه است یا خیر. در انتها باید به این نکته اشاره کنیم که این الگو شباهت زیادی به سازوکار Log های پایگاه داده ها دارد که البته تفاوت های آن باعث شده تا هر کدام مزایا و معایب خودشان را داشته باشند.منابع:[1] https://microservices.io/patterns/data/event-sourcing.html[2] https://codeopinion.com/event-sourcing-example-explained-in-plain-english/[3] https://martinfowler.com/eaaDev/EventSourcing.html[4] https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing[5] https://eventuate.io/whyeventsourcing.html[6] https://www.lagomframework.com/documentation/1.6.x/java/ESAdvantage.html[7] https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing[8] https://www.eventstore.com/blog/event-sourcing-and-cqrs[9] M. Overeem, M. Spoor, S. Jansen, "The Dark Side of Event Sourcing: Managing Data Conversion", IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), 2017این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است#معماری_نرم_افزار_بهشتی

معرفی الگوی CQRS و جزییات آن

احسان رزازیان — Wed, 01 Dec 2021 21:21:41 +0330

مقدمه:در این مقاله قصد داریم تا الگوی CQRS که مخفف Command and Query Responsibility Segregation یا همان "جداسازی مسوولیت های خواندن و نوشتن" می باشد را معرفی کنیم. این الگو امروزه به یکی از پرکاربردترین الگو ها در زمینه نرم افزار تبدیل شده است و اولین بار توسط آقای Greg Young مطرح شد.فلسفه الگوی CQRS این است که به طور کلی اعمال اصلی که در هسته نرم افزار وجود دارند، یا باعث تغییر در داده های موجود می شوند (Command)، و یا باعث تغییر در هیچ نوع داده ای نمی شوند و صرفا مقادیر داده ها را می خوانند (Query). تاکید این الگو بر این امر است که اعمال باید از هم دیگر جدا باشند و به صورت تفکیک شده از هم کار کنند.جزییات الگوی CQRS:ابتدا با ذکر یک مثال به تعریف دقیق تر Command و Query می پردازیم:فرض کنید یک مشتری قصد دارد تا فرآیند خرید یک کتاب را انجام بدهد. وی ابتدا باید وارد سایت شود. سپس لیست کتاب ها را ببیند. وقتی کاربر بر روی گزینه "مشاهده لیست کتاب ها" کلیک می کند، در پشت ماجرا یک کد اجرا می شود که لیست کتاب ها را از پایگاه داده خوانده و به کاربر باز می گرداند. به این نوع دستورات که تغییری در سیستم ایجاد نمی کند و مقداری را بر میگرداند Query گفته می شود. هنگامی که وی قصد ثبت سفارش دارد، یک کتاب را به سبد خریدش اضافه می کند. با این کار یک رکورد در پایگاه داده اضافه می شود. پس پایگاه داده ی این سایت مشمول تغییراتی شده. به این نوع دستورات که تغییر در سیستم ایجاد می کند و مقداری را بر نمی گردانند Command گفته می شود.از یک نگاه دیگر، 4 نوع دستور در پایگاه داده وجود دارد که به CRUD معرف است: Create (ایجاد یک رکورد)، Read (خواندن یک رکورد)، Update (به روز رسانی یک رکورد) و Delete (حذف یک رکورد). از بین این دستورات، Create و Update و Delete که باعث ایجاد یک تغییر در داده ها می شوند، در دسته Command قرار می گیرند. دستور Read هم در دسته Query قرار می گیرد:تفکیک دستورات در CQRSشکل فوق دسته بندی دستورات پایگاه داده در الگوی CQRS را نشان می دهد.الگوی CQRS بر این نکته تاکید دارد که به هیچ عنوان دو دسته عمل Command ها و Query ها نباید با هم دیگر قاطی شوند! این اتفاق در این مثالی که گفتیم رخ نمی دهد، اما ممکن است در بعضی شرایط ممکن است یک عمل هم شامل خواندن و هم شامل نوشتن باشد که در ادامه این مقاله خواهیم دید. الگوی CQRS تاکید دارد که این تابع باید به دو تا تابع خرد شود. همچنین مدل هایی که برای خواندن داده ها استفاده می شوند، باید با مدل هایی که برای نوشتن داده ها استفاده می شوند تفاوت داشته باشند.شکل زیر کلیات این الگو را نشان می دهد:کلیات الگوی CQRSهمانطور که مشاهده می شود، در سمت چپ تصویر UI یا همان User Interface قرار دارد. User Interface به معنی رابط کاربری است، به عنوان مثال یک صفحه از وبسایت یا یک بخش از اپلیکیشن. آن چه مهم است این است که پشت رابط کاربری، یک کاربر نشسته و با سیستم کار می کند. اگر این کاربر صرفا بخواهد این صفحه را ببیند و یا صفحه ای از سایت را رفرش کند، دیدن او تغییری در پایگاه داده ی این سایت یا اپلیکیشن ایجاد نمی کند. این یعنی Query. اطلاعات بازگشتی نیز به کمک Query Model (قسمت صورتی رنگ عکس) از پایگاه داده خوانده شده و به وی در صفحه ی آن وبسیات نمایش داده می شود. اما همانطور که پیش تر گفته شد، ممکن است کاربر با سایت تعامل برقرار کند و مثلا بخواهد سفارشی در سایت بگذارد، در این صورت به کمک Command Model این تغییر در پایگاه داده (یا همان DB که با رنگ زرد رنگ در سمت راست تصویر مشخص شده است) ثبت می شود.نکته دیگری که در عکس فوق وجود دارد این است که مدل هایی که مدل هایی که برای خواندن داده ها استفاده می شوند، با مدل هایی که برای نوشتن یا تغییر داده ها استفاده می شوند تفاوت دارند. اما قبل از به کارگیری الگوی CQRS این مدل ها با یکدیگر تفاوت نداشتند و یک مدل داشتیم.در این شکل از یک پایگاه داده استفاده شده است، اما در نسخه های پیشرفته تر الگوی CQRS، ما دو عدد پایگاه داده داریم. یک پایگاه داده فقط مختص نوشتن و تغییرات داده است و یک پایگاه داده فقط برای خواندن داده ها است. یعنی ما نباید از پایگاه داده ای که برای نوشتن داده ها استفاده می شود داده ای بخوانیم، و همین طور نباید در پایگاه داده ای که برای خواندن داده ها استفاده می شود چیزی بنویسیم. جزییات این روش در تصویر زیر مشخص شده است:الگوی CQRS پیشرفته ترهمانطور که در شکل بالا مشخص است، یک Write DB داریم و یک Read DB. این دو پایگاه داده باید با هم دیگر sync باشند، یعنی داده های موجود در آنان باید دقیقا یکسان باشد. این در حالی است که ما فقط داده ها را در Write SB می نویسیم و نه Read DB، پس چگونه می شود که داده ها باید در هر دو پایگاه داده وجود داشته باشند؟ جواب این است که این امر به کمک Replication و Message Broker اتفاق می افتد که پیاده سازی آن آسان هم نیست. همانطور که مشخص است اگر کاربر قصد نوشتن داشته باشد، از سمت چپ شکل در Write DB داده اش را می نویسد. سپس Read DB هم از این نوشتن با خبر می شود و خود را به روز می کند. حال اگر کاربر قصد خواندن داده ای را داشته باشد از سمت راست تصویر داده را از Read DB میخواند و دیگر کاری با Write DB ندارد. به این نکته توجه داشته باشید که جنی پایگاه داده های Write DB و Read DB نباید لزوما یکسان باشد و این خوبی این الگو است.همچنین در شکل فوق یک Event Data Store وجود دارد که در الگوی Event Sourcing از آن استفاده می شود.در ادامه مثالی از قطعه کد را می بینم که در یکی از آن ها از الگوی CQRS استفاده نشده است ولی در قطعه کد دیگر که ویرایش شده همان نسخه اول است، از این الگو استفاده شده است و CQRS بر آن اعمال شده است.در قطعه کد اوله زیر از الگوی CQRS استفاده نشده است:بدون استفاده از الگوی CQRSهمانطور که مشاهده می شود، تمام توابع، چه توابعی که عمل خواندن انجام می هند و چه توابعی که عمل نوشتن انجام می دهند، در یک interface (واسط) قرار گرفته اند. (این یک عیب نیست، اما اگر از CQRS استفاده شود مزایای به همراه خواهد داشت که در ادامه به آن اشاره می کنیم)در ادامه قطعه کد جدیدی را مشاهده می کنیم که همان قطعه کد قبلی است با این تفاوت که الگوی CQRS در آن اعمال شده است:با استفاده از الگوی CQRSبعد از اینکه الگوی CQRS اعمال شد، یک interface به دو تا interface تبدیل شد (PolicyCommandService و PolicyQueryService).در PolicyCommandService فقط توابعی که تغییر در پایگاه داده به وجود می آورند (Command) ها وجود دارند و اگر دقت کنید متوجه می شوید که هیچ کدام از آن ها مقداری را بر نمیگردانند. (چون void هستند) در PolicyQueryService نیز فقط توابعی که از پایگاه داده اطلاعاتی را می خوانند و هیچ واکنش از خود بروز نمی دهند وجود دارند. تمام این توابع لیستی از مقادیر (یا یک مقدار خاص یک شی) را بر میگردانند.یعنی مسوولیت توابع موجود در یک کلاس، باید یا نوشتن باشد، یاخواندن!مثال دیگری در شکل های زیر آورده شده است که در آن یک قطعه کد وجود دارد که قصد دارد تا مقدار یک متغیر به نام x را 1 عدد زیاد کرده و سپس مقدار جدید آن را برگرداند:بدون استفاده از الگوی CQRSهمانطور که مشاهده می شود، در این تابع هم تغییر روی متغیر x داده شده و هم مقدار آن خوانده شده. الگوی CQRS این را قبول ندارد! پس از اعمال الگوی CQRS به روی قطعه کد فوق، به جای یک تابع، دو تابع خواهیم داشت. یکی از از این توابع وظیفه اش این است که مقدار x را بخواند و دیگری وظیفه اش این است که مقدار x را زیاد کند:پس از اعمال الگوی CQRSبنابراین مسوولیت دو تابع تفکیک شده و یکی عملیات خواندن (Query) را دارد و دیگری مسوولیت اضافه کردن (Command) را دارد. در این قطعه کد اعمال Update و Read با هم دیگر درون یک تابع بودند، اما وقتی الگوی CQRS اعمال شد، این تابع به 2 عدد تابع خرد شد. تابع ()value تغییری در داده x ایجاد نمی کند و صرفا مقدار داده x را بر میگرداند. تابع ()increment مقداری برنمی گرداند اما تغییر در داده x ایجاد می کند (مقدار آن را یکی زیاد می کند) و این دقیقا مطابق همان تعریفی است که در ابتدای این مقاله داشتیم.این الگو نیز مانند سایر الگو ها یک سری کاربرد و همچنین یک سری مزایا و معایب دارد. در ادامه به هر کدام از آن ها می پردازیم.مزایای الگوی CQRS: شاید این سوال برای شما نیز پیش آمده باشد که کاربرد این الگو چیست و اساسا چرا باید از این الگو استفاده شود؟ از جمله دلایلی که بسیاری از برنامه نویسان از این الگو استفاده می کنند می توان به موارد زیر اشاره کرد: افزایش بهره وری: هنگامی که از این الگو استفاده می شود، می توان به جای اینکه از یک پایگاه داده استفاده کرد، از دو پایگاه داده استفاده کرد. یک پایگاه داده برای خواندن داده ها و یکی برای نوشتن. مثلا می توان از پایگاه داده های از جنس SQL برای نوشتن استفاده کرد و از پایگاه داده های از جنس non-SQL برای خواندن استفاده کرد که این کار باعث افزایش بهره وری می شود.افزایش کارآیی: از آنجایی که تعداد خواندن ها (Query) معمولا بیشتر از نوشتن ها (Command) است، می توان داده هایی که مدام خوانده می شوند را در یک موقعیت جغرافیایی مخصوص قرار داد. و یا برای آن ها یک سرور جداگانه تعبیه کرد تا سرعت سایت و زمان پاسخ (Response Time) سایت یا سیستم بیشتر شود. به طور کلی اگر تعداد خواندن ها خیلی بیشتر از نوشتن ها باشد، این الگو بسیار موثر واقع می شود.کاهش پیچیدگی: به کمک این روش، هر قطعه کد یا در حال خواندن است یا در حال نوشتن، لذا به طور کلی کد تمییز تر و خواناتری خواهیم داشت و توسعه کد آسان تر خواهد بود. استفاده از این الگو باعث طراحی و پیاده سازی ساده تری خواهد شد.افزایش مقیاس پذیری: هنگامی که تیم توسعه نرم افزار بسیار بزرگ باشد، مدیریت اینکه هر کس مسوول چه بخشی از کد است سخت خواهد بود. اما وقتی بخش خواندن و نوشتن کد از هم جدا باشد، راحت تر می توان مسوولیت را بین اعضای تیم توسعه پخش کرد. همچنین وقتی منطق کسب و کار در کد از یک حد معمول پیچیده تر است، می توان به راحتی با استفاده از این الگو کد را به دو بخش کلی شکست تا درک منطق آسان تر شود.معایب الگوی CQRS:از آن طرف ماجرا، این الگو معایبی دارد که به آن اشاره می کنیم: استفاده از این الگو نیازمند داشتن دانش فنی بالا در حوزه پایگاه داده ها می باشد و اگر با دانش کافی به سمت این الگو نرویم حتی ممکن است این الگو ضرر هم داشته باشد.وقتی از این الگو استفاده می کنیم، تمام اعضای تیم باید با آن آشنا باشند و توجیه باشند که چرا باید این الگو استفاده کنند. اگر کسی غیر از این عمل کند، ممکن است نیاز شود تا کل کد مجددا مرور شود.در برخی مواقع الگوی CQRS ممکن است باعث شود تا کد تکراری زده شود و حجم کد بیشتر شود.نکته مهم: استفاده از این الگو برای کسب و کار های که قواعد خیلی ساده ای دارند پیشنهاد نمی شود!در راستای معایب الگوی CQRS، مارتین فاولر در نوشته ای می گوید:مارتین فاولر: با وجود مزایای زیادی که CQRS دارد، باید هنگام استفاده از آن خیلی مراقب بود. به روز کردن داده ها در بسیاری از سیستم های اطلاعاتی با همان روش خواندن داده ها انجام می گیرد. افزودن CQRS به چنین سیستمی می تواند پیچیدگی قابل توجهی را به سیستم اضافه کند. من مواردی را دیده‌ام که در آن استفاده از الگوی CQRS ریسک غیرقابل توجیهی را به پروژه اضافه کرده است، حتی اگر آن پروژه در دست یک تیم قوی بوده باشد. بنابراین، در حالی که CQRS الگوی خوبی است، مراقب باشید که استفاده از آن دشوار است.در واقع در برخی سیستم ها، در دستور Update ابتدا یک خواندن مقدار اولیه از آن متغیر داریم که این ممکن است کار را سخت کند، چون گفتیم که دستور Update باید از دستور Read جدا باشد، اما این ممکن نیست چرا که Read بخشی از Update است! این موضوع ممکن است نیازمندی قفل گزاری داده را به وجود بیارد که همین امر به پیچیدگی کد و سیستم اضافه خواهد کرد.چه زمان از CQRS استفاده کنیم؟زمانی که منطق کسب و کار بسیار پیچیده است، این الگو کاربرد دارد و به آسان تر کردن درک منطق کسب و کار و کد کمک می کند.زمانی که تیم توسعه دهندگان شامل تعداد بسیار زیادی برنامه نویس است که هر کدام از آن ها یک بخش از کد را توسعه می دهند، این الگو می تواند کارا باشد.اگر سیستمی داشته باشیم که تعداد خواندن ها در آن بسیار زیاد است (مانند سایت stackoverflow) این الگو می تواند به افزایش بهره وری سیستم کمک کند.جمع بندی:الگوی CQRS یک تکنولوژی نیست، بلکه صرفا یک فرهنگ و مفهوم است که استفاده از آن مزایا و معایبی به همراه دارد. استفاده از آن در هر جایی پیشنهاد نمی شود و اشخاصی که با تجربه تر هستند (مانند مدیران پروژه) باید تصمیم بگیرند که از این الگو استفاده بشود یا خیر. علاوه بر این موضوع، این الگو می تواند مکملی برای سایر الگو ها مانند Event Sourcing باشد. الگوی CQRS و Event Sourcing معمولا به همراه همدیگر استفاده می شوند و مزایای دیگری را برای اهداف دیگری به وجود می آورند. این الگو مختص زبان برنامه نویسی خاصی نیست و در تمام زبان های برنامه نویسی می توان از آن استفاده کرد. همچنین استفاده از این الگو در معماری میکروسرویس به همراه الگوی Event Sourcing بسیار رایج است.منابع:[1] https://microservices.io/patterns/data/cqrs.html[2] https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs[3] https://www.redhat.com/architect/pros-and-cons-cqrs[4] https://martinfowler.com/bliki/CQRS.html[5] https://ravendb.net/articles/cqrs-and-event-sourcing-made-easy-with-ravendb[6] https://dzone.com/articles/cqrs-and-event-sourcing-intro-for-developers[7] https://en.wikipedia.org/wiki/Command%E2%80%93query_separation[8] https://www.baeldung.com/cqrs-event-sourcing-java[9] https://vladikk.com/2017/03/20/tackling-complexity-in-cqrs/[10] https://www.redhat.com/architect/illustrated-cqrs#معماری_نرم_افزار_بهشتیاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.

همه چیز درباره مستندسازی معماری نرم افزار با روش C4

احسان رزازیان — Wed, 17 Nov 2021 23:53:42 +0330

1: مقدمهامروزه صنعت نرم افزار با سرعت زیادی رو به رشد است و روز به روز بر تعداد کاربران حوزه نرم افزار اضافه می شود. اما آیا تا کنون به این نکته فکر کرده اید که این نرم افزار ها چگونه ساخته می شوند و از چه بخش های فنی تشکیل شده اند؟ به عنوان مثال یک وبسایت فروشگاهی را در نظر بگیرید. وقتی شما این سایت را باز می کنید، یک مجموعه ای از کد ها که توسط توسعه دهندگان مختلف توسعه داده شده اند اجرا می شوند تا این سایت به شما نمایش داده شود. این کد ها ممکن است توسط چندین توسعه دهنده مختلف نوشته شده باشند که در گذر زمان تغییر هم می کنند. این کد ها و نوه قرار گرفتن اجزای ان ها در کنار هم باید مستند سازی شود، به این دلیل که تغییرات در نرم افزار یک امر بسیار رایج است و تفاوتی که نرم افزار به عنوان مثال با رشته مهندسی عمران دارد همین تغییرات است! وقتی یک ساختمان ساخته می شود، ساخته شده و تمام شده و تا 30 سال و یا بیشتر به همان شکل و با همان اسکلت باقی می ماند. اما نرم افزار به علل مختلف، از جمله پیدایش نیاز های جدید از سوی مشتریان و پدیدار شدن تکنولوژی های جدید، تغییر می کند.مقایسه معماری نرم افزار و نقشه ساختمان2: معرفی کلی C4:روش C4 یک روش برای مستند سازی معماری نرم افزار است که به توسعه دهندگان نرم افزار کمک می کند تا بتوانند معماری کد های یک سیستم نرم افزاری را در سطوح مختلف توصیف کنند. نام این روش برگرفته از 4 نموداری است که این روش از آن ها برای مستند سازی یک نرم افزار استفاده می کند، این نمودار ها عبارت اند از: 1: Context Diagram (سطح اول) 2: Container Diagram (سطح دوم) 3: Component Diagram (سطح سوم) 4: Code Diagram (سطح چهارم)هر چه از سطح اول به پایین تر می آییم، به جزییات نزدیک تر می شویم. یعنی به عنوان مثال اگر Context Diagram یا همان نمودار مولفه را باز کنیم و جزیی تر به آن نگاه کنیم، به Container Diagram می رسیم و به همین ترتیب تا انتها. در واقع این روش این امکان را به ما می دهد که بتوانیم روی هر بخش از معماری نرم افزار زوم کنیم و به صورت جزیی تر به اجزای داخلی آن بخش پی ببریم. شکل زیر نمایانگر جزییات روابط بین این 4 نمودار است:سطوح مختلف نمودار های رویکرد C4در ادامه به تفصیل به توضیح هر کدام از این نمودار ها خواهیم پرداخت.1-2: Context Diagram:Context Diagram نمایانگر ارتباطات یک سیستم نرم افزاری با دنیای بیرون است. این دنیای بیرون می تواند شامل کاربران و یا سایر سیستم ها باشد. درک این نمودار برای افرادی که دارای دانش فنی نیستند هم بسیار راحت است. مثالی از این نمودار را در شکل زیر می بینیم:مثالی از نمودار Context یک سیستم نرم افزاری بانکیشکل فوق نمودار مولفه یک سیستم بانکداری اینترنی یا همان Internet Banking System است. این سیستم با سیستم های دیگری مانند سیستم ایمیل (E-mail System) و سیستم پردازنده مرکزی (Mainframe Banking System) در ارتباط است. همچنین با کاربرانی که مشتری نامیده می شود (Personal Banking Customer) نیز در ارتباط است.این نمودار همچنین نوع رابطه بین اجزا را نیز بیان می کند. به عنوان مثال سیستم بانکداری اینترنتی، از سیستم ایمیل برای ارسال ایمیل استفاده می کند. همچنین مشتریان به کمک سیستم بانکداری اینترنتی می توانند موجودی خود را ببیند و عملیات گوناگون مانند پرداخت انجام بدهند.2-2: Container Diagram:در سطح دوم، Container Diagram قرار دارد. بیایید ابتدا با مفهوم Container آشنا شویم. Container یک واحد مستقلی از یک سیستم نرم افزاری است که می تواند به صورت خودجوش و با اتکا بر خود اجرا شود. یک برنامه دسکتاپ یا یک برنامه موبایل نمونه هایی از Container هستند. حال وقت آن است که مثال بانکداری را در نظر بگیریم. اگر بخواهیم این نمودار را برای سیستم بانکداری اینترنتی ترسیم کنیم، به شکل زیر می رسیم:مثالی از نمودار Container برای سیستم بانکداری اینترنتیهمانطور که در شکل فوق مشخص است، Container هایی مانند اپلیکیشن موبایل (Mobile App) و اپلیکیشن یک صفحه ای (Single-Page Application) و اپلیکیشن وب (Web Application) و API Application و پایگاه داده (Database) در این سیستم وجود دارند. همچنین روابط بین این اجزا نیز نشان داده شده است. مثلا اپلیکیشن موبایل، به کمک API، از پایگاه داده اطلاعات را می خواند و به کاربر نمایش می دهد. گرپه هر کدام از این Container ها می توانند با سایر Context ها نیز در ارتباط باشند، مثلا API ها برای ارسال ایمیل از سیستم ایمیل استفاده میکنند.3-2: Component Diagram:در این نمودار جزییات هر کدام از Container ها نشان داده می شود و Container ها به اجزای ریز تر خرد می شوند و نشان داده می شود که هر Container از چه Component هایی ساخته شده است. همنین ارتباط هر Component با سایر Component ها و Container ها و سیستم ها و کاربران نشان داده می شود.برای مثال اگر بخواهیم Component Diagram سیستم بانکداری اینترنتی را رسم کنیم به شکل زیر می رسیم:مثالی از نمودار Component برای سیستم بانکداری اینترنتیبه عنوان مثال Reset Password Controller که یک مجموعه کد است که به کاربران این امکان را می دهد که رمز عبورشان را بازیابی کنند یک Component است که برای این کار از Security Component استفاده می کند. همچنین از این Component در اپلیکیشن موبایل جهت بازیابی رمز عبور استفاده می شود.3-2: Code Diagram:آخرین نمودار در روش C4، نمودار Code است. وقتی به جزییات هر Component نگاه می کنیم، به یک سری کد پی می بریم. در واقع هر Component از یک سری کد تشکیل شده است. در این مرحله از استاندارد UML کمک گرفته شده است. پیاده سازی کد ها را می توان به کمک نمودار ها مختلف UML مانند نمودار کلاس و یا ER به تصویر کشید. مثالی از نمودار Codeهمانطور که در شکل فوق مشخص است، در این نمودار جزییات کد زده شده داخل هر Component از جمله کلاس ها، واسط ها، اشیا، جداول پایکاه داده، توابع و ... به تصویر کشیده شده اند. 3: نتیجه گیری: معماری کلی نرم افزار باید یک مستند داشته باشد تا درک نرم افزار برای توسعه دهندگان جدید که به سر کار می آیند راحت تر باشد و از سمت دیگر، در مدت زمان آموزش و یادگیری معماری نرم افزار موجود صرفه جویی شود. یکی از این روش ها برای مستند سازی معماری نرم افزار روش C4 بود که جزییات این روش را با هم دیدیم. تجربه نشان داده است که داشتن مستندات در حوزه معماری نرم افزار در یک پروژه نرم افزاری می تواند کمک شایانی در وقت و هزینه بکند، پس یادگیری این موضوع امری مهم است.4: منابع: https://c4model.comhttps://www.infoq.com/articles/C4-architecture-modelhttps://en.wikipedia.org/wiki/C4_modelhttps://www.gliffy.com/blog/c4-modelاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.#معماری_نرم_افزار_بهشتی #معماری_نرم_افزار #نرم_افزار #مستند_معماری_نرم_افزار