마이크로 서비스 및 데이터 스토리지

모 놀리 식 REST API를 마이크로 서비스 아키텍처로 옮기는 것을 고려 중이며 데이터 스토리지에 대해 약간 혼란스러워지고 있습니다. 내가 본 것처럼 마이크로 서비스의 장점은 다음과 같습니다.

• 수평 확장 가능-로드 및 / 또는 서버 다운에 대처하기 위해 여러 개의 중복 마이크로 서비스 사본을 실행할 수 있습니다.
• 느슨하게 결합-다른 것을 변경하지 않고도 마이크로 서비스의 내부 구현을 변경할 수 있으며 독립적으로 배포하고 변경할 수 있습니다 ...

내 문제는 데이터 저장에 관한 것입니다. 내가 본 것처럼 몇 가지 옵션이 있습니다.

1. 모든 마이크로 서비스가 공유하는 단일 데이터베이스 서비스-느슨한 커플 링의 이점을 완전히 없애는 것 같습니다.
2. 각 마이크로 서비스에 로컬로 설치된 데이터베이스 인스턴스-수평 적으로 확장하는 방법을 볼 수 없으므로 옵션이라고 생각하지 않습니다.
3. 각 마이크로 서비스에는 자체 데이터베이스 서비스가 있습니다.이 방법은 느슨한 커플 링 및 수평 확장의 이점 (중복 데이터베이스 사본 및 / 또는 샤딩 사용)을 유지하므로 가장 유망한 것으로 보입니다.

나에게 세 번째 옵션은 유일한 옵션 인 것처럼 보이지만 엄청나게 무겁고 지나치게 과도하게 설계된 솔루션입니다. 내가 올바르게 이해하고 있다면 4-5 개의 마이크로 서비스가있는 간단한 응용 프로그램의 경우 마이크로 서버 당 2 개의 실제 마이크로 서비스 인스턴스 (서버 장애의 경우 및 다운 타임없이 배포)와 같은 16-20 개의 서버를 실행해야합니다. 마이크로 서비스 당 2 개의 데이터베이스 서비스 인스턴스 (서버 장애 등의 경우)

솔직히 말해서 이것은 약간 어리석은 것처럼 보입니다. 실제 프로젝트는 아마도 4-5 개 이상의 서비스를 가질 것이라는 점을 염두에두고 간단한 API를 실행하는 16-20 대의 서버? 내가 누락 된 기본 개념이 있습니까?

응답하는 동안 도움이 될만한 것들 :

• 저는이 프로젝트의 유일한 개발자이며 가까운 미래에있을 것입니다.
• Node.js와 MongoDB를 사용하고 있지만 언어에 구애받지 않는 답변에 관심이 있습니다. 잘못된 기술을 사용하고있을 수도 있습니다.

세 가지 옵션 중 첫 번째 (단일 공유 데이터베이스)와 세 번째 ( "데이터베이스 서비스")가 가장 일반적입니다.

첫 번째는 통합 데이터베이스 라고 합니다 . 이것은 일반적으로 마이크로 서비스 아키텍처에서 좋은 솔루션으로 보이지 않습니다. 서비스에 커플 링을 추가합니다. 또한 한 서비스가 다른 서비스를 우회하고 데이터베이스에 직접 쿼리하기가 매우 쉽습니다. 데이터베이스 수준에서 적용되지 않은 응용 프로그램 수준에서 제공하는 모든 종류의 데이터 무결성 또는 유효성 검사를 잃을 수 있습니다.

세 번째 아이디어는 호출 응용 프로그램 데이터베이스 . 서비스가 API 수준에서 느슨하게 연결되도록하고 데이터베이스 수준에서 서비스를보다 쉽게 ​​확장 할 수 있습니다. 또한 각 서비스의 기술 또는 기타 구현 세부 사항을 변경할 수있는 것처럼 기본 데이터베이스 기술을 각 서비스에 적합한 것으로 쉽게 대체 할 수 있습니다. 매우 유연합니다.

그러나 중간 솔루션을 제안합니다.

모든 마이크로 서비스에 대한 데이터베이스 서비스를 세우는 대신 모든 서비스에 대한 스키마를 세우십시오. 여러 데이터베이스 기술을 사용하는 경우 약간 다르게 분할해야하지만 아이디어는 실행중인 데이터베이스 서버 수를 최소화하는 것이지만 서비스를 자체 데이터베이스 서버로 매우 쉽게 분할 할 수 있도록하는 것입니다. 필요할 때. 데이터베이스가 자체 스키마에만 액세스하도록 허용하는 한 응용 프로그램 데이터베이스의 장점은 있지만 모든 응용 프로그램이나 서비스에 대해 존재하는 데이터베이스 서버의 오버 헤드는 없습니다.

그러나 솔로 개발자 인 저는이 시점에서 마이크로 서비스의 모든 개념에 도전 할 것입니다. Martin Fowler는 Monolith First 와 Microservice Premium 에 대해 쓰고 Simon Brown은 모듈 식 monoliths 에 대해 이야기하고 DHH는 Majestic Monolith에 대해 이야기합니다. 모노리스가 얼마나 잘 구성되어 있는지 잘 모르겠지만 리팩토링하고 구성하십시오. 부품을 쉽게 서비스로 추출하기 위해 구성 요소를 식별하고 구성 요소를 깔끔하게 분리하십시오. 데이터베이스 구조도 마찬가지입니다. 서비스로의 리팩토링을 지원할 수있는 우수하고 깨끗한 컴포넌트 기반 아키텍처에 집중하십시오. 마이크로 서비스는 단일 개발자가 운영을 구축하고 지원하기 위해 많은 오버 헤드를 추가합니다. 그러나 실제로 시스템의 일부를 확장해야하는 경우 모니터링 및보고 시스템을 사용하여 병목 현상을 식별하고 서비스로 추출하고 필요에 따라 확장하십시오.

각 마이크로 서비스에는 자체 데이터베이스 서비스가 있습니다.이 방법은 느슨한 커플 링 및 수평 확장의 이점 (중복 데이터베이스 사본 및 / 또는 샤딩 사용)을 유지하므로 가장 유망한 것으로 보입니다.

동의하다. 세 번째 옵션은 마이크로 서비스에 대한 자연 선택입니다. 마이크로 서비스가 실제로 독립되어 있고 ( 분산 된 단일체의 일부가 아닌 ) 데이터베이스가있는 것이 정상입니다.

[...] 마이크로 서비스 당 2 개의 실제 마이크로 서비스 인스턴스 (서버 장애의 경우 및 다운 타임없이 배치) 및 마이크로 서비스 당 2 개의 데이터베이스 서비스 인스턴스 (서버 장애의 경우 등).

로드 밸런싱을 원한다면 실행중인 마이크로 서비스의 수량에 대한 권리입니다. 4 개의 마이크로 서비스를 계획중인 경우 이미 설명한대로 각 마이크로 서비스의 인스턴스를 2 개 이상 (총 8 개) 준비해야합니다.

그러나 마이크로 서비스 당 두 개의 데이터베이스? 이것은 정말로 의심 스럽다. 마이크로 서비스가 수반하는 비즈니스 문제에 대한 세부 정보는 알지 못하지만 데이터베이스 중복성이있어 대부분의 제품 / 프로젝트에 매우 적합합니다. 적절한 백업을 통해 하나의 단일 데이터베이스로 시작하고 인프라의 복잡성을 최소화하는 것이 좋습니다 (적어도 초기에는).

솔직히 말해서 이것은 약간 어리석은 것처럼 보입니다. 실제 프로젝트는 아마도 4-5 개 이상의 서비스를 가질 것이라는 점을 염두에두고 간단한 API를 실행하는 16-20 대의 서버? 내가 누락 된 기본 개념이 있습니까?

A에 대한 간단한 API이 번호가 일치하지. "Microservice First" 트랩 중 하나에 속하지 않는 경우주의하십시오 .

마이크로 서비스는 극도로 서비스 지향 아키텍처의 한 형태입니다. 이들의 일반적인 목적은 커플 링을 줄이고 독립적 인 개발 및 배포를 허용하는 것입니다.

아키텍처 용어로 말하면, 마이크로 서비스는 논리적 수준에서 적용되는 용어입니다. 마이크로 서비스는 논리적으로 서로 분리되어 있습니다. 이러한 관점에서, 마이크로 서비스는 각자 소유하고 자신의 스토리지를 제공해야하며, 이는 다른 마이크로 서비스의 스토리지와 분리되어야합니다. 마이크로 서비스의 경우, 이러한 스토리지 독립성은 모듈 성과 느슨한 결합의 목표에 중요합니다.

아키텍처 관점에서 가로 스케일링은 실제 레벨에서 구현에 더 가까운 낮은 레벨에서 적용됩니다. 이 수준에서는 마이크로 서비스를 구현하고 있으며이 단일 마이크로 서비스를 내부적으로 수평 확장 가능한 상태 비 저장 구성 요소와 모든 비 상태 구성 요소가 공유하는 상태 저장 구성 요소로 분해 할 수 있습니다.  그러나 상태 비 저장 부분 만 마이크로 서비스 자체와 혼동하지 마십시오.

따라서 개별 마이크로 서비스에 대해 이야기 할 때 API와 분리 된 책임 및 분리 된 개발 / 배포주기에 대해 논리적으로 이야기합니다. 또한 수평 적 확장에 대해 이야기 할 때 물리적 수준에서 (단일) 마이크로 서비스 구현 및 상태 비 저장 및 상태 저장 구성 요소로의 분해에 대해 이야기합니다.

여러 마이크로 서비스를 구현할 때 상태 저장 구성 요소에 데이터베이스 기술을 재사용 할 수 있습니다.

• 마이크로 서비스 당 별도의 데이터베이스
• 공유 데이터베이스 :
  • 마이크로 서비스 당 개별 / 개인 스키마
  • 마이크로 서비스 당 별도 / 개인 테이블

자세한 내용은 여기를 참조 하십시오 .

모든 마이크로 서비스가 공유하는 단일 데이터베이스 서비스-느슨한 커플 링의 이점을 완전히 없애는 것 같습니다.

동의하면 테이블 행과 열을 공유하는 것이 실제로 마이크로 서비스가 아닐 것입니다.

우리의 사고 과정에서 마이크로 서비스의 논리적 개념을 마이크로 서비스의 상태 저장 및 무 상태 구성 요소의 물리적 개념에서 분리 할 수 ​​있다면, 마이크로 서비스가 제공하는 느슨한 결합을 달성하는 동시에 공유의 효율성을 유지하는 것이 더 쉽다는 것을 알 수 있습니다 데이터베이스.

일반적으로, microservices 및 상태 지속성에 대해 최대 기록 공정한 금액이있다, 또한 참조 여기에 .

글쎄, 나는이 스레드의 모든 게시물을 읽었으며 질문과 혼동된다고 말할 수 있습니다 : 마이크로 서비스 (MS)와 서비스를 데이터 액세스 서비스 (DB 서비스)와 데이터베이스 및 서버와 혼합합니다 ...

MS가 상태없는 방식으로 가장 간단한 작업 하나를 해결하는 독립적 (배포 가능) 구성 요소 인 경우 어떤 데이터베이스가 필요합니까? 가장 복잡한 하위 작업 (MS?)을 함께 해결해야하는보다 복잡한 작업을 해결하려면 여전히 MS입니까? SOA에서는이를 Orchestrating Service라고합니다. "프로세스"를 구현하고 MS 호출을 조정하므로 상태를 유지해야하며 (모든 오케스트레이션 / 주최자 / 작곡가 등은 상태 저장) 개인 데이터 저장소가 필요합니다.

그러나 우리는 데이터베이스가 아니라 데이터베이스 액세스 MS / 서비스에 대해 이야기합니다. 이것은 완전히 다른 문제입니다. MS는 회사 내에서 수집 된 일부 데이터 (내부에서 작동하는 애플리케이션이 아님)가 필요할 수 있으며 API / 인터페이스를 통해 다른 MS에 데이터를 요청할 수 없습니다. 가장 일반적이고 현실적인 시나리오입니다. 동일하거나 다른 응용 프로그램의 다른 MS가이 데이터를 필요로하거나 변경하기도합니다. 그렇습니다. 그들은 MS가 등장하기 전과 마찬가지로 데이터를 놓고 경쟁합니다.

왜 우리는 잘 알려져 있고 개방 된 '문'을 추락합니까? MS와 일반 자체 지속 객체 간의 차이점은 무엇입니까? 융통성과 구성 성을 위해 MS가 데이터 액세스 서비스 (DAS)에 접속해야한다면 MS에 대한 개별 데이터베이스가 필요한 이유는 무엇입니까? DAS는 데이터베이스에 대한 물리적 연결에 대한 인식으로부터 비즈니스 작업으로 MS를 보호합니다. 이러한 느슨한 결합과 유연성으로 인해 MS는 데이터베이스 앵커없이 여러 응용 프로그램에 자유롭게 참여할 수 있습니다.