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

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

Transcript

1. Рефакторинг микросервисной архитектуры Руслан Сафин, @razonrus
2. • Технический директор и архитектор Byndyusoft • Автор и преподаватель курса по микросервисной архитектуре ЧелГУ, ИТМО • Член программного комитета CodeFest Руслан Сафин
3. Byndyusoft — это заказная разработка с продуктовым подходом Среди наших заказчиков: Byndyusoft
4. От рефакторинга монолита к рефакторингу архитектуры микросервисов
6. Рефакторинг архитектуры Пример с проблемами Алгоритм рефакторинга Итерационный рефакторинг ПЛАН 00 01 02 03
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 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. Составить итерационный план перехода
31. 1. Сделать видимым • визуализация as is • визуализация проблем • визуализация потоков данных
32. Потоки данных. Сценарий 1. Парсинг
33. Сценарий 2. Реалтайм расчет срока
34. Потоки данных. Сценарий N … • Визуализация наложения архитектуры и сценариев • Валидация архитектуры и связей • Определение «стабильных» частей системы —например, География
35. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся в п.2) 6. Составить итерационный план перехода
36. 2. Мастер-данные
37. 2. Мастер-данные. Не всё так просто
38. Валидация сценарием. Расчет срока
39. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся в п.2) 6. Составить итерационный план перехода
40. 3. Ограниченные контексты
41. *Контекст ≥ микросервис
42. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся в п.2) 6. Составить итерационный план перехода
43. 4. Архитектура
44. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их связи • провалидировать потоками данных и сценариями 3. Выделить ответственности и bounded context • провалидировать потоками данных и сценариями 4. Наложить потоки данных и сформировать драфт архитектуры 5. Провалидировать драфт принципами (если валидация не прошла — возвращаемся в п.2) 6. Составить итерационный план перехода
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. Составить итерационный план перехода
48. План итерационного рефакторинга И пример его выполнения
49. Как постепенно отрефакторить?
50. Итерационный план перехода 1. Выносим отделимое 2. Разделяем логику и данные 3. Мигрируем данные 4. Убираем дублирование
51. 1. Выносим отделимое
52. 2. Разделяем логику и данные
53. 3. Миграция данных
54. 4. Убираем дублирование
55. Бинго
56. Итоги 1. Рассмотрели принципы архитектуры микросервисов 2. Разобрали пример с нарушением принципов 3. Составили алгоритм рефакторинга/перепроектирования 4. Спроектировали целевую архитектуру 5. Составили итерационный план перехода
57. Непрерывный процесс рефакторинга архитектуры ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 «Процесс архитектуризации выполняется в пределах всего жизненного цикла системы, а не только в пределах одной стадии жизненного цикла.»
58. С рефакторингом и без него
59. Спасибо! @razonrus