Как рефакторить архитектуру микросервисов при живом продакшне?

Презентация с тезисами к докладу Руслана Сафина "Как рефакторить архитектуру микросервисов при живом продакшне?"

Описание доклада:
Даже грамотно спроектированная микросервисная архитектура с течением времени требует пересмотра и рефакторинга.
* Как не пропустить этот момент в случае проектирования и разработки с нуля?
* Как понять, что легаси-микросервисы спроектированы не лучшим образом?
* Как, собственно, начать рефакторинг архитектуры и, что немаловажно, закончить его и довести до прода в виде реализации?

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

А также порассуждаем, как же жить с двумя и более версиями архитектуры, пока рефакторинг ещё не доехал до прода.

Transcript

1. Как рефакторить архитектуру
   микросервисов при живом продакшне?
   Руслан Сафин
   Byndyusoft
   

   View Slide

2. Обо мне
   • CTO в Byndyusoft.com
   • Развиваю техническую культуру в компании
   • Участвую в проектах в роли IT-архитектора
   • Преподаю IT-архитектуру в университете
   Byndyusoft — это заказная разработка с продуктовым подходом. Среди
   наших заказчиков:
   

   View Slide

3. От распила монолита к рефакторингу
   микросервисов
   

   View Slide

4. Рефакторинг архитектуры. Ожидание
   💩
   💩💩💩
   💩💩
   💎💎
   💎💎💎
   💎💎
   

   View Slide

5. Реальность
   💩
   💩💩💩
   💩💩
   💎💎
   💎💎💎
   💎💎
   

   View Slide

6. План
   1. Рефакторинг архитектуры в случае микросервисов
   2. Пример архитектуры и разбор её проблем
   3. Алгоритм рефакторинга и пример его выполнения
   4. План итерационного рефакторинга
   5. Жизнь на две N версий архитектуры
   

   View Slide

7. Рефакторинг архитектуры в случае
   микросервисов
   

   View Slide

8. Рефакторинг архитектуры
   • Рефакторинг — изменение структуры
   без изменения поведения.
   • В случае рефакторинга архитектуры —
   без изменения бизнес-сценариев
   

   View Slide

9. Рефакторинг архитектуры микросервисов
   • Рефакторинг данных и API
   • Изменение гранулярности
   • Перепроектирование bounded–контекстов,
   сервисов и мастер–данных
   Сложность
   рефакторинга
   

   View Slide

10. Сигналы о том, что пора рефакторить
    • Изменение гранулярности
    • Повторы или циклы в трассировках
    • Нарушение инкапсуляции и избыточности
    • Дублирование
    • Линейный рост инфраструктурных работ
    • Нарушения принципов проектирования
    

    View Slide

11. Coupling and cohesion
    • Cohesion (связность, сцепленность, прочность)
    • Reuse/Release Equivalence Principle
    • Common Reuse Principle
    • Common Closure Principle
    • Coupling (связанность)
    • Acyclic Dependencies Principle
    • Stable Dependencies Principle
    • Stable Abstractions Principle
    

    View Slide

12. Пример рефакторинга архитектуры
    

    View Slide

13. Интернет-магазин с доставкой
    

    View Slide

14. Добавляем несколько доставщиков
    

    View Slide

15. Доставщик:
    География — срок — вес-тариф
    

    View Slide

16. Добавляем несколько доставщиков
    

    View Slide

17. Верхнеуровнево — ± норм
    

    View Slide

18. Детали и нюансы
    

    View Slide

19. Детали
    и нюансы
    

    View Slide

20. Проблемы архитектуры
    • Нарушение
    • Acyclic Dependencies Principle
    • Single Responsibility или Common Closure Principle
    • Reuse/Release Equivalence Principle
    • Common Reuse Principle
    • Повторы в трассировках
    • High coupling, low cohesion
    

    View Slide

21. Нарушение Acyclic Dependencies Principle
    Allow no cycles in the component dependency graph
    

    View Slide

22. Нарушение Common Closure Principle
    (Single Responsibility)
    A change that affects a component affects only that component and no
    other components
    

    View Slide

23. Нарушение Reuse/ Release
    Equivalence Principle
    The granular of reuse is the granular of release
    

    View Slide

24. Нарушение Common Reuse Principle
    The parts in a component are
    reused together.
    If you reuse one of the parts in a
    component, you reuse them all
    

    View Slide

25. Повторы
    в трассировках
    

    View Slide

26. Повторы в трассировках
    

    View Slide

27. High coupling, low cohesion
    

    View Slide

28. High coupling,
    low cohesion
    

    View Slide

29. Алгоритм рефакторинга
    и пример его выполнения
    

    View Slide

30. Алгоритм рефакторинга
    1. Сделать видимым
    2. Выделить мастер-данные и их связи
    • провалидировать потоками данных и сценариями
    3. Выделить ответственности и bounded context
    • провалидировать потоками данных и сценариями
    4. Наложить потоки данных и сформировать драфт архитектуры
    5. Провалидировать драфт принципами
    (если валидация не прошла — возвращаемся назад в п.2)
    6. Составить итерационный план перехода
    2
    

    View Slide

31. 1. Сделать видимым
    • визуализация as is
    • визуализация проблем
    • визуализация потоков данных
    

    View Slide

32. Потоки данных. Сценарий 1. Парсинг
    

    View Slide

33. Потоки данных.
    Сценарий 2.
    Реалтайм расчет срока
    

    View Slide

34. Потоки данных. Сценарий N …
    • Визуализация наложения
    архитектуры и сценариев
    • Валидация архитектуры
    и связей
    • Определение «стабильных» частей
    системы — например, География
    

    View Slide

35. Алгоритм рефакторинга
    1. Сделать видимым
    2. Выделить мастер-данные и их связи
    • провалидировать потоками данных и сценариями
    3. Выделить ответственности и bounded context
    • провалидировать потоками данных и сценариями
    4. Наложить потоки данных и сформировать драфт архитектуры
    5. Провалидировать драфт принципами
    (если валидация не прошла — возвращаемся назад в п.2)
    6. Составить итерационный план перехода
    2
    

    View Slide

36. 2. Мастер-данные
    

    View Slide

37. 2. Мастер-данные. Не всё так просто
    

    View Slide

38. Валидация сценарием. Расчет срока
    

    View Slide

39. Алгоритм рефакторинга
    1. Сделать видимым
    2. Выделить мастер-данные и их связи
    • провалидировать потоками данных и сценариями
    3. Выделить ответственности и bounded context
    • провалидировать потоками данных и сценариями
    4. Наложить потоки данных и сформировать драфт архитектуры
    5. Провалидировать драфт принципами
    (если валидация не прошла — возвращаемся назад в п.2)
    6. Составить итерационный план перехода
    2
    

    View Slide

40. 3. Ограниченные контексты
    

    View Slide

41. *Контекст ≥ микросервис
    

    View Slide

42. Алгоритм рефакторинга
    1. Сделать видимым
    2. Выделить мастер-данные и их связи
    • провалидировать потоками данных и сценариями
    3. Выделить ответственности и bounded context
    • провалидировать потоками данных и сценариями
    4. Наложить потоки данных и сформировать драфт архитектуры
    5. Провалидировать драфт принципами
    (если валидация не прошла — возвращаемся назад в п.2)
    6. Составить итерационный план перехода
    2
    

    View Slide

43. 4. Архитектура
    

    View Slide

44. Алгоритм рефакторинга
    1. Сделать видимым
    2. Выделить мастер-данные и их связи
    • провалидировать потоками данных и сценариями
    3. Выделить ответственности и bounded context
    • провалидировать потоками данных и сценариями
    4. Наложить потоки данных и сформировать драфт архитектуры
    5. Провалидировать драфт принципами
    (если валидация не прошла — возвращаемся назад в п.2)
    6. Составить итерационный план перехода
    2
    

    View Slide

45. 5. Stable Dependencies Principle
    Depend in the direction of stability
    

    View Slide

46. 6. Stable Abstractions Principle
    A component should be as abstract as it is stable
    

    View Slide

47. Целевая
    архитектура
    

    View Slide

48. Алгоритм рефакторинга
    1. Сделать видимым
    2. Выделить мастер-данные и их связи
    • провалидировать потоками данных и сценариями
    3. Выделить ответственности и bounded context
    • провалидировать потоками данных и сценариями
    4. Наложить потоки данных и сформировать драфт архитектуры
    5. Провалидировать драфт принципами
    (если валидация не прошла — возвращаемся назад в п.2)
    6. Составить итерационный план перехода
    2
    

    View Slide

49. План итерационного рефакторинга
    

    View Slide

50. Как постепенно отрефакторить?
    

    View Slide

51. Итерационный план перехода
    1. Выносим отделимое
    2. Разделяем логику и данные
    3. Мигрируем данные
    4. Убираем дублирование
    

    View Slide

52. 1. Выносим отделимое
    

    View Slide

53. 2. Разделяем логику и данные
    

    View Slide

54. 3. Миграция данных
    

    View Slide

55. 4. Убираем дублирование
    

    View Slide

56. Бинго
    

    View Slide

57. Жизнь на две N версий архитектуры
    

    View Slide

58. Итерационный план перехода
    1. Выносим отделимое
    2. Разделяем логику и данные
    3. Мигрируем данные
    4. Убираем дублирование
    

    View Slide

59. Да, но…
    1. Выносим отделимое
    ❌ Срочный хотфикс прода
    2. Разделяем логику и данные
    ⚠️ Релиз фичи в старой версии архитектуры, которую
    делали N месяцев
    3. Мигрируем данные
    ⚡ Запуск с нуля в новом регионе
    4. Убираем дублирование
    

    View Slide

60. GitFlow…
    × N микросервисов
    × 3+ окружения
    ^ CI/CD
    

    View Slide

61. В случае разных версий архитектур
    

    View Slide

62. Reality
    

    View Slide

63. Основные проблемы
    1. Ограниченное число окружений
    — бутылочное горлышко поставки
    2. Монструозность процесса
    и его CI/CD–автоматизации при gitflow
    

    View Slide

64. Workflow работы с кодом — основа
    остальных процессов
    1. Задаёт требования к инфраструктуре (окружениям)
    2. Задаёт процесс, автоматизируемый CI/CD—пайплайном
    3. Задаёт правила работы команды (dev, QA, devops)
    Процесс разработки. Команда – микросервисы – git*flow
    

    View Slide

65. View Slide

66. GitHub Flow
    

    View Slide

67. GitHub Flow
    1. Неограниченное (почти) кол-во feature-окружений,
    поднимаемых по требованию
    • Нет конкуренции за стенды между членами команды и
    разными версиями архитектуры
    2. Проще структура CI/CD
    • Нет лишней логики и ветвлений в зависимости от веток
    

    View Slide

68. Ограничения неограниченных окружений
    • Железо
    • Сложности с восстановлением БД
    • Сложности с инфраструктурой: параметры железа и параметры
    инфраструктуры (сеть, сертификаты, мониторинг, стейтфул-
    инструменты и т.д.)
    

    View Slide

69. Deploy Feature-окружений
    • Существующее окружение
    • Точечная заливка / обновление сервиса
    • Новое окружение
    • Тип заливки
    • Ограниченный набор сервисов
    • Вся система
    • Тип окружения
    • Легковесное фиче-окружение
    • Препрод-окружение
    • Перф-окружение
    

    View Slide

70. Как решилась эта проблема?
    

    View Slide

71. Preprod
    

    View Slide

72. Итеративный
    переход
    на новую
    архитектуру
    Prod
    Архитектура 1.0
    Preprod
    Архитектура 1.1
    Preprod2
    Fix 1.1.1
    Архитектура 1.1
    Архитектура 1.2
    Fix 1.1.1
    Merge Fix 1.1.1
    Архитектура 1.2
    Архитектура 2.0
    Feature 1.2.1
    Feature 1.2.1
    Merge 1.2.1
    Архитектура 2.0
    

    View Slide

73. Итоги
    

    View Slide

74. Итоги
    1. Рассмотрели принципы архитектуры микросервисов
    2. Разобрали пример с нарушением принципов
    3. Составили алгоритм рефакторинга/перепроектирования
    4. Спроектировали целевую архитектуру
    5. Составили итерационный план перехода
    6. Обсудили проблемы переходного периода и возможные
    решения
    

    View Slide

75. Пользуясь случаем
    Спасибо всем devops’ам и нашим, в
    частности =)
    

    View Slide

76. 1 2
    3
    Ссылки
    Гранулярность
    микросервисов
    на DevOpsConf 2022
    Тезисы и слайды
    Видео
    Снижение издержек
    на добавление
    +1 микросервиса
    на Highload
    Тезисы и слайды
    Видео
    Влияние workflow
    работы с кодом на все
    остальные процессы
    и инфраструкртуру —
    CI/CD, k8s, офлайн-
    процессы команды
    Тезисы и слайды
    Видео
    

    View Slide

77. Спасибо!
    Руслан Сафин
    ruslan.safin@byndyusoft.com
    

    View Slide