https://microservices.io/ 를 이해하기 노력의 일환으로 작성한 글입니다.
대략적으로 느낀 점을 정리하자면, microservice는 어플리케이션을 모듈화하는 작업인 것 같다. 모듈화하여 각 모듈에 맞는 인원 구성을 하고, 각 모듈을 독립적으로도 운영가능하게 하면서 전체적인 서비스로도 운영가능하게 하는 듯 한 느낌...?
한 개의 함수는 한 개의 기능을 하게 하라는 것처럼 다 쪼개서 전체를 만드는 것 같다.
What are microservices?
마이크로서비스(마이크로서비스 아키텍쳐로도 알려진)은 아키텍쳐 스타일이다. 이 스타일은 어플리케이션을 아래와 같은 서비스의 조합으로 구성한다.
- 유지 관리 및 테스트 가능
- 느슨하게 결합됨
- 독립적으로 배포할 수 있음
- 비즈니스 역량을 중심으로 구성
- 소규모 팀 소유
마이크로서비스 아키텍처는 크고 복잡한 애플리케이션을 빠르고 빈번히 신뢰할 수 있도록 제공한다. 그것은 또한 조직이 기술 스택을 진화시킬 수 있도록 한다.
The pattern language is your guide
마이크로 서비스 아키텍처는 만병통치약이 아니다. 몇 가지 단점이 있다. 게다가 이 아키텍처를 사용할 때 해결해야 할 많은 문제들이 있다.
마이크로 서비스 아키텍처 패턴 언어는 마이크로 서비스 아키텍처를 적용하기 위한 패턴 모음이다. 그것은 다음 두 가지 목표를 가지고 있다
- 패턴 언어(뭐고..)는 마이크로서비스가 당신의 어플리케이션에 적합한지 결정할 수 있게 해준다.
- 패턴 언어는 당신이 마이크로서비스 아키텍처를 성공적으로 사용할 수 있게 해준다.
좋은 출발점은 모노리틱 아키텍처 패턴(https://microservices.io/patterns/monolithic.html)으로, 여전히 많은 애플리케이션에 적합한 전통적인 건축 양식(일종의 디자인패턴 같은 개념으로 이해하면 될듯)이다. 그러나 수많은 한계와 문제를 가지고 있기 때문에 대형/복합 애플리케이션을 위한 더 나은 선택은 마이크로서비스 아키텍처 패턴(https://microservices.io/patterns/microservices.html)이다.
Avoid the potholes
마이크로 서비스 아키텍처로 마이그레이션할 생각이십니까? 만약 그렇다면, 여러분은 획일적인 지옥에서 온 길에 있는 포트홀에 대한 이 프레젠테이션(http://chrisrichardson.net/post/antipatterns/2019/01/28/melbourne-microservices.html)을 보고, 안티패턴과 그것들을 피하는 방법에 대한 블로그 게시물(https://microservices.io/microservices/antipatterns/-/the/series/2019/06/18/microservices-adoption-antipatterns.html)을 읽어야 합니다.
Assess your architecture
마이크로 서비스 아키텍처로 애플리케이션을 구축한 경우 Microservices 평가 플랫폼을 살펴보십시오. 이 플랫폼은 여러분이 구축한 것을 평가하고 개선해야 할 것을 파악한다. 그것은 아키텍처와 조직의 위험을 줄이고 마이크로 서비스 아키텍처의 이점을 극대화한다.
