.NET Microservices] 1. 소개

출처 : https://youtu.be/DgVjEo3OGBI

사전지식

• Experience with building .NET REST APIs in C#
• Understanding of Docker
• Dependency Injection
• Async / Await

개발 시 필요사항

• VS Code (free)
• .NET 5 (free)
• Docker Desktop (free)
• Docker Hub 계정 (free)
• Insomnia or Postman (free)

Microservices란?

• Small (2 pizza team, 2 weeks to build) : 소규모 인원이 빠르게 만들 수 있는 사이즈
• Responsible for doing 1 thing well
• Organisationally aligned
• Form part of the (distributed) whole
• Self-contained / Autonomous

다음과 같이 운영되는 하나의 거대한 CRM system을 만나곤 한다...

• 많은 사용자
• 오랜기간 서로 연결되어 있음
• 하나의 소유자기 있는 기술스택으로 개발됨
• 하나의 아웃소싱 파트너에 의해 운영됨

이러한 시스템은 다음과 같은 문제가 있다. 

• 수정이 아주 어렵다. 
  • 기능 변경에 최소 3개월이 걸린다. 
  • 많은 양의 test를 해야한다. 하나의 거대한 시스템이므로 어디에 영향을 줄지 모른다. 
• Scale하기 어렵다. 
• 고정되어 있다. 
  • 개발팀
  • 지적재산권

Microservices의 장점

• 수정과 배포가 쉽다. (사이즈가 작고, 결합도가 낮다.)
• 다른 기술을 사용하여 빌드할 수 있다. 
• 여러 서비스들의 담당팀이 나눠져있기 때문에, ownership이 증가한다. 
• 회복력 : 하나의 서비스에 문제가 생겨도, 다른 서비스들이 run한다. 
• Scalable
• 대체 / 교체가 쉽다. 

예를들어 항공권 서비스를 제공할때 3가지 Microservices로 구성할 수 있다. 

• Flight Catalog : .Net, SQL Server, A팀 개발
• Booking : Ruby on Rails, PostgreSQL, B팀 개발
• Check in : Node, MongoDB, C팀 개발

하나의 Microservice가 다운되어도 나머지 2개의 Microservices는 이용이 가능하다. 

만약에 항공권 세일시즌이여서 사용자 접속이 증가하는 경우, Flight Catalog와 Booking Service의 instance를 추가할 수 있다. 

 

Microservices vs Monoliths

Microservices

• 전체 마이크로서비스 구조의 구성과 구현이 어렵다. 
• 아무것도 개발된 것 없이, 전체 서비스의 시작단계에서 마이크로 서비스로 시작하는 것은 어려울 수 있다. 도메인에 대한 이해가 없으면 의사결정이 어렵다. 어떠한 것을 마이크로 서비스로 만들어야 할지 결정이 어렵다. 
• 도메인 지식이 필요하다. 
• 분산구조 - network에 문제가 있을 때, 서비스 이용에 문제가 생긴다. 
• 어떤 부분에 대해서는 서로 결합도가 높다. 

Monoliths

• 구현이 쉽다. 
• CI/CD, 매일 배포, 작은 변경 등이 가능하다. 
• 도메인에 친숙해지도록 한다. 
• 2 or 3 big services로 구성할 수 있다. 
• network에 의존하지 않는다.