분산 응용 프로그램의 빌딩 블록. 첫 번째 접근법

과거에 기사 리액티브 아키텍처의 이론적 토대를 분석했습니다. 이제 데이터 흐름, 반응형 Erlang/Elixir 시스템을 구현하는 방법 및 그 안의 메시징 패턴에 대해 이야기할 시간입니다.

• 요청-응답
• 요청 청크 응답
• 요청에 대한 응답
• 게시-구독
• 반전 게시 구독
• 작업 분배

SOA, MSA 및 메시징

SOA, MSA는 시스템 구축 규칙을 정의하는 시스템 아키텍처이며 메시징은 구현을 위한 기본 요소를 제공합니다.

나는 이것 또는 저 시스템 아키텍처를 전파하고 싶지 않습니다. 나는 특정 프로젝트와 비즈니스에 가장 효과적이고 유용한 방법을 적용하는 것을 지지합니다. 우리가 어떤 패러다임을 선택하든 Unix 방식을 주시하면서 시스템 블록을 만드는 것이 더 좋습니다. 즉, 연결성이 최소이고 개별 엔터티를 담당하는 구성 요소입니다. API 메서드는 엔터티로 가장 간단한 작업을 수행합니다.

메시징 - 이름에서 알 수 있듯이 메시지 브로커입니다. 주요 목적은 메시지를 받고 보내는 것입니다. 정보 전송을 위한 인터페이스, 시스템 내에서 정보 전송을 위한 논리 채널 형성, 라우팅 및 밸런싱, 시스템 수준에서의 장애 처리를 담당합니다.
개발된 메시징은 rabbitmq와 경쟁하거나 대체하려고 시도하지 않습니다. 주요 기능:

• 분포.
  교환 지점은 이를 사용하는 코드에 최대한 가까운 클러스터의 모든 노드에서 생성할 수 있습니다.
• 단순성
  상용구 코드 최소화와 사용 편의성에 중점을 둡니다.
• 더 나은 성능.
  우리는 rabbitmq의 기능을 반복하려는 것이 아니라 가능한 한 간단하게 OTP에 맞는 아키텍처 및 전송 계층만 선택하여 비용을 최소화합니다.
• 적응성.
  각 서비스는 많은 교환 템플릿을 결합할 수 있습니다.
• 설계에 따른 탄력성.
• 확장성.
  메시징은 앱과 함께 성장합니다. 부하가 증가함에 따라 교환 지점을 별도의 기계로 이동할 수 있습니다.

비고 코드 구성 측면에서 메타 프로젝트는 복잡한 Erlang/Elixir 시스템에 적합합니다. 모든 프로젝트 코드는 하나의 저장소(우산 프로젝트)에 있습니다. 동시에 마이크로 서비스는 최대한 격리되어 별도의 엔터티를 담당하는 간단한 작업을 수행합니다. 이 접근 방식을 사용하면 전체 시스템의 API를 유지 관리하기 쉽고 변경하기 쉽고 단위 및 통합 테스트를 작성하는 것이 편리합니다.

시스템 구성 요소는 직접 또는 브로커를 통해 상호 작용합니다. 메시징의 입장에서 볼 때 각 서비스에는 다음과 같은 몇 가지 수명 단계가 있습니다.

• 서비스 초기화.
  이 단계에서 서비스 및 종속성을 실행하는 프로세스의 구성 및 실행이 이루어집니다.
• 교환 지점을 만듭니다.
  서비스는 호스트 구성에 지정된 정적 교환 지점을 사용하거나 동적으로 교환 지점을 생성할 수 있습니다.
• 서비스 등록.
  서비스가 요청을 처리하려면 교환 지점에 등록해야 합니다.
• 정상 작동.
  서비스는 유용한 작업을 수행합니다.
• 작업 완료.
  셧다운에는 정기 및 비상의 2가지 유형이 있습니다. 정기 서비스에서는 교환 지점에서 연결이 끊어지고 중지됩니다. 긴급 상황에서 메시징은 장애 조치 시나리오 중 하나를 실행합니다.

꽤 복잡해 보이지만 코드가 그렇게 무섭지는 않습니다. 주석이 있는 코드 예제는 나중에 템플릿 분석에서 제공됩니다.

교환

교환 지점은 메시징 템플릿 내의 구성 요소와의 상호 작용 논리를 구현하는 메시징 프로세스입니다. 아래의 모든 예에서 구성 요소는 메시징을 형성하는 조합인 교환 지점을 통해 상호 작용합니다.

메시지 교환 패턴(MEP)

전 세계적으로 교환 패턴은 양면과 일방으로 나눌 수 있습니다. 전자는 들어오는 메시지에 대한 응답을 의미하지만 후자는 그렇지 않습니다. 클라이언트-서버 아키텍처에서 양방향 패턴의 전형적인 예는 요청-응답 패턴입니다. 템플릿과 수정 사항을 고려하십시오.

요청-응답 또는 RPC

RPC는 다른 프로세스로부터 응답을 받아야 할 때 사용됩니다. 이 프로세스는 동일한 호스트 또는 다른 대륙에서 실행될 수 있습니다. 아래는 메시징을 통한 클라이언트와 서버 간의 상호 작용 다이어그램입니다.

메시징은 완전히 비동기식이므로 클라이언트에 대한 교환은 2단계로 나뉩니다.

1. 요청 보내기

   messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).

   교환 ‒ 고유한 교환 지점 이름
   ResponseMatchingTag ‒ 응답 처리를 위한 로컬 레이블. 예를 들어, 서로 다른 사용자의 동일한 요청을 여러 개 보내는 경우입니다.
   요청 정의 ‒ 요청 본문
   처리기 프로세스 ‒ 핸들러의 PID. 이 프로세스는 서버에서 응답을 받습니다.

2. 응답 처리

   handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)

   응답 페이로드 - 서버 응답.

서버의 경우 프로세스는 다음 2단계로 구성됩니다.

1. 환전소 초기화
2. 수신 요청 처리

이 템플릿을 코드로 설명하겠습니다. 단일 정확한 시간 메서드를 제공하는 간단한 서비스를 구현해야 한다고 가정해 보겠습니다.

서버 코드

서비스 API 정의를 api.hrl로 이동해 보겠습니다.

%% =====================================================
%%  entities
%% =====================================================
-record(time, {
  unixtime :: non_neg_integer(),
  datetime :: binary()
}).

-record(time_error, {
  code :: non_neg_integer(),
  error :: term()
}).

%% =====================================================
%%  methods
%% =====================================================
-record(time_req, {
  opts :: term()
}).
-record(time_resp, {
  result :: #time{} | #time_error{}
}).

time_controller.erl에서 서비스 컨트롤러 정의

%% В примере показан только значимый код. Вставив его в шаблон gen_server можно получить рабочий сервис.

%% инициализация gen_server
init(Args) ->
  %% подключение к точке обмена
  messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())
  {ok, #{}}.

%% обработка события потери связи с точкой обмена. Это же событие приходит, если точка обмена еще не запустилась.
handle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->
  erlang:send(self(), monitor_exchange),
  {noreply, State};

%% обработка API
handle_info(#time_req{opts = _Opts}, State) ->
  messaging:response_once(Client, #time_resp{
result = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())}
  });
  {noreply, State};

%% завершение работы gen_server
terminate(_Reason, _State) ->
  messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),
  ok.

클라이언트 코드

서비스에 요청을 보내려면 클라이언트의 어디에서나 메시징 요청 API를 호출할 수 있습니다.

case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of
    ok -> ok;
    _ -> %% repeat or fail logic
end

분산 시스템에서 구성 요소의 구성은 매우 다를 수 있으며 요청 시점에 메시징이 아직 시작되지 않았거나 서비스 컨트롤러가 요청을 처리할 준비가 되지 않았을 수 있습니다. 따라서 메시징 응답을 확인하고 실패 사례를 처리해야 합니다.
클라이언트에 성공적으로 전송한 후 서비스는 응답 또는 오류를 수신합니다.
handle_info에서 두 가지 경우를 모두 처리해 보겠습니다.

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) ->
  ?debugVal(Utime),
  {noreply, State};

handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) ->
  ?debugVal({error, ErrorCode}),
  {noreply, State};

요청 청크 응답

큰 메시지를 보내지 않는 것이 가장 좋습니다. 전체 시스템의 응답성과 안정적인 작동이 이에 달려 있습니다. 쿼리에 대한 응답이 많은 메모리를 차지하는 경우 분할이 필수입니다.

다음은 이러한 경우의 몇 가지 예입니다.

• 구성 요소는 파일과 같은 이진 데이터를 교환합니다. 답을 작은 부분으로 나누면 모든 크기의 파일에서 효율적으로 작업하고 메모리 오버플로를 포착하지 않는 데 도움이 됩니다.
• 목록. 예를 들어 데이터베이스의 거대한 테이블에서 모든 레코드를 선택하여 다른 구성 요소로 전달해야 합니다.

나는 그러한 반응을 기관차라고 부릅니다. 어쨌든 1024개의 1MB 메시지가 단일 1GB 메시지보다 낫습니다.

Erlang 클러스터에서는 응답이 교환 지점을 우회하여 수신자에게 즉시 전송되기 때문에 교환 지점과 네트워크의 부하를 줄이는 추가 이점을 얻습니다.

요청에 대한 응답

이것은 대화형 시스템 구축을 위한 RPC 패턴의 다소 드문 수정입니다.

발행-구독(데이터 분포 트리)

이벤트 기반 시스템은 데이터가 준비되는 즉시 소비자에게 데이터를 제공합니다. 따라서 시스템은 풀 또는 폴 모델보다 푸시 모델에 더 취약합니다. 이 기능을 사용하면 데이터를 지속적으로 요청하고 대기하여 리소스를 낭비하지 않아도 됩니다.
그림은 특정 주제를 구독하는 소비자에게 메시지를 배포하는 과정을 보여줍니다.

이 패턴을 사용하는 전형적인 예는 컴퓨터 게임의 게임 세계, 거래소의 시장 데이터, 데이터 피드의 유용한 정보와 같은 상태 분포입니다.

구독자 코드를 고려하십시오.

init(_Args) ->
  %% подписываемся на обменник, ключ = key
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {ok, #{}}.

handle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->
  %% если точка обмена недоступна, то пытаемся переподключиться
  messaging:subscribe(?SUBSCRIPTION, key, tag, self()),
  {noreply, State};

%% обрабатываем пришедшие сообщения
handle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->
  ?debugVal(Msg),
  {noreply, State};

%% при остановке потребителя - отключаемся от точки обмена
terminate(_Reason, _State) ->
  messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),
  ok.

소스는 편리한 위치에서 메시지 게시 기능을 호출할 수 있습니다.

messaging:publish_message(Exchange, Key, Message).

교환 - 교환 지점의 이름,
키 ‒ 라우팅 키
보내실 내용 - 페이로드

반전 게시 구독

pub-sub를 배포하면 로깅에 편리한 패턴을 얻을 수 있습니다. 소스와 소비자 세트는 완전히 다를 수 있습니다. 이 그림은 한 명의 소비자와 여러 소스가 있는 경우를 보여줍니다.

작업 분포 패턴

거의 모든 프로젝트에는 보고서 생성, 알림 전달 및 타사 시스템에서 데이터 수신과 같은 지연 처리 작업이 있습니다. 이러한 작업을 수행하는 시스템의 처리량은 프로세서를 추가하여 쉽게 확장할 수 있습니다. 우리에게 남은 것은 프로세서 클러스터를 형성하고 그들 사이에 작업을 고르게 분배하는 것입니다.

3개의 핸들러의 예를 사용하여 발생하는 상황을 고려하십시오. 작업 배분 단계에서도 배분의 공정성과 처리기의 과잉에 대한 문제가 발생합니다. 라운드 로빈 분배는 공정성을 책임질 것이며, 핸들러의 오버플로우 상황을 피하기 위해 제한을 도입할 것입니다. 프리페치_한계. 전환 모드에서 프리페치_한계 하나의 처리기가 모든 작업을 수신하도록 허용하지 않습니다.

메시징은 대기열과 처리 우선 순위를 관리합니다. 프로세서는 작업이 도착하면 수신합니다. 작업은 성공적으로 완료되거나 실패할 수 있습니다.

• messaging:ack(Tack) ‒ 메시지 처리 성공 시 호출
• messaging:nack(Tack) ‒ 모든 비상 상황에서 호출됩니다. 작업이 반환된 후 메시징은 작업을 다른 처리기로 전달합니다.

세 가지 작업을 처리하는 동안 복잡한 오류가 발생했다고 가정해 보겠습니다. 처리기 1이 작업을 받은 후 교환 지점에 아무 것도 보고할 시간도 없이 충돌했습니다. 이 경우 교환 지점은 ack 시간 제한이 만료된 후 작업을 다른 처리기로 전송합니다. 처리기 3은 어떤 이유로 작업을 포기하고 nack을 보냈고, 결과적으로 작업은 성공적으로 완료한 다른 처리기로 전달되었습니다.

예비 요약

우리는 분산 시스템의 기본 빌딩 블록을 분해하고 Erlang/Elixir에서의 사용에 대한 기본적인 이해를 얻었습니다.

기본 템플릿을 결합하여 복잡한 패러다임을 구축하여 새로운 문제를 해결할 수 있습니다.

주기의 마지막 부분에서는 서비스 구성, 라우팅 및 밸런싱의 일반적인 문제를 고려하고 시스템의 확장성 및 내결함성의 실용적인 측면에 대해서도 이야기합니다.

두 번째 부분의 끝.

Фото 마리우스 크리스텐슨
삽화 제공: websequencediagrams.com

출처 : habr.com