МИКРОСЕРВИСНАЯ АРХИТЕКТУРА В ТЕОРИИ И НА

ПРАКТИКЕ: ОПЫТ «СКБ КОНТУР»

Иван Бурмистров

Иван Дашкевич

Александр Казаков

Agenda

• Стек: .NET, IIS, Windows

• Сервисы: EDI, Диадок, Экстерн

• Сложность архитектуры: S → M → L → XL

Микросервис: что это?

• То же, что буква S в аббревиатуре SOA

• Легковесное приложение, решающее ровно одну задачу

• Небольшая утилита из не более чем 100 строк кода

• Что угодно с публичным API через HTTP протокол

• Компонент системы, работу которого знает «от» и «до» хотя бы один разработчик в команде

• …

Микросервисы: опыт «СКБ Контур»

• Микросервис – это отдельный процесс

• От 1-2 до нескольких сотен микросервисов в продуктах

• Где 10, там и 20

• На разных этапах развития требуются разные подходы

Продукт размера S (ранний EDI)Некогда объяснять, нужно делать фичи. Срочно.

JavaScript, html

Front

Cassandra

Front

Nginx

«Размер S»: must have

• Логирование: нужно знать, почему у пользователя ошибка. Используем стандартные средства логирования (в нашем случае log4net)

• Обновление схемы БД: помнить про возможные несовместимые изменения

«S» → «M»

«S» → «M»

«S» → «M»

JavaScript, html

Front Cassandra

Front

Nginx

«S» → «M»

JavaScript, html

Front Cassandra

Front

Nginx Index

«S» → «M»

JavaScript, html

Front Cassandra

Front

Nginx

Письма Печать pdf

IndexQueue

«Размер M»: ключевые цифры

• 4-6 разработчиков

• 1-6 Тб данных

• 10 микросервисов

• 10 физических серверов

Проблема: все время что-то «лежит»

Проблема: все время что-то «лежит»

• Решение: Мониторинг «живости» - достаточно простых скриптов

Проблема: ручное обновление – стресс

Проблема: ручное обновление – стресс

• Решение: Автоматизированный деплой (простые скрипты)

Проблема: все время заканчивается место

Проблема: все время заканчивается место

• Решение: Скрипт мониторинга свободного места, ручная очистка

Проблема: Service Discovery

Проблема: Service Discovery

• Решение: Достаточно файликов рядом с каждым микросервисом + голова при обновлениях

Проблема: протокол взамодействия

Проблема: протокол взамодействия

• Решение: Выбрать удобный сериализатор (например, protobuf) + голова при обновлениях

«M» → «L»

Диадок

8 разработчиков70 микросервисов

Проблема: как искать, где ошибка?

JavaScript, html

FrontNginx

ПисьмаIndex

Решение: request-id

• Пробрасывать• Через Http

• В Rabbit-хэндлеры

• В порождаемые потоки

• Не забывать логировать• Log4net ThreadContext

Проблема: как искать, что случилось?

• Не ясно, за какой диапазон искать

• Не ясно, в логах какого сервиса искать

• Все это также очень долго

Решение: централизованное логирование

Проблема: а жив ли сервис?

• Мониторинг живости – маловато будет

• Нужен мониторинг адекватности

Решение: graphite, grafana, seyren

• Graphite – хранит факты, умеет строить графики

• Встроить запись в графит:• Http: сервер/клиент

• RabbitMQ: enqueue/dequeuer

• Периодические процессы (по расписанию или по таймауту)

• Grafana

• Seyren

Проблема: deployment

• Требуется:• Разливать новые версии

• Запускать/останавливать новые реплики

• Накат/откат новых версий

• Смотреть состояние

Проблема: service discovery

• Синхронизация

• Полнота

Решение: решать можно по разному

• Вариант: заточить свой инструмент деплоя

• Вариант: централизованное хранение• В Контур-Экстерне: ClusterConfig

Продукт размера XLБольшой продукт, несколько команд

Контур-Экстерн

70 разработчиков10 команд

250 TB основное хранилище

более 200 различных сервисовболее 1500 работающих экземпляров (реплик)

Team 2 Team 3

Team 1

Team 2 Team 3

Team 1

Team 2 Team 3

Team 1

Проблема: сложность взаимодействия с внешними сервисами

Team 2 Team 3

Team 1

API

API API

API API

API

Внешний API

• Версионность

Внешний API

• Версионность

• Документация

Внешний API

• Версионность

• Документация

• RESTful

а внутренний ?

Внешний API

• Версионность

• Документация

• RESTful

RESTful API — игрушка для девочек

RESTful API — игрушка для девочек

Настоящий мужик напишет хорошего клиента

R1

R2

R3

R1

R2

R3

timeout

R1

R2

R3

R1

R2

R3

timeout = 30 sec

30% requests > 30 sec

R1

R2

R3

“Разумный” timeout

Желаемый отклик

Особенность сервиса

timeout = 10 sec

t (sec)

0

Сервис 2Сервис 1

timeout = 10 sec

request time ~ 12 sec

t (sec)

0

10

20

30

100

Сервис 2Сервис 1

ERR

Стратегии отправки запросов

Стратегии отправки запросов

Последовательная (линейная)

Стратегии отправки запросов

Последовательная (линейная)

Параллельная

Стратегии отправки запросов

Последовательная (линейная)

Параллельная

Адаптивная параллельность

t0 T/3 2T/3 T

R1

R2

R3

timeout=T

t0 T/3 2T/3 T

мы тут

R1

R2

R3

t0 T/3 2T/3 T

мы тут

OK R1

R2

R3

timeout=T

t0 T/3 2T/3 T

timeout=2T/3

мы тут

R1

R2

R3

timeout=T

t0 T/3 2T/3 T

timeout=2T/3

timeout=T/3

мы тут

R1

R2

R3

OK

timeout=T

t0 T/3 2T/3 T

timeout=2T/3

timeout=T/3

мы тут

R1

R2

R3

t0 1 5 15 30

R1

R2

R3

R4

Написал сервис — напиши клиента

Сколько делать попыток?

client.Call(attempts=3)

Количество попыток отправки запроса

Крайний случай № 1

Все 3 попытки сдохли за 10 мс

Количество попыток отправки запроса

Крайний случай № 2

Каждая из 3-х попыток зависла на 30 сек

Клиент отвалился через 15 секунд

client.Call(timeout=5000)

Думайте сами, решайте сами…

Team NTeam 1 …

Ops

Team NTeam 1 …

Ops

Проблема: зоопарк технологий и подходов для деплоя и мониторинга

Team NTeam 1 …

Ops

Проблема: зоопарк технологий и подходов для деплоя и мониторинга

Решение: DevOps

DevOps

Итого

• Размер S: логирование, обновление схемы БД

• Размер M: скрипты для простого мониторинга, деплоя, думать при обновлениях

• Размер L: трассировка запросов, централизованные логи, продвинутый деплой, метрики

• Размер XL: RESTful API, версионность, SDK, отдел DevOps