Сегодня мы поговорим о переходе с монолита на микросервисы. Многие задумываются над этим, когда наступает необходимость, но не все знают, как и с чего начать. В компании Авито сейчас как раз решают эту задачу и готовы поделиться своим опытом, поэтому рассказ пойдет от имени их специалиста.
Меня зовут Семен Катаев, я работаю в Авито над процессом перехода от монолитной архитектуры к микросервисам. Переход у нас все еще продолжается, но мне уже есть чем с вами поделиться. Это краткий обзор того, с чем придётся столкнуться, если вы задумались над созданием надежного, масштабируемого, распределённого приложения.
Нам пришлось поменять практически все процессы разработки, провести реорганизацию в компании, освоить новые для нас паттерны проектирования и начать использовать незнакомые инструменты для перехода к микросервисной архитектуре. Об инструментах сегодня и пойдёт речь.
До того как мы стали задумываться о микросервисной архитектуре, у нас было классическое веб-серверное приложение с горизонтальным масштабированием. Весь пользовательский трафик встречала серия Load Balancers, которые решали задачи L3-L4 по модели OSI. Application Layer или L7 по модели OSI мы вынесли на отдельный пул серверов, за которыми находилось приложение, формирующее ответ на пользовательский запрос. За ним стояли базы данных:
Отсюда мы начали двигаться в микросервисы. Так как бизнес развивается, в какой-то момент у нас стало 400+ инженеров, которые ежедневно пишут код, делают задачи и запускают процессы CI/CD. И с ростом сложности проекта начала падать производительность отдельно взятого инженера. Хотя микросервисы — это не единственный путь для развития компании, мы решили использовать его из-за модульного подхода к разработке ПО, когда приложение дробится на много независимых слабо связанных модулей (микросервисов). Ниже классическая схема приложения на микросервисной архитектуре.
Мы начали активно делать новые независимые микроприложения и пришли к тому, что у нас сейчас больше 1500 микросервисов (около 200 из них критичных), 2500 баз данных и 3000 git-репозиториев на стеке Atlassian-продуктов и Bitbucket. Мы проводим до 200 деплоев каждый день.
Сложно найти единое правило или критерий, до какой степени гранулярности дробить приложение. У нас пока ещё есть монолит, работающий с разными инструментами (Postgres, Sphinx, Redis, MongoDB, Nginx). Новые фичи мы делаем в микросервисах: например, реализуем API для мессенджера на всех платформах (десктоп, мобильные устройства), бэк-офис со своими независимыми кронами и демонами. У каждого микросервиса может быть своя база данных, своя команда инженеров, свой техдолг, техлид, бэклог, capacity planning и план развития:
Глядя на эту схему, может показаться, что всё очень просто — делай отдельные микро-приложения и получишь микросервисную архитектуру. Но, на самом деле, всё гораздо сложнее.
Один из вызовов микросервисной архитектуры — сделать так, чтобы не потерять комфортность разработки на таких масштабах, чтобы объем техдолга не рос экспоненциально, и количество «грязной» работы держался на одном уровне.
Под «грязной» работой я подразумеваю задачи, когда, например, в Golang v1.15 нашли уязвимость и нам надо обновить 500 микросервисов. Или в 400 микросервисах надо поменять SDK для сбора логов. Всю эту «грязную» работу надо как-то автоматизировать. Не говоря уже про управление 10 тысячами микросервисов.
Читать продолжение статьи Микросервисы для чайников: как на них перейти с монолита с нуля. Часть 2
Команда «Онтико» готова помочь тем, кто потерял работу из-за санкций и их последствий.
Заполните анкету и её увидят более 100 потенциальных работодателей.
Если у вас есть друзья, которым актуальна помощь, перешлите им это сообщение.