평소 Spring 생태계에 대해 얼추 알기는 했지만, Web 관련 개발과 거리가 멀었다.
- 퇴사 전에는 '정산 업무를 해보고 싶다' 라는 생각 전까지는 Web관련 업무가 없었기도 했다.
- 언젠가 할 기회가 생기겠지라는 생각은 있었지만, 사용 기술 스택을 들으니 업무를 받게 된다면 그때 가서 공부해도 내 의지를 믿기에 늦지 않았을 것이라고 여겼다.
- 그러다보니 오히려 서버구성이나 인프라 쪽으로 관심을 돌리게 되어 더더욱 안 하게 되었다.
- 이직준비를 하면서 느낀건, 기본이 Java + Spring / Kotlin + Spring 이 아니면 안 되는 시장의 분위기를 느꼈다.
- 공부하자
Why Spring Webflux?
장점
- 효율적인 리소스 사용
1-1. 초기세팅이 잘 구성된다면, 트래픽이 증가하는 환경이여도 오래 유지 가능 - 요청이 순간적으로 늘어나도 유연하게 커버
2.1 '유연하게'가 포인트 - Concurruncy를 극한으로 이용해서 응답속도 단축
3-1. Concurruncy를 극한으로 이용하기에, 리소스를 효율적으로 관리 - Reactor, Coroutine으로 가독성 유지
4-1. 실제 작동은 non-blocking
단점
- 비동기 로직 처리에 대한 고민
- 팀원들 모두 러닝 커브가 필요
- 디버깅, 에러 핸들링의 어려움
- 충반하지만 완벽하지 않은 생태계
1,4번은 이미 Vert.x Framework를 경험하며 이미 많이 부딪혔기에 그나마 마인드셋 자체가 훨씬 수월하다고 느껴진다.
뭘 하던지 Vert.x 보다는 Reference도 많을 것이기 때문에 . . .
Why Reactive Microservice?
Reactive
- reacting to events or situations rather than acting first to change or prevent something
- (무언가를 바꾸거나 예방하기 위해서) 먼저 행동하기 보다는 사건이나 상황에 반응하는
Reactive System
- 회복이 가능하고
- 유연하며
- 메시지 기반의 상호작용을 통해 높은 응답성 + 안정성을 유지하는 시스템 설계
Microservice Architecture
- 독립적이고 작은 서비스들이 유기적으로 협력하여 서비스를 구축하는 시스템 설계
Reactive Microservice
Reactive Microservice는 결국 '안정성'과 '확장성'이다.
서론일 뿐, 구체적인 이론은 아니다.
당장 Spring Webflux부터 들어가지 않고 차근차근 쫓아갈 것이다.
- Reactive Programming (Reactive Programming과 개발 패러다임)
- Spring Webflux (Spring reactive 스택과 여러 통신 기법)
- Spring Data Reactive (Database에 reactive 적용)
- Kotlin Coroutine (Coroutine으로 가독성과 성능 높이기)
- Spring Test Reactive (Reactive 환경에서 테스트 구성)
- Reactive Microservice (Reactive Microservice와 Spring Cloud)
🤦🏻♂️