SOA VS MSA

본 포스팅은 인프런
Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)
강의를 기반으로 작성된 포스팅입니다.

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의

---

SOA와 MSA

Service Oriented Architecture

Micro Service Architecture

두가지는 서비스를 지향한다는 점에서 같다.

SOA와 MSA의 차이점

그러나 SOA에서는 서비스의 재사용을 이용한 비용 절감을 주 목적으로 하고있고

MSA에서는 서비스간의 결합도를 최소한으로 낮추는데 그 목적이 있다.

하나의 서비스와 연결되는 다른 서비스와의 관계를 줄인다는 얘기이다.

 

---

RESTful Web Service

A way to grade your API according to the constraints of REST

by Leonard Richardson - REST API의 창시자

 

성숙도 모델 3가지

REST API의 주요한 특징들을 모은것

Level0

웹 서비스를 제공하기위해 URL만 매핑해놓은 상태

Level1

외부로 공개하고자하는 리소스에 대해서 의미있고 적절한 URL로 표현하기 시작

적절한 패턴을 가지고 작성되었지만 아직까지는 HTTP의 메소드별로 서비스를

구분하여 사용하고 있지는 않다.

즉, 서비스 형태나 작업의 종류에 맞추어 적절한 HTTP 메소드를 지정하고 있지않다.

ex) 사용자의 요청을 GET, POST로 대부분 처리하고 에러를 반환한다.

 

Level2

우리가 제공하고자하는 리소스를 적절하게 용도와 상태에 따라서

HTTP Methods에 맞게 설계하고 서비스하는 단계.

만약 리소스의 상태가 읽기 용도로 사용되는 데이터라고 한다면 GET Method를 사용한다.

새로운 리소스를 추가하는 경우는 POST Method

기존 리소스의 상태를 변경하기 위해서는 PUT Method

리소스를 삭제하고자 할때에는 Delete Method를 사용하여

서비스의 상태를 표현한다.

 

RESTful Service의 DB에 저장된 리소스를 확인하고

이러한 데이터를 조작하기 위해서 CRUD와 매칭되는 HTTP Methods를 이용하여

서비스 하는것을 Level2 단계라고 한다.

 

HTTP의 메소드를 이용하여 리소스의 상태를 구분하여 서비스 하게되면

비슷한 이름의 URI라 하더라도 HTTP Method에 따라서 다른 형태의

서비스를 제공할 수 있게된다.

 

Level3

데이터를 가지고 그 다음 작업에서 어떠한 작업을 할 수 있는지

상태 정보를 함께 넘겨준다. (HATEOAS)

 

ex) 회원 가입 후 회원 정보 수정은 어떻게 해야하는지, 조회는 어떻게 해야하는지

      회원 조회를 하면서 그다음 단계로 진행할 수 있는 또다른 리소스에 대한 정보는

      어떠한것이 있는지. 이러한 모든 정보를 같이 알려주는 기능을 HATEOAS라고 한다. 

 

클라이언트 측에서는 서버가 제공하는 서비스를 일일히 찾는 수고를 겪지 않아도 되고

엔드포인트만 가지고 있으면 서버가 제공할 수 있는 다음, 그다음 URI값을 알 수 있다.

RESTful API를 설계할 때 고려해야할 사항

1. Consumer first

- 개발자 중심의 설계방식보다 해당 API를 사용 하고있는 소비자 입장에서

   간단 명료하고 직관적인 API를 설계 해야한다.

   소비자라고 하여 엔드유저가 아닌 API를 사용 하고있는 또다른 시스템,

   개발자 등을 얘기한다.

 

2. Make best use of HTTP

- HTTP Method와 Request, Response, Header와 같은

   HTTP의 장점을 최대한 살려서 개발 해야한다.

 

3. Request methods

- 최소한 성숙도 모델 Level2로는 사용하여야 한다.

 

4. Response Status

- 각각의 API 요청에 따라서 적절한 HTTP 상태코드가 전달되어야 한다.

   단순히 성공했다고 성공했다 실패했으면 실패했다가 아닌

   왜 실패하고 성공하였는지 함께 반환 시켜주어야 한다.

   ex) 2xx - 클라이언트 요청이 정상적으로 처리 되었음을 알려준다.

         4xx - 클라이언트측 오류

         5xx - 서버측 오류

 

5. No secure info in URI

- URI에는 사용자의 정보를 포함해서는 안된다.

 

6. Use plurals

- 제공하는 데이터에 대하여 단수가 아닌 복수형태로 쓰는것이 일반적이다.

   특정 유저를 찾고자 한다면 엔드포인트에 값을 추가한다.

ex) /user -> /users 

      /users/1

 

7. User nouns for resources

- 모든 리소스는 가능하면 동사가 아닌 명사형태로 표시한다.

   API URI만 보고도 어떠한 API인지 파악할 수 있는것이 좋다.

 

8. For exceptions - define a consistent approach

-  일괄적인 엔드포인트를 사용하는것이 좋다.

    진입점을 단일화 시키는것도 포함 -> API Gateway를 사용하여 처리

 

---

SOA VS MSA

두 아키텍처의 가장 큰 차이점들은

1. 서비스의 공유를 어디까지 하는가

2. 개발하는 방식에 있어서 RESTful API를 사용하는가,

    SOAP프로토콜을 사용하는 Web Service를 사용하는가

 

사진 좌측 - SOA

사진 우측 - MSA

SOA

각각의 서비스들은 ESB(Enterprise Service Bus)에 모이게되고

모여진 서비스들이 외부에 공개된다.

이러한 부분은 Web Services라는 기술을 통해 개발되고

서비스들간의 통신외에 DB에 자료를 저장하기 위해서

공통적인 DB처리 로직을 함께 사용한다.

 

MSA

서로 분리된 서비스들은 독립적으로 개발 프로세스를 가지고있다.

독립적인 언어, 비지니스 로직, UI, DB에 독립적으로 서비스를 사용

이러한 서비스는 자신의 데이터를 외부에 공개할 때 RESTful API를 사용하고

이벤트스트림 방식과같은 메세징 서비스를 이용하여

데이터 동기화를 할 수 있다.

-> 하나의 DB에 어떠한 자료가 변경된다면 이것을 Kafka로 전달하여

     Subscriber에게 전달된 데이터를 전달해준다.

 

ex) Shopping Cart, Order라는 서비스 등에서 사용자의 정보를 

       자신이 가지고 있는 DB에 업데이트 할 수 있다.

 

이런식으로 마이크로 서비스안에 저장 되어있는 다른 DB에 저장되어 있지만

메세징 서비스를 통해서 동기화 처리가 가능하다.