Всем привет! Меня зовут Александр Ермолаев, я один из лидов в IT-платформе СберМаркета. Моя команда занимается разработкой шаблонов, библиотек и некоторых инструментов для создания микросервисов.
Это первая статья из цикла, посвященного PaaS. В СберМаркете мы посвятили его разработке уже 2 года и хотим поделиться с миром нашим положительным и не очень опытом на этом пути. В серии статей затронем следующие темы:
Библиотека для создания сервисов: как мы её написали и развиваем сейчас
Процессы в PaaS: как запустить сервис локально одной командой
Путь сервиса от разработки до прода в СберМаркете
Как устроено взаимодействие контрактов между сервисами
Про сложности при тестировании связанных сервисов и как мы их решаем
Об этом же, но менее детально мы недавно рассказали на PaaS-митапе. В статьях хотим углубиться в технику и дать больше контекста.
Итак, стартуем с самого начала. В этой статье я расскажу, с чего мы начали в далёком 2020 году, с какими проблемами столкнулись и как их решали. Материал будет особенно актуален для тех, кто задумывается о старте разработки PaaS у себя в компании и не знает, с какой стороны подступиться к этому непростому делу. Поехали!
Мечтают ли разработчики о PaaS?
Какие требования к PaaS мы сформулировали в СберМаркете
Первые проблемы и их решения: документация, выбор одного пакета и баги
О чём мечтают разработчики
Представим, что у нас есть разработчики и их работа — создавать сервисы. Скорее всего, они не хотят думать о том, как подключаться к ресурсам, как соединяться с конкретной базой данных, а таже о том, как собирать логи и метрики и отправлять спаны в трейсинг. Что они точно хотят, так это сосредоточиться на написании бизнес-логики. В принципе остальное их волновать и не должно.
Когда бизнес-логика уже написана, разработчики хотят провести тесты — в идеале автоматические. Чтобы они запускались как локально, так и в пайплайне. Естественно, они хотят использовать юнит-тесты, моки, интеграционные тесты, нагрузочные тесты.
Дальше наступает момент, когда сервис появляется на стейдже или в продакшене. Разработчикам хочется за этим процессом наблюдать: понимать, что происходит, видеть метрики на дашбордах. А если возникнет ситуация, когда сервис чувствует себя не очень хорошо, разработчик хочет иметь возможность профилировать его или запускать процесс отладки. Наконец, важно получать алерты и ошибки как можно скорее.
Одна БД, одна библиотека, одна платформа
Мы с командой попытались войти в положение разработчиков и дать им инструмент, который будет просто использовать. При этом мы понимали, что наши разработчики могут иметь совершенно разный опыт: это могут быть как видавшие виды сеньоры, так и совсем молодые и неопытные джуны. Соответственно, нужно было стандартное решение, которое можно легко контролировать: с простой поддержкой и удобными обновлениями.
Мы решили, что будем работать с одним подключением к определенному ресурсу (БД, Redis, Kafka, etc). Это означает, что мы не поддерживаем простой способ подключения нескольких ресурсов одного типа, что для микросервиса обычно не является проблемой.
Также мы установили ограничение в одну библиотеку для работы с ресурсами. Мы посчитали, что если дать разработчикам выбор библиотеки (например, использовать Sarama для подключения Kafka или Confluent), поддерживать придётся слишком много — умножать метрики, логи, трейсинг и т.д. А это в свою очередь умножит ошибки и затраты на поддержку.
Была выбрана простая конфигурация через toml-файл.
Далее мы определили стандартные каталоги, где пользователи будут размещать свои компоненты.
Для синхронного общения взяли только один протокол — gRPC. На первом этапе этого было достаточно, но в будущем у нас, конечно же, появился HTTP.
Для асинхронного общения мы рассматривали только Kafka.
И последнее. Мы хотели по возможности дать высокоуровневые интерфейсы. Они должны скрывать всю рутину от пользователя. К примеру, если он хочет получать и обрабатывать сообщения из топика Kafka, то просто вызывает функцию, которая подключает обработчик к топику.
Что мы сделали в первом подходе
Начали мы разработку PaaS с первых и самых главных шагов:
Определили структуру каталогов. Для этого выбрали структуру, которая описана в этом репозитории.
Выбрали Makefiles для запуска приложения. Makefiles — это не простой, но мощный инструмент для организации скриптов, которые удобно расширять и поддерживать дополнительные файлы разработчика.
Решили, что нам нужна библиотека, которая будет отвечать за создание приложения. Мы рассмотрели разные готовые варианты и остановились на том, что нужна своя.
Спустя полтора месяца после начала разработки у нас уже была библиотека, мы назвали ее go-libs. Она включала в себя функционал для работы с gRPC и Kafka, базами данных, health-чеки и все это было автоматически доступно разработчику. Была документация с примерами создания приложений, были Makefiles, которые реализовали команды для запуска сборки контейнеров и прочего.
Первые проблемы (и первые решения)
Естественно, как только мы выкатили инструмент, на поверхность вышли его недостатки. Вот они все сверху вниз:
Документация
Первая проблема была связана с тем, что документация представляла собой просто набор страниц, в котором каждый разработчик писал свой кусок. Мы взяли задачу в спринт и начали приводить её к единообразному виду, но лучше от этого не стало. Почему? Потому что мы упустили несколько важных моментов.
Если вы думаете над документацией для разработчиков, в первую очередь составьте глоссарий. Мы в какой-то момент называли toml-конфигурацию то конфигом, то манифестом. При этом у нас еще был манифест для Deploy. Это вызывает недоразумения и тормозит работу.
Продумайте структуру документации. Желательно, чтобы это была небольшая иерархия. Два-три уровня более чем достаточно.
Ориентируйтесь на хорошие примеры. Например, посмотрите, как оформлена документация DigitalOcean, Docker, Heart-Open.
Соберите это всё на одном портале: документация, новости, статьи, анонсы, пусть всё будет в одном месте и с хорошим поиском. Это сильно упрощает работу.
Разные пакеты
Следующая проблема заключалась в том, что разработчики с разным опытом использовали пакеты, которые им привычнее и удобнее. А мы, как уже было сказано, хотели ограничить их единым инструментом.
Чтобы выбрать пакеты, мы провели исследование. В результате получилась wiki-страница со сравнением. Критериями стали популярность, удобство поддержки и то, как решаются issues.
Вопросы разработчиков и контрибьютинг
После запуска разработчики регулярно приходили к нам с просьбами поправить какие-то куски. Мы могли это сделать, но возникал риск, что разработчик снова что-то заденет, когда продолжит работу. Нужен был более системный подход.
Мы решили сформировать канал для общения, чтобы ребята могли задавать вопросы или предлагать нам что-то улучшить. Был заведен график дежурств, по которому сотрудники PaaS занимались этими заявками. Появился вишлист: пользователи писали там свои пожелания, а мы раз в неделю просматривали список и решали, какие задачи достойны решения.
Еще мы разработали инструкцию, как контрибьютить, как работать с разными частями, как описывать документацию.
Баги и тестирование
Мы сами в команде создаем немного багов :) В основном приходится обнаруживать какие-то проблемы в сторонних пакетах: sarama, pgx, пакеты для сбора метрик. Сейчас мы практически не используем сторонние пакеты для сбора метрик, используем только свои.
Мы поняли, что должны работать так же, как наши разработчики. Во-первых, мы завели себе Sandbox. В песочнице несколько проектов, а сервисы могут объединиться и взаимодействовать друг с другом. На этом Sandbox удобно обкатывать решения и проверять все, что мы реализовываем в библиотеке. Для разработчиков тоже есть профит: они могут брать хорошие примеры и использовать в своих проектах.
Во-вторых, мы перешли к системе релизов. Спустя год после первого релиза, мы стараемся обновлять библиотеку раз в месяц.
В-третьих, мы очень серьезно относимся к тестам: автоматическим, юнит и интеграционным. Их все мы пишем в нашей библиотеке.
Что в итоге
По прошествии двух лет инструменты несколько видоизменились, но описанный опыт точно может пригодиться таким же командам, которые только начинают выстраивать единую среду. Буду рад ответить на вопросы в комментариях!
А ещё 24 августа приходите на бесплатную онлайн-конференцию E-COMMUNITY про актуальные вопросы разработки под e-com. Там расскажем о том, как платформа ускоряет доставку ценности.
Tech-команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.