Как рефакторить архитектуру микросервисов при живом продакшне? / Руслан Сафин (Byndyusoft)

• Руслан рассказывает о рефакторинге архитектуры микросервисов, который включает в себя изменение структуры без изменения поведения программного обеспечения.  

• Он обсуждает три основных вида рефакторинга: изменение контрактов, данных и гранулярности микросервисов.  

• Он также объясняет, как понять, когда нужно рефакторить архитектуру, и приводит примеры сигналов о необходимости изменения гранулярности.  

• Руслан приводит пример интернет-магазина, который растет и развивается, и ему нужно добавлять несколько разных доставщиков.  

• Он объясняет, что текущая архитектура имеет проблемы с зависимостями, инкапсуляцией и трассировками.  

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

• Обсуждение архитектуры и принципов, связанных с контекстами, мастер-данными и стабильностью.  

• Рассматриваются различные варианты разбиения на контексты и мастер-данные, а также их валидация с помощью сценариев.  

• Предлагается алгоритм рефакторинга архитектуры, включающий шесть пунктов: сделать видимым, выделить ответственность и контексты, выделить разные варианты разбиения на мастер-данные, составить итерационный план перехода.  

• Рассматриваются различные варианты разбиения на контексты и мастер-данные, а также их валидация с помощью сценариев.  

• Предлагается итерационный план перехода от текущей архитектуры к целевой, включающий четыре шага: вынести отделимое, разделить логику и данные, перенести данные и подчистить, убрать дублирование и переименовать контексты.  

• Обсуждаются сложности, связанные с живым продакшном и необходимостью учитывать срочные ходы и новые фичи.  

• В видео обсуждается сложность и автоматизация процессов в микросервисной архитектуре.  

• Сложность заключается в большом количестве окружений, которые нужно поддерживать, и в необходимости постоянно откатывать и обновлять версии архитектуры.  

• Это приводит к большому количеству нервов и времени, затрачиваемого на процесс.  

• В видео предлагается переход на GitFlow, который позволяет использовать неограниченное число окружений и упрощает автоматизацию процессов.  

• Однако, это не решает все проблемы, так как невозможно бесконечно разворачивать новые окружения.  

• В видео рассматривается алгоритм работы с двумя версиями архитектуры.  

• Сначала создается первая версия, которая тестируется и заливается на продакшн.  

• Затем создается вторая версия, которая также тестируется и заливается на препрод.  

• Если приходит срочный фикс, он разворачивается на втором препроде и проверяется.  

• Если все работает, фикс заливается на продакшн и мержится в новую версию архитектуры.  

• В конце видео автор подводит итоги и благодарит всех за внимание.  

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

• Он объясняет, что выбор был сделан в пользу гитхаба из-за его флоу.  

• Спикер обсуждает жизненный цикл окружений, поднимая их, когда это необходимо.  

• Он подчеркивает важность автоматизации очистки окружений, чтобы избежать нехватки ресурсов.  

• Спикер подчеркивает, что выбор методологии зависит от потребностей команды.  

• Он призывает выбирать то, что подходит именно вам, и не полагаться на одну методологию.