일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 | 31 |
- Java
- sftp
- @GetMapping
- IntelliJ
- 마이크로서비스
- @PatchMapping
- @PutMapping
- MSA
- 마스터링 스프링 클라우드
- Microservice
- @DeleteMapping
- @PostMapping
- @RequestMapping
- 인텔리j
- 업로드
- 클라우드 네이티브 자바
- Spring MSA
- spring
- 인텔리제이
- 파일업로드
- FTP
- Today
- Total
zerofunc
스프링 MSA 스터디 본문
현재 웹 솔루션을 유지 보수하며 사내 타 솔루션과의 의존성이 높아 몇 가지 문제점을 안고 있습니다.
개발하고 있는 솔루션의 몇 기능들이 타 솔루션에서도 사용돼야 하는 상황에서
공통 자바 프로젝트를 양쪽에서 maven으로 의존성을 가지게 하였고 해당 프로젝트는 제가 개발을 했습니다.
그러다 보니 아래와 같은 문제점을 발견했습니다
한 줄로 요약하자면 서비스별 독립적 성장과 새로운 기술의 도입 및 변경이 어렵습니다.
- 스프링 버전을 마음대로 올릴 수 없습니다
- 공통 프로젝트도 스프링을 사용하는데 스프링 버전을 올리면 타 솔루션에 영향을 끼쳐 현재 스프링5로 올릴 수 없는 상태입니다
- 운영 배포 시점을 맞춰야 합니다.
- 공통으로 사용하는 기능에서 버그가 발생할 시 양쪽에서 수정돼야 하다 보니 운영 배포 시점을 맞춰야 합니다
- 타 솔루션의 빌드 속도가 느려집니다. (이건 제가 불편한 문제는 아니지만)
위와 같은 문제로 인해 공통기능을 라이브러리로 제공하는 것이 아니라 API 기반으로 변경하려고 했고, 이러한 과정에 트랜잭션과 로깅에 대한 문제점으로 인해 API만 우선 제공하고, 나중에 타 솔루션에서 API를 호출하는 방식으로 변경하려고 계획을 세웠습니다.
우선 트랜잭션과 로깅에 대한 문제점을 풀기 위해 그리고 API 기반으로 바꾸기 위해 여러 정보를 찾아보던 중 MSA (Micro Service Architecture) 에 대한 개념을 알게 됐고, 결국 우리가 하려던 것이 MSA라는 것을 알게 됐습니다.
지금 겪고 있는 문제들을 MSA가 해결해 줄 수 있을 것이라는 판단이 들어 사내에서 스프링 MSA 스터디를 2019년 1월 18일 처음 시작했고, "마스터링 스프링 클라우드"라는 책으로 스터디를 진행했습니다.
4장까지 진행을 했는데 이 책을 읽으면서 다들 공감하는 부분이 2가지가 있었습니다.
- 설명하지 않고 넘어가는 부분들이 있습니다.
- 읽기 힘듭니다. (번역이 문제인지 원서가 문제인지… 두 가지가 있습니다 이렇게 시작해서 첫 번째는 이렇고… 라고 설명하다가 두 번째에 대한 언급이 없거나…)
그래서 책을 변경하기로 했고, 클라우드 네이티브 자바 라는 책으로 다시 스터디를 진행하려 합니다.
새로 시작한다는 마음으로 기존에는 깃헙을 통해 [https://github.com/zerofunc/TIL/tree/master/Mastering-Spring-Cloud] 정리했었는데 이제 블로그도 다시 시작할 겸 블로그에서 정리를 시작하려고 합니다!
'IT > Programming' 카테고리의 다른 글
클라우드 네이티브 자바 3장 - 12요소 애플리케이션 설정 (0) | 2019.02.27 |
---|---|
Spring @RequestMapping을 간단히 줄인 @PostMapping @GetMapping @PutMapping @DeleteMapping @PatchMapping (0) | 2018.07.18 |