نمونه ای از مکانیزم Rate Limiting
و رخ داد Quota Exceeded
کلاینت محدود شده و خطای 409 و پیام مناسب را دریافت کرده، همچنین مشخص شده که میتواند پس از 1 ثانیه مجددا سعی کند (Retry After : 1)
#Ocelot #ApiGateway #Microservice

مکانیزم توزیع کننده و متعادل کننده بار (Load Balancing & distribution )

سناریویی را فرض کنید که تعداد درخواست های زیاد و یا پردازش های سنگینی دارد، در این شرایط سرویس ها اصطلاحا زیر بار سنگینی میروند و به کندی پردازش میکنند و پاسخ میدهند. حتما تا به حال راجع به load test و stress test شنیده اید (اگر نه مطلبی در این باره به صورت جدا خواهم نوشت که دانستنش واجب است). در این تست ها سناریو های متعدد را میچینند و سرویس ها را در شرایط مختلف مانند ۱۰۰۰ یوزر در ثانیه، ۱۰۰ کوئری در ثانیه، نرخ بروز خطا، سرعت پردازش صفحات و ... آنها را تست میکنند.
یکی از نتایج، میزان باری است که سرویس در بهترین، میانگین و بدترین شرایط در این سناریو ها میتواند تحمل کند. به عنوان مثال وبلاگی را تصور کنید که در ثانیه ۱۰۰۰ درخواست را دریافت و پردازش میکند، بسته به پرفورمنس شما ممکن است هر پاسخ میانگین 100 الی 30000 میلی ثانیه طول بکشد. نتیجتا پیگیر پرفورمنس کدهای نوشته شده خواهید شد و یا به فکر کلاستر و یا توزیع این بار روی چند instance و سرور دیگر از سرویس خواهید افتاد یا مثل خیلی ها میرید سراغ آپگرید سخت افزار و صورت مسئله را نادیده میگیرید.
مقاله های متعددی به چگونگی انجام این کار پرداخته اند و بسته به تکنولوژی مورد استفاده شما، روش ها و ابزار های متفاوتی معرفی شده که یکی از معروفترین ها کانتینر های داکر و ابزارهای kubernetes و swarm هستند.
نرخ پاسخ دهی مناسب، مصرف بهینه تر منابع و امکان scale کردن سرویس ها و سرور ها از برجسته ترین مزایای این روش میباشد. در عین حال، افزایش میزان پیچیدگی پیاده سازی، تاخیر، دیباگ، کنترل و به روزرسانی آنها از مورد توجه ترین معایب هستند. (که در مفاهیم میکروسرویس این امر بدیهی و مشهود است)
به مثال قبل برمیگردیم، سرویس بلاگ که وظیفه واکشی و درج اطلاعات را دارد میتواند به دو instance افزایش پیدا کند که هر کدام روی پورت دیگری در سرور listen میشوند. حال وظیفه سرویس اصلی (Gateway, Hub) این است که درخواست ها را طوری هندل کند که فشار بر روی هر دو instance تقسیم شده و طبیعتا نرخ پاسخ دهی و عملکرد را افزایش دهد.
مکانیزم ها و الگوریتم های مختلفی در این باره هست که تعیین کننده مکانیزم تقسیم بار و بالانس میان سرویس هاست.
یکی از این الگوریتم ها Round Robin یا الگوریتم پردازش نوبتی است. در این مدل، درخواست ها به صورت نوبتی به instance های موجود سرویس ها ارجاع میشود. مثلا اول به سرویس blog1 و درخواست بعدی به blog2.
الگوریتم دیگر LeastConnection به این شکل عمل میکند که درخواست های جدید را به instance ای که کمترین درخواست را پیش از این داشته، ارجاع میدهد. بدینصورت رهگیری درخواست ها و توزیع آنها محاسبه شده و اگر سرویس blog1 رکوئست های زیادتری دریافت کرده، زین پس تا مقطعی درخواست ها به blog2 داده میشوند، این کار میتواند برای متعادل کردن بار درخواست ها به طور نسبتا مساوی تری نسبت به الگوریتم نوبتی (که هر کس نوبتش باشه باید بپذیره) عمل کند. (هر کس سرش خلوت تره میپذیره)
الگوریتم Cookie Sticky Sessions از یک کوکی برای کلاینت ها استفاده میکند و در کوکی درج میشود که درخواست ها به کدام سرور ارسال شود. ممکن است برای یک کلاینت سروری در آسیا عملکرد بهتری از سروری در اروپا بدهد، پس این کلاینت با همان آدرسی که در کوکی اش ذخیره شده ارتباط میگیرد.

در مطلبی دیگر درباره چگونگی پیاده سازی و استفاده از این مکانیزم ها به کمک کتابخانه مشهور Ocelot.net در API Gateway ها میپردازیم و میزان بار میان سرویس ها را تقسیم میکنیم. همچنین توضیحاتی درباره ocelot و قابلیت های دیگر آن به همراه کتابخانه های هم خانواده وی ارائه خواهم کرد.

https://ocelot.readthedocs.io/en/latest/features/loadbalancer.html

@csharpfriends
#Microservice #ocelot #ApiGateway #LoadBalancing

بررسی اجمالی پیکربندی API Gateway یا گلوگاه با کتابخانه Ocelot

حال نگاهی به کتابخانه بسیار کاربردی ocelot می‌اندازیم. ocelot یک کتابخانه برای ساخت api gateway ها یا همان گلوگاه های برنامه است که به شما امکان پیکربندی آدرس ها و سرویس های مورد نظر و تعداد زیادی امکانات دیگر را میدهد.
در کانفیگ زیر، درخواستی که به مسیر blog/ در gateway میرسد با نام Upstream Path مشخص شده که ورودی ما هست(درخواست کلاینت یا سرویس دیگری)، بسته به کانفیگ به Downstream تعیین شده ارجاع داده میشود. (path ها همراه پارامترها و متد ها به همدیگر map میشوند، مانند routing mvc، عملا درخواست ها فقط ارجاع میشن و پاسخ دریافتی از سرویس ها از طریق gateway به کلاینت برمیگردد)
در این کانفیگ، دو instance از سرویس Blog اجرا شده و یکی از دو Down stream توسط مکانیزم load balancing انتخاب میشود.
پارامتر Downstream Path آدرس مسیریابی میکروسرویس ها را مشخص کرده و Downstream Scheme و HostAndPort به ترتیب پروتکل آنها و url و پورتی که هاست شده اند.
[Client] Request to gateway -> localhost:9000/blog/1
=> send [Get] /blog/1 to localhost:9001/api/blog/1
=> api gateway will receive blog service response -> send result to client
تنظیم Load Balancer هم روی الگوریتم نوبتی یا همان Round Robin است که بین localhost:9001 و localhost:9002 به ترتیب بار را تقسیم میکند.
به این صورت اتصال سفت میان سرویس ها کاهش یافته و کنترل و scalability پروژه افزایش چشمگیری میابد.
{
"DownstreamPathTemplate": "/api/blog/{id}",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{ "Host": "localhost", "Port": 9001 }, // blog instance #1
{ "Host": "localhost", "Port": 9002 } // blog clone #2
],
"UpstreamPathTemplate": "/blog/{id}",
"LoadBalancer": "RoundRobin", //OR LeastConnection OR Cookie sticky
"UpstreamHttpMethod": [ "Get" ]
}

Ocelot official Docs:
https://ocelot.readthedocs.io/en/latest/introduction/bigpicture.html

@csharpfriends
#Microservice #ocelot #ApiGateway #LoadBalancing

همینطور که در تصویر مشاهده میکنید، مفهوم گذرگاه و Api gateway به شکل ساده ای ترسیم شده.
رابط کاربری یا همان کلاینت، با Gateway در ارتباط خواهد بود و gateway وظیفه کنترل محدودیت ها، ثبت رخداد ها و مسیریابی به میکروسرویس ها را انجام میدهد.
گذرگاه مانند یک میان افزار، بسته به Config انجام شده برای آن (مانند mvc endpoint routing) وظیفه مسیریابی درخواست ها و مَپ کردن آنها به مسیرهای دو سرویس در پشت این گذرگاه را دارد. سپس خروجی آنها را برمیگرداند.
* یک درخواست میتواند نیازمند اجرای دو action مختلف باشد، مثلا کلاینت درخواست گزارش وضعیت هواشناسی را ارسال میکند، گذرگاه پس از گرفتن اطلاعات از سرویس آب و هوا (1) و سپس ارسال آن به سرویس دیگری برای پردازش (2) و نهایتا بازگشت نتیجه نهایی به کلاینت. این کار در Gateway ها امکان پذیر و قابل پیکربندی میباشد.
@csharpfriends #ApiGateway #MicroService #CleanArchitecture

از سری مطالب معماری مبتنی بر سرویس و میکروسرویس ها که در چند بخش توضیح داده شده / خواهد شد:
۱. انواع پیاده سازی میکروسرویس
۲. میکروسرویس ها و Api Gateway ها
- ارتباطات سرویس ها و کلاینت ها
- محدودیت نرخ درخواست ها و تبادل
- کیفیت خدمات و کنترل جریان QoS
- مقیاس پذیری، توزیع و تقسیم بار
- نگهداری و توسعه
- ابزار ها و کتابخانه های کاربردی، ocelot.net
۳. میکروسرویس ها، Message Broker و Event Bus ها
۴. داکر، container ها و kubernetes
۵. پلتفرم های ابری و ☁️ Cloud
۵.۱ سرویس های Azure

یه مدتی خیلی درگیر مشغله های کاری بودم و از کارایی که دوست داشتم فاصله گرفتم و مطالبی که نوشته بودم رو نرسیدم تکمیل کنم، اما ازونجایی که معمولا وقتی کاری رو هی به تعویق میندازیم به مراتب دیرتر انجام میدیم یا اصلا انجام نمیدیم 😁،
تصمیم گرفتم چکیده مطالب اخیری که داشتم مینوشتم رو بزارم تا بعدا کاملترشون کنیم. (کمالگرایی اگر واژه نزدیکی بهش باشه، معمولا هممون رو اذیت میکنه و وسواس بیشتری ایجاد میکنه)‌
قطعا جای تکمیل کردن و بهتر کردن وجود داره و هیچ کس و هیچ چیز کامل نیست، من هم معمولا مطالب رو به لحاظ تجربی و نگارش خودم یا با مشاوره دوستان مینویسم و ترجمه و کپی ای نیست. دوست ندارم چیزایی که بقیه نوشتن طوطی وار تیتر کنم.
پس نظراتتون بسیار ارزشمنده و آموزنده، اکثر شما سروران و استادان بنده اید ❤️

پیش نویس طرح حمايت از حقوق كاربران و خدمات پايه كاربردی فضای مجازی.
1400/04/26

💔 برنامه نویسی در ایران به تاریخ پیوست

بالاخره طرح قطع کردن اینترنت تصویب شد. 😭😭😭
هزاران برنامه نویس بیکار میشن
یا اینکه مجبور میشن با زجر و مکافات ادامه بدن...
۲۰ ساله شغلم اینه، الان چطوری بیوفتم دنبال کار دیگه

🚫کمپین بدون اینترنت برنامه نویسی نمیکنم🚫

پخش کنید تا صنعت نرم افزار بخوابه و بفهمن نباید ابزار برنامه نویسان رو ازشون گرفت و به زور وادارشون کرد که با زجر برنامه بنویسن
@SenfProgrammer
صنف مجازی برنامه نویسان
#کمپین_بدون_اینترنت_برنامه_نویسی_نمیکنم

https://news.1rj.ru/str/csharpfriendsgroup/72
یه بخشی از موسیقی های خوبو میزارم تو گروه شاید شماهم دوست داشته باشین موقع کار، استراحت گوش بدین.
سلیقه ایه راک، پست فولک بلوز، کلاسیک، ویولون ... ولی اشتراکا بی کلام.