Говоря о многопользовательском дизайне SaaS корпоративного уровня

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

В настоящее время нет устоявшейся спецификации мультиарендности на уровне технической реализации, мало того, что много деталей, так еще и есть разные способы реализации каждой детали. Как приземлиться, зависит от существующих технических резервов текущей команды R&D, выбора технологий, силы капитала команды, характеристик отрасли или клиента (например, финансовая отрасль будет иметь более высокие требования к безопасности данных), с другой стороны, это также связано с Текущее Развитие поставщиков облачных услуг и наступление эры облачных технологий также сильно повлияли на методы создания программного обеспечения, включая SaaS.

Но в целом реальные приложения SaaS часто должны соответствовать следующим двум пунктам:

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

Классическая архитектура распределенных сервисов естественным образом решает три основные проблемы интернет-приложений (высокий параллелизм, высокая производительность и высокая доступность). Это также проблема, с которой корпоративное SaaS столкнется на средних и поздних этапах разработки. Давайте проанализируем, как проектирование и разработка в этой архитектуре.Внедрение мультитенантных приложений SaaS.

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

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

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

При реализации multi-tenancy часто более критична обработка ресурсов хранения, а вычислительные ресурсы обычно учитываются только при необходимости.Я думаю, это в основном связано с «отслеживанием состояния» хранилища. Давайте возьмем несколько типичных сценариев в качестве примеров, чтобы проанализировать, как начать проектирование с несколькими арендаторами.

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

Вообще говоря, мы логически будем хранить данные всех арендаторов в одной схеме без учета подбазы данных и подтаблицы. Для этого необходимо, чтобы в каждой таблице было поле tenant_id, то есть каждая запись несла свое «пространство имен» — идентификатор арендатора.

Взяв в качестве примера широко используемое NoSQL-решение Redis, вообще говоря, все данные арендатора хранятся в одном и том же распределенном кластере, поэтому, очевидно, идентификатор арендатора может быть перенесен на ключ.

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

Например, все операторы SQL в контексте арендатора должны содержать условие, где tenant_id=?, чтобы гарантировать правильность логики.Нам трудно представить, что в процессе от нуля до ста тысяч или миллиона строк кода, всем помнить об этом правиле.

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

Итак, как мы можем гарантировать, что разработчики также учитывают это правило?Поскольку мультиарендность является естественным атрибутом SaaS, мы можем поступить наоборот, поддерживать мультиарендную логику по умолчанию и определить аннотацию @TenantContextUnaware для выполнения операций, где мультитенантность - аренда не требуется.Описание исключения, что значительно снижает нагрузку на команду разработчиков.

Точно так же, как и при обслуживании Redis Key, также рекомендуется определить унифицированную KeyGeneratePolicy для обслуживания.

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

В дополнение к разнице в «состоянии» между вычислениями и хранилищем есть еще одно очень важное различие. Финансовые затраты на вычисления часто намного выше, чем на хранение. Например, мы можем позволить только сотням потоков обрабатывать запросы в одно и то же время. одновременно на одном виртуальном хосте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чжан Цзинь. NetEase Smart Enterprise Architect, отвечающий за построение архитектуры и инфраструктуры своих различных продуктов SaaS, имеет богатый опыт в разработке продуктов C-side и B-side. В настоящее время он в основном занимается технической структурой и управлением исследованиями и разработками продуктов корпоративного уровня.

Для более технических сухих товаров, пожалуйста, обратите внимание на «NetEase Smart Enterprise Technology +». Послушайте передовые наблюдения технического директора NetEase, посмотрите на самые ценные технические галантерейные товары и узнайте о последнем практическом опыте NetEase. NetEase Smart Enterprise Technology+ поможет вам вырасти из мыслителя в технического эксперта.