스프링캠프 2014에서 정리해 놨던 걸 이제서야 블로그에 옮긴다.
실용적 소프트웨어 설계를 위한 근본적인 질문들 (안영회)
- SW는 유기체
- Contract & Integrity: 유비쿼터스 랭귀지, 스펙 등
- Contract & Integrity >> 표준화
- 용도에 맞는 설계 적용: 예, 복잡한 상태 변화를 표현하기 위한 상태 다이어그램
- 레거시 수정의 어려움 중 하나: 멘탈 모델이 그려지지 않음 (예, 이름을 잘 정해서 응집을 높이는 등 멘탈 모델을 향상시킨다.)
- 개발 팀 별 컨텍스트를 아우르는 협업
마이크로 서비스 구축 사례 (박찬욱)
- 10년간 운영해 온 커머스 사이트 시스템을 RESTful API 기반 마이크로 서비스로 쪼개는 과정
- 화면과 API를 쪼개고, 각 화면과 API도 별도로 분리
- 20개 사이트!!! 그 동안 프로젝트를 Copy&Paste&Modify 해서 사이트 추가 -> 수정의 어려움, 비용과 제약 (기술부채) 확산
- 그 과정:
> 한 통의 WAR를 두 개 코드 분리: 화면 코드 - 로직(API) 코드
> 화면을 위한 확장(예, 디바이스 추가)은 화면용 프로젝트(WAR)만 추가
> 재사용 단위를 API로 맞춤
- 장점:
> 영역별 확장
> 분산해서 개발할 수 있는 환경
- REST 클라이언트를 스프링데이터처럼 런타임에 자동생성되도록 함
- API Spec을 별도 메이븐 모듈로 작성해서, 양쪽에서 의존으로 추가 -> 의존성 관리 어려움으로 코드가 아닌 스펙만 제공하는 것 고려 중
- 무엇을 API로 뽑아야 하나?
- Join의 최소화를 위해 적극적 캐시 도입
- 문제 발생시 문제 발생한 곳을 찾는 어려움 (여러 장비의 로그를 확인해야 함) -> Trace Key를 모든 로그에 보관
주키퍼, Vert.x 활용 실시간 푸쉬 서비스 개발 (이연복)
- 철가방 시스템에서 주문중계 서비스의 실시간 알림 기능 구축 사례
- 사용자가 앱으로 주문 발생시 가맹점에 어떻게 (최대한 실시간으로) 전달할 것인가?
- 쉬운 방법: 주문이 들어오면 전화로 다시 가맹점에 주문 전달 (정보 누락 등 문제 발생)
- 가맹점에 주문을 통지 받을 수 있는 프로그램을 배포(Flex Air로 제작)
- Flex Air와 서버 간 통신은 BlazeDS를 사용
- Flex Air와 Zookeeper 간의 중간 통신은 Vert.x로 만든 LB로 사용
- Vert.x의 분산 이벤트 버스로 클러스터 구현
- 이벤트버스를 이용해서 버티클 간 통신(데이터 전달 등)
스타트업 망한 이야기 (강규영)
(들었던 내용을 모두 옮겨 적고 싶었지만 서서 들은 관계로..... 아래 두 가지만 적음)
- 넘치는 쪽지를 비활성 유저에게 보내기: 일단 유저에게 통지하고, 그 유저가 액티브 상태가 되면, 실제 쪽지 전송 (미리 보내지 않음)
- 한글 자소 분리해서 필터 학습
REST (김강우)
- REST: REpresntional State Transfer
- REpresntational -> Resource
- State Transfer
> State: 상태의 전이가 발생
> 상태 전이를 위한 방법: POST(C), GET(R), PUT(U), DELETE(D)
>> POST(C): /order (성공: 201 응답이면 좋을 것, Location: /order/{생성된ID})
>> GET(R): /order/{id}
>> PUT(U): /order/{id} (200(데이터 보냄), 204(데이터는 안 보냄), 409(Conflict, 예, 누군가 이미 변경했다면, 즉, 낙관적 락!))
>> DELETE(D): /order/{id}
- Hypermedia 응답에 상태 전이를 위한 링크 포함 (HATEOAS: Hypermedia As The Engine Of Application State)
> 장점1: 다음 전이 상태를 쉽게 응답으로 알 수 있음
> 장점2: 연결되는 주소를 알 수 있음 (결제 주소가 넘어 옴)
- EntityTag(etag)
> 수정시, etag를 일종의 Resource의 버전으로 사용가능
- 전체 수정, 부분 수정: POST? PUT?