SaaS Architecture Вопрос от новичка
Я разработал ряд ведомственных клиент-серверных приложений, и теперь я готов начать работу над перемещением одного из этих приложений в модель SaaS. Я сделал некоторые базовые веб-разработки, но я новичок, когда речь заходит о архитектурах SaaS.
Один из первых вопросов, который приходит на ум, когда я пытаюсь спроектировать архитектуру, - это вопрос о едином или множественном аренде. Все плюсы и минусы каждого из них существенно различаются в зависимости от типа требуемого приложения и масштаба, поэтому я хотел бы описать потребности в приложении и масштабе ниже, и надеюсь, что другие могут прокомментировать, как я должен начать работу с архитектурой.
В настоящее время клиент-серверное приложение состоит из базы данных Firebird и приложения Windows. База данных содержит около 20 таблиц, содержащих несколько тысяч записей в 4 первичных таблицах, и несколько сотен записей в различных справочниках и связанных таблицах. Хотя количество записей невелико, размер может стать большим, так как база данных может содержать большие BLOBS. Каждый клиент настраивает свою собственную базу данных и имеет несколько пользователей в связанной с ней организации. Когда я обновляю схему db, открывается новое приложение Windows и проверяет схему db, а затем при необходимости применяет обновления.
Для приложения SaaS я проектирую для 100 (не 1000 или миллионов) новых клиентов в год. Моя первая мысль заключалась в том, чтобы пойти с моделью с несколькими арендаторами, чтобы упростить обновление (закрытие применяет обновления к одной базе данных, а затем запускает). С другой стороны, одна модель аренды будет предоставлять средства для одновременного обновления групп клиентов и распространения риска повреждения данных - то есть, если что-то пойдет не так с базой данных, это повлияет на одного клиента, а не на всех клиентов. С этой идеей я думал о наличии единого веб-интерфейса, который подключался бы к одной базе данных клиентов при входе в систему. Таким образом, когда новый клиент создает учетную запись, будет создана новая база данных (каждый клиент будет иметь свой собственный db с несколькими пользователями по мере необходимости для клиента).
В этой модели для обновления db потребуется либо процесс, чтобы пройти через каждый db для применения изменений схемы, либо триггер при входе в систему, чтобы инициировать обновление схемы, аналогичное используемой в настоящее время модели клиент-сервер.
Может ли кто-нибудь указать мне информацию для аналогичных приложений, которые были перенесены с клиент-сервера на SaaS? Или предоставить какие-либо указатели для рассмотрения? В основном я ищу примеры архитектуры для приема ведомственного приложения и предоставления его в качестве сайта самообслуживания для нескольких клиентов. Спасибо за любые предложения, ресурсы и т.д.
Ответы
Ответ 1
Хорошие вопросы.
Одна вещь, которая приходит на ум, состоит в том, что если у вас есть несколько баз данных, которые вы развертываете поэтапно, чтобы уменьшить вероятность взлома всех ваших клиентов, вам придется решить вопрос о том, что делать, если структура db изменения. Вы либо должны быть очень строгими в отношении поддержки обратной совместимости, либо развертывать отдельные версии вашей базы кода и каким-то образом управлять тем, какие арендаторы связаны с этими базами данных.
Мы также предоставляем наше приложение с использованием модели SaaS.
Это было первоначально приложение Windows, которое работало подобно вашему предложению нескольких баз данных. После входа в систему приложение-победитель будет аутентифицироваться в отношении одной базы данных "лицензий", которая затем ответит информацией о соединении для базы данных, относящейся к этому лицензиату. Самое приятное в этом: 1) физическое разделение данных лицензиата, которые понравились нашим клиентам, и 2) позволило нам физически найти базу данных на сервере, географически ближе к пользователям, что улучшает производительность и позволяет избежать некоторых потенциально сложных юридических и регулирующие вопросы в отношении предоставления данных по границам страны.
Конечно, поскольку приложение было толстым клиентским приложением, мы могли уйти с внесением изменений в базу данных и выталкивать их одному лицензиату за раз. Когда мы были готовы к обновлению, мы могли бы вытолкнуть обновленный толстый клиент в сочетании с новой базой данных, тем самым гарантируя соответствие кодовой базы базе данных. До тех пор, пока общая база данных аутентификации "лицензиата" оставалась последовательной, это работало достаточно хорошо.
С другой стороны, это решение привело к возникновению всех проблем, связанных с поддержанием и управлением толстым клиентским подходом, который в конечном итоге приведет нас к тому, что клиентский подход основан на браузерах.
В нашей новой модели все находится в одной базе данных. Когда у нас есть обновления, мы одновременно выставляем как код, так и db. Это решает проблему сохранения базы кода в соответствии с структурой базы данных. Тем не менее, мы столкнулись с проблемами, упомянутыми в пунктах 1 и 2 выше, которые мы еще не решили.
Надеюсь, это даст вам некоторую пищу для размышлений.
Меня тоже интересует этот вопрос.
Спасибо за сообщение.
-S
