Привет, Хабр!
Меня зовут Михаил Федяев, я работаю архитектором в департаменте управления технологиями МТС Диджитал. В нашей экосистеме порядка 500 разных продуктов — для их развития у всех команд должны быть общие правила принятия решений. Они сформулированы в виде 15 технологических принципов. Сегодня я хочу рассказать про один из них — «Микросервисы». Он определяет, как в нашей компании подходят к внедрению микросервисной архитектуры.
Техпринцип «Микросервисы»
Техпринцип описывается так: «Решения представляют собой наборы слабосвязанных, автономных, повторно используемых компонент-сервисов, размещаемых на производственных платформах и реализующих принципы и технологии DDD Bounded Contexts, Cloud Native, UI/Service/Data Mesh, Microservices и другие».
Цели и ценность применения этого техпринципа включают в себя:
уменьшение T2M (time-to-market);
эффективное масштабирование решения;
повышение надежности и отказоустойчивости решения;
увеличение автономии команд разработки;
масштабирование разработки (увеличение количества команд/разработчиков);
возможность использования разных технологий для реализации микросервисов.
Для нас микросервисы — это не модное увлечение, а осознанный выбор там, где он действительно необходим. У нас огромная инфраструктура и большое количество очень разных информационных систем — от элементарных приложений для внутренней автоматизации до гигантских индустриальных платформ, где цена ошибки может исчисляться миллионами, а простой приведет к потере доступа к таким важнейшим сервисам, как мобильная связь и цифровой банкинг. В этом посте я расскажу про наш общий подход к микросервисам и о том, почему мы не считаем их панацеей от всех проблем.
Не все то золото, что микросервис
Небольшие приложения прекрасно живут и развиваются и с монолитной, и с основанной на сервисах (service-based) архитектурой. Задуматься стоит, когда реальное или планируемое количество пользователей системы переваливает за 5–10 миллионов человек (зависит от типа сервиса и профиля нагрузки). Но даже в этом случае нужно внимательно смотреть на все требования в комплексе.
Возьмем, к примеру, систему оценки звонков в реальном времени, где мы работаем с балансами десятков миллионов абонентов. Казалось бы, это подходящий случай, чтобы разбить одну большую базу на несколько маленьких — или шардированием хранилища, или разделением контекстов и использованием микросервисного подхода. Но с финансовыми операциями такие эксперименты могут быть неэффективны или даже опасны — здесь требуется хранение данных в оперативной памяти со строгой согласованностью между всеми копиями.
Практика важнее теории: история одной трансформации
Показательный пример успешного перехода к микросервисам — наш продукт для управления корпоративными мобильными лицевыми счетами. На первый взгляд он кажется просто очередным личным кабинетом для B2B-клиентов. Некая организация покупает у МТС тысячу SIM-карт, а их собственный администратор через специальный веб-интерфейс управляет услугами связи внутри своего корпоративного лицевого счета. Казалось бы, в чем тут может быть сложность, почему монолитного веб-портала недостаточно?
Дьявол, как всегда, кроется в деталях. Структура лицевых счетов хранится в ядре нашей биллинговой системы — большой платформенной автоматизированной системы расчетов. И для понимания того, где в иерархии находится каждая SIM-карта, нужно слушать и обрабатывать огромный поток событий — до 4 000 сообщений в секунду в пиках. Все переходы лицевых счетов и перемещения мобильных номеров между счетами нужно не просто отслеживать, но и сохранять в собственной базе данных, запускать специальную бизнес-логику для разных случаев.
Если вся функциональность управления корпоративными счетами будет реализована в монолите, работа одного этого загруженного контекста будет влиять на отзывчивость и, в особых случаях, даже доступность всего решения. И действительно, после того как команда выделила подобные тяжеловесные контексты в отдельные микросервисы по принципам предметно ориентированного проектирования (DDD), ситуация кардинально улучшилась.
В цифрах и фактах
Давайте посмотрим на конкретные измеренные улучшения:
Time-to-market для новых функций сократился на 40%;
среднее время между сбоями увеличилось на 30%;
время восстановления после сбоев ускорилось на 200%;
количество операций, выполняемых быстрее 1 секунды, выросло с 65% до 95%.
Стоит отметить, что такое улучшение показателей продукта было достигнуто целым комплексом мер: и применением микросервисного подхода, и переходом на облачные вычислительные платформы, и применением более зрелых практик продуктового управления. К тому же команда получила дополнительную мотивацию от внедрения новых технологий и долгожданного рефакторинга кода с бизнес-логикой, развиваемой годами.
Как у нас это работает
Наложенная сложность разработки и управления микросервисами в МТС решается с помощью платформ.
Все начинается с платформы разработки под названием «Продуктовая фабрика». В ее основе лежит доработанный форк GitLab. Небольшие команды пользуются общими GitLab-раннерами, готовый набор которых уже работает в нашем облаке, более требовательные команды запускают свои — второй вариант дает больше скорости и меньше очередей при сборке.
Всем командам доступны готовые шаблоны пайплайнов сборки и публикаций, которые содержат все необходимое для работы с микросервисами: от структуры директорий до выбранных инструментов. Например, GitLab-раннер, сам запущенный как контейнер Docker, после компиляции кода должен собрать «Docker-внутри-Docker», и для этого уже сразу есть kaniko.
Микросервисы разворачиваются в готовом Kubernetes и подключаются к управляемым сервисам (хранилища, БД, брокеры) от нашей облачной платформы Ocean. Все управляемые сервисы имеют встроенные функции резервного копирования, возможности масштабирования, кластеризации как в одном дата-центре, так и между разными географически распределенными дата-центрами.
Должное внимание также уделяется и наблюдаемости. Каждый микросервисный контейнер реализует минимальный функционал для выставления метрик, записи логов и отправки трейсов по принципам 12 factor apps, а наша Платформа Наблюдаемости разворачивает свои локальные агенты для сбора этой информации, принимает и хранит данные и предоставляет витрины для наблюдения, средства автоматической регистрации инцидентов, контроля корректной работы сервисов и многое другое.
Для получения ресурсов от платформ командам достаточно просто зарегистрировать свои приложения в общей учетной системе.
Уровни зрелости: от совместимости до полной натурализации
Чтобы помочь командам найти место в спектре между «все монолит» и «все микросервисы», мы разработали собственную модель зрелости для продуктов, развивающих свою архитектуру. В нашем подходе путешествие в микросервисы объединяется с переходом на облачные платформы и управляемые сервисы, поэтому мы выделяем следующие уровни зрелости:
Cloud Compatible — приложения, способные работать в облаке и не привязанные к конкретной инфраструктуре. У них минимум нефункциональных требований, и они могут быть реализованы в монолитном архитектурном стиле. При переходе в облако они получают автоматизацию развертывания и управления, средства наблюдаемости, отслеживание работоспособности и автоматическое восстановление.
Cloud Ready — приложения, получающие уже более заметный выигрыш от размещения в облачной инфраструктуре благодаря распределенной архитектуре и повышенной масштабируемости при полном или частичном использовании микросервисного стиля.
Cloud Native — максимальный уровень облачной зрелости. Такие приложения соответствуют самым высоким требованиям к производительности и контролю целостности данных, в них заложено автомасштабирование (эластичность), используются надежные брокеры сообщений и применяются продвинутые паттерны микросервисных коммуникаций: Retry, Circuit Breaker, Transactional Outbox и т. п.
Это помогает нам постепенно и осознанно повышать технологическую зрелость продуктов, не пытаясь сразу загнать всех в «светлое микросервисное будущее».
Как по дороге к микросервисам не прийти к распределенному монолиту
Проектирование микросервисов — задача не из легких. По нашему опыту, критическим моментом является этап моделирования бизнеса. Здесь выясняется, какими понятиями оперируют в предметной области, как работают пользовательские сервисы, какими сущностями представлены обрабатываемые и хранимые данные.
Мы продвигаем Event Storming как методику моделирования бизнеса и мотивируем наших аналитиков и архитекторов не только глубже изучать свои предметные области, но и уметь быстро погружаться и достоверно моделировать любые бизнес-домены.
Одним из очень полезных результатов сессий Event Storming является правильная нарезка ограниченных контекстов. Она дает слабую связанность компонентов и, как следствие, масштабируемость, автономность, гибкость разработки, скорость поставки.
Выбор технологий
Любой выбор дает нам шанс извлечения уроков из его последствий. Так же и с выбором технологий для микросервисов — сделать его правильно нам помогает наш Техрадар.
Публичный Техрадар — это верхушка айсберга нашего каталога технологий. В расширенном внутреннем каталоге описано гораздо больше как отдельных технологий, так и их версий, особенностей, лицензионных ограничений, есть ссылки на гайды и рекомендации по выбору технологий для разных ситуаций.
А в сочетании с Единым Архитектурным Репозиторием мы получаем возможность узнать об использовании нужной технологии другими командами, посмотреть ее реализацию в существующих продуктах или найти типовые шаблонные архитектуры для своего случая.
Что дальше?
Мы продолжаем активно развивать подходы к управлению архитектурой. Например, хотим, чтобы команды не просто рисовали красивые схемы, а моделировали архитектуру на разработанном нами языке Architecture-as-Code. И не только лишь архитектуру самого программного приложения «в вакууме», но и архитектуру законченной информационной системы (приложение и его вычислительная инфраструктура) в виде модели развертывания. Области применения таких машиночитаемых моделей обширны и дают нам принципиально новые возможности.
В первую очередь архитектор начинает проектировать не абстрактные приложения, а реальные информационные системы «в железе». Это позволяет заранее видеть и решать такие задачи, как, например, корректный выбор контуров сетевой защиты для разных компонентов решения. Сегодня с помощью моделей развертывания мы можем ставить задачи на развертывание DevOps-инженерам, а завтра генерировать Helm-чарты, Terraform-конфигурации, firewall-правила и разворачивать информационные системы полностью автоматически.
На этих же артефактах строится и Цифровой Двойник всего ИТ-ландшафта. Мы видим, какие системы взаимодействуют друг с другом, как непосредственно, так и по длинной цепи промежуточных интеграций, можем построить карту воздействия отказов при потенциальных проблемах в какой-либо из систем и многое другое.
Меняется и совершенствуется и наш подход к административному управлению.
Вначале мы «раскручивали маховик» технологической трансформации в императивном режиме, сразу ставили командам задачи по переходу на облачные платформы и распределенные архитектуры, включая микросервисы. Конечно, даже тогда мы подходили к этому разумно, не было сомнений, что восторженный карго-культ и «микросервисы ради микросервисов» — это не наш путь.
Мы сразу ввели вышеописанную модель облачной зрелости. Кроме этого, все команды получали не голый «бумажный» стандарт, а очные встречи, консультации и конкретную помощь в «прокачке» существующих архитектур их приложений. Это позволило и нам самим быстро реагировать на неучтенные ситуации, оперативно совершенствовать наши стандарты и рекомендации, а также помогло собрать лучшие практики «с полей» и распространить их внутри МТС — не как просто идеи из «индустриального опыта», а конкретные успешные кейсы, приземленные на наши реалии.
Теперь, когда команды увидели улучшения от применения микросервисных подходов и облачных технологий на примере своих продуктов или опыта смежных команд, они уже включаются в эту инициативу добровольно и сами набирают задачи по повышению облачной зрелости в бэклоги своих продуктов.
Вместо заключения
Большую роль в успешном переходе на облачные и микросервисные технологии играет личная мотивация наших разработчиков. Для них это:
возможность поработать с новыми технологиями и сделать долгожданный рефакторинг;
автоматизировать рутинные задачи в разработке и развертывании;
повысить надежность и доступность своих продуктов с помощью новых инструментов оркестрации и наблюдаемости;
актуализировать собственные технические навыки и продвинуть свое профессиональное развитие.
На уровне отдельных продуктов такая трансформация улучшает такие критически важные метрики, как Time-to-market для новых функций, надежность систем, скорость восстановления после сбоев. Они напрямую влияют на бизнес и их улучшение — не только красивые цифры в отчетах, а реальное конкурентное преимущество.
На уровне компании важна отвязка продуктов от собственной отдельной инфраструктуры на фоне усложнения закупки вычислительных ресурсов. В экономике масштаба переход на унифицированное оборудование и динамическое выделение ресурсов значительно повышает эффективность использования вычислительных мощностей — вместо «двойного запаса» на уровне отдельных команд гораздо выгоднее держать «общий» резерв на уровне дата-центров, эластично добавляя ресурсы продуктам по мере необходимости и возвращая их в общий пул после спадания нагрузки.
Самое главное — мы научились принимать взвешенные решения о том, где микросервисная архитектура действительно нужна, а где она создаст больше проблем, чем пользы. В конце концов, главное не технологии сами по себе, а то, насколько эффективно они помогают нам решать реальные задачи бизнеса.
N. B. Технологические принципы экосистемы МТС.
Это фундаментальные правила принятия решений для команд разработки, которые поддерживают развитие их процессов, систем и продуктов в соответствии с технологической стратегией экосистемы. Следование им позволяет командам:
сократить издержки при согласовании решений;
самостоятельно действовать в своей зоне ответственности;
работать синхронно с другими командами.
Это первый материал из цикла про технологические принципы. Остальные будут появляться здесь по мере выхода новых частей: