وب سایت کانال https://codecrafters.ir

لیست هشتک‌ها در کانال رو در زیر براتون خواهم گذاشت و آپدیت خواهد شد


#design_patterns الگوهای طراحی

#postgresql پستگرس

#k8s کوبرنتیز

#agile اجایل
#scrum

#algorithm الگوریتم

#video

#meeting متینگ‌

#principles اصول کدنویسی

#project_managment_system مدیریت تیم

#free خارج از مبحث کامپیوتر


#app برنامه‌های کاربردی

#Git #actions مباحث مربوط به گیت و گیتلب

#conda #env کار با

#Docker مباحث مربوط به داکر

#AI #ML مباحث هوش مصنوعی

#book معرفی کتاب

#monitoring بررسی وضعیت سیستم و کد

#concurrency همزمانی کتاب grokking concurrency


#blovkchain #web3

#DDD #domain_driven_design

#BDD #behavior_driven_development

#soa #sso #microservice


@Code_Crafters

Git Hub:
https://github.com/CodeCrafters-ir/

2-الگوی مش سرویس
تصور کنید تو یه شهر شلوغ هستید که پر از ماشین‌ها (میکروسرویس‌ها) است که می‌خوان با هم ارتباط برقرار کنن. اگه هر ماشین بخواد خودش مسیرش رو پیدا کنه، ترافیک قفل می‌شه، تصادف پیش میاد و هیچ‌کس به موقع به مقصد نمی‌رسه. حالا مش سرویس مثل یه سیستم هوشمند مدیریت ترافیک عمل می‌کنه. این سیستم یه شبکه‌ی اختصاصی از «پروکسی‌ها» (مثل چراغ‌های راهنمایی یا پلیس‌های ترافیک) داره که تمام ارتباطات بین ماشین‌ها رو هدایت، کنترل و بهینه می‌کنه.


تصویر سوم
این لایه‌ی واسطه (که معمولاً با ابزارهایی مثل Istio یا Linkerd پیاده‌سازی می‌شه) مسئولیت کارهای زیر رو به عهده می‌گیره:

هدایت ترافیک: تصمیم می‌گیره درخواست‌ها از کدوم مسیر برن. مثلاً اگه یه سرویس شلوغ باشه، درخواست‌ها رو به یه نمونه‌ی دیگه از همون سرویس می‌فرسته.
تعادل بار (Load Balancing): بار کاری رو بین نسخه‌های مختلف یه سرویس تقسیم می‌کنه تا هیچ سرویسی بیش از حد تحت فشار نباشه.
امنیت: ارتباط‌ها رو رمزنگاری می‌کنه (مثلاً با TLS) و مطمئن می‌شه فقط سرویس‌های مجاز بتونن با هم حرف بزنن.
نظارت و رصد: اطلاعاتی مثل زمان پاسخ‌گویی، تعداد درخواست‌ها یا خطاها رو جمع‌آوری می‌کنه تا تیم توسعه بتونه عملکرد سیستم رو تحلیل کنه.
مدیریت خطا: اگه یه سرویس از کار بیفته، مش سرویس می‌تونه درخواست‌ها رو به‌طور خودکار به یه سرویس سالم هدایت کنه یا یه پیام خطای مناسب برگردونه.

مثال واقعی: فرض کنید تو یه اپلیکیشن خرید آنلاین، سرویس «پرداخت» و سرویس «سبد خرید» باید با هم کار کنن. بدون مش سرویس، هر کدوم از این سرویس‌ها باید خودشون منطق ارتباطی، مثل مدیریت خطاها یا رمزنگاری، رو پیاده‌سازی کنن. اما با مش سرویس، یه لایه‌ی پروکسی (مثلاً Envoy تو Istio) بین این دو سرویس قرار می‌گیره و تمام این کارها رو به‌صورت خودکار انجام می‌ده. اینجوری تیم توسعه می‌تونه روی منطق اصلی سرویس‌ها تمرکز کنه و نگران پیچیدگی‌های ارتباطی نباشه.

مزیت بزرگ: مش سرویس کد سرویس‌ها رو ساده‌تر می‌کنه، چون منطق شبکه‌ای (مثل retry، timeout یا رمزنگاری) از سرویس‌ها جدا می‌شه و به لایه‌ی مش منتقل می‌شه. اما یه نکته هم داره: راه‌اندازی و مدیریت مش سرویس ممکنه خودش پیچیدگی‌هایی به سیستم اضافه کنه، مخصوصاً تو محیط‌های کوچک‌تر.
#microservice #design_patterns

@code_crafters

4-الگوی Event Sourcing
حالا تصور کنید یدیه دفترچه خاطرات دارید که هر چیزی تو زندگیت توناتفاق می‌افته رو توش می‌نویسیید: امروز چی خریدید، کجا رفتید، چی گفتی. اگه بخوادی یه روز خاص رو یادتون بیاد، فقط کافیه دفترچه رو باز کنید و اون صفحه رو بخونید. الگوی Event Sourcing به همون منبع یابی رویداد تو میکروسرویس‌ها هم یه همچین چیزیه تقریبا. جای اینکه فقط حالت فعلی سیستم (مثل موجودی حساب بانکی) رو ذخیره کنید، هر اتفاقی که تو سیستم می‌افته رو به‌عنوان یه ایونت ثبت می‌کنید. بعد هر وقت بخوایذ، می‌تونیذ این رویدادها رو بخونیذ و حالت سیستم رو بازسازی کنی.

اجزای اصلی این الگو:

ا(Event): مثل یه خط تو دفترچه‌ست. مثلاً «کاربر X صد تومن واریز کرد». هر ایونت یه تغییر تو سیستم رو نشون می‌ده.
ا(Event Store): همون دفترچه خاطراته! همه رویدادها رو به ترتیب و بدون امکان تغییر ذخیره می‌کنه.
ا(Event Handler): مثل یه کتابدار که می‌ره تو دفترچه، ایونت رو می‌خونه و سیستم رو به‌روزرسانی می‌کنه.
ا(Aggregate): یه گروه از ایونت هایی مرتبط که با هم یه داستان کامل (مثل لاگ یه حساب بانکی) رو تعریف می‌کنن.
ا(Event Stream): تاریخچه ایونت هایی یه چیز خاص (مثلاً همه تراکنش‌های یه حساب).
ا(Event Publisher): مثل یه پستچی که خبر رو به بقیه می‌رسونه، ایونت رو به سرویس‌های دیگه می‌فرسته.
ا(Event Subscriber): سرویس‌هایی که منتظرن خبر جدید برسه و باهاش کار کنن.
ا(Command): درخواست‌هایی که کاربر می‌فرسته (مثل «پول واریز کن») و باعث می‌شن یه ایونت جدید ساخته بشه.

مثال:

این دفعه تصیور کنید یه اپلیکیشن بانکی دارید. به جای اینکه فقط موجودی حساب کاربر رو تو دیتابیس ذخیره کنید، هر تراکنش (مثل واریز، برداشت، یا انتقال) رو به‌عنوان یه رویداد ثبت می‌کنیذ. مثلاً:

رویداد 1: «100 تومن واریز شد»
رویداد 2: «50 تومن برداشت شد» اگه بخواید موجودی حساب رو ببینی،د سیستم همه رویدادهای اون حساب رو می‌خونه و محاسبه می‌کنه: 100 - 50 = 50 تومن. این روش نه‌تنها تاریخچه کامل رو نگه می‌داره، بلکه اگه بخواهید حسابرسی کنید یا خطایی رو پیدا کنید، خیلی راحت می‌تونید همه‌چیز رو بررسی کنید.
همچنین مقیاس پذیری ,حسابرسی و انعظاف پذیری از ویژگی های Event Sourcing به حساب میان.

کلام آخر این که تو این بخش، دو تا الگوی خفن دیگه رو بررسی کردیم:Circuit Breaker که مثل یه نگهبان جلوی خرابی‌های بزرگ رو می‌گیره(مثل بتمن🥸)، و Event Sourcing که مثل یه دفترچه خاطرات همه‌چیز رو ثبت می‌کنه.
#microservice #design_patterns

@code_crafters

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


حالا تو بخش سوم، قراره با دو تا الگوی مهم دیگه آشنا بشیم: الگوی SAGA و الگوی API Gateway. این دو الگو بهمون کمک می‌کنن تا هماهنگی داده‌ها و دسترسی به سرویس‌ها رو تو سیستم‌های پخش‌شده بهتر مدیریت کنیم.

5. الگوی SAGA (SAGA Pattern)
الگوی SAGA یه روش کارآمد برای مدیریت هماهنگی داده‌ها تو تراکنش‌های پخش‌شده بین میکروسرویس‌هاست.
تو سیستم‌های سنتی، تراکنش‌ها با مدل ACID مدیریت می‌شن که تضمین می‌کنه همه‌چیز یا کامل انجام بشه یا اصلاً انجام نشه.
اما تو معماری میکروسرویس، که هر سرویس دیتابیس خودش رو داره، پیاده‌سازی این مدل خیلی سخته.
اینجاست که الگوی SAGA یه راه‌حل هوشمندانه ارائه می‌ده.

چطور کار می‌کنه SAGA؟

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

دو نوع هماهنگی در SAGA:
🔹 کروئوگرافی (Choreography):
هیچ هماهنگ‌کننده‌ی مرکزی نداریم. هر سرویس یه رویداد منتشر می‌کنه و بقیه سرویس‌ها خودشون به اون گوش می‌دن.
مثلاً سرویس سفارش یه رویداد «سفارش ثبت شد» می‌فرسته، سرویس انبار اینو می‌شنوه و موجودی رو کم می‌کنه.
این روش تو سیستم‌های ساده خوبه، ولی تو سیستم‌های بزرگ مدیریت سخت می‌شه.

🔹 ارکستراسیون (Orchestration):
اینجا یه سرویس مرکزی (Orchestrator) همه‌چیز رو مدیریت می‌کنه. مثلاً اول به سرویس سفارش می‌گه سفارش رو ثبت کن، بعد به سرویس پرداخت دستور می‌ده پول رو بگیره.
مدیریتش متمرکزه و برای سیستم‌های پیچیده بهتره، ولی نقطه‌ی شکست هم می‌تونه باشه.

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

چرا SAGA مهمه؟
تضمین هماهنگی داده‌ها تو سیستم‌های پخش‌شده
مدیریت درست خطاها با عملیات جبرانی
مناسب برای معماری‌های مدرن که نمی‌تونن از تراکنش‌های سنتی استفاده کنن

6. الگوی API Gateway (API Gateway Pattern)
الگوی API Gateway یه راه‌حل برای ساده‌سازی و مدیریت دسترسی به میکروسرویس‌هاست.

تو سیستم‌های پخش‌شده، معمولاً سرویس‌های زیادی وجود دارن که هر کدوم وظیفه خاصی دارن.
اگه کلاینت‌ها (مثلاً اپ موبایل یا وب) بخوان مستقیماً با هر سرویس ارتباط برقرار کنن، کار خیلی پیچیده می‌شه.
اینجاست که API Gateway وارد می‌شه و همه‌چیز رو ساده‌تر می‌کنه.

چطور کار می‌کنهAPI Gateway ؟
مثل یه دربان هوشمند جلوی سیستم می‌ایسته.
هر درخواستی که از سمت کاربر میاد، اول وارد API Gateway می‌شه، بعد اون تصمیم می‌گیره این درخواست باید به کدوم سرویس بره.

وظایف کلیدی API Gateway:
هدایت و تعادل بار (Routing and Load Balancing): درخواست‌ها رو بر اساس قوانین به سرویس درست می‌فرسته و با پخش بار بین نسخه‌های مختلف، سیستم رو پایدار نگه می‌داره.
ترجمه پروتکل (Protocol Translation): می‌تونه درخواست‌های HTTP رو به فرمت‌های دیگه (مثل gRPC) تبدیل کنه تا با سرویس‌های بک‌اند سازگار بشه.
تغییر درخواست (Request Transformation): درخواست‌ها و پاسخ‌ها رو بر اساس نیاز سرویس‌ها تغییر می‌ده، مثلاً پارامترها یا هدرها رو تنظیم می‌کنه.
کش کردن (Caching): با ذخیره داده‌ها، سرعت رو بالا می‌بره و بار رو از روی سرویس‌ها کم می‌کنه.
هدایت و تعادل بار (Load Balancing) بین چند سرور

یه مثال ساده:
فرض کنید یه اپلیکیشن خرید دارید.
به‌جای اینکه اپ مستقیماً با سرویس سفارش، پرداخت و ارسال ارتباط بگیره، همه درخواست‌ها می‌رن سمت API Gateway.
اونجا اول اعتبارسنجی انجام می‌شه، بعد درخواست به سرویس مربوطه فرستاده می‌شه، و اگه لازم باشه، جواب کش می‌شه تا سریع‌تر به دست کاربر برسه.

چرا API Gateway مهمه؟
دسترسی به سرویس‌ها رو متمرکز و ساده می‌کنه
امنیت و نظارت رو از یه نقطه انجام می‌ده
به مقیاس‌پذیری، پایداری و مانیتورینگ سیستم کمک می‌کنه

#microservice #design_patterns

@code_crafters