마이크로서비스 소개 pt. 6

목차


  • What are we trying to solve?
  • The Solution: Messaging
  • Show Me the Code
  • Bibliography

  • 5부에서는 에 대해 이야기했습니다. 이 시리즈의 마지막 부분에서는 서비스가 동기식 방식으로 공동 작업을 시도하지만 할 수 없는 상황을 처리하는 방법에 대해 설명합니다. Circuit Breaker.

    우리는 무엇을 해결하려고 합니까?

    As we said before, our application's services often need to collaborate. They can do this asynchronously, e.g. messaging, or they can do it synchronously. When they collaborate synchronously, the called service might be unavailable or with high latency. While the caller service waits for an answer, its resources, such as threads, will be blocked. This can lead to resource exhaustion, which would make the caller unavailable too. This can cascade on our entire application. So, how can we solve this?

    솔루션: 회로 차단기

    We can introduce a Circuit Breaker on our services. Each service must implement a proxy, which will work similarly to an electrical circuit. If a call to an specific service fails too many times, the circuit breaker is activated and, for a period of time, all the following calls made to that service will fail automatically. After the period expires, the circuit breaker will allow some requests through. If none of them fail, the circuit breaker is deactivated. Otherwise, the timer will be reset.

    By failing fast, we'll avoid that the caller service hangs and wastes precious resources from a call that will, most likely, fail!

    이익


  • 서비스가 빠르게 실패하여 리소스 낭비를 방지할 수 있습니다.

  • 단점


  • 가양성을 생성하거나 과도한 대기 시간을 추가하지 않고 시간 초과 값을 선택하기가 어렵습니다.

  • 코드를 보여주세요

    Just for the sake of simplicity, I'll show you how to implement the Circuit Breaker pattern only on our API Gateway. If you want to dive deeper on the pattern and implement it between two services, you can head over to the Polly project Github. Polly는 Ocelot이 회로 차단기를 구현하는 데 사용하는 것과 동일한 라이브러리입니다. 자, 이제 코드를 봅시다!

    API 게이트웨이에서 회로 차단기를 구현하려면 먼저 프로젝트에 패키지를 추가해야 합니다.

    dotnet add package Ocelot.Provider.Polly
    


    그러면 게이트웨이에 Polly 공급자가 추가됩니다. 설치 후 'ocelot.json' 파일을 엽니다. 로드 밸런서의 경우와 마찬가지로 경로당 경로별로 회로 차단기를 적용해야 합니다. 이렇게 하려면 원하는 경로에 다음을 추가합니다.

    {
        "Routes": [
            {
                // ...
                "QoSOptions": {
                    "ExceptionsAllowedBeforeBreaking": 3,
                    "DurationOfBreak": 10000,
                    "TimeoutValue": 5000
                }
            },
            {
                // ...
            }
        ],
        // ...
    }
    


    이 코드를 설명하겠습니다. "QoSOptions"는 "서비스 품질 옵션"을 나타내며 여기에서 회로 차단기를 활성화하는 규칙을 정의합니다. 첫 번째 속성 "ExceptionsAllowedBeforeBreaking"은 호출이 실패할 수 있는 횟수를 정의합니다. "DurationOfBreak"속성은 회로 차단기가 활성 상태로 유지되는 시간을 밀리초 단위로 정의합니다. 마지막으로 "TimeoutValue"속성은 요청이 응답 없이 정지될 수 있는 시간을 밀리초 단위로 정의합니다.

    설정을 완료하려면 "Startup.cs"파일을 편집해야 합니다. 게이트웨이에 Polly 서비스를 삽입해야 합니다.

    // Startp.cs
    public void ConfigureServices(IServiceCollection services)
    {
        // ...
        services.AddOcelot().AddConsul().AddPolly();
        // ...
    }
    


    그게 다야! 드디어 시리즈가 끝났습니다. 이제 로드 밸런싱이 포함된 API 게이트웨이가 있고 서비스 레지스트리와 상태 확인을 사용하여 서비스의 위치와 가용성을 동적으로 결정하고 메시징과 비동기식 통신을 하고 동기식 통신 실패를 정상적으로 처리할 수 있는 기본 애플리케이션이 있습니다!

    아래 댓글에서 이 시리즈에 대한 생각을 알려주세요. 마이크로서비스에 대해 자세히 알아보려면 microservices.io 페이지를 방문하세요!

    서지

  • Microservices Patterns: Examples with Java - Chris Richardson
  • Circuit Breaker pattern - https://microservices.io/patterns/reliability/circuit-breaker.html
  • 서비스 품질 - 오셀롯 - https://ocelot.readthedocs.io/en/latest/features/qualityofservice.html
  • 폴리 - https://github.com/App-vNext/Polly
  • 좋은 웹페이지 즐겨찾기