✍️ Балансировка нагрузки | продолжение

Ранее писали про балансировку нагрузки
Напомним, балансировка — механизм распределения входящих запросов между серверами

Уровни балансировки в модели OSI

💙сетевой уровень (L3, IP) – балансировка на основе IP-адресов
💙транспортный уровень (L4, TCP/UDP) – маршрутизация запросов по номерам портов и соединениям, без анализа содержимого пакетов
💙прикладной уровень (L7, HTTP/HTTPS) – анализ HTTP-запросов и маршрутизация на основе URL, заголовков или cookies


Типы балансировщиков

Аппаратные (Hardware Load Balancer, HLB)

- физические устройства с сетевыми процессорами (ASIC), которые обрабатывают пакеты быстрее, чем программные решения
- часто используются в крупных дата-центрах
⏩ примеры: F5 Big-IP, Citrix NetScaler

Как работают
➡️клиент отправляет запрос на IP-адрес балансировщика
➡️балансировщик обрабатывает запрос на аппаратном уровне
➡️трафик направляется на нужный сервер с мин задержками


Программные (Software Load Balancer, SLB)

- ПО на сервере, которое выполняет функции балансировки
- гибкое, дешевле аппаратных решений, но требует мощностей сервера
⏩ Nginx, HAProxy, Envoy

Как работают
➡️SLB развернут на виртуальной машине / физическом сервере
➡️принимает запросы и перенаправляет их на сервера по заданным алгоритмам
➡️может использовать L4 или L7-балансировку


Виртуальные (Virtual Load Balancer, VLB)
- программные балансировщики, работают в виртуальных средах или в облаке
- поддерживают авто-масштабирование (динамическое изменение кол-ва серверов)
⏩AWS ELB, Yandex Network Load Balancer

Как работают
➡️облачный балансировщик получает запрос
➡️в зависимости от нагрузки создает новые инстансы или перераспределяет трафик
➡️атоматически масштабируется и настраивается
* инстанс (instance) – виртуальная / физическая машина, которая обрабатывает запросы


Методы балансировки

⚪️DNS-балансировка (уровень L3)
DNS-сервер возвращает разные IP-адреса на один DNS-запрос
— не учитывает загрузку серверов и может кэшироваться клиентами (возможны задержки в обновлении маршрутов)
— например, api.example.com может вести на разные серверы

⚪️Через прокси-сервер (L7)
запросы поступают на прокси → он анализирует содержимое и перенаправляет на нужные серверы

⚪️Прямая балансировка (L4)
изменяет MAC-адреса пакетов, направляет их напрямую на backend-серверы

⚪️NAT-балансировка (L3-L4)
изменяет IP-адреса и порты пакетов, направляет трафик на разные серверы онлайн


Примеры методов для разных типов нагрузки

⭐️Статический контент (изображения, видео, CSS, JavaScript)
Пользователь запрашивает изображение с сайта
➡️ DNS-балансировщик (Nginx) направляет запрос на ближайший географически сервер CDN
➡️ CDN отдает изображение из кэша, без загрузки с основного сервера

⭐️API-запросы (REST, GraphQL)
REST API с /auth и /data:
➡️ L4-балансировщик (NAT / HAProxy) направляет трафик API на серверы, распределяет нагрузку
➡️ L7-балансировщик (Nginx) перенаправляет по URL или заголовкам:
/auth — на серверы аутентификации
/data — на серверы обработки данных

⭐️Веб-приложения (динамический контент, пользовательские сессии)
L7-балансировщик (F5 BIG-IP) с алгоритмом Sticky Sessions определяет пользователя по cookie и направляет его запросы на один сервер. Данные сессии (корзина, авторизация) не потеряются

⭐️БД
Кластер PostgreSQL с мастером и 3 репликами
➡️L4-балансировщик (например, Pgpool-II) с алгоритмом Least Connections отправляет запросы на чтение (SELECT) на реплики, чтобы снизить нагрузку на мастер
➡️запросы INSERT/UPDATE идут на мастер


📎 Материалы
1. Балансировка нагрузки: основные алгоритмы и методы
2. Load Balancer и Reverse Proxy в микросервисной архитектуре
3. Load Balancers для систем оркестрации
4. Балансировка нагрузки в Облаках
5. Сетевой балансировщик нагрузки
6. DNS Балансировка нагрузки: что это такое
7. Как работает L3 балансировщик нагрузки
8. Балансировка нагрузки на L3, L4 и L7
9. Что такое Envoy, зачем он нужен и как работает

#проектирование #инфраструктура

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

✳️ Прокси-сервер

Прокси-сервер – промежуточный сервер между клиентом (пользователем / приложением) и сервером
🔵содержит прокси IP-адреса (индивидуальные IP-адреса для сокрытия реального IP)
🔵принимает запросы от клиента, обрабатывает и передает дальше
🔵может изменять или фильтровать данные

Отличие от балансировщика и VPN

🟠балансировщик нагрузки распределяет входящий трафик между серверами
🟡прокси - "посредник", без распределения нагрузки
🟠VPN (Virtual Private Network) создаёт защищённое соединение между клиентом и сервером, для шифрования и анонимности
🟡прокси может менять IP-адрес и фильтровать трафик, но не всегда шифрует данные


Для чего нужен?

Анонимность и скрытие IP-адреса
🔵пример: для доступа к заблокированному контенту с помощью зарубежного прокси

Кеширование
🔵кэширует веб-страницы и ускоряет загрузку сайтов внутри сети
(!) Кэш может быть не только в прокси. Важно учитывать последствия кэширования на разных уровнях

Контроль и фильтрация трафика
🔵блокирует доступ сотрудников к определенным сайтам

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


Пример работы

1️⃣ клиент отправляет запрос на доступ к ресурсу через прокси-сервер
2️⃣прокси принимает запрос и анализирует его (проверка политики доступа, фильтрация, логирование)
3️⃣©️ если данные есть в кэше, то прокси возвращает их без обращения к внешнему серверу
©️ если нет, то прокси пересылает запрос на целевой сервер
4️⃣сервер обрабатывает запрос и отправляет ответ прокси
5️⃣прокси передает ответ клиенту + может модифицировать его (сжать контент, удалить конфиденциальные данные)


Прямой и обратный прокси

Прямой
Клиент ➡ Прокси-сервер ➡ Интернет-ресурс ➡ Сервер
🟡перенаправляет запросы клиента в интернет, изменяет IP-адрес и фильтрует трафик
©️клиент знает о наличии прокси, и конфигурирует его

Обратный (реверсивный)
Клиент ➡ Интернет-ресурс ➡ Прокси-сервер ➡ Сервер
🟡работает на серверной стороне
🟡принимает запросы, но не передает их напрямую серверу, а перенаправляет на один / несколько серверов
©️ клиент не знает о нем


Примеры интеграции

Интеграция с CDN
▫️работает в связке с сетью доставки контента (CDN), кэширует и оптимизирует раздачу статических ресурсов

Интеграция с WAF (Web Application Firewall)
▫️фильтрует трафик через WAF для защиты веб-приложения от атак на уровне приложения

В микросервисной архитектуре
▫️управляет взаимодействием микросервисов (маршрутизация и балансировка трафика)
пример: сервис-меш с прокси для маршрутизации API-запросов между микросервисами


Пример архитектуры с прокси
[ Клиенты ] → [ Reverse Proxy ] → [ Балансировщик ] → [ Серверы приложений ] → [ БД ]

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


📎 Материалы

1. Прокси
2. Что такое прокси-сервер и как его настроить
3. Прокси-сервер: что это такое и нужен ли он вам?
4. Что такое прокси? Для самых маленьких
5. Что такое прямой прокси и обратный прокси
6. Разница между обратным и прямым прокси
7. Разница между прямым прокси, обратным прокси и балансировщиком нагрузки
8. Типы Прокси HTTP, HTTPS, Socks
9. VPN или прокси-сервер: что лучше и в чем разница?

📚Книги
Безопасность веб-приложений. Разведка, защита, нападение. — Хоффман Эндрю

#проектирование #инфраструктура

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

💳 Архитектура платежных систем

Термины

🔹платежная система — инфраструктура для маршрутизации платежей, безопасности операций и расчетов между банками (Мир, Visa, MasterCard)

🔹эквайер — банк/финансовая организация, обслуживает терминалы и принимает платежи от клиентов

🔹процессинговый центр (ПЦ) — система для обработки платежных запросов, передает их в платежную систему и банк-эмитент

🔹банк-эмитент — банк,который выпустил карту клиента; он проверяет баланс, авторизует платеж и списывает средства


Рассмотрим обобщенно: как происходит платеж с момента поднесения карты к терминалу эквайринга до списания средств со счета

1️⃣ Поднесение карты к терминалу эквайринга

Карту подносят к терминалу. Начинается процесс авторизации платежа
Терминал может быть:
🔵физическим (например, POS-терминал в магазине)
🔵виртуальным (веб-форма на сайте, мобильное приложение)

Платежная система (например, «Мир») определяет стандарты передачи данных (например, MIR Accept) и их безопасность

2️⃣ Передача данных с терминала эквайринга

Карта успешно считана, терминал передает платежные данные (номер карты, срок действия, CVV, сумму транзакции) в ПЦ эквайера через защищенное соединение

3️⃣ Передача данных в ПЦ и платежную систему

ПЦ эквайера принимает платежный запрос, проверяет его корректность и передает в платежную систему (например, «Мир»)

Платежная система маршрутизирует платеж:
🔵определет банк-эмитент по номеру карты (BIN)
🔵отправляет ему запрос на авторизацию

4️⃣ Проверка данных и авторизация в банке-эмитенте

Банк-эмитент проверяет:
🔵достаточно ли средств на счете
🔵корректно введенны данные
🔵антифрод-проверки
🔵есть ли блокировки на карте и т.д.

Если все ок, банк-эмитент выдает авторизацию и передает ответ (одобрение/отказ в проведении транзакции) платежной системе

Платежная система передает его в ПЦ эквайера - > эквайрер передает результат на терминал

5️⃣ Завершение транзакции и списание средств

После авторизации банк-эмитент резервирует сумму на счете покупателя

ПЦ передает подтверждение эквайеру
Эквайер передает его продавцу -> продавец получает платеж, транзакция завершается

Платежная система участвует в клиринге* и окончательных расчетах между банком-эквайером и банком-эмитентом

* клиринг — процесс взаимных расчетов между банками, выполняется платежной системой


Примеры технологий на каждом этапе

1. Поднесение карты к терминалу эквайринга

⚪️NFC (Near Field Communication) — для передачи данных между картой и терминалом (в том числе для Apple Pay, Google Pay). Работает на основе RFID и требует наличия чипа в карте
⚪️RFID (Radio Frequency Identification) — передача данных между картой (тегом) и терминалом через радиоволны
⚪️EMV (Europay, MasterCard, Visa) — стандарт для карт с чипом с криптографическими алгоритмами защиты данных.
⚪️MIR Accept — аналогичный стандарт для платежной системы «Мир», дополненный механизмами защиты + адаптация к требованиям

2. Передача данных с терминала эквайринга

⚪️TLS (Transport Layer Security) — защищенный протокол передачи данных
⚪️API (REST, SOAP) — для интеграции с процессингом и банками-эквайерами

3. Передача данных в ПЦ и платежную систему

⚪️API
⚪️Очереди сообщений (Kafka, RabbitMQ) — для асинхронной обработки платежных запросов

4. Проверка данных и авторизация в банке-эмитенте

⚪️API
⚪️OAuth 2.0 — механизм аутентификации и авторизации между сервисами
⚪️Системы антифрода (например, машинное обучение)

5. Завершение транзакции и списание средств

⚪️Real-time Payment Systems (например, СБП) — системы моментального перевода средств.
⚪️API


📎 Материалы
1. Платежные системы простыми словами. Как устроены и зачем нужны Mastercard, Visa, МИР и прочие
2. Интернет-эквайринг «для чайников»
3. Интернет-эквайринг в картинках
4. Как работает интернет-эквайринг
5. Платёжный сервис в банке, часть первая
6. Как мы переезжали на новый платежный сервис
7. Путешествие финансовой транзакции
8. Платёжные системы

#интеграции

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

🙂 Шаблонизаторы

Шаблонизаторы — инструменты для автоматической генерации текстовых данных на основе шаблонов и входных данных.

Используются в:
▫️API-интеграции: генерация HTTP-запросов и ответов, JSON/XML-запросов (например, Mustache в OpenAPI/Swagger)
▫️ESB: преобразование входящих сообщений в нужный формат (Freemarker в Apache Camel)
▫️MQ: формирование сообщений перед отправкой в очередь (Jinja2 в Celery, Handlebars)
▫️ETL: шаблоны для преобразования данных при загрузке в хранилище
▫️Создание конфигурационных файлов для разных окружений (Helm)
▫️Генерация технической документации
▫️Коде: создание CRUD-операций, DTO (Data Transfer Object), API-клиентов
▫️SQL: генерация динамических SQL-запросов, шаблоны для отчётов и аналитики (например, Jinja2 в dbt, Mustache в SQLAlchemy)


Примеры

⏪ Динамическое создание сценариев для разных ролей пользователей ⏩

Шаблон описывает процесс оформления заказа, но меняются условия для разных ролей:
🟡администратор может менять статус вручную
🟡менеджер получает уведомление
🟡клиент видит статус в личном кабинете
Вместо 3-х сценариев используется шаблон с переменными {role}, {action}, {notification}.
Например, с помощью Jinja2, Mustache

⏪ Гибкое преобразование данных ⏩

Форматы сообщений генерируются из шаблонов (например, FreeMarker или Jinja2):
🟡для банка нужен XML-формат: шаблон payment_template.xml
🟡для маркетинговой платформы JSON: шаблон email_template.json
🟡для ERP CSV-файл: шаблон orders_template.csv
Если банк меняет XML-структуру, достаточно обновить шаблон, а не переделывать всю интеграцию


Примеры шаблонизаторов

📌 Mustache — универсальный шаблонизатор для API, UI, конфигураций, доступен для различных языков программирования, включая JavaScript, Python и Ruby

✏️ Как применить
Разработка микросервисного API для обработки заказов

Проблемы:
❌ API-документация устаревает, обновлятся вручную
❌ доп время на написание Swagger/OpenAPI-описаний
❌ разные версии API дублируют документацию

Пример решения:
✔️ создается шаблон, где параметры API (методы, URL, заголовки) подставляются динамически
✔️ Swagger/OpenAPI автоматически заполняется актуальными значениями
✔️ любое изменение в коде API сразу отражается в документации


📌 FreeMarker — шаблонизатор на Java
Используется для генерации текстовых выходных данных (HTML, конфигурационные файлы, исходный код)

✏️Как применить:
Разработка веб-приложения

1. Динамическая генерация страниц (баланс, последние транзакции) с неизменной версткой

Контроллер Spring Boot передаёт в шаблон FreeMarker объект пользователя с балансом и историей операций.
FreeMarker подставляет данные в HTML и формирует готовую страницу
🔸если баланс больше 100 000₽, показывается статус «Премиум-клиент»
🔸если меньше 1000₽, предлагается «Пополнить баланс»
🔸история платежей подставляется в виде таблицы с циклом

2. Персонализация контента: разные предложения для пользователей

В шаблоне используются условия <#if> — если клиент VIP, добавляется блок с индивидуальными предложениями.
Контент обновляется без изменения логики бэкенда
🔸обычный клиент: «Оформите кредит под 10%»
🔸VIP-клиент: «Специальное предложение: кредит под 5%»

3. Повторное использование компонентов (хедер, меню, подвал) без копирования вручную

Общие шаблоны (layouts) с подключением через include
Если нужно изменить меню — правится один файл
-- все страницы используют один header.ftl* с логотипом и навигацией
-- в footer.ftl хранится контактная информация
-- основной шаблон (base.ftl) объединяет их в одну структуру
*FreeMarker Template Language (FTL)


📎 Материалы

1. Что такое и зачем нужны шаблонизаторы HTML
2. Текстовые шаблонизаторы и их реализация
3. Три неочевидных примера использования шаблонизаторов в backend-е
4. Шаблонизаторы HTML: что это и стоит ли их использовать в разработке
5. 15 шаблонизаторов для фронтенд-разработки
6. 6 лучших шаблонизаторов на PHP
7. 5 популярных PHP-шаблонизаторов
8. ТОП-10 шаблонизаторов HTML для web-разработки

#инфраструктура

➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

Может, познакомимся?

🔹 Канал активно ведётся уже почти 2 года, появилось 17+ тысяч подписчиков, а мы до сих пор не знакомы друг с другом. Надо исправляться.

Есть идея создать на базе нашего канала группу-комьюнити системных аналитиков, чтобы:
1. Обмениваться опытом друг с другом
2. Узнавать, как там работается в других местах
3. Что там по ЗП
4. Ну и просто болтать

Естественно, модерация и все дела.

💡 Есть также идея проводить митапы пару раз в месяц на определённые темы, за которые будут голосовать люди. Но нужны энтузиасты, которые готовы выступать НА ПУБЛИКУ 😱

💬 Пишите в комментариях всё, что думаете по этому поводу.

Ну а ниже предлагаем ответить на несколько вопросов и чуть-чуть узнать друг о друге.

👥 Коммьюнити аналитиков

Как и обещали, создаём группу-комьюнити системных аналитиков, чтобы:
1. Обмениваться опытом друг с другом
2. Узнавать, как там работается в других местах
3. Что там по ЗП
4. Ну и просто болтать

Навигация по группе

📣 Митапы — проводим онлайн-встречи. Здесь можно стать спикером или проголосовать за желаемые темы

❔ Взаимопомощь по работе — здесь можно попросить помощи у коллег и помочь самому

💬 Болталка — общение на свободные темы

📂 Обмен материалами и опытом — делимся с коллегами чем-то полезным

💸 Зарплаты и условия труда — обсуждаем, кому, где и как работается

💡 Идеи и предложения — любые ваши улучшения и пожелания по поводу организации нашей группы

💼 Поиск работы — обсуждаем резюме, вакансии, вопросы и задачи к собесам и т.д.

Ждём всех!

🔍Фильтр Блума

Фильтр Блума — структура данных, которая помогает быстро проверить, может ли элемент находится в наборе данных или точно его там нет
🟢Используется, когда проверка наличия элемента должна быть быстрой, а использование памяти минимальным


Работает как "чек-лист", отвечает:
-Может быть, элемент есть (иногда может ошибится)
-Точно элемента нет


Как работает?

🟢создается битовый массив длины m
🟢он состоит из 0 и 1
🟢изначально массив выглядит так: [0, 0, 0, 0, 0, 0, 0, 0]
🟢каждая позиция (индекс) в этом массиве и значения (0, 1) — всё, что фильтр "запоминает"

🍃Добавляется элемент

Например, id со значением 12345
1⃣Фильтр пропускает id через несколько хэш-функций
Хэш-функция — математический алгоритм, который превращает строку ("12345") в числа (индексы массива), например:
- hash_1("12345") → 2
- hash_2("12345") → 5
- hash_3("12345") → 7
2⃣ Фильтр "ставит галочки" на этих позициях, т.е. устанавливает биты на этих индексах = 1:
[0, 0, 1, 0, 0, 1, 0, 1]
Фильтр запоминает, что на позициях [2, 5, 7] что-то есть

🍃Проверка элемента

Чтобы узнать есть ли id = 54321 в фильтре Блума
id снова пропускается его через те же хэш-функции:
- hash_1("54321") → 1
- hash_2("54321") → 3
- hash_3("54321") → 6

Фильтр смотрит на эти индексы в массиве: [0, 0, 1, 0, 0, 1, 0, 1]

Позиция 1 = 0 → id = "54321" точно не добавлялся
Если бы добавлялся, то позиция 1 была бы = 1

🍃 Если все проверенные индексы равны 1, то фильтр говорит → может быть, элемент есть
🍃 Если хотя бы один бит на позициях, которые вычислили хэш-функции, равен 0 → элемент точно отсутствует


Чего нет в фильтре Блума

❌ не хранит сами данные (например, список id). Хранит информацию в битовом массиве ( создаётся в оперативной памяти RAM). Это компактное представление множества
❌ не знает ничего напрямую о добавленных элементах

❗️У него есть только массив битов (позиции, которые связаны с добавленными элементами) и хэш-функции (для поиска индексов)


Примеры применения

🍃в БД
- для ускорения поиска записей без полного сканирования таблиц
- в индексах для предварительной проверки наличия ключа
🍃в веб-приложениях для быстрой проверки, есть ли объект в кэше, без полного перебора
🍃в блокировке спама для проверки, был ли email уже отправлен
🍃для уменьшения сетевых запросов (в Cassandra или Redis). Для предварительной проверки наличия данных на узле. Если фильтр говорит "данных нет", система нре делает запрос к этому узлу
🍃в CDN (Content Delivery Network) для проверки, есть ли контент на edge-сервере


Недостатки

🔸стандартный фильтр Блума не поддерживает удаление элементов (есть модификации, например, Counting Bloom Filter)
🔸может ошибаться из-за коллизий хэш-функций: некоторые индексы в массиве могут пересекаться (это коллизии).
Пример:
"12345" ставит 1 на позициях [2, 5, 7]
"67890" ставит 1 на позициях [5, 7, 8]
Фильтр может ошибочно считать, что элемент есть, хотя его нет
🔸не подходит, если нужна точность 100%
🔸если фильтр переполняется, ложноположительные срабатывания становятся слишком частыми


📎 Материалы
1. Что такое фильтр Блума?
2. Фильтр Блума: зачем нужен и как работает
3. Что такое фильтр Блума и как он работает на практике (с примерами)
4. Что такое фильтр Блума в Blockchain?
5. Вероятностные структуры данных и где они обитают
6. Фильтр Блума – вероятностная структура данных для проверки принадлежности элемента множеству
7. Просто о сложном: что фильтрует фильтр Блума?
8. Фильтр Блума
9. Когда фильтр Блума не подходит

#инфраструктура

➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

📄Подборка шаблонов документации

Общее
1. Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения — опыт Альфы
2. Ликбез по техническому заданию
3. Как оформить спецификацию, чтобы не запутаться самому и не выбесить коллег
4. Для архитекторов и аналитиков: шаблон описания архитектуры приложения (34 страницы пользы)
5. Как выжать максимум из Confluence: часть 1, часть 2
6. Матрица трассировки требований: руководство для системного аналитика

Стандарты
1. Стандарты и шаблоны для ТЗ на разработку ПО — обзор
2. Разработка Технического задания по ГОСТ 34 легко и просто — полный гайд по ТЗ ГОСТ 34

Docs as Code
1. Опыт аналитиков Альфы про доку в коде
2. Docs as Code: как вести фронтовую документацию рядом с кодом, чтобы репозиторий не раздуло — опыт Альфы

Интеграции
1. Как создать шаблон документации к микросервису — МТС
2. Пример ТЗ для описания API⁠⁠
3. Шаблоны документации API
4. Как написать свою первую спецификацию на REST API
5. Как мы описываем требования к REST API для бэкенда в Confluence — Magnit Tech
6. REST API: заполненный шаблон постановки задачи
7. Шаблон постановки задачи на REST API-метод для Confluence
8. Полная постановка задачи на интеграцию - заполненный шаблон требований

Требования
1. Шаблон спецификации требований
2. Как мы создали шаблон функциональных требований к разработке ПО
3. Шаблон пользовательских историй

➿➿➿➿➿➿➿➿
Для пользователей базы знаний доступны реальные сокровенные шаблоны спек от аналитиков одной из жёлтых компаний, да и вообще там много полезного

Непрерывное развитие АРI.
Правильные решения в изменчивом технологическом ландшафте

✍️ Автор: Мехди Меджуи, Эрик Уайлд, Ронни Митра, Майк Амундсен
🗓 Год издания: 2023
🔤 Язык: русский
📚 Объём: 368 стр.

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

Книга охватывает:
💙 сложности управления API (масштабирование, стандарты, работа команд)
💙 стратегическое руководство (баланс централизации и гибкости)
💙 API как продукт (дизайн-мышление, опыт разработчиков, конкурентные преимущества)
💙 10 столпов успешного API — от стратегии и безопасности до мониторинга и продвижения
💙 стили API и жизненный цикл (создание, публикация, окупаемость, поддержка, удаление)
💙 работу команд (роли, масштабирование, культура).
💙 системы API (управление в крупных экосистемах, контроль версий, изменения)


#api

🙂 Docs as Code

Docs as Code – подход к созданию и сопровождению документации.
🟢для работы с документами используются те же инструменты и процессы, что и для программного кода.
🟢текст пишут на языке разметки (Markdown, AsciiDoc), хранят в Git-репозитории и собирают с помощью генераторов сайтов (например, GitLab Pages, Docusaurus, Antora)
🟢публикуемая версия всегда синхронизирована с кодом и доступна потребителям


💡Идея: документация разрабатывается как код

Ообращение с текстом документации, как с исходным кодом приложения:
💠хранится в системе контроля версий
💠проверка изменений через pull request’ы
💠автоматизированно собирать и публиковать и т.д.

❕ Документация может храниться как в одном репозитории с кодом, так и в отдельном
Но всегда должна быть актуальной и согласованной с кодом (как и наоборот)


Суть подхода

Документация:
🔵хранится в репозитории Git
🔵пишется в IDE (VS Code или IDEA) с настроенными плагинами
🔵пишется на выбранном языке разметки, диаграммы описываются в формате кода (PlantUML, mermaid и др.)
🔵собирается при помощи генератора сайтов (например, Docusaurus)


Принципы написания документации

Написание спецификаций следует принципам написания кода, но имеет свои специфичные принципы

〰 Принципы из разработки

🟢DRY (Don’t Repeat Yourself)
Не дублируем информацию: один факт — один источник, остальные ссылаются

🟢KISS (Keep It Simple, Stupid)
Держим форму и язык простыми, без лишних деталей.

🟢YAGNI (You Aren’t Gonna Need It)
Пишем только то, что нужно прямо сейчас; гипотезы и «на будущее» убираем

🟢SRP (Single Responsibility Principle)
Один раздел — одна тема или функция

🟢SLAP (Single Level of Abstraction Principle)
Уровни абстракции не смешиваем: обзор и детали храним раздельно

🟢LoD (Law of Demeter)
Ссылаемся только на ближайший нужный контекст, избегаем дальних зависимостей


〰 Принципы, относящиеся к спецификациям

🟢читабельность — короткие абзацы, активные глаголы, минимум терминов
🟢единый стиль кодирования (структура текста, отступы, пробелы и т.д.) для облегчения понимания. Разрабатываются единые шаблоны документации и готовые блоки кода
🟢диаграммы как код — PlantUML, Mermaid, LikeC4: диаграммы генерируются из текста
🟢автоматизация пайплайна — CI проверяет орфографию, битые ссылки, формат
🟢отслеживание изменений, обновлений и исправлений в документах при помощи Changelog
🟢опубликованная версия документации является актуальной проду
🟢Merge Request, вливаемые в master, проходят ревью - без получения аппрува сделать mr нельзя
🟢Merge Request с изменениями в документации привязываются к задачам в Jira


Хранение документации

✳️ Рядом с кодом
Документация лежит в том же репозитории, что и сервис. Обычно в каталоге /docs.

Каждая ветка и тег кода несут свою версию текстов.
➡️ пример: GitLab хранит руководство пользователя в том же репозитории, чтобы изменения в продукте и тексте шли синхронно.

✳️ В отдельном репозитории
Документация развивается в своём проекте (или нескольких), независимом от исходников сервисов

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


📎 Материалы
1. Docs as Code: введение в предмет
2. Опыт аналитиков Альфы про доку в коде
3. Docs as Code: как вести фронтовую документацию рядом с кодом, чтобы репозиторий не раздуло — опыт Альфы
4. Documentation as code: практики и инструменты документирования в сфере финансовых технологий
5. Статья о Docs as code от техписов - сайт собран как код на Rst
6. Инструменты подхода Docs-as-code

#инфраструктура #документация

➿➿➿➿➿➿➿➿
🧑‍🎓 Глубже по теме Docs as Code смотрите в Базе знаний по системному анализу :
⏺преимущества и недостатки Docs as Code
⏺сравнение с Confluence и другими подходами
⏺как понять, что Docs as Code действительно работает
⏺обзор инструментов
⏺пошаговое руководство, как внедрить Docs as Code
⏺как выбрать подход к документации

А ещё там 140+ статей и 2500+ ссылок на материалы -- и всё разложено по полочкам, как мы любим.

👀 Метрики и мониторинг

🙃 Метрики — данные, которые измеряют состояние системы
😂 Мониторинг — процесс сбора, анализа и визуализации этих метрик (для контроля работы системы и реагирования на проблемы)

Примеры типов метрик

😥Бизнес-метрики: отражают эффективность бизнес-процессов
(конверсия, средний чек, количество активных пользователей)
😥Технические: состояние инфраструктуры и приложений
(загрузка CPU, время ответа сервера, количество ошибок)
😥Пользовательские: оценка опыта пользователей
(время загрузки страницы, кол-во кликов до целевого действия)


Примеры технических метрик

Серверные
⭕CPU: загрузка процессора (%)
⭕Memory: использование оперативной памяти (%)
⭕Disk: использование дискового пространства (%), скорость чтения/записи
⭕Network: входящий/исходящий трафик (Мбит/с), кол-во соединений
Приложений
⭕Время ответа API (мс)
⭕Кол-во HTTP-запросов и ошибок (500, 404)
⭕Кол-во активных сессий
БД
⭕Время выполнения запроса (мс)
⭕Кол-во активных соединений
⭕Кол-во медленных запросов


Методологии анализа метрик

😂 USE

Анализ производительности ресурсов (CPU, память, диски, сеть)
Для инфраструктурных метрик
😍Utilization (Использование): какую часть ресурса используют (загрузка CPU на 80%)
😍Saturation (Насыщение): насколько ресурс перегружен (очередь запросов к диску)
😍Errors (Ошибки): например, ошибки чтения/записи

😂 RED

Для для мониторинга сервисов (часто микросервисов), API
😍Rate (Частота): кол-во запросов или событий в единицу времени (500 запросов в сек)
😍Errors (Ошибки): например, 10 ошибок "500" за мин)
😍Duration (Длительность): время выполнения запроса (среднее время ответа API — 200 мс, или  95-й перцентиль* времени ответа — 300 мс)
*какой % значений ниже определённого значения

😂 LTES

Расширенная версия RED, для сложных распределённых систем
😍Latency (Задержка): время ответа системы (ответ API  за 150 мс, или в бд время выполнения запроса — 50 мс)
😍Traffic (Трафик): кол-во запросов / данных (10 ГБ входящего трафика, в бд 5000 запросов в минуту)
😍Errors (Ошибки)
😍Saturation (Насыщение): насколько ресурс перегружен (загрузка памяти 90%, в бд очередь запросов 20 шт)


Подходы к сбору метрик

💚Push-модель
Агенты на серверах/приложениях отправляют данные на сервер мониторинга
➡ Prometheus Pushgateway: для отправки метрик от краткосрочных задач (например, cron-задач)
➡ Zabbix Agent: агент собирает данные (CPU, память, диски) и отправляет их на сервер Zabbix

💚 Pull-модель
Сервер мониторинга  запрашивает данные у агентов или экспортеров
Меньше нагрузки на сеть, сервер контролирует частоту запросов
➡ Prometheus Scrape: каждые 15 сек запрашивает метрики загрузки CPU у Node Exporter, установленного на сервере
➡ SNMP: протокол для мониторинга сетевых устройств (роутеры, свитчи)

💚 Логирование
Анализ логов для извлечения метрик (кол-во ошибок, время выполнения запросов)
Универсальный подход, логи есть почти везде
Можно анализировать исторические данные
➡ ELK (Elasticsearch, Logstash, Kibana) : Logstash собирает логи веб-сервера, парсит их и отправляет в Elasticsearch, Kibana визуализирует ошибки
➡ Grafana Loki: легковесное решение для анализа логов

💚Трейсинг
Отслеживание запросов через распределённую систему
Позволяет понять, как запрос проходит через компоненты системы
➡ Jaeger: отправляется запрос к API. Отслеживает, как он проходит через API Gateway, микросервис A и БД, измеряется время выполнения всех этапов


Инструменты мониторинга

Grafana: визуализация метрик
Prometheus: сбор и хранение метрик
ELK: логирование и анализ событий
Zabbix: мониторинг инфраструктуры
Nagios: мониторинг сетей и серверов


📎Материалы
1. Мониторинг начинается с метрик | Часть 2: серверное ПО
2. Как построить эффективную стратегию мониторинга
3. Основы мониторинга и сбора метрик
4. Мониторинг и сбор метрик
5. Руководство по мониторингу производительности сервера
6. Выбираем оптимальную архитектуру мониторинга
7. Как организовать мониторинг в мультипроцессорном режиме

#инфраструктура

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

🔵 BASE

BASE (Basically Available, Soft state, Eventually consistent) — подход к проектированию распределённых систем
Жертвует строгой согласованностью (ACID) ради доступности, масштабируемости и гибкости

Когда используют

💠NoSQL-системы (Cassandra, MongoDB)
💠высоконагруженные сервисы (соцсети, аналитика)
💠системы, где важнее скорость ответа и отказоустойчивость, чем мгновенная актуальность данных


Три принципа BASE

😃asically Available (базовая доступность)

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

✏️ Как достигается
✨репликация (копирование данных на несколько узлов)
✨шардирование (данные делятся между кластерами)
✨кэширование


😓oft State (гибкое состояние)

Данные могут меняться со временем без внешних запросов
И могут временно находиться в несогласованном состоянии из-за асинхронных обновлений

✏️ Как достигается
✨асинхронная синхронизация
✨TTL (время жизни данных, например, обновление кэша раз в 5 мин)
✨фоновые процессы согласования


😶‍🌫️ventually Consistent (окончательная согласованность)

Система придет к согласованности, но не мгновенно

✏️ Как достигается
✨конфликт-разрешающие алгоритмы (например, CRDT, LWW)
✨подтверждение записи от большинства узлов (в Cassandra)
✨Read-Repair (исправление устаревших данных при следующих чтениях)
✨Kafka или RabbitMQ с отложенной синхронизацией


BASE vs ACID vs CAP

⭐ACID — как банковский перевод: либо деньги ушли и пришли полностью, либо операция отменена. Для систем, где важна точность (платежи, бухгалтерия)
⭐BASE — как почта: письмо точно ушло, но когда дойдёт — неизвестно

БД не может быть и ACID и BASE одновременно
Это противоположные подходы
Но некоторые гибридные СУБД (например, MongoDB) позволяют гибко настраивать уровень согласованности

⭐CAP — определяет фундаментальные ограничения распределённых систем
⭐BASE — практический подход в рамках этих ограничений

CAP-теорема: система может гарантировать только 2 из 3 свойств:
💠 cогласованность
💠 доступность
💠 устойчивость к разделению

✔ ACID выбирает CP (согласованность + устойчивость)
✔ BASE - AP (доступность + устойчивость)
✔ CA-системы (консистентность и доступность) возможны только в нераспределенных системах


Пример реализации BASE

Онлайн-магазин с высокой нагрузкой

😃: пользователь добавляет товар в корзину → система сразу подтверждает действие, даже если часть серверов перегружена

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

➡️ отправка запроса → API сразу возвращает успех (202 Accepted)

😓: данные о корзине и об остатках лежат в разных сервисах

Если два покупателя одновременно добавляют последний товар → оба увидят его в корзине, но физически доступен только 1

➡️ сервис корзин (Redis) временно сохраняет изменения
Сервис склада (Kafka + PostgreSQL) асинхронно проверяет остатки

😶‍🌫️: через несколько сек система проверяет остатки и синхронизирует данные

➡️ если товара нет, система убирает из корзины и отправляет уведомление


😃В ACID система заблокировала бы остатки при добавлении в корзину → очереди и ошибки под нагрузкой
BASE позволяет сначала принять действие, потом проверить ограничения
Это критично для высоконагруженных сценариев


📎 Материалы
1. BASE
2. Как бы я сейчас объяснил молодому себе… зачем существуют требования ACID для баз данных?
3. Требования ACID. BASE модель. CAP теорема
4. БАЗОВАЯ модель разработки БД
5. NoSQL: что это такое, отличие от других баз данных, BASE

📚Базы данных. Инжиниринг надежности - Кэмпбелл Лейн, Мейджорс Черити (Глава 11. BASE)

#бд

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу