MSA해설/API First Design3 2002년, Amazon 설립자 Jeff Bezos의 명령 All teams will henceforth expose their data and functionality through service interfaces. 모든 팀은 이제부터 서비스 인터페이스를 통해 데이터와 기능을 공개합니다. -> Iceberg Microservice Teams must communicate with each other through these interfaces. 팀은 이러한 인터페이스를 통해 서로 통신해야 합니다. -> API, Domain Event(Publish/Subscribe) There will be no other form of inter-process communication allowed : no direct linking, no direct reads of a.. 2022. 11. 30. Iceberg(빙산) Microservice 위 빙산 모습을 단순화하면 다음과 같다 그런데 혹시 다음과 같은 빙산을 본적이 있는가? 당연히 있을 수 없는 모습이다. 불안정해 보이고 부자연스러운 모습이다. Microservice 별로 Data를 갖고 관련된 기능을 구현하면서 Client 에서 뭐가 필요할지 모르니 CRUD 형태로 최대한 많은 API를 노출한다고 생각하면, 아마도 이러한 부자연스러운 빙산의 모습이 될 것이다. 이러한 형태로 API가 노출된다면 DB Schema 또는 로직 등의 변경에 따라 API가 계속 흔들리게 되고 Client에 대한 영향력이 증가할 수 밖에 없다. API 정련이 필요하다. 제공하는 Provider 입장 뿐 아니라 Consumer와 상의하여 패턴화해야 한다. 이것은 단지 REST API 만의 문제가 아니다. Publi.. 2022. 10. 26. MSA 설계는 뭐가 다른가요? 기존 설계와 뭐가 다를까? 기존 Monolith 설계와 어떤 부분이 가장 차이가 날까? 위의 그림과 같이 제일 큰 차이는 분산환경이다. Application 뿐 아니라 DB 서버까지 분리되어 있고, 각 서비스별 Data 가 필요한 경우 API 또는 Event로 주고 받아야 한다. 이렇게 서비스별로 물리적으로 분리된 분산환경을 어떻게 극복할 것인가? 데이터 정합성을 어떻게 맞추고, 독립적으로 작동하기 위해서 어떤 처리를 할 것인지에 대한 How, 방법을 찾는 것이 가장 큰 설계의 차이점이다. 이러한 분산환경을 받아들일 수 없다면, 우측과 같은 서비스별/물리적으로 분리된 아키텍처를 적용하지 않아도 확장성, 장애격리, 독립적 설계/개발/테스트/배포/운영이 가능하다면 굳이 MSA를 도입할 이유가 없다. API .. 2022. 8. 3. 이전 1 다음
