멀티 테넌트 중간 계층 아키텍처

Question

우리는 기존 비즈니스 로직/데이터 액세스 계층을 대체 할 "중간 계층"을 개발 중입니다. 우리가 직면 한 디자인 문제 중 하나는 여러 고객의 데이터베이스 및/또는 중간 계층 조각이 호스팅 된 제품의 일부인 동일한 서버에 존재할 수 있도록 설계해야한다는 것입니다. 호스트 된 환경을위한 데이터베이스 스키마와 설정은 이미 생산 단계에 있기 때문에이 시점에서 상당히 정교하게 설정됩니다. 기본적으로 호스팅 된 환경의 특정 DB 서버에서 각 고객은 고유 고객 ID를 사용하여 이름이 지정된 SQL Server 인스턴스를 갖습니다.

웹 서비스, 비즈니스 로직 및 각 고객의 데이터베이스에 대한 데이터 액세스를 통해 클라이언트 응용 프로그램에서 개별 경로를 가질 것인지 여부를 결정하려고하거나 단일 공유 인스턴스 각 조각의 데이터 액세스 계층은 올바른 SQL Server 인스턴스 또는 그 둘 사이의 데이터를 가져 오는 역할을 담당합니다. 모든 것을위한 단일 공유 경로를 사용하면 하나의 조각이 떨어지면 모든 클라이언트가 액세스하므로 모든 물에 잠겨 있습니다. 다른 한편, 각 고객에 대한 개별 경로가 있으면 과장되어있을뿐만 아니라 유지 관리가 더 필요하십니까?

[Client]--|                |--[DB] 
[Client]--|                |--[DB] 
      |--> [Web Service] --> [Business Logic] --> [Data Access] ----| 
[Client]--|                |--[DB] 
[Client]--|                |--[DB] 

또는이 : (옵션 사이에서 - 또는 무엇) 다음의

[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB] 
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB] 
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB] 
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB] 

하나 더 이유가 될 것입니다 여기에 끔찍한 ASCII 아트 우리가 고려하고있는 두 가지 옵션 중 사진입니까?

Answer 1

이것은 매우 일반적인 질문이므로, 일반적인 대답을하겠습니다. 나는 과거에 유사한 원칙에 플랫폼을 구축했습니다 내가 당신을 줄 수있는 유일한 충고는 2 층으로 구조를 분할에 대해 신중하게 생각하는 것입니다 : 모든 일반적인, 일반적인 작업을 처리

• ㅇ 완전히 일반적인 프레임 워크
• 비정상적인 클라이언트 특정 기능을 포함 할 수있는 사용자 정의 가능한 특정 고객 계층.

많은 고객이 일반 프레임 워크만으로 작동 할 수도 있지만 고객이 일부 주문에 대해 대가를 치러야하는 경우 일반 레이어로 확장하거나 오히려 수정하여 수용 할 수 있습니다. .

일반적으로 우리는 꽤 일반적인 기술 (고객의 프로세싱 '파이프 라인'을 정의하는 구성 파일, 고객 어셈블리의 동적로드, 인터페이스의 풍부한 사용, 제네릭 허용 등)을 통해 이러한 종류의 확장 성과 특수화 된 동작과의 결합을 처리했습니다. 런타임에 표준 구현 또는 고객 특정 구현에 작업을 위임하는 구성 요소 등이 있습니다.

희망이 있습니다.