일반적인 프로그래밍 패러다임
일반적인 서비스
- 일반적인 서비스에서 구성 요소 or 객체는 다른 객체를 직접 호출하고 데이터를 받음.
- 이 과정에서 서로 직접 의존하기 때문에, 경계가 무너지고 구성 요소간 독립적인 실행이 보장되지 않음
- 복원력, 유연성 모두 위협
- 여기에 reactive manifesto를 적용한다면?
동기 stream
- callee는 caller에게 응답이 아닌 stream 제공
- callee는 각각의 값을 steam을 통해서 전달
- caller는 해당 stream을 collect하여 이를 처리
stream을 이용한 흐름
- 구성 요소는 서로 비동기적으로 메시지를 주고 받으며, 독립적인 실행을 보장하는가 ?
- caller는 collect를 통해 값을 조회하기 때문에, caller와 callee는 동기적 동작함.
- 메시지 큐를 생성하고 배압을 적용하여 부하를 관리하고 흐름 제어가 가능한가 ?
- stream이 메시지 큐의 역할을 하지만, 부하를 관리하지는 못함.
비동기 future
- callee는 caller에게 응답이 아닌 future를 제공
- callee는 각각의 값을 future를 통해서 전달
- caller는 해당 future를 chaining하여 이를 처리
stream을 이용한 흐름
- 구성 요소는 서로 비동기적으로 메시지를 주고 받으며, 독립적인 실행을 보장하는가 ?
- caller와 callee는 비동기적으로 동작
- 메시지 큐를 생성하고 배압을 적용하여 부하를 관리하고 흐름 제어가 가능한가 ?
- future는 메시지 큐의 역할을 할 수 없고, 부하 관리 X. 배압도 적용할 수 없다.
- 메시지 큐의 개념보다는 한번에 값을 전달하는 객체
Reactive Stream
- callee는 caller에게 응답이 아닌 publisher를 제공
- callee는 각각의 값을 publisher를 통해 전달
- caller는 해당 publisher를 subscribe하거나 다른 caller에게 전달
- caller는 subscriber를 등록하여 back-pressure를 조잘하여 처리 가능양만큼 전달 받음
stream을 이용한 흐름
- 구성 요소는 서로 비동기적으로 메시지를 주고 받으며, 독립적인 실행을 보장하는가 ?
- callee는 publisher를 반환하고, caller는 subscriber를 등록. 이 과정에서 caller와 calle는 비동기적 작동
- 메시지 큐를 생성하고 배압을 적용하여 부하를 관리하고 흐름 제어가 가능한가 ?
- publisher는 메시지 큐를 생성해서 부하를 관리하고 흐름을 제어. back-pressure를 조절할 수 있는 수단 제공. A가 B에게 처리 가능양을 알림으로써 조절 O
결론
- 비동기 데이터 stream을 사용하는 패러다임
- 모든 것이 이벤트로 구성되고, 이벤트를 통해서 전파되어야 함
- event-driven 해야하고
- 데이터의 전달, 에러, 완료까지 모두 이벤트로 취급
- Reactive manifesto의 Responsive, Resilient, Elastic, Message Driven까지 모두 해당
🤦🏻♂️