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 مشخص باشد، احتمال سوءتفاهم بین تیمها تقریباً صفر میشود.
DDD
DDD برای پروژههای بزرگ است که منطق بیزینس پیچیدهای دارند. به جای تمرکز روی دیتابیس، روی مفاهیم بیزینس تمرکز میکنیم. ما سیستم را به «بخشهای کوچک تقسیم میکنیم که هر کدام زبان مخصوص به خود را دارند. این روش باعث میشود کد ما با منطق کسبوکار همسو باشد و با تغییرات بیزینس، کد به هم نریزد.
Hexagonal
این معماری میگوید: منطق اصلی برنامه نباید به دیتابیس یا وب یا فریمورک وابسته باشد. منطق برنامه در مرکز است و از طریق درگاهها با دنیای بیرون در ارتباط است.اگر فردا بخواهیم دیتابیس را عوض کنیم یا وبسایت را تبدیل به اپلیکیشن موبایل کنیم، منطق برنامه هیچ تغییری نمیکند! این یعنی کدی که خیلی راحت تست میشود.
Event Sourcing
به جای ذخیره وضعیتِ نهایی، ما تمام رویدادهای منجر به این وضعیت را ذخیره میکنیم مثلاً ثبت واریز، برداشت، واریز
این یعنی ما همیشه تاریخچه داریم و میتوانیم در هر لحظه وضعیت سیستم را دوباره بازسازی کنیم. برای سیستمهای بانکی که حسابرسی دقیق نیاز دارند، این روش بینظیر است.
Low-code/No-code
این ابزارها برای وقتیاند که میخواهیم سریع یک ایده یا ابزار داخلی را پیاده کنیم. با درگودراپ کردنِ المانها، محصول نهایی ساخته میشود. برای استارتاپها که زمان ندارند، عالی است
اما خب، برای سیستمهای خیلی پیچیده و خاص، دست ما را میبندند و کدنویسیِ دستی همیشه انعطاف بیشتری دارد.
BPMS
توی سازمانهای بزرگ، فرآیندهایی مثل تایید مرخصی یا تایید وام مراحل زیادی دارند. به جای هاردکد کردن اینها، از BPMS استفاده میکنیم تا نمودار فرآیند را بکشیم
اگر فردا مدیر شرکت گفت باید یک مرحله اضافه شود فقط نمودار را تغییر میدهیم و تمام!
Kafka & RabbitMQ
وقتی دیتابیس زیر فشار ترافیکِ بالا در حال انفجار است، از صف پیام استفاده میکنیم. پیامها در صف میمانند تا سرویس مربوطه با سرعتِ خودش آنها را بردارد و پردازش کند
کافکا در مقیاسهای غولآسا عالی است و رابیت برای کارهای تراکنشی سریع. اینها باعث میشوند سیستم ما در برابر ترافیک بالا ناپایدار نشود.
Docker & Kubernetes
داکر یعنی بستهبندی کد با تمام پیشنیازها. کوبرنتیز هم مدیرِ این بستههاست؛ اگر کانتینری کرش کرد، خودش دوباره میسازدش؛ اگر ترافیک زیاد شد، کانتینرهای بیشتری بالا میآورد. بدون اینها، مدیریت سیستمهای ابری امروزی غیرممکن است.
معماری چند-مستأجری
در سایتهای SaaS، یک نسخه از نرمافزار به ۱۰۰ تا مشتری سرویس میدهد. چالش اصلی این است که دادههای هر مشتری باید کاملاً از بقیه جدا باشد .طراحی درست این معماری باعث میشود با کمترین هزینه زیرساخت، به بیشترین مشتری سرویس بدهیم.
مهاجرت داده
مهاجرت داده یعنی تعویض موتور هواپیما در حال پرواز! باید دیتابیس قدیمی را به جدید منتقل کنیم بدون اینکه سرویس برای لحظهای قطع شود.
این کار نیاز به برنامهریزی دقیق، تستهای مکرر و استراتژی بازگشت دارد تا مبادا دیتای مشتری حین انتقال بپرد.
