Page History
...
SOA 는 서비스들의 재사용에 중점을 두지만 MSA 는 서비스들의 독립을 추구한다.
...
경계식별
...
...
...
특성
특성및 주의점
- SOA는 각 레이어의 통신방법을 중시하며, 재사용을 위해 공유할수 있으며 모놀리식에 가까울수 있다있습니다.
- MSA는 배포와 업무 조직단위의 서비스(레파지토리) 자체가 분리된다. 서비스내에 동일 로직이 생길수 있으며 각 서비스가 책임진다.
- MSA에서 서비스 오케스트레이션 영역에 목숨걸지말고, 유지보수와 배포에 포커싱해야합낟포커싱해야합니다. ( 데브옵스는 반드시 해야한다.데브옵스 )
- MSA에서 API 게이트 웨이를 반드시 사용해야하는 강박관점도 없애야 한다.
...
애플리케이션 아키텍처는 그것을 개발하는 조직의 구조를 그대로 반영한다는 뜻입니다. 따라서 이 법칙을 역으로 이용해서 조직의 구조가 마이크로서비스 아키텍처에 고스란히 반영되도록 설계해야 합니다. 이렇게 하면 개발 팀과 서비스를 느슨하게 결합시킬 수 있습니다.
서비스 경계식별
마이크로 서비스가 무조건 작은 단위로 쪼게어, 우리가 운영을 하기 힘든케이스가 되어선 안됩니다.
중요한것은 "너무 크지도 작지도 않은것" 이며 사실은 우리에게 적절한 신중하게 디자인한 도메인모델을 사용하는것입니다.
무조건 작게 만드는것이 아닌, 어떻게 구분을 할것인가? 이며 DDD의 Bounded Conxtext 는 이러한 점에서 도움을 줄수 있습니다.
DDD가 마치 MSA를 위한것인것처럼 보일수 있는데, SOA/모놀리식 등에서도 활용될수 있습니다.
경계가 꼭 배포단위가 될필요가 없으며, 리팩토링을 통해서도 경계를 만들수 있기때문이며 필요하면 독립될수 있기때문입니다.
DDD의 바운디드 컨텍스트
소프트웨어의 관심사를 도메인을 바탕으로 분명하게 분리시켜야 한다.
상호 의존성을 갖기 때문에, 서브도메인으로 나누지 않는다면 변화가 계속됨에 따라 훨씬 큰 부담을 지게 된다.
Next - 데브옵스 패턴
오늘날의 소프트웨어 환경에서는 모든 조직이 모놀리스를 제거하고, 파이프라인을 자동화하며, 전체적인 작업을 감소함으로써 관행을 현대화해야 한다는
압박을 지속적으로 받고 있습니다. 현대화를 위해 대부분의 조직은 데브옵스 관행으로 전환하지만,
이러한 전환 여정을 자체적으로 완료할 수 있는 역량을 보유한 경우는 그리 흔치 않습니다.
데브옵스로 원활하게 전환을 해주는 단일한 방법은 존재하지 않습니다.
...
DDD의경우 도메인을 베이스로 분리하는 방법에 대해 설명을 합니다. 서로 고립된 상태로 운영되는 조직들을 정렬하려면 문화적, 절차적,
기술적 변화가 함께 이루어져야 합니다. 비즈니스 요구와 목표에 맞는 실용적인 접근 방식을 신중하게 사용하면, 궁극적으로 성공할 수 있습니다.
참고링크
- 콘웨이 법칙 : https://johngrib.github.io/wiki/Conway-s-law/
- MSA VS SOA : http://blog.naver.com/PostView.nhn?blogId=stmshra&logNo=221446919085&parentCategoryNo=&categoryNo=73&viewDate=&isShowPopularPosts=true&from=search
- DDD 바운디드 컨텍스트 : http://redutan.github.io/2018/04/28/IDDD-chapter02
- 마이크로 서비스 경계 식별 : https://docs.microsoft.com/ko-kr/azure/architecture/microservices/model/microservice-boundaries
- 데브옵스 패턴 : https://newrelic.com/kr/resources/ebooks/devops-maturity-phases
- 개발자 추천도서 : http://www.yes24.com/Product/Goods/77283734 - 클린아키텍처