https://virgool.io/feed/@a.otryd fa 2026-06-16 07:50:57 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@a.otryd https://virgool.io/@a.otryd/some-topics-from-software-architecture-io4ozbycdug1 Chaos Engineeringما همیشه سعی می‌کنیم سیستمی بسازیم که خراب نشود اما بیایید واقع‌بین باشیم؛ سیستم‌ها بلاخره یک‌جایی می‌لنگند!در مهندسی آشوب ما عمداً در محیط عملیاتی، اختلال ایجاد می‌کنیم (مثلاً قطع کردن یک دیتابیس یا ایجاد تأخیر در شبکه هدف این نیست که سیستم را بترکانیم، بلکه می‌خواهیم ببینیم سیستم در برابر خطاها چقدر تاب‌آور است. این کار کمک می‌کند نقاط ضعف پنهان را قبل از اینکه کاربر متوجه شود، پیدا کنیم. BFFقبلاً برای وب و موبایل از یک API یکسان استفاده می‌کردیم که دردسرساز بود. وب‌سایت کلی دیتا می‌خواست و موبایل فقط یک بخش کوچک. در الگوی BFF، ما برای هر رابط کاربری یک لایه بک‌اند اختصاصی داریم این‌طوری هر کلاینت دقیقاً همان دیتایی را می‌گیرد که نیاز دارد. این الگو باعث می‌شود تیم‌های فرانت‌اند و بک‌اند کمتر با هم درگیر شوند و سرعت توسعه خیلی بالاتر برود. AI4SEاین همان بخشی است که زندگی ما دانشجوها را راحت کرده. از «گیت‌هاب کوپایلوت» گرفته تا ابزارهایی که باگ‌های کد را پیدا می‌کنند یا تست می‌نویسند. اینجا هوش مصنوعی نقش یک دستیار حرفه‌ای را دارد که کارهای تکراری و خسته‌کننده (مثل داکیومنت‌نویسی یا کدنویسی‌های تکراری) را انجام می‌دهد تا ما بتوانیم روی طراحی سیستم و منطق بیزینس تمرکز کنیم. SE4AIاینجا قضیه برعکس است؛ یعنی چطور یک مدل هوش مصنوعی را داخل یک پروژه بزرگ بگنجانیم؟ برخلاف کدهای سنتی، مدل‌های هوش مصنوعی «احتمالاتی» هستند و با داده تغییر می‌کنند. مدیریت این مدل‌ها نیاز به زیرساخت خاص دارد؛ چون باید نسخه مدل، کیفیت داده‌ها و مانیتورینگ خروجی را دائماً کنترل کنیم تا مدل در طول زمان دچار افت کیفیت نشود.MLOpsهمان DevOps برای پروژه‌های یادگیری ماشین است. یک مدل وقتی روی لپ‌تاپ دانشمند داده خوب کار می‌کند، دلیل نمی‌شود در سرور هم عالی باشد MLOps کمک می‌کند که مدل‌ها به صورت خودکار آموزش ببینند، تست شوند و در محیط عملیاتی مستقر شوند. اگر دقت مدل در طول زمان کم شد، MLOps کمک می‌کند که دوباره مدل آموزش ببیند و جایگزین شود.IaCدیگر کسی سرور را دستی کانفیگ نمی‌کند! با ابزارهایی مثل Terraform، ما کل زیرساخت را در قالب کد می‌نویسیم. مزیتش این است که اگر سرورها از بین رفتند، با یک دستور کل زیرساخت را در جای دیگری بالا می‌آوریم. این کار باعث می‌شود محیط توسعه و محیط واقعی دقیقاً یکسان باشند و دیگر از بهانه‌هایی مثل «روی سیستم من کار می‌کرد» خبری نباشد. API Gateway & Service Meshدر میکروسرویس‌ها، مدیریت ارتباطات کابوس است. API Gateway مثل «لابی هتل» است؛ تمام درخواست‌های بیرونی اول می‌آیند اینجا، تأیید هویت می‌شوند و بعد به سمت سرویس مربوطه می‌روند. اما Service Mesh مثل Istio برای ارتباطات داخلی بین سرویس‌هاست؛ کارهایی مثل رمزنگاری و مدیریت خطا را انجام می‌دهد تا خود میکروسرویس‌ها درگیر پیچیدگی‌های شبکه نشوند. CQRSخیلی وقت‌ها فشار روی دیتابیس برای خواندن و نوشتن هم‌زمان، سیستم را کند می‌کند. در CQRS می‌گوییم بیایید مدل نوشتن را از مدل خواندن جدا کنیم. برای نوشتن از یک دیتابیسِ امن استفاده می‌کنیم و برای خواندن، داده‌ها را در یک مدلِ سریع کپی می‌کنیم. این کار مقیاس‌پذیری سیستم را به شدت بالا می‌برد.EDAدر سیستم‌های سنتی، همه منتظر پاسخ بقیه هستند. در EDA سرویس‌ها با «رویداد» با هم حرف می‌زنند. مثلاً سرویس سفارش فقط می‌گوید «سفارش ثبت شد» و کارش تمام می‌شود. سرویس‌های انبار و ایمیل این رویداد را می‌شنوند و واکنش نشان می‌دهند. این یعنی سرویس‌ها کاملاً از هم مستقل هستند و اگر یکی قطع شود، کل سیستم نمی‌خوابد. Serverlessدر سرورلس، ما اصلاً درگیر سرور نمی‌شویم. فقط کد خود را می‌فرستیم و اجرا می‌کنیم. هزینه‌اش هم فقط برای زمانی است که کد در حال اجراست. عالی است چون لازم نیست نگران سخت‌افزار باشیم، فقط باید حواسمان به محدودیت‌های زمانی تابع باشد. برای پروژه‌هایی که ترافیکشان نوسانی است، انتخاب اول است. API-firstقبل از زدن حتی یک خط کد، باید قرارداد API را بنویسیم. این کار باعث می‌شود تیم‌های مختلف فرانت و بک همزمان کار کنند، چون می‌دانند ورودی و خروجی‌ها چیست. وقتی این قرارداد مثل Swagger مشخص باشد، احتمال سوءتفاهم بین تیم‌ها تقریباً صفر می‌شود. DDDDDD برای پروژه‌های بزرگ است که منطق بیزینس پیچیده‌ای دارند. به جای تمرکز روی دیتابیس، روی مفاهیم بیزینس تمرکز می‌کنیم. ما سیستم را به «بخش‌های کوچک تقسیم می‌کنیم که هر کدام زبان مخصوص به خود را دارند. این روش باعث می‌شود کد ما با منطق کسب‌وکار همسو باشد و با تغییرات بیزینس، کد به هم نریزد. Hexagonalاین معماری می‌گوید: منطق اصلی برنامه نباید به دیتابیس یا وب یا فریم‌ورک وابسته باشد. منطق برنامه در مرکز است و از طریق درگاه‌ها با دنیای بیرون در ارتباط است.اگر فردا بخواهیم دیتابیس را عوض کنیم یا وب‌سایت را تبدیل به اپلیکیشن موبایل کنیم، منطق برنامه هیچ تغییری نمی‌کند! این یعنی کدی که خیلی راحت تست می‌شود. Event Sourcingبه جای ذخیره وضعیتِ نهایی، ما تمام رویدادهای منجر به این وضعیت را ذخیره می‌کنیم مثلاً ثبت واریز، برداشت، واریز این یعنی ما همیشه تاریخچه داریم و می‌توانیم در هر لحظه وضعیت سیستم را دوباره بازسازی کنیم. برای سیستم‌های بانکی که حسابرسی دقیق نیاز دارند، این روش بی‌نظیر است.Low-code/No-codeاین ابزارها برای وقتی‌اند که می‌خواهیم سریع یک ایده یا ابزار داخلی را پیاده کنیم. با درگ‌ودراپ کردنِ المان‌ها، محصول نهایی ساخته می‌شود. برای استارتاپ‌ها که زمان ندارند، عالی استاما خب، برای سیستم‌های خیلی پیچیده و خاص، دست ما را می‌بندند و کدنویسیِ دستی همیشه انعطاف بیشتری دارد.BPMSتوی سازمان‌های بزرگ، فرآیندهایی مثل تایید مرخصی یا تایید وام مراحل زیادی دارند. به جای هاردکد کردن این‌ها، از BPMS استفاده می‌کنیم تا نمودار فرآیند را بکشیم اگر فردا مدیر شرکت گفت باید یک مرحله اضافه شود فقط نمودار را تغییر می‌دهیم و تمام! Kafka & RabbitMQوقتی دیتابیس زیر فشار ترافیکِ بالا در حال انفجار است، از صف پیام استفاده می‌کنیم. پیام‌ها در صف می‌مانند تا سرویس مربوطه با سرعتِ خودش آن‌ها را بردارد و پردازش کند کافکا در مقیاس‌های غول‌آسا عالی است و رابیت برای کارهای تراکنشی سریع. این‌ها باعث می‌شوند سیستم ما در برابر ترافیک بالا ناپایدار نشود. Docker & Kubernetesداکر یعنی بسته‌بندی کد با تمام پیش‌نیازها. کوبرنتیز هم مدیرِ این بسته‌هاست؛ اگر کانتینری کرش کرد، خودش دوباره می‌سازدش؛ اگر ترافیک زیاد شد، کانتینرهای بیشتری بالا می‌آورد. بدون این‌ها، مدیریت سیستم‌های ابری امروزی غیرممکن است. معماری چند-مستأجریدر سایت‌های SaaS، یک نسخه از نرم‌افزار به ۱۰۰ تا مشتری سرویس می‌دهد. چالش اصلی این است که داده‌های هر مشتری باید کاملاً از بقیه جدا باشد .طراحی درست این معماری باعث می‌شود با کمترین هزینه زیرساخت، به بیشترین مشتری سرویس بدهیم. مهاجرت دادهمهاجرت داده یعنی تعویض موتور هواپیما در حال پرواز! باید دیتابیس قدیمی را به جدید منتقل کنیم بدون اینکه سرویس برای لحظه‌ای قطع شود.این کار نیاز به برنامه‌ریزی دقیق، تست‌های مکرر و استراتژی بازگشت دارد تا مبادا دیتای مشتری حین انتقال بپرد. Adler ie Adler ie Tue, 02 Jun 2026 18:35:21 +0330