현재 수강중인 과목의 이름은 대용량 웹서비스를 위한 MSA Full-Stack 소프트웨어 개발자 양성과정이다. 그러나 MSA에 대해서는 고작 3일정도 수업이 진행됐다. 거의 배운게 없었지만 팀원 각자가 나름의 공부를 통해서 MSA 아키텍쳐를 조금이나마 적용하여 프로젝트를 진행해보면 좋을 것 같다 라는게 오늘 회의의 주제였다.
todo
요구/기능명세서작성
웹페이지 기본구성/흐름
db설계
오전
기능/요구명세서 작성
기능
*회원가입(메일인증)/로그인
회원가입할때 이름 이메일(이메일로 로그인) 주소(주소입력 API) 전화번호 비밀번호
이메일이 아이디기 때문에, 비밀번호 찾기.
비밀번호 찾기 → 메일인증 사용해서 비밀번호 변경
*관리자계정(스프링 시큐리티 사용)
패키지 신규 등록/삭제/수정
게시판관리 : 글 삭제, 관리자문의 게시판에서 관리자만 열람/댓글 허용
관리자페이지가 따로 있어야함. 관리자 페이지 관련 → 강사님께 질문(CRUD 같은 관리자 기능들을 hidden으로 해도 되는지, 따로 만들어야 하는지)
*마이페이지(구독한 내역,구독취소,회원정보조회/수정)
*결제(토스api)
*SSL →도메인이 무조건 있어야 한다. 무료 도메인 사이트 배포를 먼저 하고, 그 아이피주소를 무료 도메인 주소에 연결. 그리고 SSL 사용. 프로젝트 생성해서 서버에 배포해야함.
*게시판-한줄평/별점
*게시판-자유게시판
*채팅/챗봇
https://medium.com/@dynamic_maize_coyote_676/spring-boot로-나만의-chatbot-구축하기-868b4a379209
*관리자 Q&A게시판
*최근 본 상품
과자 구독 관련
- 설문조사 http://officesnacking.co.kr/front/subcription#
- 인원수, 선호하는 간식종류, (희망가격) 정도를 설문받고, 그 결과따라서 패키지 2~3개
- 가격대를 정해놓고 패키지를 구성한다.
- 설문조사하면 결과에 따라 각 가격대별로 패키지를 추천해준다.
- 비로그인으로 설문 시⇒ 맞춤 패키지 추천, 사용자가 하나를 선택하면 그때 회원가입 및 로그인을 하는데, 선택했던 패키지는 최근 본 상품 식으로 저장되서 계속 따라다닌다.
- 로그인하고 설문조사 시⇒ 구현이 좀 편하다.
- 커스텀(나만의 패키지)
- 가격대만 정해놓고 자유롭게 본인이 하고싶은 상품을 고른다.
- 커스텀 옵션 선택하면 가격대가 정해져있지 않다. 쿠팡처럼 제품 고르는 화면.→ 선택 개수를 제한한다. 종류 제한. ⇒ 가격이 표시되어야 한다. 가격을 책정하는 규칙이 있어야한다.
- 드래그 앤 드롭
- (게시판에서 나만의 패키지 공유)
- 기본 패키지
- 엑셀파일보고 패키지 직접 구성해서 창에 띄우면 된다.
필요한 테이블
고객테이블
고객번호(pk) 고객은 몰라도 된다.
이메일
비밀번호
이름
주소
전화번호
패키지테이블
패키지번호(pk)
패키지 이름
패키지 가격
중간테이블
ID
패키지번호
제품번호
제품테이블
제품번호(pk)
제품이름
대분류 과자/견과류/초콜릿/
가격
구독테이블
문의게시판 테이블
자유게시판 테이블
별점/한줄평 게시판 테이블
오후
테이블 간 관계
패키지와 상품 간 어떻게 설정할까?
MSA?
DB가 여러개 https://www.popit.kr/마이크로-서비스msa를-어떻게-나눌까-ii/
https://velog.io/@agugu95/서버-아키텍쳐-공부-2-마이크로-서비스-아키텍쳐
MSA 아키텍처란?
공식적인 정의는 없다
각 서비스 간 Network를 통해, 보통 HTTP를 통한 서비스 인터페이스로 이루어져야 한다.
각 서비스는 독립적으로 배포된다.
각 서비스는 쉽게 교체 가능해야 한다.
각 서비스는 기능 중심으로 구성된다. e.g. 프론트엔드, 추천, 정산, 상품 등등
각 서비스에 적합한 프로그래밍언어, 데이터베이스, 환경으로 만든다.
각 서비스는 크기가 작고, 상황에 따라서 경계를 구분지으며, 자율적으로 개발되고, 독립적으로 배포되고, 분산되며 자동화 된 프로세스로 구축되고 배포된다.
이러한 마이크로서비스는 아직까지 아이디어 수준이다. 좋은지 나쁜지는 시간이 지나봐야 알 수 있을 것이다.
각 마이크로서비스별로 DB를 가진다. 그리고 서로 공유되는 상태가 없다.
REST API 인터페이스 외엔 호출할 방법이 없다.
공유되는 정보가 하나도 존재하지 않는다.
각 서비스는 별개의 환경을 가지고 서로 REST API 인터페이스를 통해 호출한다.
MSA의 끝은 DB의 분리이지만 DB분리를 위해서는 event-driven, 분산 트랜잭션 등과 같은 기술이 필요하다.
MSA 기초
Kafka를 이용한 Event Driven
개발자가 코드를 짜서 로컬에서 톰캣을 통해서 실행을 한다.
DB에 비즈니스에 대한 모든 데이터가 저장되어 있다. 회원정보, 상품정보, 주문정보 등등....
SCM (Source Code Management)
Git
배포(scp, 톰캣매니저)
톰캣매니저는 메모리 문제가 있을 수 있다.
High Availablity 구성
지속적으로 구동되는 시스템.
uptime? downtime?
Load Balancer(L4 switch, L7) ?
서비스의 규모가 커지며
order와 product에 대한 요청을 따로 처리한다. 서버를 분리.
⇒ share.jar가 필요하다. 그런데 서비스가 분리되어 있다고 해도 실무에서는 Share.jar에서 작업하게 된다. 더욱 편리하게 느껴지기 때문.
모든 팀들이 공유하게 때문에 sync를 맞춰야함. 따라서 정기배포가 큰 일이다.
*스냅샷(snapshot)
고정된 버전이 아님. 메이븐에서 snapshot이 붙어있으면 늘 새로운 버전을 받아온다. 오늘 잘 돌아갔던 코드가 내일 갑자기 안될 수 도 있다.
회사가 점점 더 성장하며...
*콘웨이의 법칙
모든 조직은 조직의 의사소통 구조와 똑같은 구조를 갖는 시스템을 설계한다.
조직간의 의사소통 구조가 서비스와 똑같아진다.
모놀리틱... 너무 많은 팀들이 관여가 되어있어서 서로 의사소통 관계가 복잡하다.
하나의 애플리케이션 개발/배포에 너무 많은 의사소통이 필요하다. 결정적인 단점이다.
대부분 IT 회사의 시작은 모놀리틱
장점 : 개발이 단순하다.(repository 하나 체크아웃 받아서 띄우면 된다..)
배포가 단순하다.(war 하나만 배포하면 된다.)
Scale-out이 단순하다.
그러나 DB성능으로 인한 한계가 있다.
단점 :
무겁다 - IDE가 못 받쳐줌
어플리케이션 시작이 오래 걸린다.
기술 스택 바꾸기가 어렵다.
결합도가 높다.
코드베이스의 책임 한계와 소유권이 불투명하다.
Netscape : 전면적으로 새로운 코드로 전면 재개편 하다가 실패한 사례
MSA 플랫폼을 구축해서 기존 Legacy를 고사(Strangle)시킨다.
'웹 프로그래밍 > 팀 프로젝트' 카테고리의 다른 글
| Spring Boot 팀 프로젝트 - 간식 구독 서비스 (0) | 2021.06.07 |
|---|