Переход на микросервисы: 3 урока из окопов
Прошло некоторое время с тех пор, как предприятие осознало, что много рук облегчают работу, а благодаря контейнерам и технологиям с открытым исходным кодом любой, кто заинтересован в переходе на микросервисы, имеет виртуальную энциклопедию компаний, которые прошли этот путь до них. Многие считают, что когда вы открываете монолит, все эти аккуратно упакованные микросервисы вылетают наружу. Это совсем не так. Давайте взглянем на три компании, которые пытались перейти на микросервисы с разной степенью успеха и неудач.
Copious: научиться ошибаться в микросервисах
Компания Copious была создана в 2011 году, когда несколько коллег собрались вместе, чтобы создать социальную торговую площадку с использованием Rails и некоторых серверных сервисов. Rails — это среда контроллера представления модели (MVC), предоставляющая структуры по умолчанию для базы данных, веб-службы и веб-страниц. Он поощряет и облегчает использование веб-стандартов. Rails делает упор на использование других хорошо известных шаблонов и парадигм разработки программного обеспечения, включая соглашение о конфигурации (CoC), принцип «не повторяйся» (DRY) и шаблон активной записи.
Продукт использовал график социальной сети, который представляет собой наложение всего, что они знают о ком-то из социальных сетей, и позволяет публиковать истории в социальных сетях. Граф социальной сети позволяет пользователям использовать постоянное изучение социальных сетей в своих интересах. Некоторые из них даже имеют возможность объединять сетевые данные от двух разных пользователей, предоставляя пользователям этого приложения возможность взаимодействовать друг с другом и дополнять информацию друг друга.
Первая проблема, с которой они столкнулись при работе со своим монолитом, заключалась в том, что, поскольку они получали данные из социальных графов всех остальных, у них уже были терабайты данных на Mongo и EC2. Это было намного больше, чем они обрабатывали с помощью монолита, и 200 000 записей этих данных были просто токенами аутентификации, необходимыми для предоставления пользователям доступа к их сайту. Это приводило к тому, что сервис продолжал рушиться, и пользователи не могли попасть на сайт.
Дополнительные проблемы возникли из-за того, что действия клиента на сайте, такие как покупка, просмотр или просмотр, не сохранялись как внешние данные бэкэнда, а скорее добавлялись в монолит. Поэтому, когда пользователи хотели проверить что-то вроде обзора, им приходилось объединять два гигантских монолита на веб-сервере Rails, что, по их собственным словам, было полной катастрофой.
Теперь с монолитом все поступающие данные обрабатывались как один тип данных. Хотя на самом деле внутри этих социальных данных было три разных набора данных. График личных подключений, управление взаимодействиями с токенами OAuth, чтобы пользователи могли входить в систему с Facebook или Twitter, и хранилище токенов для этих взаимодействий. Таким образом, у них был один внешний монолит и другой поддерживающий его внутренний монолит.
Иногда лучше сократить свои потери, чем углубляться в архитектуру микросервисов, особенно если вы не готовы. И это именно то, что они сделали в Copious.
Они объединили все обратно в монолит, что-то вроде восстановления системы, когда они вспомнили, как все функционировало. Это показывает, что если у вас нет четкого представления о вашем бизнесе, продукте или месте, которое вы занимаете в стеке, преждевременное разбиение вещей на набор услуг, не зная, как они будут использоваться, не будет проблемой. веселый итог.
Сначала мы выбрали эту историю не как пример неудачи, а скорее как пример того, как само собой разумеющееся может привести вас к микросервисам, и еще раз заявить, что это не только солнце и розы, и возможность неудачи действительно очень реальна. Следующий урок, однако, будет радостным, о маленьком приложении для создания заметок под названием Evernote и его путешествии в GCP.
Evernote: микросервисы в Google Cloud
Evernote начал с малого и сначала успешно мигрировал в облако, а затем значительно позже внес изменения в архитектуру микросервисов. Это отличный способ познакомиться с новой платформой и провести базовое тестирование перед тем, как идти ва-банк. Хотя это важный шаг, он никоим образом не подтверждает, что ваш производственный сервис будет работать так, как вы задумали.
Во время миграции первое, что поняла команда Evernote, это то, что это действительно помогает, если у вас есть приложение/система, в которую вы можете отдельно перенести отдельные части или компоненты. Это означает, что было чрезвычайно сложно мигрировать их старые монолитные стеки приложений, поэтому было принято решение заменить монолит набором микросервисов, чтобы будущие миграции не были такими болезненными.
Это привело их к выбору Kubernetes в качестве основы для оркестровки, и это отличное место для начала. Затем они решили оставить сложную задачу запуска кластера Kubernetes производственного уровня Google Container Engine (GKE). Это отличный пример того, как понять, что вы не в своей тарелке, и заплатить за профессиональную помощь.
Вместо того, чтобы полностью переписывать, поэтапный рефакторинг вашего монолита — хороший способ перехода к архитектуре микросервисов. Это означает, что вы постепенно создаете новое приложение, состоящее из микросервисов, и запускаете его параллельно своему монолитному приложению. Со временем количество функций, реализуемых монолитным приложением, уменьшается до тех пор, пока оно либо полностью не исчезнет, либо само станет одним из ваших многочисленных микросервисов.
Мартин Фаулер называет эту стратегию модернизации приложений приложением-душителем. Название происходит от виноградной лозы-душителя, которая является разновидностью инжирной лозы, произрастающей в тропических лесах. Лоза-душитель растет вокруг дерева, чтобы достичь солнечного света наверху, и часто медленно душит дерево до смерти.
Cloud Elements: постепенный переход к микросервисам
Постепенная модернизация приложений следует той же схеме, и новое приложение, состоящее из микросервисов, строится вокруг устаревшего приложения, чтобы медленно задушить его. Пример организации, использующей этот метод Cloud Elements. Они решили начать переход на микросервисы с частями своей платформы чуть больше года назад.
Путь, выбранный Cloud Elements, как упоминалось выше, заключался в медленном распределении независимых функций микросервисов из их монолитной платформы. Это было сделано путем распространения отдельных частей их платформы для работы в качестве микросервисов, при этом продолжая одновременно запускать текущую базовую монолитную платформу. Их конечная цель заключалась в том, чтобы монолит существовал только для поддержки API и элементов основной платформы, а все остальные функции масштабировались как микросервисы.
Вся идея здесь состоит в том, чтобы постепенно заменять функциональность, не шокируя всю систему, и ее можно сравнить с медленным обучением растений расти определенным образом. Как и в случае с Vine, в систему вносятся минимальные и дискретные изменения, когда дерево не осознает, что его душат, и постепенно монолит полностью передает власть микросервисам.
Таким образом, мы увидели три примера разных подходов к переходу на микросервисную архитектуру. Первый был слепым прыжком с целью «все остальные делают это» и закончился болезненным возвратом к монолиту. Вторым был «тотальный» подход, когда все было отдано на аутсорсинг профессионалам, а третьим была организация, которая самостоятельно успешно выполнила миграцию, постепенно выстраивая микросервисы вокруг своего монолита.
Таким образом, любые организации, планирующие перейти на микросервисы в ближайшем будущем, имеют сотни доступных им примеров, хотя каждый из них подтверждает тот факт, что каждый путь DevOps отличается и уникален во всех отношениях.