원격 데이터에 액세스Accessing Remote Data

많은 최신 웹 기반 솔루션은 웹 서버에서 호스트 되는 웹 서비스를 사용 하 여 원격 클라이언트 응용 프로그램에 대 한 기능을 제공 합니다.Many modern web-based solutions make use of web services, hosted by web servers, to provide functionality for remote client applications. 웹 서비스에서 노출 하는 작업은 web API를 구성 합니다.The operations that a web service exposes constitute a web API.

클라이언트 앱은 API에서 노출 하는 데이터 또는 작업이 어떻게 구현 되는지 몰라도 웹 API를 활용할 수 있어야 합니다.Client apps should be able to utilize the web API without knowing how the data or operations that the API exposes are implemented. 이렇게 하려면 API가 클라이언트 앱 및 웹 서비스에서 사용할 데이터 형식 및 클라이언트 앱과 웹 서비스 간에 교환 되는 데이터의 구조에 동의할 수 있도록 하는 일반적인 표준에 따라 유럽 연합 합니다.This requires that the API abides by common standards that enable a client app and web service to agree on which data formats to use, and the structure of the data that is exchanged between client apps and the web service.

Representational State Transfer 소개Introduction to Representational State Transfer

REST (Representational State Transfer)는 하이퍼 미디어를 기반으로 분산 시스템을 구축 하기 위한 아키텍처 스타일입니다.Representational State Transfer (REST) is an architectural style for building distributed systems based on hypermedia. REST 모델의 주요 이점은 개방형 표준을 기반으로 하며, 모델 또는이를 액세스 하는 클라이언트 앱의 구현을 특정 구현에 바인딩하지 않는다는 것입니다.A primary advantage of the REST model is that it's based on open standards and doesn't bind the implementation of the model or the client apps that access it to any specific implementation. 따라서 Microsoft ASP.NET Core MVC를 사용 하 여 REST 웹 서비스를 구현할 수 있으며, 클라이언트 앱은 HTTP 요청을 생성 하 고 HTTP 응답을 구문 분석할 수 있는 모든 언어 및 도구 집합을 사용 하 여 개발할 수 있습니다.Therefore, a REST web service could be implemented using Microsoft ASP.NET Core MVC, and client apps could be developing using any language and toolset that can generate HTTP requests and parse HTTP responses.

REST 모델은 탐색 체계를 사용 하 여 네트워크를 통해 개체 및 서비스를 나타냅니다 (리소스 라고 함).The REST model uses a navigational scheme to represent objects and services over a network, referred to as resources. REST를 구현 하는 시스템은 일반적으로 HTTP 프로토콜을 사용 하 여 이러한 리소스에 액세스 하기 위한 요청을 전송 합니다.Systems that implement REST typically use the HTTP protocol to transmit requests to access these resources. 이러한 시스템에서 클라이언트 앱은 리소스를 식별 하는 URI 형식으로 요청을 제출 하 고 해당 리소스에 대해 수행할 작업을 나타내는 HTTP 메서드 (예: GET, POST, PUT 또는 DELETE)를 제출 합니다.In such systems, a client app submits a request in the form of a URI that identifies a resource, and an HTTP method (such as GET, POST, PUT, or DELETE) that indicates the operation to be performed on that resource. HTTP 요청의 본문에는 작업을 수행 하는 데 필요한 데이터가 포함 되어 있습니다.The body of the HTTP request contains any data required to perform the operation.

참고

REST는 상태 비저장 요청 모델을 정의 합니다.REST defines a stateless request model. 따라서 HTTP 요청은 독립적 이어야 하 고 순서에 관계 없이 발생할 수 있습니다.Therefore, HTTP requests must be independent and might occur in any order.

REST 요청의 응답은 표준 HTTP 상태 코드를 사용 합니다.The response from a REST request makes use of standard HTTP status codes. 예를 들어 유효한 데이터를 반환 하는 요청은 HTTP 응답 코드 200 (OK)를 포함 해야 하는 반면, 지정 된 리소스를 찾거나 삭제 하지 못한 요청은 HTTP 상태 코드 404 (찾을 수 없음)을 포함 하는 응답을 반환 해야 합니다.For example, a request that returns valid data should include the HTTP response code 200 (OK), while a request that fails to find or delete a specified resource should return a response that includes the HTTP status code 404 (Not Found).

RESTful web API는 연결 된 리소스 집합을 노출 하 고, 앱이 해당 리소스를 조작 하 고 이러한 리소스를 쉽게 탐색할 수 있도록 하는 핵심 작업을 제공 합니다.A RESTful web API exposes a set of connected resources, and provides the core operations that enable an app to manipulate those resources and easily navigate between them. 이러한 이유로 일반적인 RESTful web API를 구성 하는 Uri는 노출 되는 데이터를 기반으로 하며 HTTP에서 제공 하는 기능을 사용 하 여이 데이터에 대해 작동 합니다.For this reason, the URIs that constitute a typical RESTful web API are oriented towards the data that it exposes, and use the facilities provided by HTTP to operate on this data.

HTTP 요청에 클라이언트 앱에 포함 된 데이터와 웹 서버의 해당 응답 메시지는 미디어 유형 이라고 하는 다양 한 형식으로 표시 될 수 있습니다.The data included by a client app in an HTTP request, and the corresponding response messages from the web server, could be presented in a variety of formats, known as media types. 클라이언트 앱은 메시지 본문에 데이터를 반환 하는 요청을 보낼 때 요청의 Accept 헤더에서 처리할 수 있는 미디어 형식을 지정할 수 있습니다.When a client app sends a request that returns data in the body of a message, it can specify the media types it can handle in the Accept header of the request. 웹 서버에서이 미디어 유형을 지 원하는 경우 메시지 본문에 있는 데이터의 형식을 지정 하는 Content-Type 헤더를 포함 하는 응답으로 회신할 수 있습니다.If the web server supports this media type, it can reply with a response that includes the Content-Type header that specifies the format of the data in the body of the message. 클라이언트 앱이 응답 메시지를 구문 분석 하 고 결과를 적절 하 게 해석 해야 합니다.It's then the responsibility of the client app to parse the response message and interpret the results in the message body appropriately.

REST에 대 한 자세한 내용은 api 디자인api 구현을 참조 하세요.For more information about REST, see API design and API implementation.

RESTful Api 사용Consuming RESTful APIs

EShopOnContainers 모바일 앱은 MVVM (모델-뷰-ViewModel) 패턴을 사용 하며, 패턴의 모델 요소는 앱에서 사용 되는 도메인 엔터티를 나타냅니다.The eShopOnContainers mobile app uses the Model-View-ViewModel (MVVM) pattern, and the model elements of the pattern represent the domain entities used in the app. EShopOnContainers reference 응용 프로그램의 컨트롤러 및 리포지토리 클래스는 이러한 여러 모델 개체를 허용 하 고 반환 합니다.The controller and repository classes in the eShopOnContainers reference application accept and return many of these model objects. 따라서 모바일 앱과 컨테이너 화 된 마이크로 서비스 간에 전달 되는 모든 데이터를 저장 하는 Dto (데이터 전송 개체)로 사용 됩니다.Therefore, they are used as data transfer objects (DTOs) that hold all the data that is passed between the mobile app and the containerized microservices. Dto를 사용 하 여 웹 서비스에 데이터를 전달 하 고 데이터를 수신 하는 경우의 주요 혜택은 단일 원격 호출에서 더 많은 데이터를 전송 하 여 앱이 수행 해야 하는 원격 호출의 수를 줄일 수 있다는 것입니다.The main benefit of using DTOs to pass data to and receive data from a web service is that by transmitting more data in a single remote call, the app can reduce the number of remote calls that need to be made.

웹 요청 수행Making Web Requests

EShopOnContainers 모바일 앱은 HttpClient 클래스를 사용 하 여 HTTP를 통해 요청을 수행 하며, JSON은 미디어 유형으로 사용 됩니다.The eShopOnContainers mobile app uses the HttpClient class to make requests over HTTP, with JSON being used as the media type. 이 클래스는 URI로 식별 된 리소스에서 HTTP 요청을 비동기적으로 보내고 HTTP 응답을 받기 위한 기능을 제공 합니다.This class provides functionality for asynchronously sending HTTP requests and receiving HTTP responses from a URI identified resource. @No__t_0 클래스는 HTTP 요청이 수행 된 후 REST API에서 받은 HTTP 응답 메시지를 나타냅니다.The HttpResponseMessage class represents an HTTP response message received from a REST API after an HTTP request has been made. 상태 코드, 헤더 및 모든 본문을 포함 하 여 응답에 대 한 정보를 포함 합니다.It contains information about the response, including the status code, headers, and any body. 합니다 HttpContent 클래스를 나타내는 HTTP 본문 및 콘텐츠 헤더와 같은 Content-TypeContent-Encoding입니다.The HttpContent class represents the HTTP body and content headers, such as Content-Type and Content-Encoding. 데이터의 형식에 따라 ReadAsStringAsyncReadAsByteArrayAsync와 같은 ReadAs 방법 중 하나를 사용 하 여 콘텐츠를 읽을 수 있습니다.The content can be read using any of the ReadAs methods, such as ReadAsStringAsync and ReadAsByteArrayAsync, depending on the format of the data.

GET 요청 만들기Making a GET Request

@No__t_0 클래스는 카탈로그 마이크로 서비스에서 데이터 검색 프로세스를 관리 하는 데 사용 됩니다.The CatalogService class is used to manage the data retrieval process from the catalog microservice. @No__t_1 클래스의 RegisterDependencies 메서드에서 CatalogService 클래스는 Autofac 종속성 주입 컨테이너를 사용 하 여 ICatalogService 형식에 대 한 형식 매핑으로 등록 됩니다.In the RegisterDependencies method in the ViewModelLocator class, the CatalogService class is registered as a type mapping against the ICatalogService type with the Autofac dependency injection container. 그런 다음 CatalogViewModel 클래스의 인스턴스를 만들 때 해당 생성자는 Autofac가 확인 하 고 CatalogService 클래스의 인스턴스를 반환 하는 ICatalogService 형식을 받아들입니다.Then, when an instance of the CatalogViewModel class is created, its constructor accepts an ICatalogService type, which Autofac resolves, returning an instance of the CatalogService class. 종속성 주입에 대 한 자세한 내용은 종속성 주입 소개를 참조 하세요.For more information about dependency injection, see Introduction to Dependency Injection.

그림 10-1에서는 CatalogView 표시 하기 위해 카탈로그 마이크로 서비스에서 카탈로그 데이터를 읽는 클래스의 상호 작용을 보여 줍니다.Figure 10-1 shows the interaction of classes that read catalog data from the catalog microservice for displaying by the CatalogView.

그림 10-1: 카탈로그 마이크로 서비스에서 데이터 검색Figure 10-1: Retrieving data from the catalog microservice

@No__t_0 탐색 될 때 CatalogViewModel 클래스의 OnInitialize 메서드가 호출 됩니다.When the CatalogView is navigated to, the OnInitialize method in the CatalogViewModel class is called. 이 메서드는 다음 코드 예제에서 보여 주는 것 처럼 카탈로그 마이크로 서비스에서 카탈로그 데이터를 검색 합니다.This method retrieves catalog data from the catalog microservice, as demonstrated in the following code example:

public override async Task InitializeAsync(object navigationData)  
{  
    ...  
    Products = await _productsService.GetCatalogAsync();  
    ...  
}

이 메서드는 Autofac에서 CatalogViewModel에 삽입 된 CatalogService 인스턴스의 GetCatalogAsync 메서드를 호출 합니다.This method calls the GetCatalogAsync method of the CatalogService instance that was injected into the CatalogViewModel by Autofac. 다음 코드 예제는 GetCatalogAsync 메서드를 보여줍니다.The following code example shows the GetCatalogAsync method:

public async Task<ObservableCollection<CatalogItem>> GetCatalogAsync()  
{  
    UriBuilder builder = new UriBuilder(GlobalSetting.Instance.CatalogEndpoint);  
    builder.Path = "api/v1/catalog/items";  
    string uri = builder.ToString();  

    CatalogRoot catalog = await _requestProvider.GetAsync<CatalogRoot>(uri);  
    ...  
    return catalog?.Data.ToObservableCollection();            
}

이 메서드는 요청을 보낼 리소스를 식별 하는 URI를 작성 하 고, RequestProvider 클래스를 사용 하 여 리소스에서 GET HTTP 메서드를 호출한 후 CatalogViewModel에 결과를 반환 합니다.This method builds the URI that identifies the resource the request will be sent to, and uses the RequestProvider class to invoke the GET HTTP method on the resource, before returning the results to the CatalogViewModel. @No__t_0 클래스에는 리소스를 식별 하는 URI 형식, 해당 리소스에 대해 수행할 작업을 나타내는 HTTP 메서드, 작업을 수행 하는 데 필요한 데이터를 포함 하는 본문으로 요청을 전송 하는 기능이 포함 되어 있습니다.The RequestProvider class contains functionality that submits a request in the form of a URI that identifies a resource, an HTTP method that indicates the operation to be performed on that resource, and a body that contains any data required to perform the operation. @No__t_0 클래스가 CatalogService class에 삽입 되는 방법에 대 한 자세한 내용은 종속성 주입 소개를 참조 하세요.For information about how the RequestProvider class is injected into the CatalogService class, see Introduction to Dependency Injection.

다음 코드 예제에서는 RequestProvider 클래스의 GetAsync 메서드를 보여 줍니다.The following code example shows the GetAsync method in the RequestProvider class:

public async Task<TResult> GetAsync<TResult>(string uri, string token = "")  
{  
    HttpClient httpClient = CreateHttpClient(token);  
    HttpResponseMessage response = await httpClient.GetAsync(uri);  

    await HandleResponse(response);  
    string serialized = await response.Content.ReadAsStringAsync();  

    TResult result = await Task.Run(() =>   
        JsonConvert.DeserializeObject<TResult>(serialized, _serializerSettings));  

    return result;  
}

이 메서드는 CreateHttpClient 메서드를 호출 합니다 .이 메서드는 적절 한 헤더 집합을 사용 하 여 HttpClient 클래스의 인스턴스를 반환 합니다.This method calls the CreateHttpClient method, which returns an instance of the HttpClient class with the appropriate headers set. 그런 다음 응답을 HttpResponseMessage 인스턴스에 저장 하 여 URI로 식별 되는 리소스에 비동기 GET 요청을 제출 합니다.It then submits an asynchronous GET request to the resource identified by the URI, with the response being stored in the HttpResponseMessage instance. 그런 다음 응답에 성공 HTTP 상태 코드가 포함 되지 않은 경우 예외를 throw 하는 HandleResponse 메서드가 호출 됩니다.The HandleResponse method is then invoked, which throws an exception if the response doesn't include a success HTTP status code. 그런 다음 응답을 문자열로 읽어 JSON에서 CatalogRoot 개체로 변환 하 고 CatalogService에 반환 합니다.Then the response is read as a string, converted from JSON to a CatalogRoot object, and returned to the CatalogService.

@No__t_0 메서드는 다음 코드 예제에 나와 있습니다.The CreateHttpClient method is shown in the following code example:

private HttpClient CreateHttpClient(string token = "")  
{  
    var httpClient = new HttpClient();  
    httpClient.DefaultRequestHeaders.Accept.Add(  
        new MediaTypeWithQualityHeaderValue("application/json"));  

    if (!string.IsNullOrEmpty(token))  
    {  
        httpClient.DefaultRequestHeaders.Authorization =   
            new AuthenticationHeaderValue("Bearer", token);  
    }  
    return httpClient;  
}

이 메서드는 HttpClient 클래스의 새 인스턴스를 만들고 HttpClient 인스턴스에서 수행 하는 모든 요청에 대 한 Accept 헤더를 application/json로 설정 합니다 .이 헤더는 JSON을 사용 하 여 응답의 콘텐츠를 포맷할 것으로 예상 함을 나타냅니다.This method creates a new instance of the HttpClient class, and sets the Accept header of any requests made by the HttpClient instance to application/json, which indicates that it expects the content of any response to be formatted using JSON. 그런 다음 CreateHttpClient 메서드에 대 한 인수로 전달 된 액세스 토큰은 HttpClient 인스턴스에서 만든 요청의 Authorization 헤더에 추가 되 고 문자열 Bearer 접두사가 추가 됩니다.Then, if an access token was passed as an argument to the CreateHttpClient method, it's added to the Authorization header of any requests made by the HttpClient instance, prefixed with the string Bearer. 권한 부여에 대 한 자세한 내용은 권한 부여를 참조 하세요.For more information about authorization, see Authorization.

@No__t_1 클래스의 GetAsync 메서드가 HttpClient.GetAsync를 호출 하는 경우 다음 코드 예제와 같이 Catalog 프로젝트의 CatalogController 클래스에서 Items 메서드가 호출 됩니다.When the GetAsync method in the RequestProvider class calls HttpClient.GetAsync, the Items method in the CatalogController class in the Catalog.API project is invoked, which is shown in the following code example:

[HttpGet]  
[Route("[action]")]  
public async Task<IActionResult> Items(  
    [FromQuery]int pageSize = 10, [FromQuery]int pageIndex = 0)  
{  
    var totalItems = await _catalogContext.CatalogItems  
        .LongCountAsync();  

    var itemsOnPage = await _catalogContext.CatalogItems  
        .OrderBy(c=>c.Name)  
        .Skip(pageSize * pageIndex)  
        .Take(pageSize)  
        .ToListAsync();  

    itemsOnPage = ComposePicUri(itemsOnPage);  
    var model = new PaginatedItemsViewModel<CatalogItem>(  
        pageIndex, pageSize, totalItems, itemsOnPage);             

    return Ok(model);  
}

이 메서드는 EntityFramework를 사용 하 여 SQL 데이터베이스에서 카탈로그 데이터를 검색 하 고, 성공 HTTP 상태 코드를 포함 하는 응답 메시지로 반환 하 고, JSON 형식의 CatalogItem 인스턴스 컬렉션을 반환 합니다.This method retrieves the catalog data from the SQL database using EntityFramework, and returns it as a response message that includes a success HTTP status code, and a collection of JSON formatted CatalogItem instances.

POST 요청 만들기Making a POST Request

@No__t_0 클래스는 바구니 마이크로 서비스를 사용 하 여 데이터 검색 및 업데이트 프로세스를 관리 하는 데 사용 됩니다.The BasketService class is used to manage the data retrieval and update process with the basket microservice. @No__t_1 클래스의 RegisterDependencies 메서드에서 BasketService 클래스는 Autofac 종속성 주입 컨테이너를 사용 하 여 IBasketService 형식에 대 한 형식 매핑으로 등록 됩니다.In the RegisterDependencies method in the ViewModelLocator class, the BasketService class is registered as a type mapping against the IBasketService type with the Autofac dependency injection container. 그런 다음 BasketViewModel 클래스의 인스턴스를 만들 때 해당 생성자는 Autofac가 확인 하 고 BasketService 클래스의 인스턴스를 반환 하는 IBasketService 형식을 받아들입니다.Then, when an instance of the BasketViewModel class is created, its constructor accepts an IBasketService type, which Autofac resolves, returning an instance of the BasketService class. 종속성 주입에 대 한 자세한 내용은 종속성 주입 소개를 참조 하세요.For more information about dependency injection, see Introduction to Dependency Injection.

그림 10-2은 BasketView에서 표시 하는 바구니 데이터를 바구니 마이크로 서비스 전송 하는 클래스의 상호 작용을 보여 줍니다.Figure 10-2 shows the interaction of classes that send the basket data displayed by the BasketView, to the basket microservice.

그림 10-2: 바구니에 데이터 보내기 마이크로 서비스Figure 10-2: Sending data to the basket microservice

바구니에 항목을 추가 하면 BasketViewModel 클래스의 ReCalculateTotalAsync 메서드가 호출 됩니다.When an item is added to the shopping basket, the ReCalculateTotalAsync method in the BasketViewModel class is called. 이 메서드는 바구니에 있는 항목의 total 값을 업데이트 하 고 다음 코드 예제와 같이 바구니 데이터를 바구니 마이크로 서비스 보냅니다.This method updates the total value of items in the basket, and sends the basket data to the basket microservice, as demonstrated in the following code example:

private async Task ReCalculateTotalAsync()  
{  
    ...  
    await _basketService.UpdateBasketAsync(new CustomerBasket  
    {  
        BuyerId = userInfo.UserId,   
        Items = BasketItems.ToList()  
    }, authToken);  
}

이 메서드는 Autofac에서 BasketViewModel에 삽입 된 BasketService 인스턴스의 UpdateBasketAsync 메서드를 호출 합니다.This method calls the UpdateBasketAsync method of the BasketService instance that was injected into the BasketViewModel by Autofac. 다음 메서드는 UpdateBasketAsync 메서드를 보여 줍니다.The following method shows the UpdateBasketAsync method:

public async Task<CustomerBasket> UpdateBasketAsync(CustomerBasket customerBasket, string token)  
{  
    UriBuilder builder = new UriBuilder(GlobalSetting.Instance.BasketEndpoint);  
    string uri = builder.ToString();  
    var result = await _requestProvider.PostAsync(uri, customerBasket, token);  
    return result;  
}

이 메서드는 요청을 보낼 리소스를 식별 하는 URI를 작성 하 고, RequestProvider 클래스를 사용 하 여 리소스에서 POST HTTP 메서드를 호출한 후 BasketViewModel에 결과를 반환 합니다.This method builds the URI that identifies the resource the request will be sent to, and uses the RequestProvider class to invoke the POST HTTP method on the resource, before returning the results to the BasketViewModel. 인증 프로세스 중에 IdentityServer에서 얻은 액세스 토큰은 바구니 마이크로 서비스 요청에 권한을 부여 하는 데 필요 합니다.Note that an access token, obtained from IdentityServer during the authentication process, is required to authorize requests to the basket microservice. 권한 부여에 대 한 자세한 내용은 권한 부여를 참조 하세요.For more information about authorization, see Authorization.

다음 코드 예제에서는 RequestProvider 클래스의 PostAsync 메서드 중 하나를 보여 줍니다.The following code example shows one of the PostAsync methods in the RequestProvider class:

public async Task<TResult> PostAsync<TResult>(  
    string uri, TResult data, string token = "", string header = "")  
{  
    HttpClient httpClient = CreateHttpClient(token);  
    ...  
    var content = new StringContent(JsonConvert.SerializeObject(data));  
    content.Headers.ContentType = new MediaTypeHeaderValue("application/json");  
    HttpResponseMessage response = await httpClient.PostAsync(uri, content);  

    await HandleResponse(response);  
    string serialized = await response.Content.ReadAsStringAsync();  

    TResult result = await Task.Run(() =>  
        JsonConvert.DeserializeObject<TResult>(serialized, _serializerSettings));  

    return result;  
}

이 메서드는 CreateHttpClient 메서드를 호출 합니다 .이 메서드는 적절 한 헤더 집합을 사용 하 여 HttpClient 클래스의 인스턴스를 반환 합니다.This method calls the CreateHttpClient method, which returns an instance of the HttpClient class with the appropriate headers set. 그런 다음 URI에 의해 식별 되는 리소스에 비동기 POST 요청을 전송 하 고, serialize 된 바구니 데이터를 JSON 형식으로 보내고, 응답을 HttpResponseMessage 인스턴스에 저장 합니다.It then submits an asynchronous POST request to the resource identified by the URI, with the serialized basket data being sent in JSON format, and the response being stored in the HttpResponseMessage instance. 그런 다음 응답에 성공 HTTP 상태 코드가 포함 되지 않은 경우 예외를 throw 하는 HandleResponse 메서드가 호출 됩니다.The HandleResponse method is then invoked, which throws an exception if the response doesn't include a success HTTP status code. 그런 다음 응답을 문자열로 읽어 JSON에서 CustomerBasket 개체로 변환 하 고 BasketService에 반환 합니다.Then, the response is read as a string, converted from JSON to a CustomerBasket object, and returned to the BasketService. @No__t_0 메서드에 대 한 자세한 내용은 GET 요청 만들기를 참조 하세요.For more information about the CreateHttpClient method, see Making a GET Request.

@No__t_1 클래스의 PostAsync 메서드가 HttpClient.PostAsync를 호출 하는 경우, 다음 코드 예제에 표시 된 것과 같은 BasketController 클래스의 Post 메서드입니다. API 프로젝트를 호출 합니다.When the PostAsync method in the RequestProvider class calls HttpClient.PostAsync, the Post method in the BasketController class in the Basket.API project is invoked, which is shown in the following code example:

[HttpPost]  
public async Task<IActionResult> Post([FromBody]CustomerBasket value)  
{  
    var basket = await _repository.UpdateBasketAsync(value);  
    return Ok(basket);  
}

이 메서드는 RedisBasketRepository 클래스의 인스턴스를 사용 하 여 장바구니 데이터를 Redis cache에 보관 하 고, 성공 HTTP 상태 코드 및 JSON 형식의 CustomerBasket 인스턴스를 포함 하는 응답 메시지로 반환 합니다.This method uses an instance of the RedisBasketRepository class to persist the basket data to the Redis cache, and returns it as a response message that includes a success HTTP status code, and a JSON formatted CustomerBasket instance.

삭제 요청 만들기Making a DELETE Request

그림 10-3에서는 바구니 마이크로 서비스 바구니 데이터 CheckoutView를 삭제 하는 클래스의 상호 작용을 보여 줍니다.Figure 10-3 shows the interactions of classes that delete basket data from the basket microservice, for the CheckoutView.

그림 10-3: 바구니 마이크로 서비스에서 데이터 삭제Figure 10-3: Deleting data from the basket microservice

체크 아웃 프로세스를 호출 하면 CheckoutViewModel 클래스의 CheckoutAsync 메서드가 호출 됩니다.When the checkout process is invoked, the CheckoutAsync method in the CheckoutViewModel class is called. 이 메서드는 다음 코드 예제에서 보여 주는 것 처럼 장바구니를 지우기 전에 새 주문을 만듭니다.This method creates a new order, before clearing the shopping basket, as demonstrated in the following code example:

private async Task CheckoutAsync()  
{  
    ...  
    await _basketService.ClearBasketAsync(_shippingAddress.Id.ToString(), authToken);  
    ...  
}

이 메서드는 Autofac에서 CheckoutViewModel에 삽입 된 BasketService 인스턴스의 ClearBasketAsync 메서드를 호출 합니다.This method calls the ClearBasketAsync method of the BasketService instance that was injected into the CheckoutViewModel by Autofac. 다음 메서드는 ClearBasketAsync 메서드를 보여 줍니다.The following method shows the ClearBasketAsync method:

public async Task ClearBasketAsync(string guidUser, string token)  
{  
    UriBuilder builder = new UriBuilder(GlobalSetting.Instance.BasketEndpoint);  
    builder.Path = guidUser;  
    string uri = builder.ToString();  
    await _requestProvider.DeleteAsync(uri, token);  
}

이 메서드는 요청을 보낼 리소스를 식별 하는 URI를 빌드하고 RequestProvider 클래스를 사용 하 여 리소스에 대 한 DELETE HTTP 메서드를 호출 합니다.This method builds the URI that identifies the resource that the request will be sent to, and uses the RequestProvider class to invoke the DELETE HTTP method on the resource. 인증 프로세스 중에 IdentityServer에서 얻은 액세스 토큰은 바구니 마이크로 서비스 요청에 권한을 부여 하는 데 필요 합니다.Note that an access token, obtained from IdentityServer during the authentication process, is required to authorize requests to the basket microservice. 권한 부여에 대 한 자세한 내용은 권한 부여를 참조 하세요.For more information about authorization, see Authorization.

다음 코드 예제에서는 RequestProvider 클래스의 DeleteAsync 메서드를 보여 줍니다.The following code example shows the DeleteAsync method in the RequestProvider class:

public async Task DeleteAsync(string uri, string token = "")  
{  
    HttpClient httpClient = CreateHttpClient(token);  
    await httpClient.DeleteAsync(uri);  
}

이 메서드는 CreateHttpClient 메서드를 호출 합니다 .이 메서드는 적절 한 헤더 집합을 사용 하 여 HttpClient 클래스의 인스턴스를 반환 합니다.This method calls the CreateHttpClient method, which returns an instance of the HttpClient class with the appropriate headers set. 그런 다음 URI로 식별 되는 리소스에 비동기 삭제 요청을 제출 합니다.It then submits an asynchronous DELETE request to the resource identified by the URI. @No__t_0 메서드에 대 한 자세한 내용은 GET 요청 만들기를 참조 하세요.For more information about the CreateHttpClient method, see Making a GET Request.

@No__t_1 클래스의 DeleteAsync 메서드가 HttpClient.DeleteAsync를 호출 하는 경우, 다음 코드 예제에 표시 된 것과 같은 BasketController 클래스의 Delete 메서드입니다. API 프로젝트를 호출 합니다.When the DeleteAsync method in the RequestProvider class calls HttpClient.DeleteAsync, the Delete method in the BasketController class in the Basket.API project is invoked, which is shown in the following code example:

[HttpDelete("{id}")]  
public void Delete(string id)  
{  
    _repository.DeleteBasketAsync(id);  
}

이 메서드는 RedisBasketRepository 클래스의 인스턴스를 사용 하 여 Redis cache에서 바구니 데이터를 삭제 합니다.This method uses an instance of the RedisBasketRepository class to delete the basket data from the Redis cache.

데이터 캐싱Caching Data

자주 액세스 하는 데이터를 앱에 가까이 있는 빠른 저장소에 캐싱하여 앱 성능을 향상 시킬 수 있습니다.The performance of an app can be improved by caching frequently accessed data to fast storage that's located close to the app. 빠른 저장소가 원래 원본 보다 더 가까운 앱에 있는 경우 캐싱은 데이터를 검색할 때 응답 시간을 크게 향상 시킬 수 있습니다.If the fast storage is located closer to the app than the original source, then caching can significantly improve response times when retrieving data.

가장 일반적인 형태의 캐싱은 캐시를 참조 하 여 앱에서 데이터를 검색 하는 읽기-캐싱입니다.The most common form of caching is read-through caching, where an app retrieves data by referencing the cache. 데이터가 캐시에 없으면 데이터 저장소에서 검색 되어 캐시에 추가 됩니다.If the data isn't in the cache, it's retrieved from the data store and added to the cache. 앱은 캐시 배제 패턴을 사용 하 여 읽기-읽기 캐싱을 구현할 수 있습니다.Apps can implement read-through caching with the cache-aside pattern. 이 패턴은 항목이 현재 캐시에 있는지 여부를 확인 합니다.This pattern determines whether the item is currently in the cache. 항목이 캐시에 없으면 데이터 저장소에서 읽어서 캐시에 추가 됩니다.If the item isn't in the cache, it's read from the data store and added to the cache. 자세한 내용은 캐시 배제 패턴을 참조 하세요.For more information, see the Cache-Aside pattern.

자주 읽고 자주 변경 되지 않는 데이터를 캐시 합니다.Cache data that's read frequently and that changes infrequently. 이 데이터는 앱에서 처음 검색할 때 필요할 때 캐시에 추가할 수 있습니다.This data can be added to the cache on demand the first time it is retrieved by an app. 즉, 응용 프로그램은 데이터 저장소에서 한 번만 데이터를 인출 해야 하며, 그 후에는 캐시를 사용 하 여 후속 액세스를 만족할 수 있습니다.This means that the app needs to fetch the data only once from the data store, and that subsequent access can be satisfied by using the cache.

EShopOnContainers reference 응용 프로그램과 같은 분산 응용 프로그램은 다음 캐시 중 하나 또는 둘 모두를 제공 해야 합니다.Distributed applications, such as the eShopOnContainers reference application, should provide either or both of the following caches:

  • 여러 프로세스 또는 컴퓨터에서 액세스할 수 있는 공유 캐시.A shared cache, which can be accessed by multiple processes or machines.
  • 응용 프로그램을 실행 하는 장치에 로컬로 데이터가 저장 되는 개인 캐시.A private cache, where data is held locally on the device running the app.

EShopOnContainers 모바일 앱은 앱의 인스턴스를 실행 하는 장치에 로컬로 데이터가 보관 되는 개인 캐시를 사용 합니다.The eShopOnContainers mobile app uses a private cache, where data is held locally on the device that's running an instance of the app. EShopOnContainers reference 응용 프로그램에서 사용 하는 캐시에 대 한 자세한 내용은 .Net 마이크로 서비스: 컨테이너 화 된 .Net 응용 프로그램 아키텍처를 참조 하세요.For information about the cache used by the eShopOnContainers reference application, see .NET Microservices: Architecture for Containerized .NET Applications.

캐시는 언제 든 지 사라질 수 있는 임시 데이터 저장소로 생각할 수 있습니다.Think of the cache as a transient data store that could disappear at any time. 데이터가 원래 데이터 저장소 뿐만 아니라 캐시에 유지 되는지 확인 합니다.Ensure that data is maintained in the original data store as well as the cache. 캐시를 사용할 수 없게 되 면 데이터가 손실 될 가능성이 최소화 됩니다.The chances of losing data are then minimized if the cache becomes unavailable.

데이터 만료 관리Managing Data Expiration

캐시 된 데이터가 항상 원래 데이터와 일치 하는 것은 바람직하지 않습니다.It's impractical to expect that cached data will always be consistent with the original data. 원래 데이터 저장소의 데이터는 캐시 된 후 변경 되어 캐시 된 데이터가 부실 해질 수 있습니다.Data in the original data store might change after it's been cached, causing the cached data to become stale. 따라서 앱은 캐시의 데이터가 최대한 최신 상태 인지 확인 하는 데 도움이 되는 전략을 구현 해야 하지만 캐시의 데이터가 오래 된 경우 발생 하는 상황을 감지 하 고 처리할 수도 있습니다.Therefore, apps should implement a strategy that helps to ensure that the data in the cache is as up-to-date as possible, but can also detect and handle situations that arise when the data in the cache has become stale. 대부분의 캐싱 메커니즘을 사용 하면 데이터를 만료 하도록 캐시를 구성할 수 있으므로 데이터를 최신으로 유지 하는 기간을 줄일 수 있습니다.Most caching mechanisms enable the cache to be configured to expire data, and hence reduce the period for which data might be out of date.

캐시를 구성할 때 기본 만료 시간을 설정 합니다.Set a default expiration time when configuring a cache. 많은 캐시가 만료를 구현 하며,이는 데이터를 무효화 하 고 지정 된 기간 동안 액세스 하지 않은 경우 캐시에서 제거 합니다.Many caches implement expiration, which invalidates data and removes it from the cache if it's not accessed for a specified period. 그러나 만료 기간을 선택할 때는 주의 해야 합니다.However, care must be taken when choosing the expiration period. 너무 짧으면 데이터가 너무 빨리 만료 되 고 캐싱의 이점이 줄어듭니다.If it's made too short, data will expire too quickly and the benefits of caching will be reduced. 너무 오래 된 경우 데이터 위험이 부실 합니다.If it's made too long, the data risks becoming stale. 따라서 만료 시간은 데이터를 사용 하는 앱에 대 한 액세스 패턴과 일치 해야 합니다.Therefore, the expiration time should match the pattern of access for apps that use the data.

캐시 된 데이터가 만료 되 면 캐시에서 제거 해야 하며, 앱은 원래 데이터 저장소에서 데이터를 검색 하 여 캐시에 다시 저장 해야 합니다.When cached data expires, it should be removed from the cache, and the app must retrieve the data from the original data store and place it back into the cache.

데이터가 너무 오래 지속 될 수 있는 경우 캐시가 채워질 수 있습니다.It's also possible that a cache might fill up if data is allowed to remain for too long a period. 따라서 제거 라고 하는 프로세스에서 일부 항목을 제거 하려면 캐시에 새 항목을 추가 하는 요청이 필요할 수 있습니다.Therefore, requests to add new items to the cache might be required to remove some items in a process known as eviction. 캐싱 서비스는 일반적으로 가장 최근에 사용 된 방식으로 데이터를 제거 합니다.Caching services typically evict data on a least-recently-used basis. 그러나 가장 최근에 사용한 것을 비롯 한 다른 제거 정책 및 선입 first (선입 out)가 있습니다. 자세한 내용은 캐싱 지침을 참조 하세요.However, there are other eviction policies, including most-recently-used, and first-in-first-out. For more information, see Caching Guidance.

이미지 캐싱Caching Images

EShopOnContainers 모바일 앱은 캐시를 활용 하는 원격 제품 이미지를 사용 합니다.The eShopOnContainers mobile app consumes remote product images that benefit from being cached. 이러한 이미지는 Image 컨트롤과 FFImageLoading 라이브러리에서 제공 하는 CachedImage 컨트롤에 의해 표시 됩니다.These images are displayed by the Image control, and the CachedImage control provided by the FFImageLoading library.

Xamarin.ios Image 컨트롤은 다운로드 한 이미지의 캐싱을 지원 합니다.The Xamarin.Forms Image control supports caching of downloaded images. 캐싱은 기본적으로 사용 하도록 설정 되며 24 시간 동안 로컬로 이미지를 저장 합니다.Caching is enabled by default, and will store the image locally for 24 hours. 또한 CacheValidity 속성을 사용 하 여 만료 시간을 구성할 수 있습니다.In addition, the expiration time can be configured with the CacheValidity property. 자세한 내용은 다운로드 한 이미지 캐싱을 참조 하세요.For more information, see Downloaded Image Caching.

FFImageLoading의 CachedImage 컨트롤은 Xamarin.ios Image 컨트롤을 대체 하 여 보충 기능을 사용할 수 있는 추가 속성을 제공 합니다.FFImageLoading's CachedImage control is a replacement for the Xamarin.Forms Image control, providing additional properties that enable supplementary functionality. 이 기능 중에서 컨트롤은 오류를 지원 하 고 이미지 자리 표시자를 로드 하는 동안 구성 가능한 캐싱을 제공 합니다.Amongst this functionality, the control provides configurable caching, while supporting error and loading image placeholders. 다음 코드 예제에서는 eShopOnContainers 모바일 앱이 ProductTemplateCachedImage 컨트롤을 사용 하는 방법을 보여 줍니다 .이 컨트롤은 CatalogViewListView 컨트롤에서 사용 하는 데이터 템플릿입니다.The following code example shows how the eShopOnContainers mobile app uses the CachedImage control in the ProductTemplate, which is the data template used by the ListView control in the CatalogView:

<ffimageloading:CachedImage
    Grid.Row="0"
    Source="{Binding PictureUri}"     
    Aspect="AspectFill">
    <ffimageloading:CachedImage.LoadingPlaceholder>
        <OnPlatform x:TypeArguments="ImageSource">
            <On Platform="iOS, Android" Value="default_campaign" />
            <On Platform="UWP" Value="Assets/default_campaign.png" />
        </OnPlatform>
    </ffimageloading:CachedImage.LoadingPlaceholder>
    <ffimageloading:CachedImage.ErrorPlaceholder>
        <OnPlatform x:TypeArguments="ImageSource">
            <On Platform="iOS, Android" Value="noimage" />
            <On Platform="UWP" Value="Assets/noimage.png" />
        </OnPlatform>
    </ffimageloading:CachedImage.ErrorPlaceholder>
</ffimageloading:CachedImage>

@No__t_0 컨트롤은 LoadingPlaceholderErrorPlaceholder 속성을 플랫폼별 이미지로 설정 합니다.The CachedImage control sets the LoadingPlaceholder and ErrorPlaceholder properties to platform-specific images. @No__t_0 속성은 Source 속성으로 지정 된 이미지를 검색 하는 동안 표시할 이미지를 지정 하 고 ErrorPlaceholder 속성은에 지정 된 이미지를 검색 하려고 할 때 오류가 발생 하는 경우 표시할 이미지를 지정 Source 속성.The LoadingPlaceholder property specifies the image to be displayed while the image specified by the Source property is retrieved, and the ErrorPlaceholder property specifies the image to be displayed if an error occurs when attempting to retrieve the image specified by the Source property.

이름에서 알 때 CachedImage 컨트롤은 CacheDuration 속성 값에 지정 된 시간 동안 장치의 원격 이미지를 캐시 합니다.As the name implies, the CachedImage control caches remote images on the device for the time specified by the value of the CacheDuration property. 이 속성 값을 명시적으로 설정 하지 않으면 30 일의 기본값이 적용 됩니다.When this property value isn't explicitly set, the default value of 30 days is applied.

복원 력 증대Increasing Resilience

원격 서비스 및 리소스와 통신 하는 모든 앱은 일시적인 오류에 중요 해야 합니다.All apps that communicate with remote services and resources must be sensitive to transient faults. 일시적인 오류에는 서비스에 대 한 네트워크 연결이 일시적으로 손실 되거나, 서비스를 일시적으로 사용할 수 없거나, 서비스가 사용 중일 때 발생 하는 시간 초과가 포함 됩니다.Transient faults include the momentary loss of network connectivity to services, the temporary unavailability of a service, or timeouts that arise when a service is busy. 이러한 오류는 자동으로 수정 되는 경우가 많으며, 적절 한 지연 후 작업이 반복 되 면 성공할 가능성이 높습니다.These faults are often self-correcting, and if the action is repeated after a suitable delay it's likely to succeed.

일시적인 오류는 모든 예측 가능한 상황에서 철저 하 게 테스트 된 경우에도 앱의 인식 품질에 큰 영향을 줄 수 있습니다.Transient faults can have a huge impact on the perceived quality of an app, even if it has been thoroughly tested under all foreseeable circumstances. 원격 서비스와 통신 하는 앱이 안정적으로 작동 하도록 하려면 다음을 모두 수행할 수 있어야 합니다.To ensure that an app that communicates with remote services operates reliably, it must be able to do all of the following:

  • 오류가 발생 하는 경우 오류를 검색 하 고 오류가 일시적이 될 가능성이 있는지 확인 합니다.Detect faults when they occur, and determine if the faults are likely to be transient.
  • 오류가 일시적인 것일 가능성이 있는 것으로 확인 되 면 작업을 다시 시도 하 고 작업을 다시 시도한 횟수를 추적 합니다.Retry the operation if it determines that the fault is likely to be transient and keep track of the number of times the operation was retried.
  • 재시도 횟수, 각 시도 사이의 지연 시간 및 시도 실패 후 수행할 작업을 지정 하는 적절 한 재시도 전략을 사용 합니다.Use an appropriate retry strategy, which specifies the number of retries, the delay between each attempt, and the actions to take after a failed attempt.

이 일시적인 오류 처리는 재시도 패턴을 구현 하는 코드에서 원격 서비스에 액세스 하려는 모든 시도를 래핑하여 구현할 수 있습니다.This transient fault handling can be achieved by wrapping all attempts to access a remote service in code that implements the retry pattern.

재시도 패턴Retry Pattern

응용 프로그램이 원격 서비스에 요청을 보내려고 할 때 오류를 검색 하는 경우 다음과 같은 방법으로 오류를 처리할 수 있습니다.If an app detects a failure when it tries to send a request to a remote service, it can handle the failure in any of the following ways:

  • 작업을 다시 시도 하 고 있습니다.Retrying the operation. 앱에서 실패 한 요청을 즉시 다시 시도할 수 있습니다.The app could retry the failing request immediately.
  • 지연 후 작업을 다시 시도 하는 중입니다.Retrying the operation after a delay. 앱은 요청을 다시 시도 하기 전에 적절 한 시간 동안 대기 해야 합니다.The app should wait for a suitable amount of time before retrying the request.
  • 작업을 취소 하 고 있습니다.Cancelling the operation. 응용 프로그램에서 작업을 취소 하 고 예외를 보고 해야 합니다.The application should cancel the operation and report an exception.

앱의 비즈니스 요구 사항에 맞게 다시 시도 전략을 조정 해야 합니다.The retry strategy should be tuned to match the business requirements of the app. 예를 들어 재시도 횟수 및 다시 시도 간격을 시도 중인 작업으로 최적화 하는 것이 중요 합니다.For example, it's important to optimize the retry count and retry interval to the operation being attempted. 작업이 사용자 상호 작용의 일부인 경우 재시도 간격은 짧고, 사용자가 응답을 기다릴 수 없도록 하기 위해 몇 번의 재시도만 시도 해야 합니다.If the operation is part of a user interaction, the retry interval should be short and only a few retries attempted to avoid making users wait for a response. 작업이 장기 실행 워크플로의 일부인 경우 워크플로를 취소 하거나 다시 시작 하는 데 비용이 많이 들고 시간이 오래 걸리는 경우에는 시도 사이에 대기 하 고 더 많은 시간을 다시 시도 하는 것이 적절 합니다.If the operation is part of a long running workflow, where cancelling or restarting the workflow is expensive or time-consuming, it's appropriate to wait longer between attempts and to retry more times.

참고

시도 간 지연 시간을 최소화 하 고 재시도 횟수를 최소화 하는 적극적인 재시도 전략은 거의 또는 대량으로 실행 되는 원격 서비스의 성능을 저하 시킬 수 있습니다.An aggressive retry strategy with minimal delay between attempts, and a large number of retries, could degrade a remote service that's running close to or at capacity. 또한 이러한 다시 시도 전략은 계속 해 서 실패 한 작업을 수행 하려고 하는 경우 앱의 응답성에 영향을 줄 수 있습니다.In addition, such a retry strategy could also affect the responsiveness of the app if it's continually trying to perform a failing operation.

한 번의 재시도 후에도 요청이 계속 실패 하는 경우 앱에서 더 많은 요청을 동일한 리소스로 이동 하 여 오류를 보고 하는 것이 더 좋습니다.If a request still fails after a number of retries, it's better for the app to prevent further requests going to the same resource and to report a failure. 그런 다음 설정 된 기간이 지나면 응용 프로그램은 리소스에 대해 하나 이상의 요청을 만들어 성공 했는지 확인할 수 있습니다.Then, after a set period, the app can make one or more requests to the resource to see if they're successful. 자세한 내용은 회로 차단기 패턴을 참조 하세요.For more information, see Circuit Breaker Pattern.

무한 재시도 메커니즘을 구현 하지 마십시오.Never implement an endless retry mechanism. 유한 횟수의 재시도를 사용 하거나 회로 차단기 패턴을 구현 하 여 서비스를 복구할 수 있도록 합니다.Use a finite number of retries, or implement the Circuit Breaker pattern to allow a service to recover.

EShopOnContainers 모바일 앱은 RESTful 웹 요청을 만들 때 현재 재시도 패턴을 구현 하지 않습니다.The eShopOnContainers mobile app does not currently implement the retry pattern when making RESTful web requests. 그러나 FFImageLoading 라이브러리에서 제공하는 컨트롤 CachedImage은 이미지 로드를 다시 시도하여 일시적인 오류 처리를 지원합니다.However, the CachedImage control, provided by the FFImageLoading library supports transient fault handling by retrying image loading. 이미지 로드에 실패 하는 경우 추가 시도가 수행 됩니다.If image loading fails, further attempts will be made. 시도 횟수는 RetryCount 속성으로 지정 되며, RetryDelay 속성에 의해 지정 된 지연 이후에 다시 시도 됩니다.The number of attempts is specified by the RetryCount property, and retries will occur after a delay specified by the RetryDelay property. 이러한 속성 값이 명시적으로 설정 되지 않은 경우에는 RetryCount 속성에 대해 3이 적용 되 고 RetryDelay 속성의 경우 250ms이 적용 됩니다.If these property values aren't explicitly set, their default values are applied – 3 for the RetryCount property, and 250ms for the RetryDelay property. @No__t_0 컨트롤에 대 한 자세한 내용은 이미지 캐싱을 참조 하세요.For more information about the CachedImage control, see Caching Images.

EShopOnContainers reference 응용 프로그램은 재시도 패턴을 구현 합니다.The eShopOnContainers reference application does implement the retry pattern. 재시도 패턴을 HttpClient 클래스와 결합 하는 방법에 대 한 자세한 내용은 .Net 마이크로 서비스: 컨테이너 화 된 .Net 응용 프로그램 아키텍처를 참조 하세요.For more information, including a discussion of how to combine the retry pattern with the HttpClient class, see .NET Microservices: Architecture for Containerized .NET Applications.

다시 시도 패턴에 대 한 자세한 내용은 재시도 패턴을 참조 하세요.For more information about the retry pattern, see the Retry pattern.

회로 차단기 패턴Circuit Breaker Pattern

경우에 따라 수정 하는 데 시간이 오래 걸리는 예상 이벤트로 인해 오류가 발생할 수 있습니다.In some situations, faults can occur due to anticipated events that take longer to fix. 이러한 오류는 전체 서비스 오류에 대 한 일부 연결 손실과의 범위를 지정할 수 있습니다.These faults can range from a partial loss of connectivity to the complete failure of a service. 이러한 상황에서는 응용 프로그램에서 성공할 가능성이 없는 작업을 다시 시도 하는 것은 무의미 하지 않으며, 대신 작업이 실패 한 것을 허용 하 고 그에 따라이 오류를 처리 해야 합니다.In these situations, it's pointless for an app to retry an operation that's unlikely to succeed, and instead should accept that the operation has failed and handle this failure accordingly.

회로 차단기 패턴은 응용 프로그램이 실패할 가능성이 있는 작업을 반복적으로 실행 하는 것을 방지할 수 있으며, 앱에서 오류가 해결 되었는지 여부도 검색할 수 있도록 합니다.The circuit breaker pattern can prevent an app from repeatedly trying to execute an operation that's likely to fail, while also enabling the app to detect whether the fault has been resolved.

참고

회로 차단기 패턴의 목적은 재시도 패턴과 다릅니다.The purpose of the circuit breaker pattern is different from the retry pattern. 재시도 패턴을 사용 하면 응용 프로그램이 성공 하다 고 가정 하에 작업을 다시 시도할 수 있습니다.The retry pattern enables an app to retry an operation in the expectation that it'll succeed. 회로 차단기 패턴은 응용 프로그램이 실패할 가능성이 있는 작업을 수행할 수 없도록 합니다.The circuit breaker pattern prevents an app from performing an operation that's likely to fail.

회로 차단기는 실패할 수 있는 작업에 대 한 프록시로 작동 합니다.A circuit breaker acts as a proxy for operations that might fail. 프록시는 발생 한 최근 오류 수를 모니터링 하 고,이 정보를 사용 하 여 작업을 계속 진행할 수 있는지 여부를 결정 하거나, 예외를 즉시 반환할 것인지 여부를 결정 합니다.The proxy should monitor the number of recent failures that have occurred, and use this information to decide whether to allow the operation to proceed, or to return an exception immediately.

EShopOnContainers 모바일 앱은 현재 회로 차단기 패턴을 구현 하지 않습니다.The eShopOnContainers mobile app does not currently implement the circuit breaker pattern. 그러나 eShopOnContainers는 그렇지 않습니다.However, the eShopOnContainers does. 자세한 내용은 .Net 마이크로 서비스: 컨테이너 화 된 .Net 응용 프로그램 아키텍처를 참조 하세요.For more information, see .NET Microservices: Architecture for Containerized .NET Applications.

재시도 및 회로 차단기 패턴을 결합 합니다.Combine the retry and circuit breaker patterns. 앱은 재시도 패턴을 사용 하 여 회로 차단기를 통해 작업을 호출 하 여 재시도 및 회로 차단기 패턴을 결합할 수 있습니다.An app can combine the retry and circuit breaker patterns by using the retry pattern to invoke an operation through a circuit breaker. 그러나 다시 시도 논리는 회로 차단기에서 반환 된 모든 예외에 대 한 중요 한 것 이며 회로 차단기가 일시적인 오류가 아님을 나타내는 경우 다시 시도를 중단 합니다.However, the retry logic should be sensitive to any exceptions returned by the circuit breaker and abandon retry attempts if the circuit breaker indicates that a fault is not transient.

회로 차단기 패턴에 대 한 자세한 내용은 회로 차단기 패턴을 참조 하세요.For more information about the circuit breaker pattern, see the Circuit Breaker pattern.

요약Summary

많은 최신 웹 기반 솔루션은 웹 서버에서 호스트 되는 웹 서비스를 사용 하 여 원격 클라이언트 응용 프로그램에 대 한 기능을 제공 합니다.Many modern web-based solutions make use of web services, hosted by web servers, to provide functionality for remote client applications. 웹 서비스에서 노출 하는 작업은 web API를 구성 하 고, 클라이언트 앱은 API에서 노출 하는 데이터 또는 작업이 구현 되는 방식을 몰라도 웹 API를 활용할 수 있어야 합니다.The operations that a web service exposes constitute a web API, and client apps should be able to utilize the web API without knowing how the data or operations that the API exposes are implemented.

자주 액세스 하는 데이터를 앱에 가까이 있는 빠른 저장소에 캐싱하여 앱 성능을 향상 시킬 수 있습니다.The performance of an app can be improved by caching frequently accessed data to fast storage that's located close to the app. 앱은 캐시 배제 패턴을 사용 하 여 읽기-읽기 캐싱을 구현할 수 있습니다.Apps can implement read-through caching with the cache-aside pattern. 이 패턴은 항목이 현재 캐시에 있는지 여부를 확인 합니다.This pattern determines whether the item is currently in the cache. 항목이 캐시에 없으면 데이터 저장소에서 읽어서 캐시에 추가 됩니다.If the item isn't in the cache, it's read from the data store and added to the cache.

웹 Api와 통신할 때 앱은 일시적인 오류를 인식 해야 합니다.When communicating with web APIs, apps must be sensitive to transient faults. 일시적인 오류에는 서비스에 대 한 네트워크 연결이 일시적으로 손실 되거나, 서비스를 일시적으로 사용할 수 없거나, 서비스가 사용 중일 때 발생 하는 시간 초과가 포함 됩니다.Transient faults include the momentary loss of network connectivity to services, the temporary unavailability of a service, or timeouts that arise when a service is busy. 이러한 오류는 자동으로 수정 되는 경우가 많으며, 적절 한 지연 후에 작업이 반복 되 면 성공할 가능성이 높습니다.These faults are often self-correcting, and if the action is repeated after a suitable delay, then it's likely to succeed. 따라서 응용 프로그램은 일시적인 오류 처리 메커니즘을 구현 하는 코드에서 web API에 액세스 하려는 모든 시도를 래핑합니다.Therefore, apps should wrap all attempts to access a web API in code that implements a transient fault handling mechanism.