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

1. МИКРОСЕРВИСНАЯ
АРХИТЕКТУРА В ТЕОРИИ И НА
ПРАКТИКЕ:
ОПЫТ «СКБ КОНТУР»
Иван Бурмистров
Иван Дашкевич
Александр Казаков

2. Agenda
• Стек: .NET, IIS, Windows
• Сервисы: EDI, Диадок, Экстерн
• Сложность архитектуры: S → M → L → XL

3. Микросервис: что это?
• То же, что буква S в аббревиатуре SOA
• Легковесное приложение, решающее ровно одну задачу
• Небольшая утилита из не более чем 100 строк кода
• Что угодно с публичным API через HTTP протокол
• Компонент системы, работу которого знает «от» и «до» хотя бы
один разработчик в команде
• …

4. Микросервисы: опыт «СКБ Контур»
• Микросервис – это отдельный процесс
• От 1-2 до нескольких сотен микросервисов в продуктах
• Где 10, там и 20
• На разных этапах развития требуются разные подходы

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

6. «Размер S»: must have
• Логирование: нужно знать, почему у пользователя ошибка.
Используем стандартные средства логирования (в нашем случае
log4net)
• Обновление схемы БД: помнить про возможные несовместимые
изменения

7. «S» → «M»

8. «S» → «M»

9. «S» → «M»
JavaScript, html
Front Cassandra
Front
Nginx

10. «S» → «M»
JavaScript, html
Front Cassandra
Front
Nginx Index

11. «S» → «M»
JavaScript, html
Front Cassandra
Front
Nginx
Письма Печать pdf
Index
Queue

12. «Размер M»: ключевые цифры
• 4-6 разработчиков
• 1-6 Тб данных
• 10 микросервисов
• 10 физических серверов

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

14. Проблема: все время что-то «лежит»
• Решение: Мониторинг «живости» - достаточно простых скриптов

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

16. Проблема: ручное обновление – стресс
• Решение: Автоматизированный деплой (простые скрипты)

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

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

19. Проблема: Service Discovery

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

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

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

23. «M» → «L»

24. Диадок
8 разработчиков
70 микросервисов

25. Проблема: как искать, где ошибка?
JavaScript, html
FrontNginx
ПисьмаIndex

26. Решение: request-id
• Пробрасывать
• Через Http
• В Rabbit-хэндлеры
• В порождаемые потоки
• Не забывать логировать
• Log4net ThreadContext

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

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

29. Проблема: а жив ли сервис?
• Мониторинг живости – маловато будет
• Нужен мониторинг адекватности

30. Решение: graphite, grafana, seyren
• Graphite – хранит факты, умеет строить графики
• Встроить запись в графит:
• Http: сервер/клиент
• RabbitMQ: enqueue/dequeuer
• Периодические процессы (по расписанию или по таймауту)
• Grafana
• Seyren

31. Проблема: deployment
• Требуется:
• Разливать новые версии
• Запускать/останавливать новые реплики
• Накат/откат новых версий
• Смотреть состояние

33. Проблема: service discovery
• Синхронизация
• Полнота

34. Решение: решать можно по разному
• Вариант: заточить свой инструмент деплоя
• Вариант: централизованное хранение
• В Контур-Экстерне: ClusterConfig

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

36. Контур-Экстерн
70 разработчиков
10 команд
250 TB основное хранилище
более 200 различных сервисов
более 1500 работающих экземпляров (реплик)

37. Team 2 Team 3
Team 1

38. Team 2 Team 3
Team 1

39. Team 2 Team 3
Team 1
Проблема: сложность взаимодействия с внешними сервисами

40. Team 2 Team 3
Team 1
API
API API
API API
API

41. Внешний API
• Версионность

42. Внешний API
• Версионность
• Документация

43. Внешний API
• Версионность
• Документация
• RESTful

44. а внутренний ?
Внешний API
• Версионность
• Документация
• RESTful

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

46. RESTful API — игрушка для девочек
Настоящий мужик напишет хорошего клиента

47. R1
R2
R3

48. R1
R2
R3

49. timeout
R1
R2
R3

50. R1
R2
R3

51. timeout = 30 sec
30% requests > 30 sec
R1
R2
R3

52. “Разумный” timeout
Желаемый отклик
Особенность сервиса

53. timeout = 10 sec
t (sec)
0
Сервис 2Сервис 1

54. timeout = 10 sec
request time ~ 12 sec
t (sec)
0
10
20
30
100
Сервис 2Сервис 1
ERR

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

56. Стратегии отправки запросов
Последовательная (линейная)

57. Стратегии отправки запросов
Последовательная (линейная)
Параллельная

58. Стратегии отправки запросов
Последовательная (линейная)
Параллельная
Адаптивная параллельность

59. t0 T/3 2T/3 T
R1
R2
R3

60. timeout=T
t0 T/3 2T/3 T
мы тут
R1
R2
R3

61. t0 T/3 2T/3 T
мы тут
OK R1
R2
R3

62. timeout=T
t0 T/3 2T/3 T
timeout=2T/3
мы тут
R1
R2
R3

63. timeout=T
t0 T/3 2T/3 T
timeout=2T/3
timeout=T/3
мы тут
R1
R2
R3

64. OK
timeout=T
t0 T/3 2T/3 T
timeout=2T/3
timeout=T/3
мы тут
R1
R2
R3

65. t0 1 5 15 30
R1
R2
R3
R4

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

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

68. client.Call(attempts=3)

69. Количество попыток отправки запроса
Крайний случай № 1
Все 3 попытки сдохли за 10 мс

70. Количество попыток отправки запроса
Крайний случай № 2
Каждая из 3-х попыток зависла на 30 сек
Клиент отвалился через 15 секунд

71. client.Call(timeout=5000)

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

73. Team NTeam 1 …
Ops

74. Team NTeam 1 …
Ops
Проблема: зоопарк технологий и подходов для деплоя и мониторинга

75. Team NTeam 1 …
Ops
Проблема: зоопарк технологий и подходов для деплоя и мониторинга
Решение: DevOps
DevOps

76. Итого
• Размер S: логирование, обновление схемы БД
• Размер M: скрипты для простого мониторинга, деплоя, думать
при обновлениях
• Размер L: трассировка запросов, централизованные логи,
продвинутый деплой, метрики
• Размер XL: RESTful API, версионность, SDK, отдел DevOps