스케일링 모놀리스 및 스케일링 마이크로 서비스

마이크로 서비스 사용에 대한 일반적인 논거 중 하나는 더 나은 확장 성입니다. 그러나이 주장이 실제로 유효한지 궁금합니다.

10 개의 마이크로 서비스로 구성된 애플리케이션이 있고 그 중 9 개는 각 2 개의 인스턴스 (중복 용)를 가지고 있고 그 중 하나는 4 개의 인스턴스를 사용하여로드 (확장 성)를 처리한다고 가정 해 보겠습니다. pro-microservice의 주장은이 서비스를 다른 서비스와 독립적으로 확장 할 수 있다는 것입니다.

그러나 10 개의 마이크로 서비스가 모두 단일 모놀리스의 모듈이고이 모놀리스의 여러 인스턴스 (예 : 위에서 합계와 같은 22 개)가 배포되었다고 가정 해 보겠습니다. 인스턴스가 충분하기 때문에 시스템은 중요한 부분 하나의로드를 처리 할 수 ​​있어야합니다. 인스턴스에 프로그램 논리가 필요하지 않은 경우 유일한 단점은 이진 및 필요한 RAM의 양이 약간 더 크다는 것입니다. 그러나 다시 말하지만, 대부분의 경우 그 차이는 너무 크지 않아야합니다. 적어도 스택의 나머지 부분 (스프링 부트 생각)과 비교해서는 안됩니다. 확장 된 monlith의 장점은 분산 시스템의 오류가없는 간단한 시스템 일 것입니다.

뭔가 빠졌습니까?

마이크로 서비스의 요점은 프로세서로드를 줄이는 것이 아닙니다. 사실, 통신의 오버 헤드와 전역 유틸리티 코드였던 기능의 반복으로 인해 일반적으로 프로세서로드가 다소 증가 합니다.

단일체를 폐지하는 시점은 복잡한 기능 시스템을 전혀 유지, 배치 및 실행할 수있는 것보다 훨씬 더 큽니다 . 시스템이 특정 크기, 컴파일, 테스트, 배포 등에 도달하면 적절한 가동 시간을 유지하면서 단일체를 구현하기에는 너무 비싸게됩니다. 마이크로 서비스를 사용하면 시스템 단편을 업그레이드, 재시작 또는 롤백 할 수 있습니다.

우리는 마이크로 인터페이스를 작성하지 않습니다. 마이크로 인터페이스 는 본질적으로 원격 인터페이스를 통해 느슨하게 연결 하는 더 나은 솔루션 이기 때문 입니다. 실제로, 모놀리스가 제공 할 수있는 강력한 유형 및 일관성 검사의 손실은 종종 주요 단점입니다. 때문에 우리는 그것을 우리가 가지고 복잡성이 더 나은 우리 얻었다 때문에, 그리고 최적의 상황에 최선을 다하고 있습니다.

당신은 대부분 맞습니다. 균등하게로드 된 빠른 서비스가있는 경우 모든 상자에 모두 설치할 수 있습니다. 서비스 당 상자를 갖는 것만 큼 좋지는 않지만 돈을 절약합니다.

하나. 불균형이 발생하자마자 서비스 5가 2 분 동안 CPU의 100 %를 차지한다고 가정하면 해당 서비스를 자체 상자로 이동하여 다른 서비스가 실행될 경우 모든 서비스를 차단하지 않기를 원합니다.

로드로 인해 서비스 호출이 시간 초과되면 앱의 일부 기능 만 대신 실패합니다.

이제 잘 모듈화 된 모 놀리스로 동일한 작업을 수행 할 수 있습니다. 모든 서비스를 설치하되 서비스 5 트래픽 만 그 중 하나에 라우팅하십시오. 서비스 5 트래픽을 다른 상자로 라우팅하지 않는 동안.

그러나 일반적으로 모놀리스는 본질적으로 같은 상자에 설치되는 느슨한 서비스 모음이 아닙니다. 모듈간에 메모리 호출이 발생하여 앱이 실패 할 수 있습니다.

마이크로 서비스의 요점은 1) 관심사 분리 및 2)로드 분배입니다. 본질적으로 이것은 우리가 그 일에 특화된 기술로 우리가 할 수있는 최고의 블랙 박스 서비스를 만들 수있게 해줍니다. 우리의 서비스는 여러 스택에서 다른 프로그래밍 언어로 작성된 폴리 글로 트일 수 있습니다. 다른 팀은 API 계약 이외의 다른 팀이 어떻게 작동하는지에 대한 지식없이 각 서비스에서 작업 할 수 있습니다. 이것은 전체적으로 취해 져서 각 서비스에 대해 훨씬 간단한 코드 기반을 허용하므로 성능을 디버그, 이해 및 조정하기가 더 쉽습니다.