다중 테넌트 시스템에서 확장 성을 어떻게 관리합니까?

나는 지금 몇 가지 큰 웹 기반 멀티 테넌트 제품을 가지고 있으며, 곧 테넌트별로 많은 사용자 정의가 있음을 알 수 있습니다.

여기 또는 거기에 추가 필드, 워크 플로 중간에 추가 페이지 또는 추가 논리가있을 수 있습니다.

이러한 사용자 정의 중 일부는 핵심 제품에 적용 할 수 있으며 훌륭합니다. 그들 중 일부는 매우 구체적이며 다른 사람의 방식으로 얻을 것입니다.

나는 이것을 관리하기위한 몇 가지 아이디어를 염두에두고 있지만 그중 어느 것도 제대로 확장되지 않는 것 같습니다. 확실한 해결책은 수많은 클라이언트 레벨 설정을 도입하여 클라이언트별로 다양한 '기능'을 활성화하는 것입니다. 물론 단점은 엄청난 복잡성과 혼란입니다. 정말 많은 수의 설정을 도입 할 수 있으며 시간이 지남에 따라 다양한 유형의 논리 (프레젠테이션, 비즈니스)가 제대로 작동하지 않을 수 있습니다. 그런 다음 클라이언트 특정 필드의 문제가 있는데, 이는 기존 테이블에 nullable 필드를 추가하는 것보다 더 깨끗한 것을 요구합니다.

그래서 사람들은 이것을 관리하기 위해 무엇을하고 있습니까? Force.com은 확장 성의 마스터 인 것 같습니다. 분명히 그들은 처음부터 확장 가능한 플랫폼을 만들었습니다. 웹 기반 UI로 거의 모든 것을 추가 할 수 있습니다. FogBugz는 비슷한 플러그인 모델을 만들었습니다. 강력한 플러그인 모델은 실제로 Force에서 영감을 얻은 것으로 생각됩니다. 나는 그들이 많은 시간과 돈을 썼다는 것을 알고있다. 만일 내가 실수하지 않는다면, 의도는 미래의 제품 개발을 위해 실제로 그것을 내부적으로 사용하는 것이었다.

내가 만들고 싶은 유혹을 받았지만 그렇게해서는 안 될 것 같은 소리. :)

플러그 형 아키텍처에 대한 막대한 투자가 유일한 방법입니까? 이러한 문제를 어떻게 관리하고 있으며 어떤 결과를보고 있습니까?

편집 : FogBugz는 상당히 견고한 플랫폼을 구축하고 화면을 구성하는 데 사용하여 문제를 처리 한 것처럼 보입니다. 이를 확장하기 위해 ISearchScreenGridColumn과 같은 인터페이스를 구현하는 클래스를 포함하는 DLL을 작성하면 모듈이됩니다. 나는 그들이 많은 개발자를 가지고 몇 달 동안 일한 것을 고려할 때 빌드하는 데 막대한 비용이들 것이라고 확신합니다. 또한 표면적은 아마도 내 응용 프로그램 크기의 5 % 일 것입니다.

지금 Force.com이이 문제를 처리하는 올바른 방법인지 궁금합니다. 그리고 저는 하드 코어 ASP.Net 녀석입니다.

나는 비슷한 문제에 직면했고, 그것을 해결하는 방법을 알려줄 것입니다.

1. 먼저 "핵심"라이브러리 또는 엔진이 있습니다. 이것은 이미 이해 한 것처럼 기본적으로 쇼를 실행합니다. 동적, 사용자 및 계정 관리, 역할, 이름 지정 등 모든 시스템에 공통적 인 사항을 처리합니다.

2. 시스템의 모든 부분은 모듈 내에 포함되어 있습니다. 모듈에는 종속성 (의존하는 다른 모듈)이 있습니다. 예를 들어 "핵심"시스템에는 보안 (사용자, 그룹, 역할, 비밀번호 정책), 로케일 (번역, 국가, 문화), 파일 저장소, 이메일 등이 있습니다. 각 모듈은 xml 파일을 사용하여 자체를 정의합니다. xml 파일은 기본적으로 스키마, 테이블, 계산 클래스, 화면 정의 등을 지정합니다. 이것은 파일 날짜가 변경된 경우 응용 프로그램이 시작될 때 읽 힙니다 .

3. 고객 별 모듈에는 고유 한 xml 파일과 고유 한 DLL이 있습니다. 그것은 나머지 시스템과 함께 그에 따라 투명하게 작동합니다. 기존 MVC보기를 사용자 정의 코드 및 사용자 정의보기 모델을 사용하여 사용자 정의보기로 대체 할 수 있습니다.

4. 고객이 기존 기능을 확장하려는 경우 xml / system은 한 모듈을 다른 모듈에서 "파생"할 수있는 방법을 제공합니다. 새 모듈에는 기존 기능이 모두 있지만 새 DLL에 대한 고객의 특정 요구 사항과 수정이 가능한 확장 XML 파일이 있습니다. 주의 사항은 실제로이 시스템의 기존 필드를 제거 할 수 없지만 확장하여 완전히 새로운 객체와 기능을 제공 할 수 있다는 것입니다.

관리 할 버전 관리 로직과 코드 계층이 많더라도 웹 앱 / 사이트에 가치가 추가되지 않습니다. 또한 무슨 일이 일어나고 있는지 이해하고 더 많은 두뇌 능력이 필요합니다.

나는 다르게 조언합니다. 복잡한 것보다 단순하게 유지하는 것이 좋습니다.

모든 사람에게 동일한 단일 코드 기반을 유지하십시오. 추가 한 모든 기능은 모두를위한 기능입니다. 기능이 아닌 항목 또는 스토리지 수 또는 수량화 가능한 항목의 수만 제한하십시오. 그 이유는 스토리지, 데이터 항목 수 등과 같은 것들을 정량화하기 때문에 프로그래밍하기가 매우 간단하며 사용자가 앱에서 크게 돈을 버는 것을 제한하는 소수의 것들에만 적용될 수 있습니다. 기능 로직을 수행하는 대신 항목을 추가 할 때만 프로그래밍하면됩니다. 기능이 다른 기능에 묶여 있으면 어떻게됩니까? 이것을 코딩하는 것은 매우 복잡해진다.

답변을 받기 위해 많은 고객에게 제공되는 전자 상거래 프레임 워크를 구축했으며 모든 특성을 유지하려는 어려운 방법을 배웠습니다. 결국 체인을 깨고 전자 상거래를위한 멀티 테넌트 인 단일 관리 웹 사이트를 만들었습니다. 그런 다음 웹 서비스 호출에서 데이터를 가져 오는 웹 사이트가 있습니다. 이를 통해 각기 다른 기술 팀이 전자 상거래 사이트에 대해 특정 기능을 구현할 수 있으며, 동일한 인프라에서 매달 요금을 계속 지불하고 있으며 그들이하는 일에 신경 쓰지 않습니다. 기능이 아니라 숫자로 사용량을 제한합니다. 훨씬 쉬워요. 고객은 자신의 공급 업체를 선택하여 웹 사이트를 구축 할 수 있으며 더 이상 이러한 결정에 관여하지 않습니다.

컨텐츠 관리 SAAS에 대한 서브 스크립 션 서비스도 있습니다. 이것은 사용 계층별로도 작동하며 고객이 원하는 경우 팀에서 더 많은 기능을 추가하도록하는 동안 고객이 원하는 경우 자체 플러그인을 추가 할 수 있습니다.

이것은 오랫동안 머리를 벽에 부딪 히고 더 간단한 무언가에 걸려 넘어진 경험입니다.

어떤 것이 항상 각 고객에 따라 달라지는 경우에는 프레임 워크를 만들지 마십시오. 프레임 워크 부분이 모두를 위해 작동하도록 가장 간단한 부분으로 나누고 나머지 부분을 잘라내어 개인을 위해 확장하십시오.

내가 작업하는 소프트웨어 제품에는 사용자 확장 성을위한 추가 필드가 있습니다. 이러한 필드에 대한 각 데이터 항목은 응용 프로그램의 기본 테이블에있는 기존 행에 입력 할 수 있습니다. 예를 들어 소프트웨어에 고객과 각 고객이 주문 목록을 포함하는 경우 사용자 정의 가능한 데이터 테이블에는 고객 테이블과 주문 테이블에 대한 외래 키 열이 있으며 그 중 하나만 null이 아닙니다. 하나 또는 여러 개의 테이블 각각에 하나의 테이블에 대한 사용자 정의 필드가 있습니다.

이는 사용자를 위해 추가 데이터를 저장하는 간단하고 성능이 좋은 방법입니다. 이 필드의 이름과 유형에 대한 추가 정보를 저장해야합니다.

여기에는 고객의 사용자 정의 필드가 포함됩니다. 사용자 지정 동작의 경우 웹 서비스 API는 확장을 허용합니다.

1) 자신의 박스에서 다른 사람의 코드를 실행하는 것은 매우 어려운 문제입니다. 당신이 그것들을 믿을 수 있거나 책임을 합리적으로 연기 할 수 있다면, 코드를 매우 많이 샌드 박스해야하고 평균 이상의 보안에 헌신해야합니다. 플러그인 시스템이 더 많은 기능을 허용함에 따라 보안을 유지하기가 더 어려워집니다. 서비스 거부 (플러그인이 너무 많은 리소스를 소비 함), 정보 유출 (플러그인이 다른 테넌트의 데이터에 액세스 할 수 있음) 등과 같은 것은 매우 현실적이고 귀찮을 수 있습니다. 사람들에게 매우 친숙해질 수 없다면 이것에 참여하지 않을 것입니다. 이러한 문제 또는 시간이 많이있는 유능한 사람들이 올바르게 해결할 수 있습니다.

2) 그렇습니다. 모듈 성과 사용자 정의가 어렵습니다. 전략 패턴과 같은 것들이 도움이 될 수 있습니다 (함수 포인터의 멋진 이름; Java에서는 일반적으로 클래스의 사용자가 코드의 동작을 사용자 정의하기 위해 구현할 수있는 인터페이스를 선언하여 구현됩니다).하지만 매우 분리되고 분리되어야합니다. 이 코드가 작동합니다.

3) 데이터 측면에서 이는 스키마가없는 스토리지가 유용한 예 중 하나 일 수 있습니다. 관계형 데이터 모델이있는 경우 서로 다른 고객에 대해 많은 열이있는 테이블을 갖는 것은 문제가됩니다 (예, 널 입력 가능한 많은 열이 나옵니다 . 그 이유는 올바른 제한 조건을 설정하기가 어렵거나 불가능하기 때문입니다. 무효 인 null 조합이 표시되지 않는 제약 조건]). 고객 별 테이블을 추가하면 (즉 users, 모든 고객에게 유효한 필드 foo_users를 users보유 foo_users하고 Foo 전용 파일을 보유한 상태로) 더 좋습니다. 올바른 제약 조건을 쉽게 가질 수는 있지만 RDBMS가 (폭발 조인, 테이블 수 제한 등으로 인해) 정상적으로 처리하지 못할 수 있으며 코드에서보기 흉하게 보일 것입니다.

RDBMS에서 키-값 저장소를 구현하면 데이터 모델의 관계가 줄어들고 불편 함이 발생할 수 있습니다 (즉, 관계형 데이터베이스가 관계형 모델에서 가장 잘 작동 함). NoSQL 솔루션이 전반적인 문제에 적합한 지 확실하지 않지만 대부분의 구현에서 스키마가없는 것이 유리할 수 있습니다.