4. Service Gateway

 

AS-IS	TO-BE

지금은 Client(Angular app)에서 접근하는 서비스가 AuthService 하나지만, 비즈니스가 추가되면 Service가 100개 이상이 될 수도 있습니다. 따라서 Client는 모든 Service의 도메인을 알아야 한다는 불편함이 있습니다.

이를 보완하기 위해 일반적으로 Api Gateway를 이용합니다. 여기서는 Api Gateway를 지원하는 여러 라이브러리 중 Netflix의 zuul을 사용하기로 결정했습니다. zuul은 Websocket을 지원하지 않기 때문에 NotiService에 대한 요청은 그대로 두고, AuthService와 UserService에 대한 요청만 게이트웨이를 타도록 변경했습니다.

 

1. API Gateway Service

앵귤러에서 들어오는 모든 요청은 앞으로 gateway service를 거치게 됩니다. gateway service는 어플리케이션이 뜰 때 config server에서 게이트웨이 정보를 가져오게 됩니다. 마찬가지로 config server는 뜰 때 깃에서 정보를 읽어오게 됩니다. 

 

[gateway.properties]

zuul.routes.userservice.url=http://localhost:8081
zuul.routes.authservice.url=http://localhost:8082

위 깃의 정보는 zuul.routes의 정보로 url이 userservice가 들어오면 http://localhost:8081로, authservice가 들어오면 http://localhost:8082로 변경하여 연결해 주겠다는 뜻입니다.

 

앵귤러 어플리케이션은 앞으로 

 

[user.service.ts]

login(user: User): Observable<User> {
    return this.http.post<User>(`${environment.AUTH_API_URL}login`, user);
}
 
updateProfile(user: User) {
    return this.http.put(`${environment.AUTH_API_URL}update`, user);
}
 
logout(user: User): Observable<User> {
    return this.http.post<User>(`${environment.AUTH_API_URL}logout`, user);
}

와 같이 요청을 보내게 될 것이며, environment는 다음과 같습니다. 

 

[environment.ts]

export const environment = {
  production: false,
  AUTH_API_URL: 'http://localhost:8083/authservice/',
  USER_API_URL: 'http://localhost:8083/userservice/'
};

http://localhost:8083/authservice/login은 게이트웨이 서비스에 의해 http://localhost:8082/login으로 변경되어 요청됩니다.

---

2. Actuator

스프링 클라우드에는 Actuator가 내장되어 있으므로, api gateway 서버를 띄우고 ~/actuator로 접근하면 게이트웨이 서버의 상태에 대한 정보를 볼 수 있습니다. 각각 원하는 정보에 대한 url 정보가 나와 있어 링크로 접근이 가능하며, /acturator/refresh로 접근하면, 게이트웨이 서비스가 config server에 다시 게이트웨이 정보를 요청하게 되고, 요청을 받은 config server는 다시 한번 깃에서 게이트웨이 정보를 가져와 응답하게 됩니다. 

 

깃의 게이트웨이 정보가 변경될 경우 곧바로 동기화되도록 설정하기 위해 spring cloud bus라는 것을 사용하게 되는데, bus는 github에 webhook을 걸어서 동작하게 됩니다. 그런데 현재 프로젝트는 gitlab으로 구성되어 있으며, gitlab의 경우 webhook 기능은 유료버전에서만 사용이 가능하므로 현재는 사용하지 않겠습니다.