Путешествие Shoprocket к микросервисам: Часть 1

Несколько месяцев после начала работы в Shoprocket я начал испытывать разочарование. У нас была PHP-приложение, над которым работала наша небольшая команда ярких разработчиков, разбросанных по всему миру. Почему я испытывал разочарование? Мне казалось, что исправление ошибок порождает новые ошибки, интеграция новых функций не была такой простой, как могла бы быть, а развертывания происходили редко и были стрессовыми. Причина этих проблем: сильно связанные коды.

У нас было монолитное приложение, и почти вся наша кодовая база находилась в одном репозитории Github. Обновления или исправления одной функции часто происходили в нескольких местах. Для тестирования у нас был процесс рецензирования, когда как минимум два других разработчика должны были одобрить ветку, прежде чем она будет объединена с основной и развернута. Все это означало, что, когда ошибки удавалось проскользнуть незамеченными, часто было сложно найти разрушительные изменения. А как только мы их находили, исправления проходили тот же процесс, и все приложение приходилось разворачивать заново.

Будучи стремительным молодым разработчиком, всегда ищущим новое, когда я наткнулся на микросервисы, я подумал, что этот архитектурный стиль решит все наши проблемы. Формального определения микросервисов нет, но из моего исследования я понял, что архитектура микросервисов – это способ проектирования программных приложений в виде распределенных систем независимых сервисов, каждый из которых высоко специализирован и имеет свой собственный жизненный цикл. Для читателей, которые хотят получить более подробное введение в концепцию, я рекомендую отличную статью Мартина Фаулера.

Меня интересовало множество аспектов микросервисов, но два особенно: Во-первых, идея разделения приложения на сервисы с очень строгими границами. Это снижает вероятность утечки логики, специфичной для одного бизнес-контекста, между компонентами, так как интерфейсы между границами должны быть тщательно спланированы. Это не так просто, как вызовы локальных функций; Во-вторых, каждый компонент может иметь свой собственный независимый жизненный цикл. Это позволяет командам брать на себя ответственность за свой код и использовать технологический стек, наиболее подходящий для отдельного сервиса. Кроме того, это позволяет более тонко контролировать приложение, поскольку изменения могут развертываться для одного сервиса за раз и откатываться без влияния на остальные части приложения, если что-то пойдет не так.

Так что я был в этом убежден. Shoprocket разобьет монолит! Это первое из короткой серии блогов, следящих за этим путешествием. Я надеюсь, что читатели, планирующие или проходящие через подобный переход, извлекут уроки из наших успехов и неудач и будут чувствовать себя лучше подготовленными к этой задаче в своих собственных проектах.

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

Оглядываясь назад, это, возможно, был плохой выбор компонента для первого сервиса. Наш продукт включает в себя javascript-плагин, который обеспечивает электронную коммерцию на любом веб-сайте. Мы рассматриваем сессии как ресурс, сохраняя информацию о сессии в базе данных для подробного анализа КПЭ, таких как уровень abandono корзины. Однако этот ресурс не так материален, как заказы или позиции. Кроме того, мы использовали ресурс сессий почти при каждом изменении состояния приложения. Это означало, что сервис неизбежно будет постоянно общаться с остальной частью приложения, что я не предвидел, но усложнило мою задачу.

Убедив своего начальника, я углубил свои исследования по микросервисам. Помимо вышеупомянутой статьи, я также нашел 'Building Microservices' Сэма Ньюмана весьма ценным ресурсом. Я буду часто ссылаться на оба этих источника в своих постах.

В своей книге Ньюман рекомендует сначала реорганизовать существующее приложение на модули, которые отражают границы контекстов домена. Затем, как только разработчики будут довольны, модули могут быть выделены в собственные сервисы. Причина этого в том, что гораздо легче разбить на части и переписать модули, если их границы были плохо выбраны, чем разбить на части и переписать целые сервисы с их дополнительным кодом и постоянными ресурсами. Однако из-за ограничений по времени и моего стремления создать собственный компонент, я решил пойти вперед с первым сервисом.

Я выбрал стек, только слегка отличающийся от того, который мы использовали для нашего монолита, и начал построение. Сам процесс сборки прошел довольно быстро, мне потребовалось несколько недель, чтобы создать автономное приложение с REST API. Только тогда начались настоящие испытания.

Мне нужно было заставить сервис взаимодействовать с монолитом. В этот момент я понял, как тесно связано управление сессиями с остальным кодом. У меня ушло некоторое время, чтобы разбить существующие вызовы функций и преобразовать их в вызовы API. Это было сложно. Поскольку у сервиса сессий и монолита были свои собственные схемы баз данных, мне пришлось переписать любую логику в монолите, которая использовала ресурсы сессий из старой базы данных, реорганизуя данные на границе приложения для поддержания совместимости с клиентами, такими как наш javascript-плагин.

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

Сервис, возможно, скоро будет внедрен в эксплуатацию, однако теперь я чувствую, что мне следовало бы следовать совету Ньюмана и сосредоточиться на модулировании нашего существующего приложения. Преимущество наличия одного сервиса, существующего самостоятельно, незначительно. Реальная выгода будет заключаться в разделении всего на, по крайней мере, грубо структурированные сервисы, которые общаются как можно меньше. Это требует очень тщательно продуманных границ компонентов, и у нас пока не все готово.

Я все еще убежден в идее микросервисов, и я рассматриваю свою попытку выделить сервис как успешный эксперимент. Я многому научился о архитектуре приложений и моделировании доменов в процессе, и улучшил понимание принципов REST, среди прочего. Это оказало немедленное влияние на другие области нашего кода.

Для читателей, стремящихся к преобразованию, я рекомендую изучить как можно больше по этой теме и отложить работу до тех пор, пока вы не будете уверены в своей существующей кодовой базе и модели домена. Существуют и другие способы ввести стабильность и надежность в монолитное приложение. Разработка через тестирование и автоматизированные модульные и функциональные тесты очень помогают. Горизонтальное масштабирование также помогает сделать развертывания немного более гладкими.

Shoprocket продолжит свой путь к микросервисам. Мы с нетерпением ждем возможности рассказать вам больше во второй части!