Руководство для начинающего архитектора ПО.
Современные приложения и сайты состоят из множества строк кода, который пишут разные люди. Поэтому важно организовать всё так, чтобы при совмещении разных кусочков проект работал как единый механизм.
То, как организован код, называется архитектурой программного обеспечения — она бывает монолитной или микросервисной. Выбор архитектуры зависит от проекта: в больших проектах разработчики, как правило, выбирают микросервисы.
Из этой статьи вы узнаете:
Вадим Федосеев
Principal software developer в «Альфа-Банке», тимлид.
Проверяющий куратор в Skillbox на курсе «Архитектор ПО».
Что такое микросервисная архитектура
Микросервисная архитектура ― это подход к разработке программного обеспечения, при котором систему разделяют на небольшие независимые сервисы. Каждый выполняет определённую функцию и взаимодействует с другими сервисами через API.
Представьте, что вы организуете файлы на своём компьютере. Можно сложить всё в одну папку: и семейные фото, и любимые фильмы, и рабочие документы. Если у вас всего несколько файлов, несложно найти то, что нужно. Но если их сотни, придётся долго листать, прежде чем вы найдёте вторую часть «Гарри Поттера». Поэтому мы сортируем файлы по разным папкам.
Примерно так работают микросервисы ― один сервис выполняет одну изолированную функцию.
Чем микросервисная архитектура отличается от монолитной
Инфографика: Оля Ежак для Skillbox Media
Легче всего понять, как работает микросервисная архитектура, если сравнить её с другой популярной моделью ― монолитом.
Монолитная архитектура ― традиционный подход к разработке программного обеспечения. Приложение представляет собой модуль, в котором объединены все компоненты. Управление интерфейсом, бизнес-логикой и базой данных осуществляется в одном месте.
Монолитная архитектура кажется более простой и понятной. Но, когда продукт разрастается, поддерживать такую архитектуру становится сложно.
Одна из компаний, которая использует микросервисную архитектуру, ― Netflix. Платформа построена на более чем 1000 микросервисов. Множество независимых модулей отвечают за обработку личных данных пользователей, совершение платежей по подписке и предоставление персонализированных рекомендаций.
Из чего состоит микросервисная архитектура
Микросервис
Микросервис ― это небольшой автономный компонент системы. Его можно разработать и развернуть независимо от других компонентов. Каждый модуль отвечает за конкретную функцию. Система может быть распределённой. Это значит, что микросервисы могут работать на разных серверах и связываться друг с другом.
API
API ― это набор правил и команд, который позволяет разным программам взаимодействовать друг с другом.
В микросервисной архитектуре API — набор универсальных «ручек», доступ к которым можно предоставить каждому. Если надо, чтобы один из микросервисов что-то сделал, то можно просто «дёрнуть ручку» и получить ответ. При этом не надо знать, как сервис будет выполнять задачу.
Работу API можно рассмотреть на примере автомобиля. Под капотом у него находится двигатель, система управления климатом, электроника и множество датчиков. В салоне водитель видит только кнопки и рычаги. Если он захочет набрать скорость, то просто сильнее нажмёт на педаль газа. Ему не надо знать, как в этот момент будет подаваться топливо и охлаждаться двигатель. В этом случае элементы управления в салоне авто — ручки API.
Чтобы больше узнать о том, как программы общаются между собой, переходите к нашей статье про API.
API-шлюзы (API Gateways)
Представим, что вы хотите попасть в здание, но, чтобы войти, нужно пройти через охранника. Он проверяет вашу личность, разрешает войти и подсказывает, как сориентироваться внутри здания. В мире компьютерных программ эти функции выполняют API-шлюзы (API Gateways). Они — проводники между разными частями сервиса. Когда одна часть программы хочет отправить запрос другой, она делает это через шлюз.
API Gateway проверяет, имеет ли программа право делать то, что она запрашивает. Это как проверка вашего паспорта охранником. Если всё в порядке, он направит программу туда, куда нужно, ― как охранник, направляющий вас в нужное место.
Шлюз может сохранять некоторые ответы, чтобы не запрашивать их каждый раз заново. Это как если бы охранник помнил, что вы уже были тут раньше и сразу вас пропускал.
Так что API Gateway ― это такой контрольно-пропускной пункт для взаимодействия разных частей программы между собой. Он проверяет уровни доступа и направляет запрос в нужную сторону.
Базы данных
База данных ― это виртуальное хранилище информации. Вместо того чтобы держать данные в отдельных файлах или таблицах, их помещают в единую базу. Так намного быстрее и удобнее искать информацию.
Чаще всего база данных выглядит как набор таблиц, где каждая представляет определённый тип данных, например информацию о пользователях приложения. Каждая строка таблицы представляет отдельную запись, а столбцы определяют различные атрибуты, например пол и возраст. С помощью специальных запросов можно извлекать, обновлять, добавлять или удалять данные из таблиц.
Ещё встречаются нереляционные базы данных — их называют NoSQL (то есть не связанные с языком SQL). В них представление информации не привязано к табличному виду.
Так выглядит простая база данных с информацией о сотрудниках компании
Скриншот: VS Code / Skillbox Media
Микросервисы используют базы данных для хранения информации. При этом у каждого сервиса она может быть своя. Например, в интернет-магазине один микросервис отвечает за то, чтобы заносить данные новых пользователей в базу, а другой ― подгружает данные о товарах из своей базы по мере обновления страницы.
Мониторинг
Системы мониторинга анализируют состояние каждого микросервиса для поддержания работоспособности всего приложения. Каждый микросервис записывает логи — файлы, которые содержат информацию о его работе. Это могут быть сообщения о событиях, ошибках, запросах и других важных моментах.
С помощью этого можно автоматически собирать метрики для оценки производительности микросервисов. Все полученные данные сохраняются, чтобы потом можно было проанализировать аномалии и тренды.
Конфигурация
Конфигурация в микросервисах — централизованный способ изменения параметров, которые влияют на работу всей системы. Поскольку микросервисы разрабатывают независимо друг от друга, важно иметь возможность менять конфигурацию не только отдельных сервисов, но и сразу всех компонентов без перезапуска.
Представьте себе кофейню с разными напитками в меню: эспрессо, латте и американо. Для каждого вида кофе есть рецепт, в котором отмечено количество зёрен, их сорт, температура воды и время заваривания. Рецепты ― это ваша конфигурация.
Если вы решите изменить порядок приготовления эспрессо, то лучше сразу обновить рецепт в базе данных заведения. Иначе придётся бегать по всему кафе и рассказывать каждому бариста о том, как теперь следует заваривать эспрессо.
Контейнеризация
Для развёртывания и масштабирования микросервисов использую контейнеры и системы оркестрации. Чаще всего разработчики выбирают для этого популярные Docker и Kubernetes.
С помощью контейнеров можно упаковать микросервисы со всем необходимым для переноса на сервер. Если надо будет переехать, то разработчикам не придётся собирать всё снова. Это и делает микросервисы переносимыми. Ещё контейнеры отвечают за изоляцию, предотвращая влияние сервисов друг на друга.
Микросервисная vs монолитная архитектура: плюсы и минусы
Монолитная
Монолитная архитектура иногда может быть полезна.
- Простота разработки. Все компоненты приложения находятся в одном месте, что делает процесс разработки простым и прозрачным.
- Простота развёртывания. Развёртывание монолитного приложения проще, так как для этого не требуется управления большим количеством микросервисов.
- Меньшие затраты на инфраструктуру. Монолиты часто требуют меньше инфраструктуры для развёртывания и поддержки, что помогает сократить затраты на разработку.
- Уменьшенная зависимость от сети. Поскольку все части приложения работают в пределах одного процесса, нет необходимости в постоянном взаимодействии по сети.
- Сложность масштабирования. Монолиты могут столкнуться с трудностями в масштабировании, особенно если определённые части приложения требуют больше ресурсов.
- Взаимозависимость компонентов. Если одна часть монолита требует изменений, это может повлиять на всю систему, что затрудняет внесение изменений.
- Сложность поддержки. Большие проекты тяжело поддерживать и понимать, как работают все их компоненты.
- Ограниченная гибкость. Изменения в одной части монолита могут затронуть другие, что может сделать систему менее гибкой и податливой к изменениям.
- Ограниченность стека. Монолиты обычно используют единый стек технологий, что ограничивает возможности использования различных технологий для разных компонентов.
Микросервисная
Микросервисная архитектура имеет ряд преимуществ перед монолитной архитектурой.
- Гибкость. Микросервисы позволяют разрабатывать, изменять и масштабировать отдельные части приложения независимо от других. Это делает систему более гибкой.
- Масштабируемость. Каждый микросервис можно масштабировать отдельно от всей системы. Сложность проекта растёт вместе с увеличением нагрузки.
- Изоляция ошибок. Проблемы в одном микросервисе редко влияют на остальные, а значит, искать и устранять ошибки становится проще.
- Свобода стека. Для каждого микросервиса можно выбрать свой стек технологий и язык программирования. Это даёт больше свободы разработчикам.
- Сложность управления. Чем больше микросервисов в проекте, тем сложнее ими управлять. Для этого нужны дополнительные инструменты и специалисты.
- Зависимость от сети. Микросервисы общаются друг с другом по сети, это может вызывать задержки и проблемы с производительностью.
- Затраты на развёртывание и инфраструктуру. Развёртывание и поддержка инфраструктуры для микросервисов обходится дороже.
Каждый из этих двух методов подходит для создания программного обеспечения в разных ситуациях. Монолит ― когда нужно быстро запустить и протестировать небольшое приложение. Микросервисы ― для сложных систем, которые будут дополняться и развиваться годами.