Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DUMP-2015 «Микросервисная архитектура в теории и на практике» Иван Бурмистров, Александр Казаков, СКБ Контур

1,677 views

Published on

Выступление на DUMP-2015.

Published in: Internet
  • Be the first to comment

DUMP-2015 «Микросервисная архитектура в теории и на практике» Иван Бурмистров, Александр Казаков, СКБ Контур

  1. 1. МИКРОСЕРВИСНАЯ АРХИТЕКТУРА В ТЕОРИИ И НА ПРАКТИКЕ: ОПЫТ «СКБ КОНТУР» Иван Бурмистров Иван Дашкевич Александр Казаков
  2. 2. Agenda • Стек: .NET, IIS, Windows • Сервисы: EDI, Диадок, Экстерн • Сложность архитектуры: S → M → L → XL
  3. 3. Микросервис: что это? • То же, что буква S в аббревиатуре SOA • Легковесное приложение, решающее ровно одну задачу • Небольшая утилита из не более чем 100 строк кода • Что угодно с публичным API через HTTP протокол • Компонент системы, работу которого знает «от» и «до» хотя бы один разработчик в команде • …
  4. 4. Микросервисы: опыт «СКБ Контур» • Микросервис – это отдельный процесс • От 1-2 до нескольких сотен микросервисов в продуктах • Где 10, там и 20 • На разных этапах развития требуются разные подходы
  5. 5. Продукт размера S (ранний EDI) Некогда объяснять, нужно делать фичи. Срочно. JavaScript, html Front Cassandra Front Nginx
  6. 6. «Размер S»: must have • Логирование: нужно знать, почему у пользователя ошибка. Используем стандартные средства логирования (в нашем случае log4net) • Обновление схемы БД: помнить про возможные несовместимые изменения
  7. 7. «S» → «M»
  8. 8. «S» → «M»
  9. 9. «S» → «M» JavaScript, html Front Cassandra Front Nginx
  10. 10. «S» → «M» JavaScript, html Front Cassandra Front Nginx Index
  11. 11. «S» → «M» JavaScript, html Front Cassandra Front Nginx Письма Печать pdf Index Queue
  12. 12. «Размер M»: ключевые цифры • 4-6 разработчиков • 1-6 Тб данных • 10 микросервисов • 10 физических серверов
  13. 13. Проблема: все время что-то «лежит»
  14. 14. Проблема: все время что-то «лежит» • Решение: Мониторинг «живости» - достаточно простых скриптов
  15. 15. Проблема: ручное обновление – стресс
  16. 16. Проблема: ручное обновление – стресс • Решение: Автоматизированный деплой (простые скрипты)
  17. 17. Проблема: все время заканчивается место
  18. 18. Проблема: все время заканчивается место • Решение: Скрипт мониторинга свободного места, ручная очистка
  19. 19. Проблема: Service Discovery
  20. 20. Проблема: Service Discovery • Решение: Достаточно файликов рядом с каждым микросервисом + голова при обновлениях
  21. 21. Проблема: протокол взамодействия
  22. 22. Проблема: протокол взамодействия • Решение: Выбрать удобный сериализатор (например, protobuf) + голова при обновлениях
  23. 23. «M» → «L»
  24. 24. Диадок 8 разработчиков 70 микросервисов
  25. 25. Проблема: как искать, где ошибка? JavaScript, html FrontNginx ПисьмаIndex
  26. 26. Решение: request-id • Пробрасывать • Через Http • В Rabbit-хэндлеры • В порождаемые потоки • Не забывать логировать • Log4net ThreadContext
  27. 27. Проблема: как искать, что случилось? • Не ясно, за какой диапазон искать • Не ясно, в логах какого сервиса искать • Все это также очень долго
  28. 28. Решение: централизованное логирование
  29. 29. Проблема: а жив ли сервис? • Мониторинг живости – маловато будет • Нужен мониторинг адекватности
  30. 30. Решение: graphite, grafana, seyren • Graphite – хранит факты, умеет строить графики • Встроить запись в графит: • Http: сервер/клиент • RabbitMQ: enqueue/dequeuer • Периодические процессы (по расписанию или по таймауту) • Grafana • Seyren
  31. 31. Проблема: deployment • Требуется: • Разливать новые версии • Запускать/останавливать новые реплики • Накат/откат новых версий • Смотреть состояние
  32. 32. Проблема: service discovery • Синхронизация • Полнота
  33. 33. Решение: решать можно по разному • Вариант: заточить свой инструмент деплоя • Вариант: централизованное хранение • В Контур-Экстерне: ClusterConfig
  34. 34. Продукт размера XL Большой продукт, несколько команд
  35. 35. Контур-Экстерн 70 разработчиков 10 команд 250 TB основное хранилище более 200 различных сервисов более 1500 работающих экземпляров (реплик)
  36. 36. Team 2 Team 3 Team 1
  37. 37. Team 2 Team 3 Team 1
  38. 38. Team 2 Team 3 Team 1 Проблема: сложность взаимодействия с внешними сервисами
  39. 39. Team 2 Team 3 Team 1 API API API API API API
  40. 40. Внешний API • Версионность
  41. 41. Внешний API • Версионность • Документация
  42. 42. Внешний API • Версионность • Документация • RESTful
  43. 43. а внутренний ? Внешний API • Версионность • Документация • RESTful
  44. 44. RESTful API — игрушка для девочек
  45. 45. RESTful API — игрушка для девочек Настоящий мужик напишет хорошего клиента
  46. 46. R1 R2 R3
  47. 47. R1 R2 R3
  48. 48. timeout R1 R2 R3
  49. 49. R1 R2 R3
  50. 50. timeout = 30 sec 30% requests > 30 sec R1 R2 R3
  51. 51. “Разумный” timeout Желаемый отклик Особенность сервиса
  52. 52. timeout = 10 sec t (sec) 0 Сервис 2Сервис 1
  53. 53. timeout = 10 sec request time ~ 12 sec t (sec) 0 10 20 30 100 Сервис 2Сервис 1 ERR
  54. 54. Стратегии отправки запросов
  55. 55. Стратегии отправки запросов Последовательная (линейная)
  56. 56. Стратегии отправки запросов Последовательная (линейная) Параллельная
  57. 57. Стратегии отправки запросов Последовательная (линейная) Параллельная Адаптивная параллельность
  58. 58. t0 T/3 2T/3 T R1 R2 R3
  59. 59. timeout=T t0 T/3 2T/3 T мы тут R1 R2 R3
  60. 60. t0 T/3 2T/3 T мы тут OK R1 R2 R3
  61. 61. timeout=T t0 T/3 2T/3 T timeout=2T/3 мы тут R1 R2 R3
  62. 62. timeout=T t0 T/3 2T/3 T timeout=2T/3 timeout=T/3 мы тут R1 R2 R3
  63. 63. OK timeout=T t0 T/3 2T/3 T timeout=2T/3 timeout=T/3 мы тут R1 R2 R3
  64. 64. t0 1 5 15 30 R1 R2 R3 R4
  65. 65. Написал сервис — напиши клиента
  66. 66. Сколько делать попыток?
  67. 67. client.Call(attempts=3)
  68. 68. Количество попыток отправки запроса Крайний случай № 1 Все 3 попытки сдохли за 10 мс
  69. 69. Количество попыток отправки запроса Крайний случай № 2 Каждая из 3-х попыток зависла на 30 сек Клиент отвалился через 15 секунд
  70. 70. client.Call(timeout=5000)
  71. 71. Думайте сами, решайте сами…
  72. 72. Team NTeam 1 … Ops
  73. 73. Team NTeam 1 … Ops Проблема: зоопарк технологий и подходов для деплоя и мониторинга
  74. 74. Team NTeam 1 … Ops Проблема: зоопарк технологий и подходов для деплоя и мониторинга Решение: DevOps DevOps
  75. 75. Итого • Размер S: логирование, обновление схемы БД • Размер M: скрипты для простого мониторинга, деплоя, думать при обновлениях • Размер L: трассировка запросов, централизованные логи, продвинутый деплой, метрики • Размер XL: RESTful API, версионность, SDK, отдел DevOps

×