#Microservice
#CircuitBreaker
این الگو ابرای تشخیص قطعی ها و منطق جلوگیری از تکرار مداوم یک مشکل در ارتباط به کار می رود زمانی که سرویس ما یا برنامه ما از یک سرویس ثانویه استفاده میکند
فرض کنید درخواستی به سرویس ما یا برنامه ما ارسال می شود. برنامه ما این درخواست را باید به سرویس ثانویه ارسال کند تا جواب ان را بعد از تحلیل به درخواست کننده ارسال کند. حال فرض کنید در این حالت برای سرویس ثانویه مشکلی پیش می اید/ارتباط شبکه قطع می شود/ سرویس قطع شده /زمان دریافت جواب طولانی می شود/ غیره . وقتی که تعداد درخواست هایی که به برنامه ما ارسال می شود خیلی زیاد شود، برنامه ما درگیر این درخواست هایی می شود که جواب های یکسان و خطا است و ممکن است برنامه با مشکل مواجه شود.
الگوی circuitbreaker به عنوان لایه ای بین برنامه ما و سرویس ثانویه قرار می گیرد و برای سناریوهای مشابه، جواب های اماده ارسال می کند. به عنوان مثال بعد از چند بار دریافت timeout دیگر پاسخ درخواست ها را بدون این که به سرویس ثانویه ارسال کند برگردانده و با پیغام مناسب نمایش داده می شود.
استفاده از این الگو باعث می‌شود زمانی که یک قسمت یک سیستم دچار مشکل شده است یا موقتاً Down شده است بقیه قسمت‌های سیستم بکار خود ادامه دهند و مشکل Cascading Failure رخ ندهد.
پیاده‌سازی Circuit Breaker را می‌توان به‌صورت Central در سطح Gateway یا برای هر سرویس پیاده‌سازی کرد که بنا بر استفاده و نیاز هر سازمان مزایا و معایبی دارد که می‌توان به موارد زیر اشاره کرد:
اگر به‌صورت متمرکز پیاده شود، نیاز نیست هر تیم به‌صورت جداگانه روی پروژه‌های خود پیاده کند.
اگر به‌صورت متمرکز پیاده شود، نیاز نیست اعضای هر تیم دانشی برای پیاده‌سازی آن داشته باشند.
اگر به‌صورت متمرکز پیاده شود، و سرویس مرکزی از کار بیفتد کل سیستم از کار می افتد.
اگر جداگانه پیاده شود، و اگر تیم‌ها و سرویس‌ها با تکنولوژی‌های مختلفی پیاده‌سازی شده باشند، پیچیدگی کار، Learning Curve ایجاد شده برای Developer های هر سرویس قطعاً بیشتر خواهد بود.
این الگو سه حالت دارد
1- Close
2- Open
3- halfOpen
حالت close وقتی است که درخواست ارسال شده و جواب ان بدون مشکل برگردانده می شود و مشکلی وجود ندارد
حالت open در صورتی است که پس از فراخوانی سرویس ثانویه با خطا مواجه شویم و یا درصد مشخصی از درخواست ها با مشکل مواجه شوند در این صورت circuitBreaker به حالت open رفته و درخواست به سرویس ثانویه ارسال نخواهد کرد و خودش جواب پیش فرض را بر میگرداند
حالت halfOpen در صورتی است که بعد از یک بازه زمانی مشخص یا… مجددا درخواستی به سرویس ثانویه ارسال می شود اگر جواب برگرندانده شد یعنی ارتباط درست است و به حالت close تغییر خواهد یافت در صورتی که جواب با مشکل مواجه شد به حالت open رفته و مجددا این روال تکرار خواهد شد.
ترجمه:
The concept of microservice design patterns in simple terms
#Microservice
#CircuitBreaker
This pattern is used to detect outages and logic to prevent a communication problem from recurring when our service or application uses a secondary service.
Suppose a request is sent to our service or our application. Our program should send this request to the secondary service to send the answer to the requester after analysis. Now suppose that in this case there is a problem with the secondary service/the network connection is interrupted/the service is interrupted/the time to receive the answer is prolonged/etc. When the number of requests sent to our program increases, our program gets involved in these requests that have the same answers and errors, and the program may encounter problems.
The circuitbreaker pattern is placed as a layer between our application and the secondary service and sends prepared responses for similar scenarios. For example, after receiving a timeout several times, the response to the requests will be returned without sending to the secondary service and displayed with the appropriate message.
Using this model makes it possible for other parts of the system to continue working when one part of a system has a problem or is temporarily down, and the problem of cascading failure does not occur.
The implementation of Circuit Breaker can be implemented centrally at the Gateway level or for each service, which has advantages and disadvantages depending on the use and needs of each organization, which can be mentioned as follows:
If it is implemented centrally, there is no need for each team to implement it individually on their projects.
If it is implemented centrally, there is no need for each team member to have the knowledge to implement it.
If it is executed centrally, and the central service fails, the entire system will fail.
If it is implemented separately, and if teams and services are implemented with different technologies, the complexity of the work, the learning curve created for the developers of each service will definitely be higher.
This pattern has three modes
1- Close
2- Open
3- Half Open
The close mode is when the request is sent and the answer is returned without any problem and there is no problem
The open mode is if we encounter an error after calling the secondary service or if a certain percentage of requests encounter problems, in this case circuitBreaker will go to open mode and will not send requests to the secondary service and will return the default answer.
The half-open mode is if a request is sent to the secondary service again after a certain period of time or… If the answer is returned, it means that the connection is correct and it will be changed to the close mode, if the answer encounters a problem, to the open mode This procedure will be repeated again.
#Microservice
#CircuitBreaker
This pattern is used to detect outages and logic to prevent a communication problem from recurring when our service or application uses a secondary service.
Suppose a request is sent to our service or our application. Our program should send this request to the secondary service to send the answer to the requester after analysis. Now suppose that in this case there is a problem with the secondary service/the network connection is interrupted/the service is interrupted/the time to receive the answer is prolonged/etc. When the number of requests sent to our program increases, our program gets involved in these requests that have the same answers and errors, and the program may encounter problems.
The circuitbreaker pattern is placed as a layer between our application and the secondary service and sends prepared responses for similar scenarios. For example, after receiving a timeout several times, the response to the requests will be returned without sending to the secondary service and displayed with the appropriate message.
Using this model makes it possible for other parts of the system to continue working when one part of a system has a problem or is temporarily down, and the problem of cascading failure does not occur.
The implementation of Circuit Breaker can be implemented centrally at the Gateway level or for each service, which has advantages and disadvantages depending on the use and needs of each organization, which can be mentioned as follows:
If it is implemented centrally, there is no need for each team to implement it individually on their projects.
If it is implemented centrally, there is no need for each team member to have the knowledge to implement it.
If it is executed centrally, and the central service fails, the entire system will fail.
If it is implemented separately, and if teams and services are implemented with different technologies, the complexity of the work, the learning curve created for the developers of each service will definitely be higher.
This pattern has three modes
1- Close
2- Open
3- Half Open
The close mode is when the request is sent and the answer is returned without any problem and there is no problem
The open mode is if we encounter an error after calling the secondary service or if a certain percentage of requests encounter problems, in this case circuitBreaker will go to open mode and will not send requests to the secondary service and will return the default answer.
The half-open mode is if a request is sent to the secondary service again after a certain period of time or… If the answer is returned, it means that the connection is correct and it will be changed to the close mode, if the answer encounters a problem, to the open mode This procedure will be repeated again.
