일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Spring Data Redis
- test
- netflix
- 탐색
- 단위테스트
- forkandjoinpool #threadpool #jvm #async #non-blocking
- spring cloud
- Eureka
- springcloud
- Java
- 서비스스펙
- Dynamic Routing
- java #jvm #reference #gc #strong reference
- BFS
- unittest
- dfs
- zuul
- netflix eureka
- spring cloud netflix
- unit
- docker
- reactive
- spring cloud netflix zuul
- code refactoring
- api-gateway
- spring cloud netflix eureka
- container image #docker #layer #filesystem #content addressable
- 설계
- microservice architecture
- Today
- Total
목록Programming/Reactive (7)
phantasmicmeans 기술 블로그
먼저 expectNext / assertNext / consumeNextWith (아래에서 설명할 thenConsumeWhile와 비교를 위해 간단히 추가 했습니다.) 가장 기본적인 연산자로는 expectNext / assertNext / consumeNextWith가 있습니다. 모두 결국 onNext signal을 기반으로 동작합니다만, 이 연산자들은 아이템이 emit 되지 않으면 에러를 발생시킵니다. 즉, empty publisher를 차단할 수 있습니다. (empty publisher 반환을 테스트하고 싶다면 아래와 같은 방법을 사용하거나 아래에서 설명할 thenConsumeWhile을 사용하면 됩니다.) @Test public void EMPTY_PUBLISHER_TEST() { Mono mono..
일반적인 flow는 Publisher -> Data -> Subscriber이다. 그러나 Publisher -> [Data1] -> Operator -> [Data2] -> Operator2 -> [Data3] -> Subscriber 처럼 Operator를 활용해 Subcriber에 도달하는 Data를 컨트롤 할 수 있다. 쉽게 말해 Operator는 Data를 가공한다. JAVA8의 Stream 관련 메소드와 비슷한 의미를 가진다고 보면 된다 아래 코드는 3가지 operator를 거쳐 logSubscriber에게 데이터가 전달되는 과정을 나타낸다. 기본 개념은 아래와 같다. 대리 Subscriber를 사용하여 subscriber를 연결한다. 초기 Publisher에서 정의한 Subscription을 ..
흐름 제어 푸시모델만 사용하는것으로는 기술적 한계가 있다. 메시지 기반 통신의 본질은 요청에 응답하는 것이다. Producer가 Subscriber의 처리 능력을 무시하면 시스템에 악영향을 끼칠 수 있기 때문에 매우 까다롭다. 느린 프로듀서와 빠른 컨슈머 컨슈머가 매우 빠르게 동작하는 상황에서 프로듀서가 느리게 동작한다고 가정하자. 이러한 상황은 컨슈머의 능력을 프로듀서가 믿지 못하기에 발생할 수 있다. 상황에 따라 컨슈머의 처리 능력이 동적으로 변할 수도 있다. 가장 쉽게는 프로듀서 수를 늘려서 컨슈머에게 부담을 증가시킬 수 있고 그렇지만.. 결론적으로 이러한 문제를 해결하기 위해 필요한 것은 실제적 요구이다. 순수 푸시모델은 이러한 메트릭을 제공할 수 없으므로 동적으로 시스템의 처리량을 증가시키는 것..
Publisher Rective Stream에서 정의하는 Publisher는 sequential한 element들을 제공하는 provider이고, Subscriber의 요구에 따라 publish 한다. 앞서 살펴보았던 Observable과 동등한 의미로 보면 된다. Observable은 registerObserver(Observer observer)로 subscriber를 등록했다면, Publisher는 subcribe(Subscriber
앞선 글에서 Observer pattern + Iterator 패턴(이벤트의 끝, 그리고 Error) == Reactive Stream이라고 정리했다. 이와 더불어 토비의 리액티브 스트림 첫 강의에서 나온 Iterable Observable (Duality) 에 대해 짚고 넘어가자 Duality Iterable Observable [Iterable] [Observable] [Pull] [Push] [값을 끌어온다는 의미] [값을 가져가라는 의미] [iterator.next()] [notifyObservers(arg)] Iterable, Observable Pull, Push 먼저 Iterable과 Observable의 Pull-Push 차이를 보자. Iterable을 구현한 클래스들은 for-each s..
Iterator 반복자 패턴 RxJava(ReactiveX)는 Observer pattern, Iterator pattern 및 함수형 프로그래밍의 조합으로 사용된다. Observer pattern은 무한한 데이터 스트림에 매력적이다. 그러나 데이터 스트림의 끝 을 알리는 기능이 없고, 에러 전파 메커니즘 또한 포함하고 있지 않다. 또한 consumer가 준비되기 전 producer가 이벤트를 생성하는 것은 그다지 좋은 상황도 아니다. 동기식의 경우 이런 때를 대비해서 Iterator 패턴이 존재한다. public interface Iterator { T next(); boolean hasNext(); } 위 Iterator interface는 하나씩 항목을 검사하기 위한 next() method와 다음..
관찰자 패턴은 관찰자라고 불리는 자손의 리스트를 가지고 있는 주체(Subject) 를 필요로한다. 주체는 일반적으로 자신의 메서드 중 하나(e.g. notify)를 호출해 관찰자에게 상태 변경을 알리게 된다. GoF 에서의 옵저버 패턴 설명 객체 사이에 일대 다의 의존 관계를 정의해두어, 어떤 객체의 상태가 변할 때 그 객체의 의존성을 가진 다른 객체들이 변화를 통지받고 자동으로 갱신될 수 있게 만든다. 이 패턴은 이벤트 처리 기반 시스템에 필수적 e.g. MVC 패턴, 거의 모든 UI 라이브러리가 내부적으로 이 패턴 사용 Subject - Observer 는 1:N 관계를 이룰 수 있음. Subject |- Observer |- Observer |- Observer |- Observer 일반적인 옵저버..