Коллеги,

Занимаюсь проектированием отраслевой Saas-системы.

Прошу Вас покритиковать текущие наработки и по возможности подсказать более удачные варианты.

Будут использоваться технологии Microsoft:
- MS Windows Server 2012 R2
- MS SQL Server 2014 Web Edition
- ASP.NET MVC, WinForms + WCF (ASP.NET Web Api)

Особенностью данной системы будет относительно небольшое количество организаций-пользователей, при достаточно большом объеме функциональности и данных. Поэтому в части проектирования базы данных уже решено отказаться от упоминания в каждой таблице ссылки на учетную запись. Вместо этого под каждую организацию будет выделяться отдельная схема, в которой будут представлены все необходимые таблицы. Итого данные будут храниться на нескольких серверах, на каждом сервере несколько баз данных, в каждой базе данных несколько схем, по одной на организацию. Будет поддерживаться модельная база данных, на основе которой будет скриптоваться создание схемы под новую организацию, а также автоматизированный накат изменений. Важным преимуществом такого подхода, является возможность вынести все данные организации в отдельную базу, сделать бекап и развернуть ее локально на мощностях заказчика, а также предоставить прямой доступ заказчику к его базе данных и схеме.

Также будет выделена база данных со списком учетных записей, биллингом и прочим.
В таблице учетных записей (Account) будут такие поля:
- AccountId
- AccountCode
- AccountName
- AccountServer
- AccountDatabase
- AccountSchema

Далее возникают вопросы.

В рамках одного датацентра упрощенно архитектура мне представляется такой:

- 2 App сервера
- 2 DB Org сервера
- 1 DB Account сервер

App-серверы вешаются один dns адрес (mydomain.ru). При входе в систему (формат логина пользователей user1@org1) мы определяем организацию и ищем пользователя в нужной базе данных.

Но мне бы хотелось разместить систему в двух датацентрах, чтобы часть организаций работала с одним, часть с другим. И настроить перекрестное бекапирование.
Тогда архитектура такая:

В каждом датацентре:
- 1 App сервер
- 1 DB Org сервер

И где-то отдельно:
- 1 DB Account сервер

В таком случае есть мысль для каждого клиента делать свою dns-запись org1.mydomain.ru. Соответственно настроивать эти записи на нужный App сервер.

Что думаете?

Далее возникают еще вопросы: например, что использовать WCF или Web Api и т.д., но это думаю обсудить чуть позже.

поясню:

есть успешный опыт разработки заказных систем + онлайн сервисов для некоторой отрасли (сейчас совершенно не важно какой)
сейчас появилась идея вынести это в онлайн систему, и продавать пользование этой системой и сервисами

потенциальных организаций-пользователей системы не так много (<100), а функций много.

поэтому идея в том что под каждую организацию выделять свои область (схему, для крупных можно и целую базу)

т.е. по факту сам функционал системы никак не знает о том, что рядом есть другие организации.

но чтобы делать маршрутизацию пользователей до своей базы, вести примитивный биллинг и т.п. нужна общая база данных.

и тут появляются вопросы как лучше организовать обращение пользователей к своей базе.

Petro123arkhimedОсобенностью данной системы будет относительно небольшое количество организаций-пользователей, при достаточно большом объеме функциональности и данных. Поэтому в части проектирования базы данных уже решено отказаться от упоминания в каждой таблице ссылки на учетную запись. Вместо этого под каждую организацию будет выделяться отдельная схема, в которой будут представлены все необходимые таблицы.
- 3 правила нормализации БД
- если всё решено, то зачем вопрос?
т.е. вместо таблицы-справочники "Организации на 10 записей", у вас будет 10 схем\БД организаций?
- Рядом форум "Проектирование БД".

1. решено только по одной пункту, дальше есть вопросы

2. сам справочник организаций будет сидеть в отдельной базе.
в дальнейшем планируется наладить обмен документами между организациями-пользователями системы.

3. вопрос не только по проектированию бд, но и вообще по построению архитектуры

irbis_alА по мне архитектура не так уж плоха.
За исключением построение всё на винде...( но это личное. :-) )...мне в целом нравится.

выбор технологии обуславливается опытом команды разработчиков
а также легкостью интеграции с собственными информационными системами организаций-заказчиков (вплоть для доступа некоторых заказчиков напрямую в базу данных)

Petro123arkhimed,
imho
это слишком общие вопросы, чтобы на них отвечать.
1. "As is to be" - при создании 2-ой очереди ИС, нужно знать как у вас сейчас работает.
2. Пользователь обращается к приложению, а не к БД. Так?
Мы опять не уйдём от конкретики - что продаём?
1С в облаке?

система полностью самописная
разрабатываем с нуля, поэтому в принципе есть большая свобода.
при этом, конечно, опираемся на прежние наработки.

сейчас в портфеле 2 системы, которые устанавливаются у заказчика и работают по архитектуре клиент-сервер (sql server + winforms)
также есть онлайн сервис (sql server + asp.net mvc / wcf-winforms)

так вот идея в том, чтобы объединить свои наработки в некоторую новую систему.
причем пока будем параллельно делать интерфейс на asp.net mvc и на winforms+wcf/web api
десктоп думаем оставить, т.к. данных достаточно много и опыта работы с ними больше именно в таком варианте.
на веб будет облегченная версия

плюс рассматриваем возможность давать доступ по ssl к базам данных напрямую для тех заказчиков, кто захочет упрощенно интегрировать свою внутреннюю систему с нашей.

Petro123arkhimed,
ищите примеры облака, которые для вас подходят.
ВИ №1 дропбокс
===
- делаете клиент-сервер, который по факту облегчённая ваша версия по примеру дропбокса.
Её нужно очень сильно облегчить и обозвать SaaS.
Дальше исследование рынка...клюнули или нет.

предварительный анализ рынка уже сделали, поэтому сейчас вопросы больше не коммерческие, а технические

первый:
как организовать маршрутизацию пользователей к их базам, при учете, что они находятся в разных датацентрах и избежать при этом излишнего трафика.

Petro123arkhimedкак организовать маршрутизацию пользователей к их базам, при учете, что они находятся в разных датацентрах и избежать при этом излишнего трафика.
если у вас а-ля дропбокс, то они все в одной БД.
Если у вас облако-1С, то аналогия с платным хостингом.
У вас хостинг с виртуальными операционками. Пользователям скриптом запускаете виртуалку с экземпляром 1С.
Там квоты, безопасность, панел управления и т.д.
Доступ по IP.

хочется промежуточный вариант
чтобы снаружи это выглядело как обычный веб-сервис с понятным адресом
т.е. никаких виртуалок и т.п.

пока мысль дошла только до разделение пользователей по dns: org1.mydomain.ru, org2.mydomain.ru и т.п. - это адреса одного или нескольких app-серверов, которые находятся в том же датацентре, что и сервер с базой данных организации

Petro123arkhimed,
так?
http://рога_и_копыта.livejournal.com/приложение_1С?qqqqqqqqqq
http://рога_и_копыта.livejournal.com/приложение_шашки?qqqqqqqqqq
http://toyota.livejournal.com/приложение_1С?qqqqqqqqqq
виртуалка или железо никакой разницы не имеет

по адресации да
но имеется ввиду, что доступа к ос у пользователей не будет
т.е. они работают через веб-сервис (app-сервер)

в крайнем случае даем доступ к бд, но опять же без доступа к ос

Petro123arkhimed,
досту к любому ресурсу - как захотите.
авторПри входе в систему (формат логина пользователей user1@org1) мы определяем организацию и ищем пользователя в нужной базе данных.
вы зря тут пишите тонкости вроде формат логина.
Т.к. даже не определено - веб или не веб приложение.
вот такая ВЕБ-форма:
http://org1.livejournal.com/приложение/форма_логина

формат логина нужен для того, что определить куда перенаправлять запрос, т.к. таблица User у всех организаций будет своя
это делается для того, чтобы можно было вынести функционал для конкретной организации в отдельное самодостаточное приложение

веб - не веб все равно, т.к. в любом случае будет app-сервер по протоколу http

т.е. если мы в вин-приложении вводим логин user@org1 и пароль, то вин-приложение уже может само подставить адрес https://org1.mydomain.ru и передать запрос туда

на самом деле такой подход я видел достаточно часто. например, яндекс.почта для домена.

Petro123arkhimedт.е. если мы в вин-приложении вводим логин user@org1 и пароль, то вин-приложение уже может само подставить адрес https://org1.mydomain.ru и передать запрос туда
я тебя не понял.
У тебя окно входа в твоё облачное приложение (не в админку)
Ты в поле логин хочешь _заставить_ вводить: user@org1
или user@имя_поддомена
?

в данном случае код организации будет использовано имени поддомена

например:
организация ООО "Рога и Копыта", код "rogikop" -> url для входа rogikop.mydomain.ru, формат логина user@rogikop

Petro123arkhimedнапример, яндекс.почта для домена.
подробнее

перепутал, в яндексе есть возможность свой домен замапить

а вот в гравителе именно так (см картинку):

если заходим на общий адрес, то надо вводить полное имя
если заходим на свой адрес, то надо ввести только часть имени до @, остальное уже подставлено

Petro123arkhimedurl для входа rogikop.mydomain.ru, формат логина user@rogikop
нафига дублировать?

дублировать не нужно, если зашли на свою страницу