https://virgool.io/feed/@13alirezaalidoosti77 fa 2026-06-17 07:05:47 https://files.virgool.io/upload/users/110617/avatar/avatar.png?height=120&width=120 https://virgool.io/@13alirezaalidoosti77 https://virgool.io/@13alirezaalidoosti77/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%D8%B1-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7%DB%8C-%D8%B4%D8%A7%D9%85%D9%84-ab-%D8%AA%D8%B3%D8%AA-qggyeaqviyv8 مقدمهدر این نوشته سعی میشود برای سیستم های شامل a/b تست معماری ارائه شود که تا حد خوبی دغدغه های ذینفعان و توسعه دهندگان این سیستم ها را کاهش دهد. طبیعی است که موارد استفاده a/b تست در سیستم و اپلیکیشن ها با توجه به نیازمندی ها بسیار متنوع است و امکان اینکه یک نسخه واحد برای معماری همه آن ها در نظر گرفت، شاید ممکن نباشد اما در این مقاله سعی شده با استفاده از مطالعه و تجربه افراد مختلف نیازمندی های پر تکرار و غالب در این تست را جمع آوری و بر اساس آن ها راه کاری ارائه شود.در فضای پر رقابت امروزی داشتن بازخورد کاربر و تجربه آن نسبت به هر تغییر یا ویژگی جدید برای تصمیم گیری درست نسبت به تغییر، ماندگاری یا حذف استراتژی کنونی بسیار مهم است همچنین امروزه ایده های (بعضا مشترک) زیادی به سرعت توسط شرکت های مختلف توسعه داده میشود که اهمیت اینکه بین این ایده ها کدام یک بهترین نتیجه را به همراه خواهد داشت و به چه شکل متناسب با نیازمندی های ما باید در سیستم ماندگار شود بسیار زیاد است. بنابراین برای اینکه بهترین تصمیم گیری را داشته باشیم خوب است همیشه بتوانیم بازخورد کاربر را داشته باشیم و امکان مقایسه بین حالت های مختلف پیاده سازی یک نیازمندی را (که تا حد امکان به جز تفاوت در موارد از پیش تعیین شده و توافق شده، در شرایط یکسان توسط کاربر تجربه شده باشند) داشته باشیم.در مورد a/b تستاین تست برای این است که شما تاثیر تغییر یا افزودن یک ویژگی مشخص را در دو استراتژی و طراحی جدا، از تحلیل روی بازخورد مشتری یا اطلاعات دریافتی از کاربر مشخص کنید و بوسیله ی این نتیجه گیری و مقایسه بهترین تصمیم را برای ماندگاری یکی از روش ها بگیرید.معمولا افراد وقتی برای بار اول در مورد a/b تست جست و جو میکنند مقالات سعی میکنند با ترکیبی از تست قناری و یک مثال در مورد تغییر یک قسمت از فرانت اپلیکیشن (مثلا تغییر رنگ یا تعویض مکان یک button)این تست را توضیح دهند، همچنین نمونه های کمی از تجربه شرکت های بزرگ در زمینه به کار گیری این نوع تست وجود دارد. در این نوشته سعی شده است تمرکز بیشتری روی موارد کاربرد این نوع تست در نیازمندی های دیگر به خصوص در سمت بک اند (به طور مثال استفاده از مدل های AI یا یک provider خارجی) شود.مشکلات توسعه دهندگان برای پیاده سازی یا اجرای a/b تستاین مشکلات برای سیستم هایی که همواره در حال توسعه و اجرای سناریو های مختلف a/b تست هستند پیش می آید و اگر سیستم کوچکی وجود دارد یا تعداد بسیار محدود a/b تست با سناریو های مشابه در آن صورت با این دست مشکلات مواجه نخواهد شد.همان طور که گفته شد امروزه این نوع تست بسیار پر کاربرد هستند و نیازمندی های جدید از سمت cator های مختلف(تیم مارکتینگ، فنی و ....) برای اجرای a/b تست را میتوان به دو دسته کلی زیر تقسیم کرد:در مواردی تغییرات سیستم برای اجرای این تست ها زیاد است و اکثرا از نوع نیازمندی جدید هستند بنابراین ضرورت توجه به معماری نرم افزار که قابلیت ایجاد تغییرات یا اضافه شدن قابلیت یا سناریو جدید با حداقل تاثیرات منفی در ساختار موجود بسیار مهم استدر بسیاری از موارد شامل کارهایی از یک جنس هستند، بنابراین این با ایجاد فرآیند برای دسته های مختلف تست به سمت automate شدن تعریف و اجرای b/a تست ها میروند که تیم فنی در برخی سناریو ها ضرورتی به درگیر شدن ندارد .automate شدن این فرآیند ها در صورتی که معماری درست و maintainable نداشته باشیم تقریبا غیر ممکن است.موضوع مهم توانایی سیستم برای پذیرش تعداد بالای این تست ها با سناریو های متفاوت است که حتما باید در طراحی معماری آن مواردی در نظر گرفته شود در غیر این صورت سیستم توانایی پیاده سازی این نوع تست ها را نخواهد داشت.نیازمندی های غیر کارکردی مهم برای معماری این نوع از سیستم هامعماری این سیستم ها برای اینکه بتوانند نیازمندی های مطرح شده از سمت actor های مختلف برای اجرای سناریو های متفاوت تست را در کمترین زمان ممکن پاسخگو باشند (اهمیت زمان در بسیاری موارد به دلیل فضای رقابتی بین شرکت های مختلف است) باید شامل یک سری ویژگی ها باشند که در قسمت زیر به تفکیک نام برده شده اند: نیازمندی Maintainabilityانعطاف پذیری سیستم برای پیاده سازی سناریو های تست و نیازمندی ها مرتبط با آن به نوعی که روند معمول توسعه و نگهداری سیستم را با مشکل مواجه نکند(زیرا همان گونه که گفته شد در مورد سیستم های بزرگ با تعداد اجرای بالای سناریو های a/b تست صحبت میکنیم). در بسیاری از سناریو های تکراری ایجاد روند اتوماتیک برای اجرای a/b تست ضروری است زیرا در غیر اینصورت علاوه بر کند شدن روند اجرای تست تیم توسعه و فنی درگیر فرایند های تکراری میشود. استفاده از معماری میکروسرویس برای پاسخگویی به موارد ذکر شده و maintainable بودن توصیه میشود زیرا با جداسازی منطقی بخش های مختلف سیستم در سرویس های مشخص به راحتی میتوان با توجه به تعریف، سطح (نزدیکی به بیزینیس لاجیک) و پیچیدگی آن a/b تست های مرتبط با هر کدام از سرویس ها را مشخص کرد. به عنوان مثال سرویس مرتبط با پرداخت و سرویس نمایش موجودی و تراکنش ها ی کاربر در معماری میکروسرویس به صورت دو سرویس جداگانه هستند که سناریو های a/b تست متفاوتی هم دارند (برای سرویس پرداخت استفاده از درگاه های پرداخت مختلف و برای سرویس نمایش تغییر فرمت و رنگ های نمایش و ...). بنابراین با تفکیک سرویس ها علاوه بر جداسازی دغدغه ها و نیازمندی ها بین سرویس ها و تیم های جداگانه میتوان طراحی و راه حل های اختصاصی برای هر یک از سرویس ها متناسب با وظیفه و کارکرد آن ها داشت، این کار روند خودکار سازی سناریو های تکراری a/b تست را هم بسیار راحت تر میکند،به عنوان مثال سرویس های یکسان صرفا با کانفیگ های مختلف در production بالا بیایند که باعث میشود عملکرد مورد نیاز برای a/b تست را داشته باشند.نیازمندی availability and reliabilityبا توجه به اینکه b/a تست ها در بازه زمانی خاصی اجرا میشوند و نتایج بازخورد کاربر یا به طور کلی تغییرات در بازه خاصی برای مقایسه و اعتبار سنجی تست انتخاب میشوند در صورتی که سیستم در این بازه زمانی در دسترس نباشد یا عملکرد درست خود را از دست بدهد میتوان گفت سیستم قابلیت اجرای این نوع از تست ها را ندارد. فیدبک یا رفتار کاربر در a/b تست ذخیره میشود تا بوسیله تحلیل روی این داده ها و مقایسه گروه های مختلف وضعیت تاثیر تغییرات جدید و مقایسه بین عملکرد گروه های مختلف صورت بگیرد, بنابراین اجرای a/b تست ها برای همه گروه ها باید با شرایط درست و یکسانی اجرا شود. اگر تفاوتی در اجرای تست گروه ها به دلیل خطاها، در دسترس نبودن سرویس یا مشکل در بخشی از امکانات و ابزار های مورد نیاز آن ها باشد دیگر داده های جمع آوری شده در زمان a/b تست قابل استناد نیستد.نیازمندی Performanceبا توجه به اینکه در b/a تست گروه های مختلف تست بوجود می آید که رفتار های های متفاوت دارند و در مواردی نیازمند منابع اضافه (ذخیره داده های مربوط به ورودی و خروجی قسمت یا قسمت های مورد تست، تغییر مدل AI که نیاز به داده بیشتری برای predict کردن دارد،اضافه کردن سرویس جدید و افزایش تعداد connection های بین سرویس ها و ...) در سرویس ها یا ابزار های مورد استفاده خود هستند باید توجه داشت performance سیستم تحت تاثیر قرار نگیرد. البته باید درنظر گرفت منظور از performance در اینجا performance ویژگی های مورد تست نیست و performane موارد a و b در a/b تست میتواند در تحلیل نهایی تاثیر گذار باشد(مثلا performance دو الگوریتم برای محاسبات مالی) ، یعنی مثلا با افزایش منابع یکی از موارد a یا b (به صورتی که بیشتر از نیازمندی منطقی آن ها باشد) در a/b تست باعث نابرابری در شرایط تست آن ها شویم و در نهایت با توجه به نادرستی داده های تست دچار نتیجه گیری اشتباهی شویم.استفاده از ابزار های مناسب (مثلا دیتابیس، cache و ...) با نیازمندی های تست نیز در performance تاثیر گذار است (مثلا استریم داده ها در kafka و ذخیره آن ها در فرمت مناسب در دیتابیس nosql یا sql)نیازمندی Scalabilityدر مواردی زیادی از سناریو های a/b تست شاهد ایجاد نیازمندی جدیدی هستیم، که در بسیاری از این موارد باید سرویس و ساختار فعلی ما بدون تاثیرات منفی (هزینه زمان و منابع زیاد، تغییرات زیاد ساختاری و ...) قابلیت رشد داشته باشد. به طور مثال قابلیت پردازش داده های بیشتر، قابلیت پاسخ به درخواست های بیشتر، توانایی scale شدن متناسب با حجم پردازش یا تعداد درخواست ها و ... همچنین باید ابزار های وابسته به سرویس ها یا ماژول هم scalable باشند. به طور مثال فضای ذخیره سازی داده ها یا استریم های مورد استفاده باید قابلیت دریافت حجم بیشتری از داده ها را در زمان تست داشته باشند.نیازمندی Monitoring and logاهمیت وجود مانیتورینگ برای سیستم های نرم افزاری بسیار مهم است و از کاربرد های آن میتوان به شناسایی رفتار سیستم در بازه های مختلف زمانی، دلیل رفتار های غیر معمول، وضعیت منابع، گزارش گیری و... را نام برد. تمامی موارد نام برده شده در اجرای تست و تحلیل آن بسیار مهم است. اگر در بازه زمانی تست مشکلی ایجاد شود با سرعت بالایی قابل شناسایی و علت یابی است، همچنین تاثیر تغییرات جدید مورد تست در رفتار سیستم یا سرویس های مختلف مرتبط با آن قابل شناسایی است. زمان تحلیل ممکن است بوسیله monitoring بتوان دلایلی برای برخی تفاوت ها و مشکلات بیان کرد، به طور مثال ممکن است در یک سناریو تست، response time در گروه تست provider جدید بسیار بالا باشد ولی مشکلی از سمت provider نباشد بلکه دیتابیس مورد استفاده یا سرویس دیگر که در فرایند ایجاد response حضور دارند کند شده باشند یا تعداد خطاهای آن ها بالا رفته باشد، که با بررسی مانیتورینگ های مربوطه میتوان به راحتی علت را یافت و در مواردی به راه حل رسید (مثلا تغییر بازه زمانی اجرای a/b تست و انتفال آن به ساعات با ترافیک ورودی کمتر).همانطور که قبلا اشاره شد قسمت مهمی از فرآیند a/b تست زمان تحلیل آن است. باید در سیستم و سرویس لاگ های مناسب همراه داده های مهم و ضروری وجود داشته باشد تا امکان trace کردن سناریو ها و خطاها وجود داشته باشد. در صورت نبود این امکان یا پیاده سازی نشدن دقیق و درست آن تحلیل مشکلات بوجود آمده در زمان اجرای تست یا تحلیل خروجی آن بسیار دشوار و حتی در مواردی غیر ممکن میشود. در مواردی ممکن است با وجود در نظر گرفتن تمامی شرایط و نکات مربوط به پیاده سازی و اجرای تست خطا یا مشکالتی در حین اجرا مشخص شود که به دلایل خارجی باشد (مشکالت سرور, اینترنت یا دیتابیس و ...) که برای تشخیص درست، به موقع و تصحیح یا گزارش دقیق آن نیازمند ثبت وقایع در سیستم هستیم. داده های موجود در log management میتواند در نتیجه نهایی تست هم تاثیر گذار باشد و یا حتی قسمتی از داده های لازم برای تحلیل به حساب بیایند. به طور مثال فرض کنید در تستی نتیجه تحلیل دو گروه شباهت زیادی دارد و تغییری در رفتار کاربران ایجاد نشده ولی تغییر جدید، درصد خطاهای موجود در سیستم را کاهش داده که میتواند باعث برتری ویژگی جدید شود. استفاده از ابزار مناسب که دارای داشبورد user friendly و امکانات جست و جو و گزارش گیری باشد بسیار مهم استنیازمندی Documentضرورت وجود داکیومنت برای سیستم هایی که ساختار اجرای a/b تست ها را دارند و این نوع تست ها در آن ها به دفعات اجرا میشود بالا است. باید نوع جدا سازی،دلایل و طراحی component و module ها مشخص و وجود داشته باشد و actor های مرتبط با آن ها (اینکه تست نیازمندی تیم های مختلف مانند مارکتینگ،فنی و ... باشد) بوسیله نمودار های use case digram قابل تشخیص باشد. در این صورت علاوه بر این که نیروهای جدید شرکت به راحتی با قسمت های مختلف سیستم و عملکرد آن ها آشنا میشوند، تشخیص نوع نیازمندی های جدید (به کدام بخش سیستم مربوط میشود) برای اجرای تست و تکراری بودن سناریو یا جدید بودن آن برایشان آسان میشود و جلوی دوباره کاری های احتمالی با وجود نیرو های جدید گرفته میشود. همچنین به دلیل وجود دلایل طراحی سیستم در صورت برخورد با نیازمندی جدید که نیاز به تعریف فرایند جدید تست و اجرا دارد به راحتی و در زمان کمتری امکان پیشنهاد راه حل جدید وجود خواهد داشت. همچنین فرایند automate کردن تست ها برای تیم فنی با وجود document های به روز بسیار دقیق تر و راحت تر انجام خواهد شد.پیشنهاد یک pattern معماری برای سیستم های شامل A/B تستهمانطور که در مقدمه نیز اشاره شد این pattern با توجه به دغدغه ها و نیازمندی های پر تکرار و مشترک طراحی در نموونه های a/b تست طراحی شده است و امکان تغییر آن متناسب به نیازمندی ها به خصوص وجود دارد.اجرای یک a/b تست معمولا نیازمد این هستیم که یک بخش و منطق مشخص و به خصوص در سیستم را به روش دیگر یا به نوع دیگری استفاده کنیم و سپس روی نتایج به کارگیری آن ها در بازه مشخص تحلیل کنیم.حال هر چه این بخش مورد نظر برای تغییر دارای وابستگی های کمتر (مستقل تر) و پیچیدگی کمتری باشد کار راحت تری از نظر حجم تغییرات و سهولت پیاده سازی و تغییرات برای اجرای تست داریم. بنابراین اگر با سیستمی رو به رو هستید که کوچک است و وابستگی ها (بین سرویس ها یا ماژول ها) و پیچیدگی های کمی دارد شاید بهتر است تغییری ایجاد نکرد زیرا ممکن است صرفا پیچیدگی به پیاده سازی و معماری اضافه شود.این پیشنهاد به دو بخش تقسیم میشود که شامل بخش ها و اعمال مورد نیاز برای قبل از اجرا ی a/b تست (پذیرش a/b تست) و اجرای آن است (که بوسیله آن کار خودکار سازی این تست ها ممکن میشود) البته همانطور که گفته شد تمرکز بیشتر سمت نیازمندی های سمت بک اند است.پیش از اجرای a/b تستزمانی که task یک a/b تست جدید مطرح میشود معمولا actor های آن ها اگر از سمت تیم فنی نباشد جزییاتی فنی در مورد اجرای آن نادیده گرفته میشود(مثلا منابع اضافه مورد نیاز، dependency ها پکیج های جدید یا تغییر ورژن آن ها و ....) زیرا آن ها دیدی نسبت به این جزییات ندارند و نباید هم داشته باشند و این تیم فنی است که باید همیشه نسبت به تغییرات جدید و قسمت های فنی آن آگاهی داشته باشد و اگر این تغییرات نیازمند آمادگی (مثلا خرید سخت افزار، آپدیت ورژن نرم افزاری، تعیین پکیج جدید و ...) هستند آن ها را در نظر بگیرد و اگر باعث ایجاد خرابی و مشکلات (افزایش باگ ها و هزینه ها و ...) میشود آن ها را اطلاع رسانی کند در غیر این صورت اجرای a/b تست های زیاد بدون پیش بینی های گفته شده باعث مختل شدن روند کار معمولی سیستم میشود و به نوعی کل بیزینس را تهدید میکند که این بر خلاف فلسفه این تست است.البته باید توجه داشت اگر سناریو های a/b تست منطقی و در چهارچوب همیشگی و توافق شده مطرح شوند ولی سیستم و نرم افزار ما توانایی پیاده سازی آن را نداشته باشد یا با هزینه زیاد این کار را بکنند مشکل از معماری و طراحی سیستم است و باید تغییر بکند.به همین خاطر همیشه باید وضعیت فعلی سیستم از لحاظ منابع مورد استفاده (و حداکثر منابع موجود)، پکیج ها و dependency ها و ... را داشته باشیم و در صورت مطرح شدن سناریو جدید ابتدا نیازمندی ها، تغییرات و کانفیگ های سیستم را بررسی کنیم سپس به سمت اجرای تست برویم زیرا این کار روند اجرای آن را ساده تر میکند و جلوی خرابی و دوباره کاری ها را میگیرد.به طور مثال فرض کنید در یک سیستم یک سرویس پیش بینی وضعیت آب و هوا را میکند، که این سرویس از یک provider خارجی به نام گوگل استفاده میکند، حالا از سمت یک تیم (به جز تیم فنی) در خواست استفاده از یک provider دیگر به نام X مطرح میشود (به دلیل قیمت کمتر آن نسبت به گوگل) که برای اطمینان از علکرد درست آن و بد تر نکردن تجربه کاربر ها باید روی این دو مورد a/b تست انجام شود.ابتدا باید مواردی مثل response time این provider با توجه به در خواست های اپلیکیشن ما (استفاده از load test) بررسی شود یا تعداد exception های آن زیرا ممکن است این provider با استاندارد های سیستم و بیزینس ما نخواند و اصلا نیازمند اجرای a/b تست برای آن نباشیم.همچنین در این حالت باید در این سرویس برای پرسیدن پیش بینی آب و هوایی چند برابر I/o مصرف شود (از دو provider نتایج گرفته شود و با وضعیت آب و هوایی واقعی آن روز مقایسه شود، برای ذخیره نتایج در دیتابیس و ...)، این مورد نباید response time ، performance و به طور کلی روند کار طبیعی سیستم را دچار مشکل کند. به همین دلیل تیم فنی باید قبل از اجرای a/b تست منابع مورد نیاز (دیتابیس، I/O و ...) را در نظر بگیرد.بنابراین باید در documentation های خود همواره وضعیت نهایی سیستم از لحاظ کانفیگ ها، resource ها، حجم درخواست ها، استاندارد های خودمان برای حداکثر response time و exception rate و ... را داشته باشیم و به روز نگه داریم، همچنین قابلیت انجام مواردی مثل load test و تست های مورد نیاز دیگر را بر روی سرویس داشته باشیم.اجرای a/b تستدر این بخش در مورد نکاتی گفته میشود که روند اجرا و خودکار سازی a/b تست ها را ساده مکیند برای این کار همانطور که قبلا هم گفته شد داشتن معماری میکروسرویس تا حدی خوبی لازم است.برای طراحی این pattern ابتدا فرایند a/b تست را به سه بخش سناریو، موجودیت تست و کانفیگ های تست تقسیم میکنیم، ابتدا هر بخش و استفاده آن را توضیح میدهیم و در آخر آن ها را ترکیب و نحوه کمک کردن وجود آن ها در معماری نرم افزار سیستم های شامل a/b تست را ذکر میکنیم.سناریو تست: سناریو تست شامل طراحی کلی تست است یعنی تست باید شامل چه موجودت های تستی باشد (مورد a و b) ، نیاز به تقسیم ترافیک دارد و اگر آره بر چه اساسی (مثلا یوزر آیدی های زوج برای موجودیت a و یوزر آیدی فرد برای موجودیت b)، استریم و ذخیره نتایج (schema، نوع دیتابیس و اطلاعات لازم) برای تحلیل، نوع تفکیک موجودیت ها برای تست (جداسازی بر اساس سرویس یا بر اساس لاجیک)، بازه زمانی اجرای تست، کاربران تحت تاثیر (منطقه جغرافیایی و ...) و. موارد دیگری که همه برای اجرای صحیح a/b تست نیازمند مشخص شدن هستند.موجودیت تست: موارد مورد تست (a و b) در یک سناریو a/b تست، که میتواند شامل تغییرات جدید برای ایجاد یک موجودیت تست، نیازمندی های موجودیت جدید (منابع، ابزار، پکیج ها و ورژن آن ها و ...)، سرویس های تحت تاثیر (مجموعه از سرویس ها برای ایجاد یک موجودیت تست مورد نیاز است یا سرویس هایی که با اجرای a/b تست درگیر میشوند)، موجودیت های تست تکراری و جدید (موجودیت های پیاده سازی شده که میتوانند مجدد استفاده شوند یا موجودیت جدید که نیاز به پیاده سازی دارند)کانفیگ های تست: فلگ ها و تنظیماتی که مشخص کننده عملکرد سناریو تست است که در فرایند خودکار سازی وجود آن ها بسیار لازم است.این کانفیگ ها میتوانند شامل مواردی مثل موجودیت های مورد استفاده در تست (موجودیت های پیاده سازی شده که امکان انتخاب را بدهد)، نحوه تقسیم ترافیک بین موجودیت های تست (مثلا بر اساس یوزر آیدی یا منطقه جغرافیایی)، مدت زمان اجرای تست یا بازه زمانی آن، استریم و ذخیره نتایج داده ها.سناریو های تست بسته به کانفیگ های تست که بر اساس طراحی و نیازمندی های تست از بین موجودیت های تست برای اجرای سناریو انتخاب میکند همچنین آن ها را با توجه به طراحی فراخونی (مثلا فراخوانی به صورت هم زمان یا بر اساس ترافیک تفسیم شده و ورودی و ...) میکند. در واقع سناریو تست چگونگی مقدار دهی کانفیگ ها استفاده از موجودیت های تست را مشخص میکند. حال اگر معماری سیستم به صورت میکروسرویس باشد و قسمت های مختلف سیستم با توجه وظایف و موضوع آن ها به درستی تفکیک شده باشد ایجاد این pattern در آن ها به سادگی بیشتری انجام میشود زیرا این سرویس ها تا حد ممکن به صورت مستقل هستند (تیم های مجزا روی آن ها کار میکنند) و برای ایجاد یک موجودیت تست یا اجرای سناریو های a/b تست با حداقل تغییرات و در کمترین زمان بدون تاثیرات منفی (بر روی سرویس های نا مرتبط) میتوان این کار را صورت داد. در واقع در این حالت با توجه به سناریو تست و نحوه استفاده از موجودیت های تست میتوان به شکل های مختلفی موجودیت های مختلف تست را ایجاد کرد.مثلا صرفا با توجه کانفیگ های تست سرویس ها را به نوعی deploy کرد که عملکرد مورد انتظار موجودیت تست را دشته باشند (مثلا کانفیگ استفاده از یک provider یا دانلود یک مدل AI متناسب با موجودیت تست) که این حالت میتواند کار اجرای تست را بسیار راحت کند اما در صورتی که موجودیت های مختلف در سرویس پیاده سازی شده باشند برای استفاده از آن ها بهتر است منطقی وجود داشته باشد که بر اساس ورودی هایش از موجودیت های مختلف استفاده کند (مثلا بر اساس ورودی یوزر آیدی یکی از حالت های نمایش را انتخاب کند). در این حالت زمانی که باید یک a/b تست اجرا شود ابتدا باید مشخص شود این سناریو تکراری است یا خیر که بر اساس اینکه نیازمندی تکراری است یا نه، موجودیت های تست تکراری است یا خیر، کانفیگ های موجود کافی است یا خیر و ... میتوان این مورد را تشخیص داد، حال اگر سناریو تکراری است که میتوان این مورد را دوباره بدون هزینه پیاده سازی اجرا کرد البته باید همیشه توجه داشت نتایج تست را متناسب با نیازمندی ها و چک کردن با actor ها یا data analyst ذخیره کرد زیرا اگر ساختار نتایج به صورت ناقص (بدون فیلد های مورد نیاز در schema) ذخیره شود امکان تحلیل روی آن ها از دست میرود، در غیر اینصورت باید قسمت های جدید و غیر تکراری را مشخص کرد که در این حالت بیشترین هزینه مربوط به پیاده سازی موجودیت جدید است البته در این حالت اگر به خوبی لاجیک های کد تفکیک شده باشد و تا حد ممکن ارتباطات آن ها به صورت بهینه تعریف شده باشد این تغییرات زمان و هزینه زیادی را از تیم فنی نخواهد گرفت. در نهایت با ایجاد تغییرات مورد نیاز میتوان تست را اجرا کرد.خودکار سازی فرایند a/b تستبا توجه به مواردی که گفته شد این کار به راحتی صورت خواهد گرفت و actor هایی که نیازمندی های یک a/b تست را مطرح میکنند میتوانند به وسیله یک واسط کاربری که امکان تغییرات بر روی کانفیگ های سناریو های تست را میدهد این کار را انجام دهند. البته برای این کار نیاز به استفاده از ابزار های درست و مناسب (یا حتی هماهنگی و دریافت مجوز از تیم های فنی نیز ممکن است باشد) است اما با ایجاد فرایند آن دوباره کاری ها برای اجرای a/b تست ها و هزینه های این چنینی در تیم فنی کم یا صفر میشود. Alireza Alidoosti Alireza Alidoosti Thu, 02 Feb 2023 23:19:27 +0330 https://virgool.io/@13alirezaalidoosti77/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%D8%AA%D8%B9%D8%AF%D8%A7%D8%AF%DB%8C-%D8%A7%D8%B2-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-%D9%85%D9%87%D9%85-%D8%AF%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-u8txolozxeil Domain Driven Designبه طور کلی یعنی معماری نرم افزار ما با domain آن مشخص شود. منظور از domain موضوع اصلی که نرم افزار حول آن توسعه داده میشود است. البته در بسیاری موارد ممکن است یک نرم افزار شامل موضوعات متفاوتی باشد یا نتوان به راحتی تفکیک میان domain ها را داشته باشیم، در این حالت باید موضوعات مختلف موجود در نرم افزاربه صورت جداگانه مورد بررسی قرار داده شوند که هر کدام محتوا و متخصصان domain خود را خواهند داشت (bounded context). با استفاده از این جداسازی کار بر روی هر یک از domain ها و مدیریت آن ها راحت تر جلو میرود.DDD راه حلی برای توسعه نرم افزار هایی است که پیاده سازی آن ها به شدت با مدل بیزینسی و domain بیزینس ارتباط دارد و ارتباط بین توسعه دهندگان و افراد آشنا به بیزینس را بسیار راحت تر خواهد کرد. به همین دلیل DDD بیشتر در نرم افزار ها یا سازمان های بزرگ کارایی دارد. برای ارتباط راحت و کارا بین توسعه دهندگان و افراد آشنا به بیزینس از زبان ubiquitous استفاده میشود تا با وجود زبان مشترک کار انتقال مطالب سریعتر و راحت تر باشد همچنین ابهامات در گزارشات و بیان مطالب بین این دو گروه از بین برود.Hexagonal architectureنام دیگر آن port and addaptors است.در واقع Hexagonal architecture یک design pattern برای نرم افزار هایی است که باید بسیار maintainble باشند. اولین بار به عنوان را حل برای مشکلات موجود با object orient سیستم ها مطرح شد. این pattern میگوید تغییرات هرچه سریعتر تر روی سیستم اعمال شوند بهتر است همچنین این pattern سعی میکند موارد و تعداد technical dept ها را حداقل کند که نتیجه این موارد باعث میشود راحت تر بتوان سیستم را maintain کرد. نمایش این pattern به شکل ۶ ضلعی است با این وجود اصرای بر وجود ۶ port در پیاده سازی نیست و به توسعه دهندگان و نیازمندی ها بستگی دارد.موجودیت های pattern:پورت: در واقع interface هایی هستند که فرمت دیتای خروجی را مشخص میکنند و شامل دسته بندی زیر میشوند:پورت Primary: ارتباط سیستم با دنیای خارج که بعد از دریافت درخواست کلاینت لاجیک های سیستم را اجرا میکند(سمت راست ۶ ضلعی)پورت Secondary: برای ارسال و دریافت دیتا از موجودیت های بیرونی که معمول ترین آن دیتابیس ها هستند(سمت چپ ۶ ضلعی)آداپتور: برای ارتباط بین لایه های مختلف بوسیله port ها که در این حالت ارتباطات بین لایه و تغییرات در آن ها تاثیری روی منطق سطح بالا (core logic) نمیگذارد و هر adapter به صورت مستقل کار میکند (به طور مثال ممکن است چندین adapter برای یک core تعریف شود که مستقل هستند و تغییرات آن ها تاثیری روی core نخواهد داشت). Adapters هم شامل دسته های Primary و Secondary میشود.CQRSمخفف Command and Query Responsibility Segregation است و یک pattern برای تفکیک فرایند read و write داده در database است. در روش های قدیمی فرایند write و read از یک موجودیت استفاده میکند که برای استفاده های پیچیده و سنگین به دلیل اینکه در سمت خواندن شامل query های متفاوت و در سمت write شامل policy های متنوعی میباشد ممکن است با یک مدل بیش از حد پیچیده که بار زیادی روی آن هست روبه رو شویم. در روش تعریف شده که تا حد زیادی مشابه event sourcing هست و در واقع کار query زدن روی event sourcing را حل میکند دیتا به صورت لاگ های مجزا وارد یک صف میشوند و در واقع ما تاریخچه ای از وقایع را نگهداری میکنیم پس از این مرحله دیتابیس ما قرار دارد که read کردن از آن اتفاق میافتد.در واقع write دیتا مجموعه از وقایع را تشکیل میدهد که این لاگ ها باعث update و insert دیتا در پایگاه داده میشود. پس از write یا ایجاد یک واقعه یک لاگ برای آن ثبت و در صف قرار میگیرد حالا دیتابیس که حساس به ورود لاگ است update میشود و در نهایت فرایند read از این ماژول اتفاق میافتد.اگر بخواهیم در زمان read روی لاگ ها پردازش داشته باشیم بسیار کند میشویم. این راه حل باعث بهبود ویژگی های performance , scalability و security میشود. البته به دلیل جدا شدن فرایند read و write ممکن است inconsistency داشته باشیم.MVVMیک design pattern است که تمرکز اصلی آن بر روی جدا سازی لاجیک برنامه از کنترلر های interface است. این design pattern با نام model view binder هم شناخته میشود و توسط microsoft ایجاد شده است. این روش سعی میکند تا برنامه را به ماژول هایی تقسیم بندی کند که کار توسعه، بروزرسانی و نگهداری سیتم را راحت تر کند. این طراحی شامل view، view model و model میشود:بخش View:شامل interface ها برای کاربران و ui های برنامه میشود که با view model ارتباط دارد و از آن استفاده میکند.بخش View model:واسطی بین model و view است و وظیفه دریافت دیتا و آماده کردن آن را برای view را دارد. به نوعی وضعیت داده در model را توصیف میکندبخش Model: در این موجودیت دیتا و لاجیک اصلی قرار دارد که نمیتواند به صورت مستقیم با view ارتباط داشته باشد بلکه view model واسط بین آن ها استدر این طراحی سعی شده ui از لاجیک اصلی(بیزینسی) برنامه تفکیک شود و همین موضوع باعث میشود طراحی قابل فهم و تست باشد همچنین توسعه دهندگان و designer ها میتوانند به راحتی کنار یکدیگر کار کنند.همچنین باعث میشود قسمت ها و مدل های مجزا قابلیت reuse را داشته باشند به طور مثال برای لاجیک اصلی چندین نوع ui متفاوت برای web,mobile app و … تعریف شود.Event Sourcingدر این روش برخلاف حالت معمول برای ذخیره و دریافت اطلاعات که در آن همیشه حالت نهایی ذخیره میشود و در واقع با ایجاد هر رویداد رکورد متناظر با آن update میشود، برای هر واقعه و درخواست یک لاگ insert میشود. این روش برای کاربرد هایی که نیاز به تاریخچه رویداد ها دارند یا حتی توالی این رویداد ها برای آنها مهم است کاربرد دارد. در event sourcing مجموعه رویداد ها به صورت لاگ در سیستم در نظر گرفته میشود و برای حفظ توالی آنها به صورت دنباله ای از وقایع ذخیره میشوند. سیستم برای ذخیره رویداد ها از event store استفاده میکند که پایگاه داده ما برای ذخیره وقایع هست. این پایگاه داده ها که باید ویژگی حفظ توالی رویداد ها را داشته باشند در واقع دارند مشابه message broker ها عمل میکنند، به این ترتیب شما با داشتن تاریخچه ای از رویداد ها اگر مشکلی در سیستم رخ دهد سناریو ایجاد آن مشکل را خواهید داشت و همواره قادر خواهید بود توالی رویداد ها را ردیابی کنید و راحت تر مشکل را حل کنید. این روش مناسبی برای سیستم های رویداد محور است و چالش های آن ها را حل کرده اما این روش چالش های پیاده سازی دارد که از آن ها میتوان به آشنایی با ابزار های متفاوت پیاده سازی و query زدن برای read کردن دیتا نام برد.Micro Frontendsاین مفهوم تلاش میکند تا مفاهیم میکرو سرویس را وارد دنیای frontend کند. در واقع فرانت اند هایی که به صورت یکجا توسعه، نگهداری و اجرا میشوند هزینه نگهداری و تغییر بالایی دارند به همین دلیل در Micro Frontends سعی می شود فرانت اند به application هایی مستقل و تا حد امکان با کمترین وابستگی شکسته شود.در سیستم های قدیمی به دلیل اینکه کل سیستم به صورت واحد و monolithic است امکان اینکه تیم های توسعه به‌ صورت مستقل از هم کار کنند و وابستگی به هم نداشته باشند وجود ندارد همچنین هزینه نگهداری آن به مرور افزایش می یابد زیرا پروژه سنگین تر و پیچیده تر می شود. در این حالت مجموعه ای از micro frontend ها کل فرانت اند سیستم را خواهند ساخت که هر کدام به صورت مستقل توسعه و نگهداری میشوند، به همین دلیل تیم های مختلف می‌توانند به صورت مستقل و با کمترین وابستگی روی یک قسمت خاص از فرانت اند کار کنند که کار توسعه، تغییر و نگهداری در هر کدام بسیار کم هزینه تر و راحت تر میشود همچنین تمرکز محصول بیشتر به سمت مشتری می‌رود زیرا هر قسمت به صورت مستقل امکان بهبود و تولید ویژگی های جدید را خواهد داشت. در نهایت برای اجرا و نمایش کل پروژه نیاز است کل این قسمت ها با هم ادغام شوند و خروجی واحد را بسازند.Low Code Platformدر مورد پلتفرم هایی است که می‌توانند با کمترین هزینه اولیه برای توسعه ، پیاده سازی و آموزش راه اندازی و اجرا شوند. بیشتر با توجه به اسم طراحی فکرشان به سمت این می رود که باید سیستم با کمترین مقدار کدی که به صورت دستی توسط توسعه دهندگان نوشته می‌شود به فاز نهایی و اجرا برسد درصورتی که این مفهوم شامل مواردی مثل راحتی نسبی در توسعه و اجرا، پوشش کامل اهداف و نیازمندی ها با کمترین هزینه و سرعت بالای توسعه میشود. بنابراین بسته به حجم و پیچیدگی قابلیت ها یا نیازمندی ها یی که پروژه دارد ممکن است نیاز به توسعه و حجم کد بالایی داشته باشیم تا الزامات برطرف شوند یا ممکن است بدون هیچ کدی امکان پاسخگویی و راه اندازی را داشته باشیم. استفاده از این روش باعث می‌شود یک سازمان بتواند بدون استفاده از تعداد بالای مهندسان نرم افزار و پرداخت هزینه زیاد فرایند جذب و آنبورد آن ها نرم افزار های پیچیده و متناسب با نیاز خود رو تولید کند همچنین توسعه دهندگان با تجربه کمتر و بدون سابقه طولانی می‌توانند نرم افزار های پیچیده را طراحی و راه اندازی کنند. البته از معایب آن میتوان به این مورد اشاره کرد به دلیل نبود درک عمیقی از مفاهیم مهندسی نرم افزار، توسعه دهندگان نتوانند تصمیم های مناسبی در مورد طرز کار سیستم بگیرند همچنین ممکن است در طراحی مواردی مثل ذخیره برخی لاگ ها و وقایع که در بازاریابی ، اشکال یابی و بررسی موارد این چنینی مورد نیاز است نادیده گرفته شوند.ESBیک معماری است که شامل مجموعه ای قوانین و اصول برای ادغام انواع برنامه های کاربردی که توسط توسعه دهندگان و مجموعه های مختلف ایجاد و توسعه داده شده اند. این روش قابلیت ادغام و یکپارچه سازی برخی کاربرد ها را می‌دهد اما نحوه انجام و میزان قابلیت های آن بسته به نیازمندی تفاوت میکند. شما در واقع برای یکپارچه کردن تمامی این برنامه ها یک گذرگاه ارتباطی مشترک بین آن ها قرار می‌دهید و سپس هر برنامه برای ارتباط با دیگران باید از این BUS مشترک استفاده کند. استفاده از این گذرگاه مشترک باعث می‌شود این برنامه ها که معمولا توسعه دهندگان منحصر به فردی دارند بدون وابستگی و آگاهی از یکدیگر تنها از طریق BUS ارتباط برقرار کنند. به دلیل اینکه در ارتباط یک به یک بعد از گذشت زمان و افزایش سرویس ها، مدیریت ارتباط ها سخت و شکننده میشود و همچنین اشکال یابی در ساختار point to point با وجود سرویس های زیاد دشوار میشود نیاز است با وجود یک ساختار مرکزی برای ارتباط بین اجزای مختلف سازمان مدیریت لاگ و ارتباط های بین آن ها بسیار ساده تر شود همچنین تغییرات در ارتباطات بین برنامه ای در این معماری ساده تر انجام می‌شود. علاوه بر این سیستم مقیاس پذیر تر میشود و با ورود یا ایجاد یک سرویس جدید تعریف ارتباطات آن میتواند به راحتی انجام گیرد.API gatewayیک ابزار برای مدیریت api ها که بین client و سرویس هایی که ارائه دهنده api ها هستند است و بین آن ها قرار میگیرد. تمامی سرویس هایی که یک سازمان ارائه می‌دهد بوسیله api gateway در دسترس است و بسیار معمول است که خدمات سازمان ها از این طریق ارائه شوند.در ابتدا گمان میکنیم کل کار به دریافت یک request و پاسخ به آن مربوط میشود اما پارامتر ها و وظایف متنوعی میتواند درگیر شود. برای مثال:شما نیاز دارید تا سرویس هایتان مورد سواستفاده و استفاده بیش از حد مجاز قرار نگیرد بنابراین نیاز به یک سرویس برای احراز هویت یا محدود کننده نرخ استفاده داریداستفاده از ابزار تجزیه تحلیل و نظارت برای شناسایی رفتار مشتریان و چگونگی کار آن ها با api های شمادر صورتی که api های شما شامل هزینه استفاده میشود باید سیستمی برای محاسبه صورت حساب و هزینه ها باشد مثلا بر اساس تعداد درخواست ها و type و نوع درخواست ها یا حتی حجم response برگشتیممکن است برای پاسخ به یک درخواست نیاز به استفاده از چندین سرویس مجزا برای پاسخگویی باشدشما درواقع با استفاده از api gateway میتوانید تمامی پیچیدگی های درون سیستم خود را از دید کاربر پنهان کنید و کاربر بوسیله آن سرویس مورد انتظار خود را بگیرد و این api gateway است که وابسته به درخواست از سرویس های متنوع برای پاسخگویی استفاده میکند.Business Process Management Systems (BPMS)بر اساس نوع کسب و کار و مدل آن این روش برای طراحی، تحلیل، اجرا و پایش فرآیندهای کسب‌ و کارها استفاده میشود. روش های قدیمی تر تنها تمرکزشان بر ری ایجاد مدلی از کسب و کار و اجرای متمرکز آن بوده در حالی که در BPMS سعی میشود فرایند های کسب و کار ها با ورودی و منابع درست و در زمان درست به صورت خودکار اجرا شوند. برای اینکه بیشتر BPMS درک شود میتوان آن را مشابه پکیج های برنامه نویسی دانست که برای یک هدف و نیازمندی ممکن است پکیج های زیادی موجود باشد که کاربر میتواند از بین آن ها انتخاب کند همچنین استفاده از این پکیج ها باعث میشود کابر بدون اینکه درگیر پیاده سازی های داخلی و جزئیات شود از خدمات آن ها استفاده کند. درBPMS هم نرم افزار ها و مجموعه های ارایه دهنده آنها هرکدام دارای ویژگی هایی هستند که کسب و کار ها میتوانند با انتخاب آن ها نیاز هایی که در این زمینه دارند را بدون درگیری در چگونگی پیاده سازی و جزییات فرایند خودکار سازی پاسخ دهند. همچنین به دلیل وجود و راحتی در ابزارهای ساخت، اجرا (پلتفرم) و مانیتورینگ فرایند ها به کاربر های این فرصت داده میشود تا در بهبود و رفع خطاهای فرایند های کسب و کار بوسیله ابزار های ساده مشارکت داشته باشند.Business Rules Management Systems (BRMS)قوانین تجاری اهداف سازمان را مشخص میکنند و برای اجرای فرایند های متفاوت دستورالعمل های متناسب را ارایه میدهند به همین دلیل در واقع فعالیت های تجاری کسب و کار ها را تعریف یا حتی محدود میکنند. در سازمان هایی که این قوانین مستند نیستند، کارکنان آن سازمان به خصوص افراد با سابقه میدانند باید به چه شکلی کار ها انجام شود یا فرایندی طی شود اما این کار ناهماهنگی و ناکارآمدی را در سطح سازمان افزایش میدهد. با مستند کردن و مدیریت این فرایند ها تعریف واحد و رسمی برای انجام فرایند های کسب و کار ایجاد میشود که اهداف انجام آن ها برای همه افراد سازمان مشخص است. BRMS یک راه حل نرم افزاری برای تعریف، مستند سازی، اجرا و مانیتورینگ و مدیریت قوانین تجاری است یعنی با استفاده از BRMS، استفاده از قوانین تجاری در کل سازمان خودکار میشود و سازمان هایی که دارای قوانین تجاری هستند و هنوز از روش های قدیمی و غیر خودکار استفاده میکنند با این کار ویژگی های زیر را بدست خواهند آورد:کارایی بالاتر و کاهش فرایند های دستی و تصمیمات تکراریبوسیله مانیتورینگ از روند اجرا و درستی آن اطمینان حاصل کنیدبهبود کارایی و افزایش سرعت که رضایت مشتری های شمارا به دنبال خواهد داشتتامین امنیت قوانین کسب و کار شما و دسترسی نداشتن افراد غیر مجازتجزیه و تحلیل اجرا و قوانین، برای بهبود فرایند هاMessage Queue (such as Kafka and RabbitMQ)یک نوع راه برای انتقال پیام به صورت asynchronous است.انتقال پیام در صف دو طرف producer و consumer دارد که وظیفه producer انتقال پیام و وظیفه consumer دریافت آن است. در Message queue ها داده ها به همان ترتیبی که وارد میشوند نگهداری میشوند و تا زمانی که پیامی خوانده یا حذف نشود (ack فرستاده نشود) آن پیام در صف باقی میماند.به طور مثال در معماری های microservice برای ارتباط بین دو سرویس یا در eventsourcing برای دریافت لاگ ها یا وقایع استفاده میشود، علاوه بر انتقال پیام میتوان برای بافر کردن یا تقسیم load بین منابع پردازشی هم از صف ها استفاده کرد. استفاده از صف ها تا حد خوبی میتواند قابلیت اطمینان و مقیاس پذیری در انتقال پیام را افزایش دهد. حالتی را در نظر بگیرید که قدرت پردازش تولید کننده پیام بیشتر از مصرف کننده آن است یا بازه زمانی پردازش داده در این دو گروه متفاوت است (cronjob ها) در این حالت اگر قرار باشد همان زمانی که تولید کننده (ارسال کننده) پیام را ایجاد کرده مصرف کننده(دریافت کننده) آن را دریافت یا پردازش کند احتمالا همه یا تعداد بسیاری پیام از دست میرود.استفاده از صف ها باعث میشود وابستگی بین دو گروه producer و consumer در برخی کاربرد ها کم شود و امکان انتقال پیام بین این دو گروه با تفاوت هایی که گفته شد امکان داشته باشد.Docker and Containerizationمنظور از Containerization یعنی ایجاد یک بسته و گروه که شامل فایل ها و تنظیمات و …. با خود برنامه که در واقع هر چیزی برای اجرای برنامه نیاز است را فراهم میکند تا در یک محیط ایزوله اجرا شود. این روش اجرا بسیار سبک تر از روش های قدیمی است زیرا مستقیما روی سیستم عامل میزبان اجرا میشود و از منابع و ویژگی هایی که از قبل سیستم عامل داشته استفاده میکند. برای ایجاد و راه اندازی برنامه ها به این روش راه حل های متفاوتی وجود دارد ولی محبوب ترین آن ها docker است. پس در واقع docker روشی است برای ساختن container ها به صورت ساده و سریع به طوری که روی سیستم عامل های متنوع قابلیت به کارگیری دارد و هم در فضای development و هم production استفاده میشود. همچنین docker دارای repository از container های آماده است که با شما امکان میدهد زمانی که میخواهید برنامه خود را بوسیله آن بالا بیاورید میتوانید نیازمندی هایی دیگر یا ابزار های مورد نیاز خود را در رجیستری جست و جو و به صورت آماده استفاده کنید . استفاده از Containerization باعث انعطاف پذیری بیشتر، مدیریت بهتر منابع، افزایش سرعت فرایند اجرا، کاهش نگرانی ها و ریسک ها در مورد بستر پایده سازی و منابعی که به آن ها وابسته هستیم، امنیت و مدیریت راحت تر و… میشود، اما استفاده از Containerization ها ممکن است هزینه هایی داشته باشد مثل نبود معماری خوب یا نبود توسعه دهندگان با سابقه در استفاده از این روش ها تحت نیازمندی خاص.Container orchestration (such as Kubernetes)برای خودکار کردن مجموعه کار های مورد نیاز برای deploy و اجرای container ها در فضای production که شامل مواردی میشود که توسعه دهندگان برای مدیریت مجموعه ای از کار ها مثل deployment, scaling, networking و load balancing انجام میدهند. به دلیل اینکه استفاده از container ها در معماری microservice به دلیل سبک بودن و مقیاس پذیر بودنشان بسیار مورد استفاده است در سیستم های بزرگ با مقیاس بالا ممکن است دارای تعداد زیادی از این container ها باشیم که مدیریت اجرا و توسعه آن ها بعد از گذشت مدتی نیاز به تلاش بسیاری دارد و اگر این کار ها به صورت دستی انجام شود سرعت عمل را در تیم های Devops کم می‌کند برای همین Container orchestration فرایند توسعه و عملیات های مربوطه را خودکار میکنند تا برای تیم های devops استفاده از container ها و مدیریت آن در فضای production منطقی باشد. ابزار های موجود می‌توانند بوسیله هماهنگی بین container ها بر اساس تقاضا و درخواست ها scaling دوباره انجام دهند یا در مواردی که نیاز است راه اندازی مجدد را انجام دهند به این ترتیب انعطاف پذیری افزایش پیدا می‌کند.همچنین سازماندهی و حفظ امنیت در container ها بالا می‌رود و امکان خطای انسانی در مدیریت آن ها به کمترین حد خود می‌رسد.Log Management Tools (such as ELK)لاگ ها، وقایع و گزارش هایی هستند که برنامه و سیستم در روند اجرای خود ثبت و ارسال می‌کند و میتواند شامل پیام های مختلف، گزارش خطا، request های دریافتی و … شود که باید زمان وقوع آن ها هم ثبت شود به همین دلیل timestamp در کنار گزارش برای ثبت زمان آن می‌آید. Log Management و ابزار های مورد استفاده در آن برای ایجاد فرایندی است که به طور پیوسته نسبت به جمع آوری، ذخیره سازی، پردازش و تحلیل گزارش عمل میکنند که خروجی آن ها برای بررسی performance ، تشخیص خرابی، حجم خطای سیستم، مدیریت بهتر منابع و حفظ بهتر امنیت سیستم و تشخیص سریع خطر های احتمالی به کار می آید. استفاده از ابزار های مناسب در جمع آوری ، مانیتورینگ، ذخیره سازی و… باعث میشود تیم های مختلف توسعه و نگهداری برنامه نرم افزاری و سیستم بتوانند به راحتی وضعیت و کیفیت بخش های مختلف را رصد کنند و برای گزارش خرابی فرایند های خودکاری تعریف کنند همچنین در صورت بوجود آمدن اشکال کار رصد و یافتن منبع مشکل ساده تر انجام شود. در انتخاب ابزار باید نکاتی مثل ذخیره سازی یکپارچه داده ها، بهبود امنیت، تشخیص زمان درست و واقعه، ابزار مانیتورینگ قابل مشاهده در تمام سازمان و متناسب با نیازمندی های آن ها، تجزیه و تحلیل متناسب با سیستم و نیازمندی ها، عیب یابی سریع و و شامل اطلاعات دقیق و درست را در نظر گرفت.Monitoring tools (such as Prometheus)ابزار هایی که برای رصد پیوسته وضعیت سیستم استفاده می شود تا بوسیله آن بتوانیم در زمان درستی از failure, defect و اشکالات آگاه شویم. از مانیتورینگ میتوان در ابزار ها و محیط های متفاوتی استفاده کرد و کاربرد آن فقط در برنامه و کد های زده شده نیست به طور مثال برای پایگاه داده ها، وضعیت شبکه، امنیت، حجم منابع مورد استفاده و …. هم میتوان استفاده کرد. میتوان برای هر یک از موارد threshold و مرزهایی تعیین کرد تا در صورت تجاوز از آن به صورت خودکار به مدیران و توسعه دهندگان مربوطه alert دهد. وجود تاریخچه ای از رفتار سیستم بر اساس گزارش ها و نمودار های مانیتورینگ در بسیاری از مواقع میتواند در مواردی مثل ارزیابی سیستم یا تشخیص رفتار کلاینت ها به سازمان دید بدهد، و در صورت نیاز به بهبود عملکرد، بتوان با اطلاع دریافتی از مانیتورینگ تغییرات درست و متناسب در تنظیمات و config های پروژه و ابزار های وابسته به آن را داد. البته باید به این موضوع دقت کرد که معمولا ابزار های مانیتورینگ یک دید از بالا نسبت به وضعیت سیستم و اجزای سیستم به ما میدهد و باید با اولین نگاه بتوان اطلاعات درستی از نمودار ها و گزارش های آن گرفت برای همین باید زمان تعریف آن ها دقت لازم برای هر چه کمتر کردن پیچیدگی های اضافی و متناسب ساختن آن با نیازمندی های سازمان را انجام داد.Static Code Analysis (such as SonarQube)روشی برای یافتن اشکالات و خطاهای کد های زده شده بدون اجرای آن ها است همچنین کد ها و ساختار آن ها بررسی می‌شود تا کیفیت لازم را داشته باشند، اصول و استاندارد های تعریف شده را هم رعایت کرده باشند. این روش توسط تیم های توسعه نرم افزار و تضمین کیفیت بوسیله ابزار هایی به کار گرفته میشود تا کد های پروژه اسکن و تحلیل شوند و موارد لازم برای اصلاح مشخص و انجام شوند. استفاده از این ابزار ها باعث کاهش خطاهای برنامه نویسی میشود و پیش از ایجاد اشکالات بزرگ و تاثیر گذاری در کل سیستم این اشکالات شناسایی و رفع میشوند همچنین در صورت نقض استاندارد ها و ساختار کلی پروژه نسبت به تغییر آن هشدار داده میشود. جلوگیری از ایجاد مقادیر تعریف نشده و خطاهایی که به syntax مربوط می‌شوند یا حتی در مواردی بررسی آسیب پذیری های امنیتی نیز انجام می‌شود. روند انجام این کار بوسیله ابزار های خودکار با تعریف یک سری از قوانین برای اسکن و تحلیل کد ها شروع می‌شود که پس از آن ابزار به صورت خودکار کد را بررسی و درصورت رعایت نکردن قوانین هشدار های لازم را می‌دهد. ممکن است درمواردی هشداری داده نشود که این مورد ضرورت بررسی کد بوسیله توسعه دهندگان را نشان میدهد اما درصورت نبود ابزار هایی که این کار را تا حد زیادی خودکار کنند بررسی آن توسط عامل انسانی علاوه بر این که درصد اشتباه را بالا می‌برد سرعت توسعه دهندگان و کیفیت خروجی آن ها را کاهش میداد.Continuous Deliveryدر دنیای امروزی که سرعت تغییرات زیاد شده و نیازمندی های جدید و تغییر آن ها با نرخ بسیار بیشتری به سمت توسعه دهندگان می آید استفاده از روش های قدیمی برای deploy ناکارآمد است و پروژه باید همیشه با تغییرات انجام شده قابلیت deploy و نمایش برای کلاینت ها را داشته باشد. Continuous Delivery فرایندی است که به ما این امکان را می‌دهد به صورت پیوسته انواع مختلف تغییرات در کد را که شامل اضافه کردن ویژگی جدید، رفع باگ یا تغییر تنظیمات و … میشود را در production اعمال کنیم و تغییرات به صورت امن و پایدار در کمترین زمان توسط کلاینت قابل استفاده باشد. بنابراین باید همیشه مطمئن باشیم پروژه و کد های ما آماده deploy هستند که این نیاز به این دارد مراحل integration و test و … قبل از آن انجام شده باشد. اغلب وقتی از deploy مستمر و همیشگی صحبت می‌شود به کیفیت پایین تر و پایداری کمتر فکر میشود ولی در این روش و با استفاده از ابزار های مناسب علاوه بر اینکه این مشکلات بوجود نمی آید بلکه در زمینه رقابت با رقبا به دلیل توجه سریعتر و همیشگی به نیاز ها، موفق تر ظاهر می شویم همچنین ریسک خطر نیز کاهش پیدا میکند زیرا در هر لحظه امکان تغییر و اصلاح را داریم همچنین با وجود مراحل تست و بررسی های مربوط به کیفیت خطر بوجود آمدن مشکل به کمترین حد خود می‌رسد.Single Sign on (SSO) and Identity Managementزمانی که از یک سرویس مشترک برای احراز هویت و لاگین کلاینت ها استفاده میشود و به کاربران برای دسترسی به سرویس های گوناگون تنها لازم به لاگین از طریق یک سرویس هستند در واقع از SSO استفاده میشود. SSO میتواند در سیستم ها با مقیاس های مختلف استفاده شود. SSO یک federal identity management است که یکی از مثال های معروف آن میتواند OAuth باشد که در آن کاربر یک حساب گوگل، فیس بوک یا … دارد و می‌تواند بوسیله آن ها در بسیاری از سایت ها ثبت نام کند و از خدمات آن ها استفاده کند. روش های مختلفی برای پیاده سازی SSO وجود دارد مثلا سرویس احراز هویت یک تیکت به کاربر بدهد و کاربر دیگر از آن برای دریافت خدمات از سرویس های دیگر استفاده کند. استفاده از این روش ریسک هایی دارد که اگر پیش بینی نشوند و از آن ها جلوگیری نشود منجر به حمله های امنیتی و مشکلات بزرگی میشود. مثلا اگر اطلاعات ورود کاربر به نوعی توسط attacker گرفته شود میتواند بوسیله آن به همه سرویس ها و خدمات دسترسی داشته باشد و خسارت بالای ایجاد کند به همین دلیل معمولا از روش هایی مثل multi factor authentication استفاده میشود اما اگر ملاحظات امنیتی رعایت شود به دلیل اینکه کاربر تنها یک بار لاگین میکند و میتواند از همه خدمات استفاده کند سهولت کار با سیستم بیشتر می‌شود همچنین خطا یابی و و اصلاح در این سیستم راحت تر میشود.service meshیک روش برای ارتباط و اشتراک و کنترل قسمت های مختلف برای اشتراک داده ها است و یک ساختار و لایه جدا و مشخص است که کار مدیریت ارتباط را انجام میدهد و و به دلیل مستقل بودن آن مشاهده‌پذیری، امنیت و قابلیت اطمینان برنامه‌ها افزایش می یابد.معماری microservice شامل سرویس های مجزایی هستند که به صورت مستقل توسعه و نگهداری میشوند اما ارتباطاتی با یکدیگر دارند که در سیستم های بزرگ و یا در حال توسعه نیاز به مدیریت دارند ،service mesh برای این منظور استفاده میشود. پیاده سازی آن بوسیله مجموعه ای از پراکسی ها است که مقیاس پذیر هستند و علاوه بر این که ارتباطات بین سرویس ا بوسیله آن ها انجام میشود feature های مورد نیاز در service mesh هم در آن ها تعریف میشود. این روش در خدمات ابری کاربرد زیادی دارد زیرا ممکن است در آن ها یک برنامه شامل سرویس های زیادی باشد که از هرکدام چندیدن instance بالا باشد، مدیریت ارتباطات میان این ها که هر کدام ممکن است به صورت مستقل هر لحظه تغییر یا reconfig شوند، برای اطمینان از عملکرد و وضعیتشان بسیار مهم است. نمونه ای از feature هایی که میتوان در service mesh پیاده سازی کرد:پخش درخواست ها به نسخه های متنوع از یک سرویسانتخاب instance از سرویس برای پاسخ که بهترین زمان پاسخگویی را داردنگهداری نوع و زمان پاسخ instance ها و داشتن history از عملکرد آن هاکنار گذاشتن instance های دارای خطای زیادامتحان مجدد یا retry کردم درخواست هایی که fail شده اند….. Alireza Alidoosti Alireza Alidoosti Thu, 24 Nov 2022 18:08:18 +0330