Микросервисы для тех, кто прикидывается разработчиком. Часть 2
И вот настал тот день, когда я наконец соизволил встать с дивана и дописать следующую статью о микросервисах. Кто не в теме — в прошлой части мы выяснили, как сильно неправильная пунктуация и тупые приколы могут раздражать. Ну и немного обсудили, что такое микросервисы и зачем они вообще нужны. Не будем отходить от трендов и в этой части, продолжим погружаться в этот дивный мир машинного перевода, шуточек за 300 и микросервисов.
Глобально существует два способа перехода на новую архитектуру: либо мы делаем все за раз, либо по частям. Первый способ выглядит очень неплохо на бумаге: составляем структуру будущей микросервисной архитектуры, делимся на команды, закрываем разработку новых фич и полностью переключаемся на миграцию. Получается очень круто, модно и молодежно: один могучий потуг — и штаны стали теплыми система уже на микросервисах. Но где же в этом чудном плане хранится подвох? Давайте попробуем разобраться.
Сложность в оценке продолжительности работы. Из-за множества подводных камней и непредвиденных факторов точно оценить сроки переезда на новую архитектуру будет очень проблематично. Соответственно переезд может затянуться на неопределенный срок.
Еще чуть-чуть и мы переехали на микросервисы
Сложность коллаборации большого количества программистов. Одной из причин перехода на микросервисы может быть сильно возросший штат на проекте. Как следствие сложность коллаборации и внедрения новых технологий (блокировки MR, деплой на каждый чих и т.д.). Даже если мы правильно разбили коллектив — резать всё за раз будет похоже на басню «Лебедь, рак и щука». Множество merge request’ов, перекрывающихся задач и сбоев могут сильно замедлить работу
Риск забросить. Маловероятно, но если все затянется очень сильно и не будет виден какой-то результат, лавочку могут прикрыть.
Остановка новых фич. Внедрение новых возможностей будет заблокировано на неопределенный срок. Это риск потерять пользователей и клиентов. Бизнес не может позволить себе паузу на месяцы или даже годы ради перехода на новую архитектуру. Убытки растут, а к миграции добавляются еще и финансовые проблемы. С другой стороны, в случае неудачи это будет шикарной возможностью найти себя на другом проекте, ну или открыть гусиную ферму
Возможно он все 22 года пытался перейти на микросервисы с монолита, кто знает…
С другой стороны подход «по частям» гораздо более жизнеспособный. Суть его, как понятно из названия, заключается в поэтапной миграции. Вместо того, чтобы ломать систему целиком, вы постепенно выделяете отдельные компоненты и превращаете их в микросервисы. Остается дело за малым — определить приоритеты и те самые компоненты для микросервизации.
Мы, конечно же, можем как всегда кинуть монетку и случайно выбрать кусок кода для вынесения его в новую архитектуру. План, конечно, хорош, но лучше подстраховаться и рассмотреть еще несколько способов. Итак, куда направить свой зоркий взгляд?
Область, где чаще всего происходит изменение кода. Миграция кода где изменения никогда не требуются — идея крутая, но не жизнеспособна. Зачем делать приоритет на то, что никогда не меняется и прекрасно работает. Нужно мыслить наоборот и смотреть на ту часть системы, которая постоянно дорабатывается и обновляется. Чем чаще происходят изменения, тем больше проблем вызывает процесс обновления всего монолита. Выделив эту часть в микросервис, можно упростить разработку и мердж реквесты, сократить частоту деплоя и сохранить сократить количество багов. Теперь данный участок будет независимо деплоиться и обновляться.
Область, требующая наибольшей масштабируемости. Если есть участки системы, на которые приходится основная нагрузка — имеет смысл вынести их в первую очередь. Это улучшит масштабируемость и повысит отказоустойчивость. Также это позволит сократить нагрузку на основной сервер. При необходимости можно купить несколько небольших серверов и разбить нагрузку между ними через Load Balancer. При монолите это также возможно -, но цена вопроса существенно дороже. Да и технически это существенно сложнее.
Область с наименьшим техническим долгом. Также начинать миграцию можно с тех компонентов, где наименьшее количество «костылей». Это позволит сократить количество нервных клеток при переходе на новую архитектуру.
Из плюсов данного подхода можно выделить
Нет жесткого дедлайна: переход можно проводить постепенно, не торопясь и не выжигая все ресурсы команды. Работа продолжается в нормальном режиме.
Видимый прогресс: каждый успешно мигрированный компонент — это ощутимый результат для команды и бизнеса.
Бизнес не страдает: поскольку процесс миграции идет параллельно с разработкой новых функций, бизнес продолжает развиваться и платить вам денежку.
Процесс миграции
Слышали ли вы что-либо об strangler fig? Звучит как название крутого блокбастера, но на самом деле это вид тропических и субтропических растений, которых объединяет специфический «душащий» образ жизни. Если интересны детали — фикусы-душители. По аналогии с таким поведением Мартин Фаулер (Martin Fowler) создал шаблон программирования strangler pattern. Суть его проста — мы «обвиваем» старый код и начинаем выносить из него куски. Рассмотрим детальнее:
Для начала необходимо создать фасад для пользователей с целью перенаправления запросов на новые микросервисы.
Далее определяем область с наивысшим приоритетом и выносим данный функционал в отдельный микросервис.
Перенаправляем запросы из вынесеной области в новый блок кода. При этом старый участок удалять не рекомендуется:
Процесс переноса может иметь новые баги. Процесс починки займет какое-то время, а сервис должен работать.
Всегда хорошо иметь возможность вернуть все как было без существенных усилий
Повторяем процесс.
По итогу полностью переходим на новую архитектуру. Profit.
Советы
Оставить стек без изменений. Если у вас была реляционная база дынных — оставьте ее. Использовали java? Во-первых — мое уважение, а во вторых — продолжаем также делать до полного перехода на микросервисы. В противном случае рискуете создать себе несколько неожиданных проблем. Помните золотое правило: «Работает — не трогай».
Не спешите рефакторить. Сначала полностью перенесите всю архитектуру иначе рискуете откусить больше чем проглотить. Причины все те же.
Чем больше тестов — тем лучше. Очень важно понимать, что в процессе переноса мы не создали новых багов и полностью совместимы с другими частями приложения.
Определить API. Заранее продуманные интерфейсы между микросервисами помогут избежать путаницы и сбоев при взаимодействии компонентов. Семь раз отмерь — один отрежь.
Изолировать компонент: Все внутренние зависимости должны быть вынесены из кода, чтобы каждый микросервис мог работать независимо от других частей системы. Другими словами — микросервис должен быть на столько обособленным на сколько это возможно.
На этом, пожалуй, все. Пишите комментарии — всегда интересно почитать на сколько я тупой и вообще все что написано — ересь. Ну, а в следующей части мы поговорим о базах данных в микросервисах.
