마이크로서비스(MSA)와 스프링 클라우드 (Spring Cloud)

Microservice란 ? 

 

antifragile

- auto scaling

- microservices

- chaos engineering

- continuous deployments 

 

 

CNA 

확장 가능한 아키텍처

- 확장된 서버로 시스템의 부하 분산, 가용성 보장

- 시스템 또는 서비스 애플리케이션 단위의 패키지(컨테이너 기반 패키지)

- 모니터링 

 

탄력적 아키텍처

- 서비스 생성-통합-배포 => CI/CI => 비즈니스 환경 변화에 대한 민첩성 향상

- 분할된 서비스 구조 

- 무상태 통신 프로토콜

- 서비스의 추가와 삭제 자동 감지

- 변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리) 

 

장애 격리

- 특정 서비스에 오류가 발생해도 다른 서비스에 영향 주지 않음 

 

 

 

CNA

특징 

- Microservices

- CI/CD

- DevOps

- Containers 

 

 

CI/CD

- 지속적인 통합, 지속적 배포

- 통합 서버, 소스 관리,빌드 도구, 테스트 도구

- Jenkins, Team CI, Travis CI

 

- 카나리 배포와 블루그린 배포 => 점진적으로 사용차 층을 새로운 버전으로 사용하도록 함 

 

DevOps

- Development + Operation + QA

 

 

Container 가상화

Traditional Deployment -> Virtualized Deployment -> Container Deployment 

 

 

 

12 Factors 

(https://12factor.net)

 

 

12가지 요소에 + 3 

+ API first

+ Telemetry

+ Authentication and authorization 

 

 

 

 

Monolithic Vs. MSA 

- Monolith : 하나의 소프트웨어 안에서 개발 

  - 모든 업무 로직이 하나의 애플리케이션 형태로 패키지 되어 서비스

  - 애플리케이션에서 사용하는 데이터가 한곳에 모여 참조되어 서비스되는 형태 

 

- MSA : 

  - Building Microservices(Orelly, Sam Newman) 

  - "Single application as a suite of small services, each running in its own process and communication with lightweight mechanisms, on an HTTP resource API..."

- "are build around business capabilities and independently deployable by fully automated deployment ..."

- "a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies..." (Martin Fowler) 

 

 

 

 

 

 

Amazon & Netflix 

 

각각 하나의 서비스에서 서로를 연결 

 

in 2002, Amazon found and CEO Jeff Bezos's email to Employees 

 

-> 회사의 resources를 사용하기 위한 방법 정의 

 

 

특징 정리 

1) challenges 

2) small well chosen deployable units

3) bounded context

4) RESTful

5) configuration management

6) cloud enabled

7) dynamic scale up and scale down

8) ci/cd 

9) visibility 

 

 

 

그렇다면 모든 것들이 microservice 여야 할까? -> no 

다음 질문을 생각해보자 

1) multiple rates of change

2) independent lif cycles

3) independent scalability

4) isolated failure

5) simplify interations with external dependencies

6) polyglot technology 

 

 

 

Microservice team structure 

- two pizza team (4 ~5) 

- teams communicating through API contracts

- develop, test and deploy each service independently

- consumer driven contract 

 

 

 

 

 

SOA

- soa : service oriented architecture => 재사용을 통한 비용 절감

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

 

 

 

 

Restful Web Service

"a way to grade your API according to the constraints of REST" (Leonard Richardson)

- LEVEL 0 :

  - expose soap web services in rest style 

  - http://server/getPosts

 

- LEVEL 1:

  - expose resources with proper uri

  - http://server/accounts

  - http://server/accounts/10

 

- LEVEL 2: 

  - level1 + HTTP Methods (POST, PUT, GET, DELETE) 

 

- LEVEL 3: 

  - level2 + HATEOAS = next possible actions 

 

 

- 개발자 중심보다는 Consumer first 

 

- make best uss of HTTP 

 

- LEVEL 2 -> proper request methods

- LEVEL 2 -> proper reponse status (200, 404, 400, 201, 101) 

  - e.g. search 요청에 대해 서버에 resource가 없으면 서버 상에서는 500이 뜨지만 이것이 서버의 문제가 맞을까? -> 서버 기능상에는 문제가 없음 -> 200을 낼 수도 있지만 404를 내려줘서 클라이언트가 찾는 것이 없다는 메시지를 전달 할 수도 

 

- no secure info in uri 

 

- USE plurals 

- USE nouns for resources 

 

 

 

 

msa 표준 구성요소 

 

 

 

Kafka를 통한 동기화 

 

각각의 서비스들은 정보를 kafka에 업데이트 해주고 그것을 누가 받는지 관심을 갖지 않아도 된다.

 

필요한 서비스들은 각각 kafka를 구독하고, 구독하는 서비스들에게 메시지가 배송되도록 한다. 

 

 

 

API 게이트웨이를 통해 클라이언트 요청을 받음

-> gateway에서 라우팅 -> 적절한 곳으로 전달 : service discovery 

-> load balancing을 통해 어디로 가야할지를 결정 

 

 

 

Service mesh 

: 아키텍처를 적용한 내부 통신 

=> 정해진 개념이라기보다는 추상적이다 

=> 설정 정보, 라우팅, 인증/인가, 로드 밸런싱 

 

 

 

CNCF 

(https://landscape.cncf.io)

 

 

 

 

 

Spring cloud 

 

- Centralized configuration management

  - Spring Cloud Config Server

 

- Location transparency

  - Naming Server 

 

- Load Distribution(Load Balancing)

  - Ribbon
  - Spring Cloud Gateway

 

- Easier Rest Clients

  - ReignClient

 

-  visibility and monitoring

  - Zipkin Distributed Tracing

  - Netflix API gateway

 

- fault Tolerance 

  - Hystrix 

 

 

---

ref. https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4