Microservice 소개

Cloud Native Architecture

확장가능한 아키텍처 

• 시스템의 수평적 확정 (Scale out) 에 유연
• 시스템 또는 서비스 애플리케이션 단위의 패키지 (컨테이너 기반패키지) , 모니터링

탄력적 아키텍처 

• 서비스생성 - 통합 - 배포 , 비즈니스 환경변화에 대응 시간 단축
• 분활된 서비스 구조 , 무상태 통신 프로토콜 , 독립적이어야 한다. 

장애격리 = 특정 서비스에 오류가 발생해도 영향을 퍼트리지 않음

지속적인 통합 CI (Continuous Integeration)

• 통합서버, 소스관리 (SCM) , 빌드도구 ,테스트 도구

지속적인 배포

• Continuous Delivery , Deployment 
• 카나리 배포 (95는 이전서비스, 5는 새로운 서비스) , 블루그린 배포 (점진적으로 업그레이드)

Container 를 이용하기에 기존의 Virtualized Deployment 처럼 각각 OS를 가지고 있지 않고 가볍다.

 

12 + 3 Factors

1. Base Code

하나의 앱은 하나의 repository로 배포를 한다. 형상관리를 하기 위함이다. 

2. Dependency Isolation

3. Configurations

코드 안이 아닌 외부에서 MSA를 운영하기 위해 필요한 작업이 가능해야함.

4. Linkable Backing Service

MSA가 가져야할 부가적인 뒷단(연결) 기능들을 분리해놓음으로 independecy를 높일 수 있다. 

5. Stages of Creation

빌드 , 배포 ,운영 환경을 각각 분리한다. 

6. Stateless processes

분리된체 자체 프로세스에서 독립적으로 굴러갈수 있어야 한다.

7. Port Binding

각각의 app은 각각의 port를 가지고 있어야 한다.

8. Concurrency 

하나의 인스턴스를 복사해서 많은 트래픽을 여러부하로 나누기 때문에 동시성을 가지고 있어야 한다.

9. Disposability

정상적으로 종료를 할 수 있어야한다. 인스턴의 갯수를 줄이거나 늘리는게 쉬워야함

10. Devlopment & Production Parity 

개발단계와 production 단계를 구분할 수 있어야 한다.

11. Logs

로그와 application 이 완전히 분리가 되어야 한다. 별도의 모니터링 도구를 사용 할 수 있다.

12. Admin Processes for eventual processes

현재 운영되고 있는 MSA 들의 resource와 state를 관리할 수있는 도구가 있어야 한다.

13. API first

모든 마이크로 서비스들은 API로 제공된다. 

14. Telemetry

모든 지표는 수치화 및 시각화

15. Authentication and Authroization 

 

 

Monolithic vs MSA

app 이 사용하는 데이터가 한곳에 모여 참조되어 서비스되는 형태

조금 수정해도 전체를 다시 패키징 빌드 배포 하는 과정을 거쳐야한다.

 

각각이 모두 독립적으로 서비스를 운영하고 있다. 

 

항상 MSA가 좋을까?

1. 어느정도 변화가 생길것인가? 비용 고려

2. 독립 라이프 사이클을 형성 할수 있는가?

3. 독립적인 스케일링 이 가능한가?

4. 독립적으로 오류 발생이 되는가?

 

SOA 와 MSA의 차이점

SOA = 재사용을 통한 비용 절감

MSA = 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응

 

service mesh

서비스간의 여러 역할을 담당하는 파트

로드밸런싱 , 서비스 검색, 프록시 , 인증 , 설정분리 등등을 모아둔 추상화이다.

 

Spring Cloud

각각의 서비스마다 설정 값이 변경되었을 때 굳이 서비스를 다시 빌드 할 필요가 없고

configuration persistence에서 설정값을 변경하면 그것을 참조하는 방식으로 운영할 수 있다.

예전 spring 버전에 존재하는 ribbon을 통해 Load Blanacing을 해줄 수 있다.