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

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

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

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

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

Transcript

1. Как рефакторить архитектуру микросервисов при живом продакшне? Руслан Сафин Byndyusoft
2. Обо мне • CTO в Byndyusoft.com • Развиваю техническую культуру в компании • Участвую в проектах в роли IT-архитектора • Преподаю IT-архитектуру в университете Byndyusoft — это заказная разработка с продуктовым подходом. Среди наших заказчиков:
3. От распила монолита к рефакторингу микросервисов
4. Рефакторинг архитектуры. Ожидание 💩 💩💩💩 💩💩 💎💎 💎💎💎 💎💎
5. Реальность 💩 💩💩💩 💩💩 💎💎 💎💎💎 💎💎
6. План 1. Рефакторинг архитектуры в случае микросервисов 2. Пример архитектуры и разбор её проблем 3. Алгоритм рефакторинга и пример его выполнения 4. План итерационного рефакторинга 5. Жизнь на две N версий архитектуры
7. Рефакторинг архитектуры в случае микросервисов
8. Рефакторинг архитектуры • Рефакторинг — изменение структуры без изменения поведения. • В случае рефакторинга архитектуры — без изменения бизнес-сценариев
9. Рефакторинг архитектуры микросервисов • Рефакторинг данных и API • Изменение гранулярности • Перепроектирование bounded–контекстов, сервисов и мастер–данных Сложность рефакторинга
10. Сигналы о том, что пора рефакторить • Изменение гранулярности • Повторы или циклы в трассировках • Нарушение инкапсуляции и избыточности • Дублирование • Линейный рост инфраструктурных работ • Нарушения принципов проектирования
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
12. Пример рефакторинга архитектуры
13. Интернет-магазин с доставкой
14. Добавляем несколько доставщиков
15. Доставщик: География — срок — вес-тариф
16. Добавляем несколько доставщиков
17. Верхнеуровнево — ± норм
18. Детали и нюансы
19. Детали и нюансы
20. Проблемы архитектуры • Нарушение • Acyclic Dependencies Principle • Single Responsibility или Common Closure Principle • Reuse/Release Equivalence Principle • Common Reuse Principle • Повторы в трассировках • High coupling, low cohesion
21. Нарушение Acyclic Dependencies Principle Allow no cycles in the component dependency graph
22. Нарушение Common Closure Principle (Single Responsibility) A change that affects a component affects only that component and no other components
23. Нарушение Reuse/ Release Equivalence Principle The granular of reuse is the granular of release
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
25. Повторы в трассировках
26. Повторы в трассировках
27. High coupling, low cohesion
28. High coupling, low cohesion
29. Алгоритм рефакторинга и пример его выполнения
30. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся назад в п.2) 6. Составить итерационный план перехода 2
31. 1. Сделать видимым • визуализация as is • визуализация проблем • визуализация потоков данных
32. Потоки данных. Сценарий 1. Парсинг
33. Потоки данных. Сценарий 2. Реалтайм расчет срока
34. Потоки данных. Сценарий N … • Визуализация наложения архитектуры и сценариев • Валидация архитектуры и связей • Определение «стабильных» частей системы — например, География
35. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся назад в п.2) 6. Составить итерационный план перехода 2
36. 2. Мастер-данные
37. 2. Мастер-данные. Не всё так просто
38. Валидация сценарием. Расчет срока
39. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся назад в п.2) 6. Составить итерационный план перехода 2
40. 3. Ограниченные контексты
41. *Контекст ≥ микросервис
42. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся назад в п.2) 6. Составить итерационный план перехода 2
43. 4. Архитектура
44. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся назад в п.2) 6. Составить итерационный план перехода 2
45. 5. Stable Dependencies Principle Depend in the direction of stability
46. 6. Stable Abstractions Principle A component should be as abstract as it is stable
47. Целевая архитектура
48. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся назад в п.2) 6. Составить итерационный план перехода 2
49. План итерационного рефакторинга
50. Как постепенно отрефакторить?
51. Итерационный план перехода 1. Выносим отделимое 2. Разделяем логику и данные 3. Мигрируем данные 4. Убираем дублирование
52. 1. Выносим отделимое
53. 2. Разделяем логику и данные
54. 3. Миграция данных
55. 4. Убираем дублирование
56. Бинго
57. Жизнь на две N версий архитектуры
58. Итерационный план перехода 1. Выносим отделимое 2. Разделяем логику и данные 3. Мигрируем данные 4. Убираем дублирование
59. Да, но… 1. Выносим отделимое ❌ Срочный хотфикс прода 2. Разделяем логику и данные ⚠️ Релиз фичи в старой версии архитектуры, которую делали N месяцев 3. Мигрируем данные ⚡ Запуск с нуля в новом регионе 4. Убираем дублирование
60. GitFlow… × N микросервисов × 3+ окружения ^ CI/CD
61. В случае разных версий архитектур
62. Reality
63. Основные проблемы 1. Ограниченное число окружений — бутылочное горлышко поставки 2. Монструозность процесса и его CI/CD–автоматизации при gitflow
64. Workflow работы с кодом — основа остальных процессов 1. Задаёт требования к инфраструктуре (окружениям) 2. Задаёт процесс, автоматизируемый CI/CD—пайплайном 3. Задаёт правила работы команды (dev, QA, devops) Процесс разработки. Команда – микросервисы – git*flow
66. GitHub Flow
67. GitHub Flow 1. Неограниченное (почти) кол-во feature-окружений, поднимаемых по требованию • Нет конкуренции за стенды между членами команды и разными версиями архитектуры 2. Проще структура CI/CD • Нет лишней логики и ветвлений в зависимости от веток
68. Ограничения неограниченных окружений • Железо • Сложности с восстановлением БД • Сложности с инфраструктурой: параметры железа и параметры инфраструктуры (сеть, сертификаты, мониторинг, стейтфул- инструменты и т.д.)
69. Deploy Feature-окружений • Существующее окружение • Точечная заливка / обновление сервиса • Новое окружение • Тип заливки • Ограниченный набор сервисов • Вся система • Тип окружения • Легковесное фиче-окружение • Препрод-окружение • Перф-окружение
70. Как решилась эта проблема?
71. Preprod
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
73. Итоги
74. Итоги 1. Рассмотрели принципы архитектуры микросервисов 2. Разобрали пример с нарушением принципов 3. Составили алгоритм рефакторинга/перепроектирования 4. Спроектировали целевую архитектуру 5. Составили итерационный план перехода 6. Обсудили проблемы переходного периода и возможные решения
75. Пользуясь случаем Спасибо всем devops’ам и нашим, в частности =)
76. 1 2 3 Ссылки Гранулярность микросервисов на DevOpsConf 2022 Тезисы и слайды Видео Снижение издержек на добавление +1 микросервиса на Highload Тезисы и слайды Видео Влияние workflow работы с кодом на все остальные процессы и инфраструкртуру — CI/CD, k8s, офлайн- процессы команды Тезисы и слайды Видео
77. Спасибо! Руслан Сафин ruslan.safin@byndyusoft.com