Circuit Breaker & QOS (Quality of service) مکانیزم

مفهوم QOS یا کیفیت خدمات، توانایی ارائه اولویت های مختلف برای برنامه های مختلف و یا تضمین سطوح معینی از عملکرد یک جریان داده را بیان میکند. از معروف ترین کتابخانه هایی که پیکربندی و استفاده از این مکانیزم را فراهم میکنند کتابخانه Polly است که معمولا در کنار کتابخانه Ocelot با Api Gateway استفاده میشوند.
در صورتی که فرآیندی دچار اختلال و خطا شود، همه کلاینت ها خطا دریافت میکنند.
به عنوان مثال واکشی داده از سرویس منجر به رخ دادن استثناء هایی میشود. کلاینت ها هر بار درخواست قبلی را تکرار میکنند تا بلکه جوابی دریافت کنند و هزینه این اختلال، فشار به سرویس ها و حجم زیادی از درخواست ها است که میتواند منجر به کاهش پرفورمنس و تولید انبوهی لاگ و خطا شود.

حال اگر مکانیزم QOS را داشته باشید میتوانید در صورت بروز مشکل، سرویس ها را به حالت تعلیق درآورده و پیام مناسبی به کلاینت مبنی بر در دسترس نبودن سرویس و یا مشکل در پردازش درخواست ارسال کنید. همچنین میتوانید مکانیزم گزارش دهی خطا و Health Check را پیاده کرده و پس از مثلا ۵ دقیقه مجدد درخواست های جدید را به سرویس بفرستید. در صورتی که مجددا خطا رخ دهد، کلاینت ها تا ۵ دقیقه یا بیشتر، پیام عدم در دسترس بودن سرویس را برای درخواست های مشابه دریافت میکنند.

توسط این مکانیزم وقتی سرویس/برنامه ای به مشکل میخورد، دیگر درگیر درخواست ها و پردازش های تکراری نمیشود، تا زمانی که تیم فنی هشدار مربوطه را دریافت کرده و مشکل را رفع کنند و یا سرویس به حالت stable برسد.

برخی از مهمترین پارامترهای مکانیزم QOS:
- تعداد استثناء های مجاز قبل از قطع جریان یا ExceptionsAllowedBeforeBreaking بیان کننده تعداد خطاهایی است که اگر بیبشتر از آن خطا رخ دهد، جریان سرویس قطع میشود.
- مدت زمان قطع جریان یا DurationOfBreak تعیین کننده زمانی است که سرویس از دسترس خارج میشود و اصطلاحا جریان های داده آن (درخواست ها و پاسخ ها ...) قطع میشوند، و سپس مجددا آزاد میشود.
- مدت زمان پایان دادن درخواست یا TimeoutValue تعیین کننده زمانی است که باید پس از آن درخواست متوقف شود و time out برگرداند. مثلا اگر مقدار را روی 10000 بگذارید(10ثانیه)، درخواست هایی که بیشتر از 10 ثانیه طول بکشند بطور خودکار متوقف شده و به time out میخورند.

به این ترتیب میتوان کنترل و دسترسی پذیری بهتری را برای سرویس ها مهیا کرد تا در صورت بروز هر نوع اختلال حادی، بتوان از آن مطلع شد و در عین حال فشار و پردازش زیادی را از روی دوش سرور و کلاینت کاست. معمولا QOS را در API Gateway ها (به صورت Global یا برای هر سرویس) پیاده و کانفیگ میکنند. هر چند که میتوان در کدهای هر سرویس هم اینکار را کرد اما مقصود در اینجا یکبار انجام دادن آن (در gateway) و ایجاد انعطاف برای هر سرویسی است.

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

@csharpfriends
#ApiGateway #MicroService #Gateway #QOS #SoftwareArchitecture

مثالی از مکانیزم QoS و Circuit Breaker در یک API، که به خوبی فرآیند قطع جریان پس از رخ دادن خطا و سپس ادامه کار پس از باازگشت به وضعیت stable را نشان میدهد.
#Polly #QOS #Microservice

مکانیزم محدود کننده نرخ (Rate Limiting)

فرض کنید سرویسی در ثانیه چند صد درخواست پشت سر هم و بسیار سریع از کلاینت دریافت کند.
فرضا درخواست یک واکشی داده سنگین، میبایست صدبار اجرا شود ( حتی اگر کش هم داشته باشید فقط مرحله واکشی رو رد کردید). بنابر دلایل متعددی مانند حمله DDos، ربات ها و یا ارسال خیلی سریع درخواست به سرویس ها، سرویس های شما بی دفاع و آسیب پذیر هستند. ( در یک اپلیکیشن که اخیرا مینوشتیم کاربر میتونست تند تند صفحه رو با pull کردن رفرش کنه و جدای از داشتن کش به هر حال سرورو با ریکوئست های زیاد درگیر میکرد، یا همیشه خدا ربات های خزنده خارجی به endpoint های مختلف حمله میکردن)
مکانیزم محدود کننده نرخ تبادل (rate limiting) تعیین میکند که هر کلاینت مجاز به ارسال چند درخواست در ثانیه/دقیقه/ساعت/... است.
مثلا سرویس Payment(پرداخت) را طوری تنظیم کردید که اجازه ارسال 1 درخواست در فاصله زمانی 1 ثانیه را میدهد. هر کلاینتی که در طول 1 ثانیه، بیش از 1 درخواست ارسال کند پیامی مبنی بر محدود شدن به مدت 10 ثانیه دریافت میکند و زین پس درخواست های وی تا 10 ثانیه آینده بدون رسیدن به سرویس رد میشوند(چه 1 ریکوئست و چه 1000).

مهمترین پارامتر های مورد استفاده در این مکانیزم به شرح زیر میبباشد:
- دوره زمانی یا Period مشخص کننده بازه زمانی مجاز میبباشد، مثلا 1s/5m/1h/1d (1ثانیه/5دقیقه/1ساعت/1روز)
- زمان انتظار دوره یا Period Timespan تعیین کننده مدت زمانی است که میتوان پس از آن مجددا درخواست ارسال کرد. اگر کلاینت محدود شود و مثلا period timespan روی 10 تنظیم شده باشد، پس از گذشت 10 ثانیه مجاز به ارسال درخواست واقعی میشود.
- میزان محدودیت یا Limit تعیین کننده تعداد درخواست مجاز در بازه زمانی تعریف شده در Period است. بیشتر از این مقدار منجر به فعال شدن Period Timespan و اعمال محدودیت میشود.
- پیام تکمیل سهمیه مجاز یا QuotaExceededMessage حامل پیامیست که هنگام محدود شدن کلاینت به وی ارسال میشود.
- لیست سفید کلاینتها یا ClientWhitelist میتواند در بردارنده کلاینت های به خصوصی باشد که مکانیزم RateLimiting روی آنها اعمال نمیشود (مثلا کلاینت هایی مثل پنل ادمین که بهشون اطمینان دارید)
- کد وضعیت یا HttpStatusCode تعیین کننده http code دلخواهیست که هنگام رخ دادن مکانیزم محدودیت به کلاینت ارسال میشود (استاندارد کد 409 نشان دهنده وضعیت Too Many Request است)

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

نمونه ای از مکانیزم 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
یه بخشی از موسیقی های خوبو میزارم تو گروه شاید شماهم دوست داشته باشین موقع کار، استراحت گوش بدین.
سلیقه ایه راک، پست فولک بلوز، کلاسیک، ویولون ... ولی اشتراکا بی کلام.