Ruby on Rails(Pub/Sub 포함)에 대해 자세히 알아보기

Ruby on Rails (Rails, RoR)은 잘 알려진 웹 애플리케이션 프레임워크입니다. Ruby 프로그래밍 언어입니다. Pub/Sub 라는 소프트웨어 디자인 패턴의 줄임말입니다. 게시-구독. Rails의 소프트웨어 컴포넌트 간의 통신을 Pub/Sub에서 어떻게 처리할 수 있는지 설명하겠습니다.

Pub/sub란 무엇인가요?

Pub/sub 는 서비스 간 통신을 제공하는 소프트웨어 디자인 패턴입니다. 서비스
는 게시자(생산자) 또는 수신자(소비자)의 두 가지 역할 중 하나를 수반합니다. 무엇
생성되어 소비되는 것은 이벤트나 메시지 또는 알림으로 결정됩니다. 이벤트의
이 글의 맥락에서는 같은 것을 지칭할 때 같은 의미로 사용됩니다.
생산하는 서비스는 누가 소비하는지 알 수 없습니다. 소비하는 서비스는
메시지의 출처를 알 수 있습니다. 서로에게 알려지지 않은 상태로 남아있을 수 있습니다. 다음과 다릅니다.
메시지 대기열에서 메시지를 보내는 컴포넌트가 종종 목적지를 알고 있습니다.
- 이 메시징 스타일을 사용하면 어디서나 메시지를 보낼 수 있습니다. 이 메커니즘은 핵심입니다.
의 Pub/sub 분리되어 있다는 의미입니다.

서로의 관심사를 표현하려면 공통의 이해를 공유해야 합니다. 따라서
두 가지 역할 모두 메시지 생산자와
메시지의 소비자를 만납니다. 이 메커니즘을 제목, 구독 또는 주제라고 합니다. 이는
주제에 대한 메시지 분류를 담당하며, 본질적으로 상태 비저장 메시지 필터입니다.
토픽은 방송국 역할을 합니다. 퍼블리셔는 토픽에 대한 메시지를 생성합니다,
구독자는 토픽의 메시지를 즉시 수신합니다. 디커플링으로 인해
서비스에서 메시지를 교환하는 가장 효율적인 방법은 비동기적으로 처리하는 것입니다.

Pub/Sub 없는 레일

기본적으로 컴포넌트 간에 메시지를 전달하기 위한 소프트웨어 디자인 패턴에 대한 Rails 오버헤드는 없습니다. 개발자는 표준 객체 지향 프로그래밍 (OOP) 패러다임: 함수에 매개변수를 전달하고 값에 대한 클래스를 요청합니다.

애플리케이션이 다소 복잡하지 않은 경우에는 이 정도면 충분할 수 있습니다. 예를 들어 애플리케이션이 성장하여 일부 작업을 비동기적으로 수행해야 하는 경우, 애플리케이션이 커지면 프로젝트 데이터 워크플로우를 해결하는 추상화가 필요합니다. 개발자는 바퀴를 재발명하는 대신 다음과 같이 구현할 수 있습니다. Pub/sub 를 사용하여 이러한 추상화의 부족함을 채울 수 있습니다.

레일이 있는 게시/서브의 장점

• 활성 레코드 콜백을 피하세요.
• 시스템에 비동기 병렬 처리를 추가하면 성능, 안정성 및 확장성이 향상됩니다.
• 메시지는 시스템의 다른 부분에 비동기적으로 브로드캐스트할 수 있습니다.
• 메시지를 시스템의 다른 부분으로 비동기적으로 브로드캐스트할 수 있습니다.
• 디커플링 - 기능을 추가하거나 변경해도 게시/서브는 아무런 영향을 미치지 않습니다.
  를 사용하면 모든 항목의 상호 작용 방식을 수정할 수 있습니다.
• 메시지 소비자는 더 이상 주기적으로 업데이트 또는 새
  정보를 제공합니다. 시스템에서 특히 문제가 될 수 있는 전송 지연 시간을 줄입니다.
  지연을 용납하지 않습니다.
• 시스템에서 처리할 수 있는 구독자 수에는 제한이 없으므로 변경할 수 있습니다,
  언제든지 업그레이드, 증식 또는 사라질 수 있습니다.

레일이 있는 게시/서브의 단점

• 퍼블리셔/서브 시스템의 가장 큰 단점은 퍼블리셔와 퍼블리셔가 분리되어 있다는 것입니다.
  구독자.

Rails Pub/Sub 소개

라이브러리를 사용하여 작성된 Rails의 소스 예시
게시/서브 온 레일즈 (루비의 명명법에서는 라이브러리를 gem이라고 합니다): 자세한 내용은 gem의 readme에서 확인할 수 있습니다. 구현은 모듈로 구성됩니다:

1. 도메인,
2. 이벤트,
3. 이벤트 핸들러,
4. 이벤트 게시자,
5. 구독.

도메인

게시/서브에 컨텍스트를 제공하기 위한 비즈니스 로직을 설명하여 깔끔하게 정리합니다. 코드.

 모듈 알림
   PubSub::도메인 확장
 end

 모듈 보고서
   PubSub::도메인 확장
 end

이벤트

어떤 일이 일어났는지 설명하는 클래스입니다. 클래스 이름은 취소, 변경, 생성, 삭제, 전송, 업데이트와 같이 가능한 한 어떤 일이 일어났는지를 설명하는 자체 설명으로 선언하세요. 이벤트 이름은 다음과 같을 수 있습니다: 손익 계산서가 생성되었음을 의미하는 ProfitAndLossStatementCreatedEvent.

 Reports::ProfitAndLossStatementCreatedEvent 클래스 < PubSub::DomainEvent
   속성 :profit_and_loss_statement_id, Types::Strict::Integer
 end

이벤트 게시자

이벤트를 방출할 수 있는 클래스입니다. 이 예는 서비스 보고서를 만드는 것을 보여줍니다. 보고서가 성공적으로 생성되면 해당 보고서 생성 이벤트를 발생시킵니다.

Reports::ProfitAndLossStatementService 클래스
   포함 PubSub::Emit
    def execute
     emit(:report_profit_and_손실명세서_created, profit_and_손실명세서_id: id) if result.ok?
   end
 end

이벤트 핸들러

이 클래스는 이벤트 처리에 대한 응답으로 실행되어야 합니다.

모듈 Notifications
 ReportsProfitAndLossStatementCreatedHandler 클래스 < PubSub::DomainEventHandler
   def call
     ReportMailer.profit_and_loss_statement(profit_and_loss_statement).deliver_now
   end

   private

   def profit_and_loss_statement
     profit_and_손실명세서.find(event_data.profit_and_손실명세서_id)
   end
 end
end

구독

이벤트는 구독을 통해 핸들러에 바인딩됩니다.

알림:
 보고서__profit_and_손실_명세서_생성: 비동기

사용 사례 예시:

• "소셜 네트워크의 '팔로우' 기능,
• 사물 인터넷,
• 메일링,
• 생성된 파일에 대한 알림.

유사한 패턴

1. 이벤트 버스 - 컴포넌트는 누가 이벤트를 수신할지, 얼마나 많은 응답자가 반응할지 모른 채 이벤트버스에 이벤트를 보낼 수 있습니다,
2. 옵저버 - 대상은 관찰자라고 하는 부양 가족의 목록을 관리하고 상태가 변경될 때마다 이들에게 알림을 보냅니다,
3. 풀링 - 폴링할 때 클라이언트는 주기적으로 시스템에 새로운 이벤트나 데이터가 있는지 묻습니다.

보석

• https://github.com/edisonywh/rocketman

• https://github.com/krisleech/wisper

• https://github.com/stevo/pubsubon레일

요약

Pub/sub는 루비 인 레일즈에서 일반적인 접근 방식은 아닙니다. 이 문서에서 소개한 것처럼 이 패턴은 코드를 깔끔하게 만들고, 서비스를 분리하며, 쉽게 확장할 수 있도록 하는 등 프로젝트에 많은 이점을 가져올 수 있습니다.