В облачном поле мы часто слышим слово:мульти аренды. Слово имеет разное значение в разных контекстах. В этой статье будет представлена концепция мультиарендности в облачных платформах и идея реализации поддержки мультиарендности.
что такое арендатор
Когда вы впервые знакомитесь с этой концепцией, слово «арендатор» должно показаться вам странным. Но предположим, мы изменим слово, и я уверен, вы сразу это почувствуете. Слово «клиент» (клиент здесь относится к клиенту выше бизнеса).
Арендатор — это клиент. Например, если мы разрабатываем услугу для компании XXX, то эта компания является одним из наших клиентов/арендаторов. Если предположить, что услуга ориентирована на Интернет, то каждый пользователь Интернета, использующий эту услугу, является клиентом. /жилец.
Зачем вам нужна поддержка нескольких арендаторов
Разработчики усердно работали над созданием сервиса. Предоставлено для личного/корпоративного использования, это конец? Конечно, это не должно быть просто так. Мы разработали сервис. Предпочтительно, он может предоставляться нескольким лицам/компаниям одновременно. И для этих клиентов лучше всего использовать один и тот же набор среды выполнения службы (Runtime), что может значительно снизить затраты на эксплуатацию и обслуживание службы:
-
Если услуга выполняется отдельно, стоимость эксплуатации и обслуживания пропорциональна количеству клиентов (например, сценарий обновления и развертывания большого количества клиентов)
-
Экономия ресурсов (максимальное использование ресурсов, необходимых службам: единая команда эксплуатации и обслуживания, использование оборудования)
Кроме того, это также может снизить стоимость разработки сервиса:
-
Нам нужно только рассмотреть, как реализовать логику обслуживания одного пользователя: бизнес-логика одинакова для всех его клиентов, а услуги, предоставляемые программой, одинаковы независимо от того, какой клиент ее использует. Далее, на бизнес-уровне, нам теоретически не нужно рассматривать мультиклиентскую поддержку при разработке этого сервиса, мы только ориентируемся на то, как реализована бизнес-логика сервиса
-
Функции управления несколькими клиентами могут быть унифицированы: разработчики не должны учитывать функции управления клиентами, которые должна предоставлять облачная платформа.
Примеры мультитенантных сценариев
Если сервис, который мы хотим разработать, представляет собой блог-платформу, то этот сервис предназначен для пользователей Интернета, и каждый пользователь Интернета является нашим клиентом (пользователь — арендатор).
В среде, которая не поддерживает мультиарендность, чтобы изолировать данные каждого пользователя, мы, по крайней мере, будем учитывать, что большинство таблиц имеют поле user_id при проектировании таблицы базы данных. Используйте это поле для изоляции пользователей при использовании для данных CRUD.
Например, сегодняшний бизнес — это «публикация статей». Данные о статьях должны храниться в таблице статей, и при реализации мы обращаем внимание на две вещи:
-
CRUD: это часть реализации бизнес-логики.
-
Изоляция пользователя: необходимо добавить user_id. создавать деловые ассоциации
1 — это реализация «чистой» части бизнес-логики. Это должно быть достигнуто;
2 предназначен для многопользовательской платформы для ведения блогов, что не является бизнес-логикой самой платформы для ведения блогов.
Это предполагает, что поддержка мультиарендности платформы доступна, и пункт 2 не рассматривается. Это может быть сосредоточено на первом этапе реализации бизнес-логики, который является типичным мультитенантным сценарием.
Поддержка нескольких арендаторов
Мы можем понимать поддержку мультиарендности следующим образом:
-
С точки зрения предоставления услуг. Сервис, который мы разрабатываем, может использоваться несколькими клиентами одновременно. И данные/состояние между клиентами остаются изолированными
-
С точки зрения использования услуги, вы и я можем использовать одну и ту же услугу в качестве разных клиентов одновременно.В это время бизнес, который мы заканчиваем, используя услугу, не повлияет друг на друга, точно так же, как мы используем нашу собственную эксклюзивную услугу. .
Затем этот сервис поддерживает несколько «клиентов», то есть сервис поддерживает мультиарендность. «Сервис» здесь может быть приложением, платформой SaaS или платформой PaaS. Просто взглянув на знакомые нам облачные платформы, мультиарендная поддержка приложений должна быть самой обычной. Это потому, что приложение ориентировано на пользователей, а эта группа очень большая.
Поддержка нескольких арендаторов с точки зрения реализации. «Это технология архитектуры программного обеспечения», причина, по которой подчеркивается, что она относится к уровню архитектуры, заключается в том, что для ее реализации ее необходимо учитывать при создании технической архитектуры.
модель арендатора
В начале этой статьи мы упомянули об использовании термина «клиент» вместо «арендатор», чтобы понять значение термина «арендатор». С «коммерческой» точки зрения нетрудно обнаружить, что арендаторы фактически являются частью реализации своей бизнес-модели в облачной среде. Бизнес-модели разнообразны. Это означает, что разделение арендаторов также разнообразно. Здесь мы опишем один возможный стек арендаторов в повествовании:
-
Приложение предоставляется пользователю.Для приложения пользователь является его арендатором (это относительно единообразно в отрасли).
-
Услуги, предоставляемые SaaS, используются разработчиками приложений.Для SaaS разработчики приложений являются его арендаторами.
-
Услуги, предоставляемые PaaS, используются прикладной системой для PaaS. Совокупность связанных приложений является его арендатором
SaaS и PaaS предназначены для ролей, не являющихся конечными пользователями, таких как разработчики и системы. Эта часть обычно определяется разработчиком облачной платформы (бизнес-модель в комплекте). В частности, частные/корпоративные облачные платформы обычно не рассматривают такие сценарии, как «поддержка реализации нескольких платформ SaaS на платформе PaaS». Так что многие из наших других дискуссий вращаются вокруг «поддержки приложений для мультитенантности».
Мультитенантность приложений
Сценарии использования мультитенантности приложений были представлены ранее. Теперь, если мы являемся разработчиком облачной платформы, чтобы удовлетворить потребности в поддержке приложений для поддержки мультиарендности, нам необходимо обеспечить следующие поддержки в облачной платформе:
-
Управление арендаторами: CRUD, статистика
-
Изолированные/разделяемые сервисы арендатора: очереди, кэши, базы данных и т. д.
-
Статистика изоляции арендаторов: журналы, квоты
Эти опоры можно разделить на две категории:
-
Управление арендаторами: не будет напрямую облегчать взаимодействие пользователя между приложениями. Это приложение приложения. Платформа должна предоставлять подробную реализацию
-
Изоляция данных/статуса арендатора: с самого начала запроса должна быть возможность различать, от какого арендатора исходит запрос, и контекст арендатора также должен передаваться по ссылке вызова при обработке запроса. Доступ к данным разделен по арендаторам. Он также изолирован от арендатора при вызове услуг, предоставляемых платформой.
Пункт 1 относительно легко реализовать. Это проблема бизнес-модели, и модель арендатора может быть абстрагирована в соответствии с бизнес-доменом.Например, корпоративные приложения обычно различают арендаторов по «организации»;
Пункт 2 — чисто техническое требование. При реализации платформенной технологии необходимо поддерживать изоляцию времени выполнения по «арендатору». уровень Мы должны иметь возможность абстрагировать его. Минимизировать влияние диверсификации бизнес-модели на техническую архитектуру). Мы можем сопоставить арендаторов с абстракцией, которая обеспечивает наши потребности в изоляции.
Пространства имен
Ранее мы обсуждали, что поддержка мультиарендности осуществляется сверху вниз: от требований мультиарендности приложений к реализации изоляции данных; теперь мы изменим перспективу снизу вверх: сначала изолируем данные через пространства имен, а затем предоставляем пространства имен приложениям. многопользовательское использование. Восходящая цель в основном находится внутри платформы, где мы можем абстрагироваться от изоляции данных/состояний через «пространства имен». В конечном счете, в идеале пространства имен должны не только поддерживать многопользовательскую реализацию приложений, но и опционально предоставлять доступ к API-интерфейсам пространств имен. Позволяет приложениям изолировать определенные данные (например, кэширование). Содействовать реализации бизнеса.
Реализация изоляции
От начала до конца запроса арендатора платформе необходимо знать пространство имен этого сопоставления запросов. Из стека обработки запросов мы можем примерно разделить его следующим образом:
-
Балансировщик нагрузки (LB)
-
Контейнер приложения (приложение)
-
Сервисный интерфейс платформы (RPC)
-
Реализация службы платформы (DB/Cache/MQ....)
Каждая платформа в этом стеке должна знать соответствующее пространство имен этого запроса. Платформа может предоставить унифицированную службу входа в систему, которая сопоставляет информацию об арендаторе с пространством имен и сохраняет ее в сеансе пользователя, чтобы каждый раз, когда пользователь запрашивает:
-
Пространства имен можно различать при передаче LB
-
Возможность передачи сессий в контейнере APP
-
Передать пространство имен, когда RPC
-
Реализуйте пространства имен в соответствии с различными службами (например, БД использует разные схемы в соответствии с пространствами имен, а MQ использует разные очереди в соответствии с пространствами имен).
Основная идея реализации изоляции, которую мы здесь используем, — «Общее приложение», то есть несколько арендаторов совместно используют приложение и соответствующий набор инфраструктуры.
дизайн платформы
Мы так много говорили раньше, теперь мы можем создать облачную платформу, поддерживающую мультитенантность приложений:
(Идеи дизайна здесь также включают сценарии, в которых некоторым арендаторам требуются эксклюзивные ресурсы)
Суммировать
-
У арендаторов и клиентов похожие концепции
-
Поддержка мультиарендности, как правило, относится к поддержке мультиарендности приложения.
-
Поддержка мультитенантности на техническом уровне требует изоляции данных/состояний.
-
Используйте пространства имен для изоляции и абстракции
-
Платформа может интегрировать сопоставление арендатора с пространством имен.