Page History
| Info |
|---|
RestAPI는 단순하고 작성하기 쉽습니다. 하지만 미들웨어 고성능통신 또는 미들웨어 분산 마이크로 서비스 구축시 RestAPI 로만은 분명 성능적한계,구현적 한계가 있습니다. RestAPI는 모든 서비스를 만드는 강력한 방법이고 유일한 방법이다란 굳은 믿음을 가지고 있으면서 Redis를 중간에 부적절하게 사용하고, RabbitMQ/KafKA등 연결해서 사용하는것을 봐왔습니다. 외부 통신툴킷 사용에 있어서 문제제기하는것이 아니며 이것의 본질적인 문제 아래 두가지에대한 고민입니다.
우리의 목표는 다양한 메시지 모델처리를 위해 n개의 서비스를 뛰우는것이 아닌 1개의 서비스로으로도 가능하고 , 필요하면 확장하는 전략을 선택할것입니다. 그것을 위해 앞으로 구현해야할 메시지 전송모델 몇개를 간략하게 소개합니다. |
RestFul
일반적으로 웹서비스에 많이 사용하는 Rest방식입니다. 어떠한 웹브라우져또는 외부 고객에게
Rest-API를 통해 서비스를 제공하는것은 가장 무난하고 일반적입니다.
하지만 실시간통신및, 내부서비스의 상태를 고성능으로 처리하기위해서는 REST는 성능적으로 한계가 있습니다.
HTTP 프로토콜을 사용하는 REST는 일반적으로 매 요청마다 새로운 커넥션을 요구하고 끊어버리기 때문에
단순하게 초당 천개의 메시지를 전송하는 시나리오에서, 다수의 커넥션을 맺는데 모든 리소스를 다 사용할것입니다.
Rest vs Websocket 수행시간
Rest의 수행속도가 메시지가 증가함에 따라, 기울기가 급격해지는 성능저하를
볼수가 있습니다. 이것은 Rest의 수행속도에 한계가 있음을 의미합니다.
Server/Client VS PeerToPeer
...
대부부분의 요청 트래픽은 중앙 서버에 집중이됩니다.
AKKA의 Remote Router로 구현가능합니다.
PeerToPeer방식은 각 노드의 요소들이 서로연결하여 필요한 데이터를 룰에의해 주고 받습니다.
분산처리가 되지만, 중앙서버 방식보다 구현방법이 더 복잡해집니다.
AKKA의 클러스터 액터는 이러한 피어투피어방식을 단순하게 사용할수 있는 툴을 제공해줍니다.
PUB/SUB
아주 직관적이고 간단한 메시지전송 모델이기떄문에 여러 통신가능한 라이브러리 혹은 툴킷에서 많이 도입되었습니다.
...