- Database per Service Design Pattern

Mongo DB는 4버전 부터 Transaction 을 지원한다.
하지만 RDB의 transaction 메커니즘과 달리 replica set 을 활용해 구성한다.

• MongoDB의 이전 버전에서는 Transaction을 지원하지 않으므로, 명시적으로 MongoTransactionManager Bean을 생성해주어야한다.
  

Mongo Transaction 지원 관련 문서

https://www.mongodb.com/docs/manual/core/transactions/#transactions-and-atomicity

https://spring.io/blog/2018/06/28/hands-on-mongodb-4-0-transactions-with-spring-data

Mono 를 공부하다보면
Mono.fromSupplier() / Mono.fromCallable() 이렇게 두가지 static method 를 발견할 수 있다.

둘 다 Functional Interface 로, body 의 구성도 같다.
Supplier -> V get();
Callable -> V call();

둘의 차이는 무엇일까?

• 가장 큰 차이는 사용하는 환경의 차이 (different usage) 이고, 다음은 예외 반환여부이다.
  Callable 은 Runnable 과 같이 thread 의 병렬 프로그래밍에서 등장하며,
  Runnable 의 () -> () 과 달리, () -> V 로써, 다른 쓰레드로의 반환값을 기대한다.
  즉, Future 와 관련된 값들을 리턴하는 처리에서 활용되어진다.
  또한, Callable 은 예외를 반환하기도 한다.
  이렇게 하면 기타 쓰레드 에서 발생한 예외를 현 쓰레드로 넘겨 별도의 예외 처리가 가능하며,
  Supplier 는 예외를 던지지 못하여 단순한 () -> V 로직을 처리하는 Functional Interface 이다.

Json

Use JsonView to refactor Response
https://medium.com/chequer/jackson-json-view%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%B4-%EC%9B%90%ED%95%98%EB%8A%94-%ED%95%84%EB%93%9C%EB%A7%8C-json%EC%9C%BC%EB%A1%9C-%EC%A7%81%EB%A0%AC%ED%99%94-%ED%95%98%EA%B8%B0-7cda06896c26

내용

service layer 에서 persistence layer 로의 확장을 하며,
MSA 데이터에 영속성을 부여한다. (add persistence layer)
또한 영속성 중심의 자동 테스트를 작성한다.

목적

Spring Data 를 바탕으로, MongoDB 및 MySQL 데이터베이스에 데이터를 저장하기 위함이다.

참조

product, recommendation 은 MongoDB에,
review 는 MySQL에 담는다.

내용

• docker 를 사용하여 MSA 를 container 에 담는다.

목적

• MSA 환경에 대한 완전한 자동화된 테스트
• docker engine 외 다른 infra가 필요없이 수행

참고

현재는 한 인스턴스에서 docker 를 바탕으로 내부적으로 여러 application 을 컨테이너에 올려
MSA 환경인듯한 모습을 보여주므로, docker container name 으로 host 가 지정되지만,
앞으로 MSA 로 확장해갈수록 service discovery 로 확장해나갈 계획

Web on Reactive Stack

• Spring WebFlux
• Reactive WebClient, support for testing
• Reactive Libraries

reference

https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html

Spring Cloud Netflix Eureka 를 활용하여 내부망의 인스턴스간 통신의 사전 정보들을 모아두는
중앙 검색 서버를 배치한다. 이는 각 서버에서 hard-coding 되며 작성된 host 와 port 정보에 대한 불편함을 줄여주나,
trade-off로 추가적인 네트워크 비용이 발생한다. 하지만 인스턴스들의 정보를 일괄적으로 관리가 가능하여 편리함을 제공한다.

내용

MSA에 접근할 때 참고할 수 있는 API 를 swagger 및 Spring fox 를 사용해 문서화한다.

목적

접근이 쉬운 좋은 문서를 통해 유용하게 API 를 사용할 수 있게한다.

참고

end-to-end 에 대해서,
기존 monolithic 과 달리 MSA 에서는 다른 API server 도 client 가 될 수 있다.
(꼭 front, mobile, 실제 사용자 만이 client 가 아니라는 의미)

Test 에 있어 다양한 방식으로 Mocking 및 Stubbing 을 활용할 수 있도록 해준다.

stub & mock

mock()
spy()
(@ Mock, @ Spy, @ InjectMocks)
mockStatic()
mockConstruction()

mocking

• 행위 검증
  Mockito.verify()
  Mockito.verifyNoMoreInteractions()

stubbing

• 상태 검증
  Mockito.when()
  BDDMockito.given()
  Mockito.doReturn()
  Mockito.doNoting()
  Mockito.doThrow()

행위와 상태 검증

https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#1

implement
https://search.maven.org/artifact/org.mockito/mockito-core/4.5.1/jar

일반적으로 @Test_ 는 컴파일 시점에 정적으로 정의되어지고, 행위는 런타임에 어떤 일이 발생하더라도 영향받지 않는다.
Assumptions 는 동적 행위에 대한 처리를 제공하지만, 제한되는 부분이 존재한다.

이런 표준외에도 새로운 종류의 test programming model이 Junit Jupiter에 도입이되었다.
-> dynamic test, 동적 테스트로 런타임에 @TestFactory_ 를 바탕으로 factory method 를 통해 생성되어진다.

@TestFactory_ 의 return type 은 반드시

• DynamicNode
• Stream
• Collection
• Iterable
• Iterator
• array of DynamicNode

@TestFactory_는 private 혹은 static 이 될 수 없으며,
런타임에 생성되어지고, display name 과 Executable 로 구성되어진다. (Executable : @FunctionalInterface)

Dynamic Test LifeCycle
동적테스트의 생명주기는 일반적인 @Test와는 다르다. 특히 각 동적 테스트에 대해서 lifecycle callback 이 존재하지 않는다.
@BeforeEach와 @AfterEach 가 적용된 메서드와 해당되는 extension callbackemfdms @TestFactory 메서드에 대해 실행되지만, 각 동적 테스트에 대해서는 실행되지 않는다. 

예외 : JunitException

reference

https://junit.org/junit5/docs/current/user-guide/#writing-tests-dynamic-tests

• Spring 을 사용한 non-blocking 동기 REST API
• 비동기 이벤트 기반 서비스
• 두 가지 방식의 선택 기준에 대한 학습
• Reactive MicroService 환경을 위한 수동 및 자동 테스트 작성 및 실행

리액티브 시스템은 메시지 기반의 비동기 통신을 토대로 유연성, 확장성 탄력성을 확보하여 장애에 강하다.