Рефакторинг микросервисной архитектуры

Даже грамотно спроектированная микросервисная архитектура с течением времени требует пересмотра и рефакторинга.

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

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

Transcript

1. Рефакторинг микросервисной архитектуры Руслан Сафин Byndyusoft
2. Обо мне • CTO в Byndyusoft.com • Развиваю техническую культуру в компании • Участвую в проектах в роли IT-архитектора • Преподаю IT-архитектуру в университете Byndyusoft — это заказная разработка с продуктовым подходом Среди наших заказчиков:
3. От рефакторинга монолита к рефакторингу микросервисов
4. От рефакторинга монолита к рефакторингу микросервисов
5. План 1. Рефакторинг архитектуры в случае микросервисов 2. Пример архитектуры и разбор её проблем 3. Алгоритм рефакторинга и пример его выполнения 4. План итерационного рефакторинга и пример его выполнения
6. Рефакторинг архитектуры в случае микросервисов
7. Рефакторинг архитектуры • Рефакторинг — изменение структуры без изменения поведения. • В случае рефакторинга архитектуры — без изменения бизнес-сценариев
8. Рефакторинг архитектуры микросервисов • Объединение или разделение • сервисов • ограниченных контекстов • Рефакторинг данных и API https://www.youtube.com/watch?v=x1xqlXnyXp8 Но что если этого не достаточно? • Перепроектирование bounded-контекстов и мастер-данных
9. Сигналы о том, что пора рефакторить • Сигналы для изменения гранулярности • Что пора объединять • Что пора разделять • Нарушения принципов проектирования
10. Сигналы для изменения гранулярности • Повторы или циклы в трассировках • Нарушение инкапсуляции и избыточности • Дублирование • Максимальная сцепленность • Линейный рост инфраструктурных работ • https://techleadconf.ru/2022/abstracts/9081
11. Нарушения принципов проектирования • Единственность ответственности • Связанность и связность (coupling and cohesion) • Принципы проектирования пакетов/сборок — микросервисов • Reuse/Release Equivalence Principle • Common Reuse Principle • Common Closure Principle • 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. Нарушение Single Responsibility / Common Closure Principle 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. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи - провалидировать потоками данных и сценариями 3. Выделить ответстственности и bounded context - провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся назад в п.2) 6. Составить итерационный план перехода 2
48. План итерационного рефакторинга и пример его выполнения
49. Как постепенно отрефакторить?
50. Итерационный план перехода 1. Выносим отделимое 2. Разделяем логику и данные 3. Мигрируем данные 4. Убираем дублирование
51. 1. Выносим отделимое
52. 2. Разделяем логику и данные
53. 3. Миграция данных
54. 4. Убираем дублирование
55. Бинго
56. Итоги 1. Рассмотрели принципы архитектуры микросервисов 2. Разобрали пример с нарушением принципов 3. Составили алгоритм рефакторинга/перепроектирования 4. Спроектировали целевую архитектуру 5. Составили итерационный план перехода
57. Такой рефакторинг работает и при отсутствии архитектуры Антихрупкость в IT Рефакторинг микросервисного монолита, как одного из этапов перехода на микросервисы
58. Непрерывный процесс рефакторинга архитектуры ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 «Процесс архитектуризации выполняется в пределах всего жизненного цикла системы, а не только в пределах одной стадии жизненного цикла.»
59. С рефакторингом и без него
60. Спасибо!
61. Руслан Сафин iruslansafin@gmail.com Byndyusoft @razonrus vk.com/ruslan.safin