Коллеги,

Занимаюсь проектированием отраслевой 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
нафига дублировать?

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

Petro123arkhimedдублировать не нужно, если зашли на свою страницу
ты веб-программист?
Если куки пустые, то что значит своя страница?
Если клиент-сервер, то пиши в своём логине-окне что захочется.
Даже виндовую авторизацию на сиквел.

под своей страницей я имею ввиду страницу своей организации по адресу org1.mydomain.ru

т.е. существует сразу несколько адресов:
- org1.mydomain.ru
- org2.mydomain.ru
- orgN.mydomain.ru

они смотрят на один и тот же app-сервер
веб приложение может сразу определить по url, что это за организация, а если такой нет показать page not found

Нахлобучarkhimedв части проектирования базы данных уже решено отказаться от упоминания в каждой таблице ссылки на учетную запись. Вместо этого под каждую организацию будет выделяться отдельная схема, в которой будут представлены все необходимые таблицы.
Как будете выходить из ситуации, когда в версии N+1 всего программного комплекса в схему БД будут внесены обратно-несовместимые изменения?

Ситуация: веб-приложение уже обновлено до версии N+1, какие-то схемы уже на версии N+1, а десяток схем всё еще на версии N.

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

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

Нахлобучarkhimedвыбранная архитектура как раз позволит производить частичное обновление версий
а также можно будет добавлять какие-то кастомные объекты бд в схеме организации
Вернее, выбранная архитектура позволит набить себе много шишек в интересных местах из-за неизбежного расхождения в версиях веб-приложения, схемы БД и наборах объектов в оных.

В случае, когда есть, грубо говоря, одна БД (всякие кластеры и Failover'ы для упрощения не рассматриваем) и N веб-серверов, обновление тривиально.

Когда на БД накатываются только обратно-совместимые миграции, веб-сайт можно даже не останавливать: бэкапим, применяем миграции, и, в случае успешного выполнения, простой Rolling Update на веб-сервера.

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

В случае же нескольких БД всё становится интереснее. Если один веб-сервер смотрит на несколько БД и на одной из них миграции не применились, то получаем ворох ошибок. Если из пула веб-серверов взялся сервер со старой версией кода и он пытается обработать запрос к обновленной БД -- тот же ворох ошибок.

обновление будет делаться скриптами по всем базам
на время обновления также вешаем заглушку
причем можно сделать обновление на одной группе db и app серверов

Petro123arkhimed,
Нельзя без ведома хозяев обновлять скриптами.

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

Олег2015Необходимо вынести аутентификацию в отдельную подсистему, это позволит сосредоточиться на уровне приложений только на авторизации и бизнес-логике, а система аутентификация будет озадачена ведением оргструктуры (пользователи, организации), назначением привилегий, ролей, предоставление нескольких протоков аутентификации (WS-Federation, SAMl2p, OpenID и т.д.). Пользователи веб-приложение аутентифицируются при помощи WS-Federatiom, толстые клиенты могут использовать WS-Trust, а мобильные - OpenID, причем вместо ввода логина и пароля может применяться eToken. А еще SSO, home realm discovery, ГОСТовские алгоритмы шифрования (что очень важно для гоструктур).

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

насколько я понимаю, нужно использовать windows identity foundation: в нем заложены все нужные режимы. или я не прав? хочется сделать унифицированную схему аутентификации и авторизации для веб-сайта и api для толстого клиента.

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

Хотя биллинг и платежи вынесены в отдельную БД на том же сервере.

Вы ещё скажите у вас у каждой ассоциации планируется своя domain model, иначе зачем им отдельные схемы?

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

насчет domain model, поясните, пожалуйста, что имеете ввиду?

skyANAА насчёт dns-записи, то у каждого клиента она своя.

у вас это используется для каких целей?
я думаю это использовать именно с целью направления клиентов на "свои" app-сервера.
т.е. на условно 50 организаций на одной группе app-сервер+db-сервер, еще 50 на другой и т.п.
причем эти группы будут располагаться в разных географических зонах.

еще вопрос по этому поводу:
мы, конечно, будем использовать ssl режим.
на один веб-сервер будет смотреть несколько записей:
org1.mydomain.ru CNAME server1.mydomain.ru
org2.mydomain.ru CNAME server1.mydomain.ru
orgN.mydomain.ru CNAME server1.mydomain.ru

не будет ли проблем с ssl-сертификатом и настройкой IIS? или wildcard-сертификат решит все вопросы? просто никогда еще не использовал такую схему.

Petro123skyANA,
я думаю, ему нужно как можно проще.
Из-за этого он шифрует в логин имя поддомена. Что я не очень приветствую.
ТЗ (которое он не колется):
- каждой организации свой экземпляр 1С.
- авторизация самой 1С должна дружить с авторизацией и билингом надсистемы Облако.
- смена версий ПО в облаке решается желанием заказчика (может заморозить).

Уважаемый Petro123,

еще раз повторю:
нет никакого 1С, разработка полностью своя с нуля.
думаем использовать подход хранения в разных схемах по нескольким причинам:
1. упрощенная разработка схем таблиц и процедур (нет необходимости везде вводить поле AccountId).
2. для некоторых крупных клиентов можно предоставить прямой доступ к их схеме.
3. всегда можно достаточно легко вынести данные клиента в отдельную бд и отдать ему.
4. у каждого клиента будет достаточно много данных, несколько миллионов строк. таких клиентов будет, например, около 100.
намного проще разнести их данные на несколько бд и серверов, причем в зависимости от требований клиентов можно будет предоставлять разный регламент бекапирования и т.п.

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

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

skyANAarkhimedпропущено...


у вас это используется для каких целей?
я думаю это использовать именно с целью направления клиентов на "свои" app-сервера.
т.е. на условно 50 организаций на одной группе app-сервер+db-сервер, еще 50 на другой и т.п.
причем эти группы будут располагаться в разных географических зонах. У клиентов нет "своих" app-серверов. У нас 10 веб-серверов в ферме для распределения нагрузки, а не для распределения клиентов.

Для ваших 100 организаций зачем вообще несколько серверов, пока не понятно. Какое количество запросов в секунду планируется?

arkhimedеще вопрос по этому поводу:
мы, конечно, будем использовать ssl режим.
на один веб-сервер будет смотреть несколько записей:
org1.mydomain.ru CNAME server1.mydomain.ru
org2.mydomain.ru CNAME server1.mydomain.ru
orgN.mydomain.ru CNAME server1.mydomain.ru

не будет ли проблем с ssl-сертификатом и настройкой IIS? или wildcard-сертификат решит все вопросы? просто никогда еще не использовал такую схему.Не будет. Главное не забывайте сертификаты обновлять :)

т.е. я просто могу не указывать host name?
и SNI мне не нужен? если я правильно понял, SNI нужен, если у меня несколько сайтов на одном IP. а у меня сайт будет один на данный момент, просто несколько адресов.

skyANA,

по поводу зачем несколько серверов.

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

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

если не сложно, расскажите как у вас? всё находится в одном дц?

Petro123arkhimedдумаем использовать подход хранения в разных схемах по нескольким причинам:
разумеется вам как то надо разделять БД между заказчиками.
Как вы "приложениеА" для разных заказчиков в одной БД будете держать. Это и не обсуждается.
OFF


Вы не совсем меня поняли.
Мы не собираемся готовое приложение переносить "в облако" как есть.
Схема данных проектируется с нуля.
Поэтому в принципе мы можем в каждой табличке предусмотреть ссылку на клиента.
Но на данный момент мне не кажется, что по трудозатратам это будет оптимальным вариантом.

Petro123arkhimedна первом этапе я хочу, развернуть 2 сервера.
я бы советовал, после опытной эксплуатации.
Т.к. это ещё далеко и это чисто админский вопрос.
К разработке не имеет отношения.

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

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