다중 테넌트 마이크로 서비스 디자인

모 놀리 식 애플리케이션을 마이크로 서비스 아키텍처로 마이그레이션하는 중입니다. 일부 규제 요건으로 인해 여러 국가의 고객 데이터를 별도의 (국가 별) 데이터베이스에 보관해야합니다. 즉 미국 고객의 경우 미국 DB, 영국 고객의 경우 영국 DB ...

고려중인 다음과 같은 디자인은 다음과 같습니다.

옵션 1 : 최대 절전 모드 다중 테넌트 지원 기능이있는 다중 테넌트 응용 프로그램 (요청에 따라 N 번으로 확장 가능) (kubernetes 포드 생각). 이 응용 프로그램의 단일 인스턴스는 모든 데이터베이스에 연결할 수 있습니다.

옵션 2 : 국가 데이터베이스 당 1 개의 마이크로 서비스 인스턴스를 배포합니다. 트래픽을 라우팅하는 API 게이트웨이

이러한 유형의 시스템을 설계하려는 경우 어떤 선택을 하시겠습니까?

microservices

— 헬로 월드
소스

특정 기능 및 비 기능 요구 사항이 무엇인지에 달려 있다고 생각합니다.

— Robert Harvey

다른 데이터베이스이지만 동일한 인스턴스가 읽고 있습니까? 그것은 규제 요건을 위반하지 않습니까?

— Jimmy T.

옵션 1이 Microservices 아키텍처 스타일과 너무 일치하지 않는 것 같습니다.

— Laiv

Kebernetes에 대해 언급했지만 컨테이너 사용 여부는 명확하지 않습니다. Docker를 사용 하여이 작업을 수행하는 경우 (예를 들어) 데이터베이스에 연결하는 앱을 만들면됩니다. 그런 다음 컨테이너를 시작할 때 매개 변수 및 / 또는 구성을 통해 연결 세부 사항을 지정하십시오. 많은 유사한 데이터베이스에 연결되는 하나의 응용 프로그램이 있으면 잠재적 인 문제 만 발생합니다. 디자인에 좋은 점은 없습니다.

— JimmyJames

답변:

옵션 2는 나쁘지 않지만 필요하지 않을 수도 있습니다. 마이크로 서비스는 여러 응용 프로그램의 요구를 처리 할 수 있도록합니다.

여기서 가장 큰 요인은 두 스키마간에 차이가 있는지, 앞으로 있을지 여부입니다.

일반적으로 리포지토리에 인터페이스를 사용하는 것이 불필요하다고 생각합니다. 그러나이 경우에는 노력할 가치가 있습니다. 리포지토리 팩토리가 중요합니다.

옵션 1의 문제는 너무 구체적이라는 것입니다. 설명 된 설정에서 각각 고유 한 DB를 쉽게 가리키는 두 개의 개별 인스턴스로 이동할 수 있어야합니다. 응용 프로그램이 데이터를 가져 오는 곳에서는 관리하지 않아야합니다.

스키마는 두 개의 서로 다른 데이터베이스마다 다르지 않지만 응용 프로그램에서 차이를 알지 않고도 하나의 리포지토리에서 두 가지를 쉽게 처리 할 수 있습니다.

public class MyEntityRepository : ISavesMyEntity, IGetsMyEntity
{
    public MyEntityRepository(string connectionString)
    {
       _connectionString = connectionString;
    }
}

public class MyEntitySaverFactory
{
    public ISavesMyEntity GetSaver(User user)
    {
        if (user.IsUK)
            return new MyEntityRepository(Config.Get("UKConnString"));
        if (user.IsUS)
            return new MyEntityRepository(Config.Get("USConnString"));
        throw new NotImplementedException();
    }
}

//USE
ISavesMyEntity saver = factory.GetSaver(currentUser);
saver.Save(myEntityInstance);

DB 스키마가 미국과 영국간에 서로 다른 경우 기능을 완전히 다른 두 저장소로 나눕니다. 공장을 변경하기 만하면되기 때문에 쉬울 것입니다.

— TheCatWhisperer
소스

왜이 공장이 필요한지 모르겠습니다. 시작시 구성 세부 정보의 경로를 전달하지 않는 이유는 무엇입니까? 이를 통해 새로운 지역 / 국가를 추가 할 때마다 코드를 수정해야합니다.

— JimmyJames

여기서 문제는 다른 국가의 사용자를 다루지 않고 다른 데이터베이스를 다루는 것입니다. 다른 스키마가있는 경우 어떻게합니까? 소비 클래스가 DB 연결 문자열을 얻을 수있는 위치를 파악해야하는 이유는 무엇입니까?

— TheCatWhisperer

무슨 말인지 모르겠어요 연결 문자열을 가져올 위치를 '피겨 링'할 책임은 코드에 없습니다. 구성입니다. 왜 이것이 QA 데이터베이스와 프로덕션 구성을 사용하는 것과 다른지 알 수 없습니다. if 문을 코드에 넣지 마십시오.

— JimmyJames

이것은 두 개의 데이터베이스와 통신하는 하나의 응용 프로그램입니다.

— TheCatWhisperer

"여러 국가의 고객 데이터를 별도의 (국가 별) 데이터베이스에 보관해야합니다"단일 응용 프로그램 "인스턴스"가 두 데이터베이스와 통신하는 데 필요한 것은 아닙니다. 나는 그것이 단지 두 개의 DB인지 의심합니다. OP는 아마 "ie"를 입력했을 때 "eg"를 의미했을 것입니다

— JimmyJames

두 번째 옵션을 사용하면 개발 및 배포시 마찰이 줄어 듭니다.

이렇게하면 전 세계에서 하나 이상이 아닌 지역 당 1 개 (또는 하나 이상의) 인스턴스에 앱을 배포 할 때 확장 성과 가용성이 향상되고 다운 타임이없는 배포 옵션이 향상됩니다.

요구 사항이 변경되면 더 많은 지역별 비즈니스 로직과 데이터 변경 사항이있을 수 있으므로 코드와 지역별로 데이터를 분할하려고 시도하고 지역별 비즈니스 로직을 공유하지 마십시오 (일부 핵심 코드를 공유하게 될 수 있음).

말이 되나요?

— 션 파머
소스