Рефакторинг

микросервисной
архитектуры
Руслан Сафин, @razonrus
Руслан Сафин

• Технический директор и архитектор

Byndyusoft
• Автор и преподаватель курса по
микросервисной архитектуре
ЧелГУ, ИТМО
• Член программного комитета
CodeFest
Byndyusoft

Byndyusoft — это заказная

разработка с продуктовым подходом

Среди наших заказчиков:

От рефакторинга монолита
к рефакторингу архитектуры микросервисов
ПЛАН

Рефакторинг архитектуры 00

Пример с проблемами 01

Алгоритм рефакторинга 02

Итерационный рефакторинг 03
Рефакторинг
архитектуры
В случае микросервисов
Рефакторинг архитектуры

▪ Рефакторинг — изменение структуры

без изменения поведения

▪ В случае рефакторинга архитектуры —

без изменения бизнес-сценариев
Рефакторинг архитектуры микросервисов
Сложность
▪ Рефакторинг данных и API рефакторинга
▪ Изменение гранулярности
▪ Перепроектирование bounded–
контекстов, сервисов и мастер–данных
Сигналы о том, что пора рефакторить

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

▪ Нарушения принципов проектирования

Coupling and cohesion

▪ Cohesion (связность, сцепленность, прочность)

▪ Reuse/Release Equivalence Principle
▪ Common Reuse Principle
▪ Common Closure Principle
▪ Coupling (связанность)
▪ Acyclic Dependencies Principle
▪ Stable Dependencies Principle
▪ Stable Abstractions Principle
Пример архитектуры
И разбор её проблем
Интернет-магазин с доставкой
Добавляем несколько
доставщиков
Доставщик:
География — срок — вес-тариф
Добавляем несколько
доставщиков
Верхнеуровнево — ± норм
Детали и нюансы
Детали
и нюансы
Проблемы архитектуры
▪ Нарушение
▪ Acyclic Dependencies Principle
▪ Single Responsibility или Common Closure Principle
▪ Reuse/Release Equivalence Principle
▪ Common Reuse Principle

▪ Повторы в трассировках
▪ High coupling, low cohesion
Нарушение Acyclic Dependencies
Principle
Allow no cycles in the component dependency graph
Нарушение Common Closure
Principle
A change that affects a component affects only that
component and no other components
Нарушение Reuse/ Release
Equivalence Principle
The granular of reuse is the granular of release
Нарушение 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
Повторы в трассировках
Повторы в трассировках
High coupling, low cohesion
High coupling,
low cohesion
Алгоритм рефакторинга
И пример его выполнения
Алгоритм рефакторинга
1. Сделать видимым
2. Выделить мастер-данные и их связи
• провалидировать потоками данных и сценариями
3. Выделить ответственности и bounded context
• провалидировать потоками данных и сценариями
4. Наложить потоки данных и сформировать драфт
архитектуры
5. Провалидировать драфт принципами
(если валидация не прошла — возвращаемся в п.2)
6. Составить итерационный план перехода
1. Сделать видимым
• визуализация as is
• визуализация проблем
• визуализация потоков данных
Потоки данных. Сценарий 1.
Парсинг
Сценарий 2. Реалтайм расчет срока
Потоки данных. Сценарий N …
• Визуализация наложения
архитектуры и сценариев
• Валидация архитектуры
и связей
• Определение
«стабильных» частей
системы —например,
География
Алгоритм рефакторинга
1. Сделать видимым
2. Выделить мастер-данные и их связи
• провалидировать потоками данных и сценариями
3. Выделить ответственности и bounded context
• провалидировать потоками данных и сценариями
4. Наложить потоки данных и сформировать драфт
архитектуры
5. Провалидировать драфт принципами
(если валидация не прошла — возвращаемся в п.2)
6. Составить итерационный план перехода
2. Мастер-данные
2. Мастер-данные. Не всё так
просто
Валидация сценарием. Расчет
срока
Алгоритм рефакторинга
1. Сделать видимым
2. Выделить мастер-данные и их связи
• провалидировать потоками данных и сценариями
3. Выделить ответственности и bounded context
• провалидировать потоками данных и сценариями
4. Наложить потоки данных и сформировать драфт
архитектуры
5. Провалидировать драфт принципами
(если валидация не прошла — возвращаемся в п.2)
6. Составить итерационный план перехода
3. Ограниченные контексты
*Контекст ≥ микросервис
Алгоритм рефакторинга
1. Сделать видимым
2. Выделить мастер-данные и их связи
• провалидировать потоками данных и сценариями
3. Выделить ответственности и bounded context
• провалидировать потоками данных и сценариями
4. Наложить потоки данных и сформировать драфт
архитектуры
5. Провалидировать драфт принципами
(если валидация не прошла — возвращаемся в п.2)
6. Составить итерационный план перехода
4. Архитектура
Алгоритм рефакторинга
1. Сделать видимым
2. Выделить мастер-данные и их связи
• провалидировать потоками данных и сценариями
3. Выделить ответственности и bounded context
• провалидировать потоками данных и сценариями
4. Наложить потоки данных и сформировать драфт
архитектуры
5. Провалидировать драфт принципами
(если валидация не прошла — возвращаемся в п.2)
6. Составить итерационный план перехода
5. Stable Dependencies Principle
Depend in the direction of stability
6. Stable Abstractions Principle
A component should be
as abstract
as it is stable
Алгоритм рефакторинга
1. Сделать видимым
2. Выделить мастер-данные и их связи
• провалидировать потоками данных и сценариями
3. Выделить ответственности и bounded context
• провалидировать потоками данных и сценариями
4. Наложить потоки данных и сформировать драфт
архитектуры
5. Провалидировать драфт принципами
(если валидация не прошла — возвращаемся в п.2)
6. Составить итерационный план перехода
План итерационного
рефакторинга
И пример его выполнения
Как постепенно отрефакторить?
Итерационный план перехода
1. Выносим отделимое
2. Разделяем логику и данные
3. Мигрируем данные
4. Убираем дублирование
1. Выносим отделимое
2. Разделяем логику и данные
3. Миграция данных
4. Убираем дублирование
Бинго
Итоги
1. Рассмотрели принципы архитектуры
микросервисов
2. Разобрали пример с нарушением принципов
3. Составили алгоритм
рефакторинга/перепроектирования
4. Спроектировали целевую архитектуру
5. Составили итерационный план перехода
Непрерывный процесс рефакторинга
архитектуры

ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011

«Процесс архитектуризации выполняется в пределах

всего жизненного цикла системы, а не только в
пределах одной стадии жизненного цикла.»
С рефакторингом и без него
Спасибо!
@razonrus