Владислав Светлаков | Архитектура бэкенда. API для надежных корпоративных приложений (2026) [PDF]

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

Ключевые темы:

Методики сбора требований к программной системе перед началом ее разработки
Рассмотрение основных паттернов коммуникации между сервисами, включая синхронные и асинхронные взаимодействия
Управление операционными данными проекта, изучение реляционных и нереляционных (SQL и NoSQL) подходов к моделированию данных
Управление сложной логикой приложения, архитектурные стили, связанность и связность
Безопасность приложения, защита от хакерских атак, безопасное хранение данных
Мониторинг приложения, анализ инцидентов
Доставка изменений, использование тестов, автоматическое тестирование

Оглавление
Что такое бэкенд разработка

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

Сбор требований к системе

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

Семантика синхронных взаимодействий. REST

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

Масштабирование приложений.

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

Асинхронные взаимодействия.

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

Кеширование.

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

Операционные данные приложения

Нередко ядром системы являются ее данные, поэтому их организация играет большую роль. Поэтому отдельная глава посвящена тому, как именно могут обрабатываться операционные данные в рамках бэкенд-проектов. Помимо подходов с применением реляционных баз данных (PostgresSQL, MySQL), также рассматриваются нереляционные решения (MongoDB, Redis, БД временных рядов), а также проводится их сравнение в тех или иных ситуациях, для того, чтобы подобрать наиболее эффективное решение, решающее поставленную бизнес задачу.
Реляционные и нереляционные БД
Реляционные и нереляционные БД

Сложная логика приложений.

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

Безопасность

Как показывает практика, за безопасность приложения нужно платить, а за ее отсутствие - расплачиваться. Поэтому при построении своего решения, пристальное внимание нужно уделять тем местам, которые могут быть эксплуатированы не по назначению. Для этого в рамках данной главы разбираются основные векторы атак, которым подвержены приложения, а также способы защиты от них. Например, разбирается применение JWT токенов, организация OAuth2 и OIDC, а также защита от SQL инъекций, XSS и CSRF атак. Отдельное внимание обеспечено организации аутентификации, прав и ролей доступа.

Этап эксплуатации и подготовка к ней

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

Проверка изменений

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

Доставка изменений

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

Мониторинг работы системы

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

Целевая аудитория

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

О чем эта книга?

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

Почему важно помнить про бизнес цель

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

Важность технологий

Большое многообразие проектов, которые привязаны упростить те или иные части разработки, сформировалось не просто так. Разнообразие поставленных перед разработкой задач не позволяет эффективно закрыть их одним удачным инструментом. На первых порах, глаза могут разбежаться от многообразия фреймворков, баз данных, облачных сервисов, а количество их кросс-взаимодействий еще сильнее сбивает с толку. Но со временем, с каждой решенной задачей, идеи этих инструментов становятся более понятными.
Именно поэтому я посвятил главы 3-7 шаблонам коммуникации, способам хранения данных и инструментам оркестрации приложений. Если знать о существовании этих подходов заранее, велик шанс того, что не придется изобретать велосипед, поскольку похожие задачи уже возникали ранее, и для них существуют устоявшиеся решения, которые можно адаптировать под ваши сценарии. И тут ключевым является именно знание и ширина этого знания, которую я и постарался передать. Также Глава 9 полностью посвящена обеспечению безопасности приложений, поскольку это важный технологический аспект, пренебрежение которым может быть крайне болезненным для бизнеса и проекта.

Архитектура и сложная логика приложений

Это крайне важный и интересный аспект, который в процессе разработки играет ключевую роль. Архитектура может как упрощать жизнь разработчикам, позволяя быстрее и эффективнее развивать свою платформу, так и ровно наоборот, давить любую возможность внесения изменений, поскольку на каком то из этапов были допущены определенные ошибки. Поэтому определенный процент книги я посвятил именно ей, например глава 8 рассказывать про основные архитектурные стили а также важные показатели архитектуры на проекте, а глава 10 описывает управление техническим долгом и подготовку к релизу.
Мне хотелось подчеркнуть важность баланса. Нередко более сложная архитектура, которая может обработать большое количество запросов, а также является модульной и расширяемой, может быть не такой полезной, поскольку для решения бизнес задачи вполне можно было обойтись чем то простым. Ровно как и наоборот, из-за подобной простоты страдают многие программные системы, которые не всегда могут выйти из этого круга, из-за накопленного технического долга. Такие понятия как связанность и связность пронизывают все программные системы, поэтому многие моменты книги к ним отсылаются.

Тестирование

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

Доставка изменений

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

Мониторинг

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

Вместо заключения

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

Владислав Светлаков – ведущий инженер-программист (Lead Software Engineer) с многолетним опытом. Сфера интересов и компетенций — Python, FastAPI, PostgeSQL, Kafka, AWS, PyTorch, Ray, Kubernetes. В рамках профессиональной деятельности занимается коммерческой разработкой и консультированием в областях искусственного интеллекта и машинного обучения, бэкэнд-разработки, инженерии данных и архитектуры решений. Выполнял разработку и проектирование агентных систем искусственного интеллекта, систем для мониторинга Интернета вещей, высокопроизводительных средств компьютерного зрения. В настоящее время занимается искусственным интеллектом и машинным обучением для решения прикладных задач.