Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

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

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

Byndyusoft

March 17, 2023
Tweet

More Decks by Byndyusoft

Other Decks in Programming

Transcript

  1. Обо мне • CTO в Byndyusoft.com • Развиваю техническую культуру

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

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

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

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

    Повторы или циклы в трассировках • Нарушение инкапсуляции и избыточности • Дублирование • Линейный рост инфраструктурных работ • Нарушения принципов проектирования
  6. Coupling and cohesion • Cohesion (связность, сцепленность, прочность) • Reuse/Release

    Equivalence Principle • Common Reuse Principle • Common Closure Principle • Coupling (связанность) • Acyclic Dependencies Principle • Stable Dependencies Principle • Stable Abstractions Principle
  7. Проблемы архитектуры • Нарушение • Acyclic Dependencies Principle • Single

    Responsibility или Common Closure Principle • Reuse/Release Equivalence Principle • Common Reuse Principle • Повторы в трассировках • High coupling, low cohesion
  8. Нарушение Common Closure Principle (Single Responsibility) A change that affects

    a component affects only that component and no other components
  9. Нарушение 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
  10. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их

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

    сценариев • Валидация архитектуры и связей • Определение «стабильных» частей системы — например, География
  12. Алгоритм рефакторинга 1. Сделать видимым 2. Выделить мастер-данные и их

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

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

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

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

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

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

    данные 3. Мигрируем данные 4. Убираем дублирование
  19. Да, но… 1. Выносим отделимое ❌ Срочный хотфикс прода 2.

    Разделяем логику и данные ⚠️ Релиз фичи в старой версии архитектуры, которую делали N месяцев 3. Мигрируем данные ⚡ Запуск с нуля в новом регионе 4. Убираем дублирование
  20. Основные проблемы 1. Ограниченное число окружений — бутылочное горлышко поставки

    2. Монструозность процесса и его CI/CD–автоматизации при gitflow
  21. Workflow работы с кодом — основа остальных процессов 1. Задаёт

    требования к инфраструктуре (окружениям) 2. Задаёт процесс, автоматизируемый CI/CD—пайплайном 3. Задаёт правила работы команды (dev, QA, devops) Процесс разработки. Команда – микросервисы – git*flow
  22. GitHub Flow 1. Неограниченное (почти) кол-во feature-окружений, поднимаемых по требованию

    • Нет конкуренции за стенды между членами команды и разными версиями архитектуры 2. Проще структура CI/CD • Нет лишней логики и ветвлений в зависимости от веток
  23. Ограничения неограниченных окружений • Железо • Сложности с восстановлением БД

    • Сложности с инфраструктурой: параметры железа и параметры инфраструктуры (сеть, сертификаты, мониторинг, стейтфул- инструменты и т.д.)
  24. Deploy Feature-окружений • Существующее окружение • Точечная заливка / обновление

    сервиса • Новое окружение • Тип заливки • Ограниченный набор сервисов • Вся система • Тип окружения • Легковесное фиче-окружение • Препрод-окружение • Перф-окружение
  25. Итеративный переход на новую архитектуру 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
  26. Итоги 1. Рассмотрели принципы архитектуры микросервисов 2. Разобрали пример с

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

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