Эта статья является частью серии:

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

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

Разделите ваше приложение

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

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

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

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

Пример CRUD

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

  • Создать пользователя — POST /users
  • Получить пользователя — GET /users/:id
  • Получить всех пользователей — GET /users
  • Обновить пользователя — PUT /users/:id
  • Удалить пользователя — DELETE /users/:id

Какова наша логическая группировка?

Логической группировкой будет вся функциональность /users. Теперь мы определили нашу пиццу 🍕.

Сколько облачных функций входит в группу?

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

Пять отдельных облачных функций, хорошая идея?

Когда вы разбиваете вещи до такой степени, организационные накладные расходы резко возрастают. Вы также более восприимчивы к «холодным запускам», которые происходят, когда ваша облачная функция впервые получает запрос и не получает никаких запросов в течение длительного периода времени (например, 3–10 минут, это может быть по-разному).

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

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

Когда бы я предложил этот подход?

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

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

Какая альтернатива, как мне с этим справиться?

Если вы ищете альтернативу, чтобы сделать миграцию более гладкой с меньшими накладными расходами и меньшими проблемами «холодного запуска». Вы можете думать о логических группировках по-разному. Например, давайте представим все приложение как пиццу 🍕 и сделаем каждый кусочек пиццы 🍕 подмножеством функциональности (например, /users CRUD).

  • Пицца — Все приложение
  • Кусочек пиццы — Логическая группировка схожей функциональности (например, /users CRUD)

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

  • Нужно беспокоиться только о «холодном запуске» одной облачной функции.
  • Нужно только управлять одной облачной функцией
  • Менее раздутая автоматизация
  • Легче понять

Если в будущем мы добавим дополнительные функции, например, некоторые новые конечные точки API для /schedules, которые также будут иметь полную функциональность CRUD, аналогичную /users. У нас будет две облачные функции.

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

Пример 30+ минутного процесса

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

  1. API вызывается crontab
  2. API отправляет запрос на внутренний сервер
  3. Бэкенд-сервер постоянно делает запрос к стороннему API, пока не будут получены все данные.
  4. Бэкенд-сервер записывает в вашу собственную базу данных, пока все данные не будут записаны

Мы можем добиться большего, и одним из потенциальных способов может быть использование SQS для работы в качестве нашего «работника». Для простоты представим, что сторонний API может вернуть нам общее количество записей менее чем за секунду. Давайте также представим, что шаг № 3 имеет параметры, называемые «начало» и «конец», которые мы можем использовать вот так, ?start=0&end=100000. Для обработки каждых 100,000 записей потребуется 1 minute.

Обновим список.

Первая часть:

  1. Сервер вызывает API с помощью crontab
  2. API отправляет запрос на внутренний сервер, обрабатывающий наш код API.
  3. Бэкенд-сервер делает запрос к стороннему API на общее количество записей
  4. Бэкенд-сервер разбивает общее количество записей на 100,000 фрагментов и создает URL-адрес, https://third-party-api.com/api?start=0&end=100000
  5. Бэкенд-сервер отправляет URL-адрес в SQS в виде сообщения

Часть вторая:

  1. SQS вызывает облачную функцию один за другим для каждого сообщения, попадающего в очередь.
  2. Облачная функция распаковывает сообщение, содержащее URL-адрес, для отправки стороннего API-запроса.
  3. Облачная функция делает запрос к стороннему API и получает порцию данных
  4. Облачная функция записывает данные в базу данных

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

Часть первая (обновленная):

  1. Правило CloudWatch вызывает облачную функцию
  2. Облачная функция делает запрос к стороннему API на общее количество записей
  3. Облачная функция разбивает общее количество записей на 100,000 фрагментов и создает URL-адрес, https://third-party-api.com/api?start=0&end=100000
  4. Облачная функция отправляет URL-адрес в SQS в виде сообщения

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

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

Обзор

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

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

Дополнительный контент:

Что делает Serverless Guru?

Serverless Guru помогает компаниям создавать масштабируемые и экономичные приложения в облаке. Мы помогаем обучать компании тому, как использовать IAC, бессерверные и облачные сервисы. Мы помогаем перенести существующие приложения в облако и оптимизировать существующие приложения в облаке, чтобы сделать их более рентабельными. Мы являемся Партнером по разработке бессерверных решений и Партнером-консультантом AWS.

Что мы пропустили?

Когда вы оставите свой ответ, обязательно либо прокомментируйте его ниже, либо напишите свой ответ в @serverlessgurux в Твиттере.

Райан Джонс

Основатель и генеральный директор — Serverless Guru

LinkedIn — @ryanjonesirl

Твиттер — @ryanjonesirl

Спасибо за прочтение 😃

Если вы хотите узнать больше о Serverless Guru, подпишитесь на нас в Medium, Twitter, Instagram, Facebook или LinkedIn!