Я пытаюсь создать веб-решение SaaS, и я попадаю в путь, где я не уверен, что буду использовать несколько арендаторов или несколько экземпляров. Я постараюсь описать, чего я пытаюсь достичь, и у каждого подхода есть свои преимущества и недостатки (мое мнение, согласно тому, что я прочитал). Пожалуйста, включите ваши предложения на случай, если я что-то упустил в одном подходе над другим.
Как я уже говорил, приложение, которое я пытаюсь создать, представляет собой SaaS-решение, в котором компании могут создавать свои учетные записи, и у каждой учетной записи / компании есть свои пользователи, клиенты, продукты, услуги ... и т. Д. Каждый пользователь; кто сотрудник компании; связанные с одним аккаунтом / компания будет иметь доступ только к своим клиентам, продуктам и услугам своей компании. Компании могут иметь неограниченное количество клиентов, продуктов и услуг, поэтому у каждой компании должен быть свой собственный дата-центр.
Для этого я решил создать общую базу данных (сохраняя учетные данные всех пользователей для входа в систему) и общую схему с несколькими базами данных (база данных для каждой учетной записи / компании). В основном, Multi Tenancy .
Тогда кто-то предложил вместо этого использовать Multi Instance , где каждая компания будет иметь свой собственный экземпляр приложения (то есть код, библиотеки, базы данных, платформы и т. Д.), Полностью отделенный от других компаний. Это звучит лучше, поскольку мне не нужно заботиться о дополнительном слое, где я должен убедиться, что пользователи каждого арендатора имеют доступ только к данным своей компании. Я думаю, что это хорошо, чтобы упомянуть, что я полагаюсь на Docker для достижения этого подхода (я никогда не использовал его раньше), но я думаю, что в нем отсутствуют функции (подробнее об этом позже), которые мне понадобятся в будущем (по крайней мере, я не сделал не могу найти их с небольшим количеством поиска).
Тем не менее, каждый подход имеет свои плюсы и минусы, поэтому я не мог принять решение, какой подход пойти. Вот список, но со мной, так как мне не хватает знаний в обоих случаях, поэтому может быть что-то, о чем я не знаю, или решение проблемы, которую я не нашел в Интернете: [Каждый подход имеет упорядоченный список, за которым я следовал одно за другим сравнение]
Мульти Арендная плата :
- Общий хост / оборудование, общий код и мультибазы данных.
- Это проще , чтобы расширить функциональные возможности кода и исправления ошибок (общий код).
- Это сложнее расширить оборудование (можно использовать облачный сервис), или переместить базу данных индивидуального арендатора на другую систему , не делая изменений в коде.
- Самое главное, как я упоминал ранее, мне нужно добавить дополнительный слой в систему, чтобы удостовериться, что пользователь действительно принадлежит его / ее компании и не имеет доступа к информации другой компании.
Мульти Экземпляр :
- Общий или неразделенный хост / оборудование, код на экземпляр и база данных на экземпляр.
- Это труднее , чтобы расширить функциональные возможности или исправление ошибок (я не уверен , если есть способ сделать это в Докер , где вы можете добавить функциональность / функцию одного экземпляра или Докер контейнер, и развернуть его на другие).
- Это проще , чтобы переместить весь экземпляр на другой хост / аппаратное обеспечение.
- Как пример, мне не нужно заботиться об этом слое, поскольку каждый экземпляр будет иметь свою собственную базу данных.
Все преимущества и недостатки избыточны в случае, если я хочу что-то сделать вручную (например, создание экземпляра для каждого арендатора вручную), и поэтому я сомневаюсь в решении Docker, если только нет способа решить это, что, возможно, является основным причина вопроса. Буду признателен, если вы ответите на вопрос со ссылками на решения, и почему вы думаете, что этот подход лучше, чем другой.
В случае, если это поможет (возможно?), Мы используем Laravel в качестве основного фреймворка для серверной части (все RESTful).
Ответы:
Я задаю себе точно такой же вопрос в данный момент.
Я склоняюсь к единственному решению для нескольких экземпляров, но еще не принял окончательного решения. Позвольте мне поделиться некоторыми своими мыслями:
Основным историческим преимуществом мультитенантной архитектуры является более эффективное использование ресурсов инфраструктуры путем взаимного объединения (одна ОС, одна база данных, один уровень приложений) и лучшее использование указанных ресурсов (когда один пользователь отсутствует, другой может использовать один и тот же ресурс) ,
Это также значительно упрощает жизненный цикл программного обеспечения : вы развертываете новые версии на одном экземпляре, все клиенты обновляются одновременно.
Однако, похоже, что недавние достижения в облачных технологиях делают первый класс преимуществ в значительной степени доступным в архитектуре с несколькими экземплярами (экземпляр на клиента) (я имею в виду именно такую платформу, как Jelastic, но я уверен, что есть и другие, которые обеспечить те же функции):
Таким образом, управление оборудованием и платформой больше не является заботой поставщика программного обеспечения. Ресурсы взаимовыгоднее, чем раньше, на уровне инфраструктуры и платформы .
Для нескольких экземпляров все равно будут накладные расходы (некоторые приложения и промежуточное ПО будут запускаться N раз вместо одного), но намного ниже, чем при использовании отдельной (виртуальной) машины для каждого экземпляра. В любом случае база данных может быть общей (одна схема на экземпляр, несколько схем на сервер БД)
Также :
Конечно, нам нужен какой-то центральный сервис, который управляет всем этим автоматически (например, создание экземпляра, когда новый пользователь создает учетную запись). Это также помогло бы решить вопросы оплаты и лицензирования, взаимодействия между экземплярами и т. Д. Этот центральный сервис может быть довольно сложным и сложным в разработке, но хорошо то, что нам не нужно внедрять его заранее (теперь, когда у нас мало ресурс), в то время как мультитенант должен был бы быть включен в приложение с самого начала.
Что подводит меня к последним преимуществам разработки одного арендатора для проекта запуска на очень ранней стадии (до инвестирования):
NB: Я, очевидно, имею в виду бизнес-приложение, где клиентами будут предприятия (каждый с несколькими индивидуальными пользователями), а не отдельные лица. Не имеет смысла запускать отдельный экземпляр приложения для каждого отдельного пользователя (или так?)
источник
Возможна также поддержка обоих вариантов (пул арендаторов в нескольких экземплярах).
Я поддерживаю многоэкземплярную причину естественной изоляции. Каждый экземпляр клиента работает в своих собственных процессах, а его данные изолированы в его собственной базе данных. При желании вы можете обновить экземпляры до новых версий для каждого клиента / экземпляра.
Системы, основанные на арендаторах, сопряжены с риском информационной безопасности. Просто подумайте, как легко забыть предложение WHERE tenantId = x. Основной причиной использования системы, способной арендатора, будет производительность, процессы - это большой вес, так как, разделяя процесс, вы потенциально можете получить больше от одной машины. Это было более верно, я думаю, что в 32-битном мире сейчас 64-битные машины имеют гораздо больше оперативной памяти.
Системе с несколькими экземплярами, возможно, потребуется немного больше инструментов для создания и настройки среды, такой как базы данных и экземпляры веб-приложений. Кто-то может возразить, что вам нужно в любом случае использовать этот сценарий также для развертываний с одним экземпляром. У этого есть и другие преимущества, такие как возможность настройки сред разработки и тестирования.
Я бы оставил возможности арендатора, пока вы не сможете доказать это (затраты на проектирование против затрат, сэкономленных на (аппаратной) инфраструктуре за счет совместного использования процессов).
источник