Проектирование приложений serverless-архитектуры

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

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

Проектирование приложений Serverless-архитектуры

Гордина Анна Тимофеевна бакалавр, инженер-программист ООО «МТС Диджитал», Санкт-Петербург. Сфера научных интересов: проектирование и разработка программного обеспечения; объектно ориентированное программирование; облачные вычисления. Автор 1 опубликованной научной работы.

Рисунок 1. Традиционная архитектура трехуровневого приложения

Уровень данных – уровень хранения. Здесь находятся основные хранилища, например, базы данных, файловые системы и др., необходимые для размещения данных приложения.

Логический уровень может быть размещен на выделенном физическом сервере, и при повышенной нагрузке появляется необходимость в масштабирование его ресурсов. Serverelss является технологией без управления серверами, которая обеспечивает автоматическую оптимизацию, поэтому проектирование бессерверной трехуровневой архитектуры может дать существенные преимущества. При переходе на Serverless необходимо разбить приложение на микрозадачи, под каждую из которых будет спроектирована функция [7] – фрагмент программы, реагирующий на событие и обрабатывающий его. Коммуникация между клиентом и набором функций происходит посредством API-шлюза (см. Рисунок 2).

Рисунок 2. Serverless-архитектура

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

Использование API-шлюза и функций

API-шлюз (API Gateway) – это инструмент управления, который является связующим звеном между клиентом и внутренними сервисами приложения.

Шлюз API маскирует внутреннюю реализацию от внешнего наблюдателя, обеспечивая единую точку входа для каждого API. По сути API Gateway является RESTful API. REST API представляет собой набор методов, интегрированных с конечными точками HTTP, функциями и прочими сервисами приложения.

Проектирование приложений Serverless-архитектуры

Предположим, у нас есть приложение для грузоперевозок, которое использует Serverless-сервисы поставщика облачных услуг Yandex. Cloud. Пользователю необходимо управлять грузами и их перевозками. Каждый API для работы с ними реализован с помощью Yandex Cloud Functions.

Рассмотрим схему работы бессерверного логического уровня приложения. Конечными точками являются перевозки (movements) и грузы (goods). От пользователя поступает запрос GET или POST к конечным точкам, Yandex API Gateway обрабатывает его и направляет к функциям. В этом случае реализованы функции по поиску грузов, созданию перевозок и их отслеживанию (см. Рисунок 3).

Рисунок 3. Работа API-шлюза

Основной стандарт при реализации REST API – OpenAPI версии 3.0 [10]. OpenAPI представляет собой интерфейс по взаимодействию пользователей с сервисами и позволяет понимать их возможности без необходимости доступа к исходному коду. Пример спецификации для приложения по управлению грузоперевозками приведен на Рисунке 4.

1 openapi: 3.0.0

2 info:

3      title: Freight Movement API

4      version: 1.0.0

paths:

/goods:

get:

/movements:

get:

Рисунок 4. Спецификация API-шлюза

Пути вызова – /goods и /movements. Далее указывается метод get/post. Расширение x-yc-apigateway-integration является точкой входа для интеграции Yandex API Gateway с другими сервисами. Поле type описывает тип расширения для действий при вызове по указанному пути. При вызове облачных функций, указанных в поле function_id, в поле type указывается cloud-functions.

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

Микросервисы и Serverless

Serverless-архитектура схожа с микросервисной; при ее проектировании задачи также разбиваются на независимые друг от друга микрозадачи [9], каждая из которых работает в собственном процессе (см. Рисунок 5). По сути бессерверная архитектура – это расширенная микросервисная архитектура.

Рисунок 5. Микросервисная архитектура

Несмотря на сходство этих двух архитектур, их основным отличием является подход к проектированию микрочастей приложения. Микросервис может выполнять несколько задач; чаще всего он работает по системе «запрос – ответ», в то время как функция однонаправленная и выполняет только одну задачу [8]. Это значит, что микросервис может быть равен одной или нескольким Serverless-функциям. Помимо этого микросервисы относятся к сервисно ориентированной архитектуре (далее – СОА), а serverless продолжает развитие в событийно ориентированном мире архитектуры, что дает успехи и явные преимущества в сокращении времени выхода ПО на рынок и снижении эксплуатационных расходов.

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

При создании микросервисов Serverless каждый микросервис в приложении может быть разбит на одну или несколько функций (см. Рисунок 6).

Основным преимуществом Serverless-функций является простота их комбинирования с другими сервисами приложения – базами данных, очередями сообщений, инструментами управления API. Такая гибкость уменьшает количество повторяемого и шаблонного кода, который дополняется по мере масштабирования системы. Гибридная микро-сервисная Serverless-архитектура – разумный вариант для программного продукта, в ко-

Проектирование приложений Serverless-архитектуры тором микросервисы выполняют обработку тяжелых процессов, а serverless решает более простые задачи.

Рисунок 6. Микросервисная Serverless-архитектура

Принцип единой ответственности и принцип разделения ответственностей

При проектировании функции или микросервиса важно думать о понятии связности – меры когерентности элементов и группировании связного кода. Данное утверждение можно спроецировать на сформулированный Робертом Мартином принцип единой ответственности (Single Responsibility Principle, SRP), который гласит [5]: «Соберите вместе те вещи, которые меняются по одной и той же причине, и отделите те вещи, которые меняются по разным причинам». Иными словами, ответственность – это «причина для изменения», то есть каждая подсистема, класс, функция не должны иметь более одной причины для изменения. Каждая Serverless-функция должна быть нетривиальной и иметь уникальную ответственность.

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

Вернемся к нашему примеру про сервис грузоперевозок. Когда при создании перевозки она будет помечена как готовая к отправлению, будет создано событие, которое вызовет функцию для проверки терминала отправки клиента. Далее последует другая функция для генерации отгрузочной метки для перевозки. После произойдет подтверждение перевозки отправлением уведомления на email клиента (см. Рисунок 7).

Разделение ответственностей (Separation of Concerns, SoC) – подход проектирования программы, который предполагает, что каждый ее функциональный блок должен как можно меньше дублировать функциональность другого блока. Принцип разделения ответственностей обеспечивает повторное использование функций, индивидуальную оптимизацию и изолирование от допустимого отказа других функций. Разделение задач обеспечивается за счет инкапсуляции внутри каждого блока кода, который имеет свой определенный интерфейс. Инкапсуляция – принцип, который позволяет объединить данные и функции по их обработке [3]. Это позволяет улучшать отдельные разделы программы и вносить изменения без ущерба на реализацию сторонних модулей.

Крис Рид сделал вывод, что идеи в подходе дифференциации задач сводятся к трем основным [4]: 1) описание вычислений, 2) организация последовательных вычислений на небольшие шаги, 3) организация управления памятью во время вычислений. Он отмечает [4]: «В идеале программист должен иметь возможность сосредоточиться на первой из трех задач, не отвлекаясь на две другие, более административные, задачи. Очевидно, что администрирование важно, но, отделив его от основной задачи, мы, вероятно, получим более надежные результаты и сможем облегчить проблему программирования, автоматизируя большую часть администрирования».

Рисунок 7. Принцип SRP для цепочки Serverless-функций

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

В традиционной архитектуре могут возникать конфликты при чтении и записи из одного в одно и то же хранилище данных. Функции Serverless могут избавить систему от подобных проблем. Например, есть сервис, отвечающий за грузы на складе. Клиенту необходимо изменять, удалять и читать данные из этого сервиса. Для этого организуем функции под каждый необходимый запрос: добавление, удаление, чтение (см. Рисунок 8).

public class AddGoodsFunction {

@PutMapping("/add") public void addGoods _ } public class DeleteGoodsFunction{ @DeleteMapping("/delete") public void deleteGoods „

} public class ListGoodsFunction { @GetMappingC"/list") public void listGoods „

}

Рисунок 8. REST API с применением SoC для функций

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

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

Заключение

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

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

Завершенность и целостность – каждая функция выполняет только свою ответственность.

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

Логическая независимость – работа функции не зависит от работы других модулей и функций.

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