Обмен практическим опытом Spring Cloud в облачных вычислениях SaaS

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

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

В настоящее время существует три основных многопользовательских решения SaaS для баз данных:

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

Совместное использование + изоляция: база данных может быть общей, но существует независимая схема. Таким образом, его показатели относительно средние.

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

Схема в базе данных представляет собой набор объектов базы данных. Например, в Oracle пользователь обычно соответствует схеме.

Для MySQL схема не является подчиненной базой данных, но эквивалентна базе данных. Например, выполнение теста создания схемы аналогично тесту создания базы данных.

Соответствие уровня базы данных между Oracle и MySQL выглядит следующим образом:

Преимущества режима независимой схемы:

Высокая независимость:У каждого арендатора есть своя библиотека, изолированная от других арендаторов;

Высокая масштабируемость:Он может легко выполнять горизонтальное расширение и миграцию данных;

Развитие бизнеса просто:При разработке нужно учитывать только бизнес-логику одного тенанта.За счет переключения схемы для достижения эффекта мультитенантности меньше таблиц для совместного запроса;

Индивидуальный сервис:Пользователи могут настраивать персонализированные услуги, не затрагивая других арендаторов;

Проблемы с режимом независимой схемы:

1. Что делать, если баз данных становится все больше и больше? Если есть 100 000 арендаторов, есть 100 000 библиотек, с которыми один сервер точно не справится.

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

3. Данные арендатора изолированы, что делать при проведении общего анализа данных?

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

После того, как арендаторы распределены, можно использовать следующие методы для поиска арендаторов:

Вторую и третью проблемы можно решить с помощью микросервисов данных:

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

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

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

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

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

Продукты состоят не из услуг, а из API. Сервис есть сервис, нам не обязательно делать его принадлежащим какому-то продукту, а объединять API разных сервисов в один продукт.

Ниже приведен пример топологии службы с использованием Spring Cloud:

Фронтенд и бэкэнд совместная работа

Проблемы при обычном использовании swagger:

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

Плохая гибкость, проблематично открывать определенные интерфейсы (например, третьим сторонам) конкретным людям;

Требуется специальная обработка, чтобы закрыть чванство при выпуске в производство;

Swagger иногда конфликтует с другими пакетами jar (например, springfox-swagger2.6.0 вызовет исключение для регистрации Eureka).

Разработка не ведется, и документация на первом месте. Перед формальной разработкой предпочтительно писать независимые микросервисы Swagger для справки разработчиков, чтобы Swagger вернулся к сути документов;

В начале проекта микросервис Swagger напрямую возвращает отформатированные поддельные данные для фронтенд-отладки, что удобно для фронтенд- и бэкенд-параллельной разработки;

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

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

Внутренняя служба вообще не вводит никакого кода Swagger, поддерживает чистоту кода и избегает конфликтов Swagger.Просто отключите службу Swagger при публикации и производстве;

Меры предосторожности:

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

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

Технологии — это еще не все

Вот и все на сегодняшнем обмене, спасибо всем!