Конспект доклада «Что мы знаем о микросервисах» (HL2018, Avito, Вадим Мадисон)

    Привет, %username%!

    Совсем недавно закончилась конференция Highload++ (еще раз спасибо всей команде организаторов и olegbunin лично. Было очень круто!).

    Накануне конференции Алексей fisher предложил создать инициативную группу «сталкеров» на конференции. Мы, во время докладов, писали небольшие конспекты, которыми обменивались. Некоторые конспекты получились достаточно детальными и подробными.

    Сообщество в соц сетях позитивно оценило такой формат, поэтому я (с разрешения) решил опубликовать конспект первого доклада. Если данный формат будет интересен, то я смогу подготовить еще несколько статей.

    image

    Погнали


    В авито много сервисов и очень много связей между ними. Это порождает проблемы:

    • Много репозиториев. Сложно менять код одновременно везде
    • Команды ограничены своим контекстом. Максимум пересекаются незначительно и не все
    • Добавляется фрагментарность данных.

    Большое количество инфраструктурных элементов:

    • Логирование
    • Трассировка запросов (Jaeger)
    • Агрегация ошибок (Sentry)
    • Статусы / сообщения / события из Kubernetes
    • Race limit / Circuit Breaker (Hystrix)
    • Связность сервисов (Istio)
    • Мониторинг (Grafana)
    • Сборка (Teamcity)
    • Общение
    • Трекер задач
    • Документация
    • ...

    Есть ряд слоев, доклад описывает только один (PaaS).

    В платформе 3 основные части:

    • Генераторы, которые управляются через cli
    • Аггрегатор (коллектор), который управляется через дашборд
    • Хранилище (storage) с триггерами на определенные действия.

    Стандартный конвейер разработки микросервиса


    CLI-push -> CI -> Bake -> Deploy -> Test -> Canary -> Production

    CLI-push


    Долго учили делать правильно разработчиков. Все равно осталось слабым местом.

    Автоматизировали через cli утилиту, которая помогает создать базис под микросервис:

    1. Создаёт сервис по шаблону (поддерживаются шаблоны для ряда ЯП).
    2. Автоматически разворачивает инфраструктуру для локальной разработки
    3. Подключает БД (не требует конфигурирования, разработчик не думает о доступах к любой базе).
    4. Live-сборка
    5. Генерация болванок автотестов.

    Конфиг описывается в toml файле.

    Пример файла:

    image

    Валидация


    Базовая валидация проверяет:

    • Наличие Dockerfile
    • app.toml
    • Наличие документации
    • Зависимостии
    • Правила алертов для мониторинга (задаёт владелец сервиса)

    Документация


    Документация должны быть у всех, но ее почти ни у кого нет

    В документации должно быть:

    • Описание сервиса (краткое)
    • Ссылка на диаграмму архитектуры
    • Runbook
    • FAQ
    • Описание endpoint API
    • Labels (привязка к продукту, функциональности, структурному продразделению)
    • Владелец(цы) сервиса (может быть несколько, в большинстве случаев можно определять автоматически).

    Документацию нужно ревьюить.

    Подготовка пайплайна


    • Готовим репозитории
    • Делаем пайплайн в TeamCity
    • Выставляем права
    • Ищем владельца (двух, одного ненадежно)
    • Регистрируем сервис в Atlas (внутренний продукт)
    • Проверяем миграции.

    Bake


    • Сборка приложения в docker image.
    • Генерация helm-чартов для самого сервиса и связанных ресурсов (БД, кэш)
    • Создаются тикеты админам на открытие портов, учитываются ограничения по памяти и cpu.
    • Прогон unit-тестов. Ведётся учёт по code-coverage. Если ниже определённого, то деплой заворачивается. Если объём покрытия не прогрессирует, пушатся уведомления.

    Поиск owner определяется по пушам (количество пушей и количество кода в них).

    Если есть потенциально опасные миграции (alter), то регистрируется триггер в Атлас и сервис помещается в карантин.

    Через пуши владельцам разруливается карантин (в ручном режиме?)

    Проверка конвенций


    Проверяем:

    • Сервисные endpoint
    • Соответствие ответов схеме
    • Формат логов
    • Выставление заголовков (в том числе X-Source-ID при отправке сообщений в шину для отслеживания связности через шину)

    Тесты


    Тестирование выполняться в закрытом контуре (например hoverfly.io) — записывается типовая нагрузка. Затем по ней эмулируется в закрытом контуре.

    Проверяется соответствие потреблений ресурсов (отдельно смотрим крайние случаи — слишком мало / много ресурсов), отсечка по rps.

    Нагрузочное тестирование также показывает дельту производительности между версиями.

    Canary тесты


    Начинаем запуск на очень малом количестве пользователей (<0.1%).

    Минимальная нагрузка 5 минут. Основная 2 часа. Затем увеличивается объём пользователей если все ок.

    Смотрим:

    • Продуктовые метрики (в первую очередь) — их много (100500)
    • Ошибки в Sentry
    • Статусы ответов,
    • Respondents time — точное и среднее время ответов
    • Latency
    • Исключения (обработанные и необработанные)
    • Специфичнее для языка метрики (например, воркеры php-fpm)

    Squeeze testing


    Тестирование через выдавливание.

    Нагружаем реальными пользователями 1 инстанс до точки отказа. Смотрим его потолок. Далее добавляем ещё инстанс и догружаем. Смотрим следующий потолок. Смотрим регрессию. Обогащаем или заменяем данные из нагрузочного тестирования в Atlas.

    Масштабирование


    Только по cpu плохо, надо добавлять продуктовые метрики.

    Итоговая схема:

    • CPU + RAM
    • Кол-во запросов
    • Время ответа
    • Прогноз по историческим данным

    При масштабировании не забывать смотреть зависимости по сервисам. Помним про каскад масштабирования (+1 уровень). Смотрим исторические данные инициализирующего сервиса.

    Дополнительно


    • Обработка триггеров — миграции, если не осталось версии ниже Х
    • Сервис давно не обновлялся
    • Карантин
    • Secure updates

    Дашборд


    Смотрим на все сверху в аггрегированном виде и делаем выводы.

    • Фильтрация по сервису и лейблам
    • Интеграция с трассировкой, логированием, мониторингом
    • Единая точка документации по сервисам
    • Единая точка показа всех событий по сервисам

    Пример:

    image
    Поделиться публикацией

    Комментарии 10

      0
      Да! Конечно, конспекты любых докладов на любых конференциях(в пределах разумного конечно) это нужно!
        0
        я может чего-то не понимаю, но записи видео и презентации будут доступны через некоторое (не очень большое) время. А конспекты попахивают пиратством…

        Кстати, доклад Мадисона был в Конгресс-Холле и поэтому доступе по ссылке на ненарезанное видео трансляции.
          0
          записи видео и презентации будут доступны через некоторое (не очень большое) время

          Если вам так удобнее, можете пропустить и посмотреть исключительно видео или презентации. Лично мне такие конспекты помогают лучше понять доклад, запомнить основные мысли, отразить некоторые выводы для себя. Ну и потратить 10 минут на чтение тезисных моментов всегда проще, чем пересмотреть видео на 50 минут.
          Изучение тезисов не отменяет, при желании, пересмотр видео (может быть даже не 1 раз).

          А конспекты попахивают пиратством…

          Не могли бы пояснить мысль?
            0
            Ну, как бы сама презентация — уже и есть конспект (в опреленной мере, в силу своей сути).
            Не могли бы пояснить мысль?

            Вы правы. В договоре на участие в конференции такой идеи не было. Но как правило хорошего тона — не распространять материалы до официальной публикации (либо авторами самих материалов, либо представителями конференции). И мне не ясно, правда, распространяется ли оно на конспекты. И одно дело — обсуждение в кулуарах и с коллегами (в закрытом кругу), а другое — публикация на хабр.
            Возможно, я уже паранойю, т.к. поздно. Или меня просто сотрудники безопасности покусали (и теперь я зомби и мне нужно срочно лекарство ))))))

            P.S. пункт о конфиденциальности получаемой информации нашел в договоре о проведении конференции от другой организации, не Онтико.
              0
              В договоре на участие в конференции такой идеи не было

              Очень странно принимать участие в таком обсуждении.

              Но как правило хорошего тона — не распространять материалы до официальной публикации

              На этот счет я отдельно спрашивал и получил разрешение и одобрение.

              одно дело — обсуждение в кулуарах и с коллегами (в закрытом кругу)

              А если с ними поделился, они потом никому не могут говорить?

              Для меня знания — это источник света, вдохновения и роста, а для вас гриф секретности.
              Мне действительно очень жаль, что вы считаете эту публикацию вредной.
                0
                Я не считаю вредной (в худшем случае — бесполезной), а уточнил основания публикации ) возможно не совсем удачно, но уже весьма поздно.
                И вообще хайлоад (да и прочие конференции Олега Бунина) стоит своих денег.
                К сожалению, недостатки есть везде. И с точки зрения организациии- просто физически невозможно успеть на все потоки и митапы (кстати, они самое «мясо», т.к. записей митапа нет и не предвидится).
                Для меня знания — это источник света, вдохновения и роста, а для вас гриф секретности.

                Ну, нет. Есть разница между «знания — гриф секретности» и «распространять материалы конференции», не так ли? К тому же, никто не мешает рассказать о своем опыте по мотивам тех же тем (и это будет оригинальный материал)
                И ещё отдельный вопрос (который был): чем лучше конспект самой презентации.
        0
        1. yushkevichv Большое спасибо, продолжайте в том же духе!

        2.
        > сложно менять код…
        Может оно не достаточно «микро-»?
          0
          По п.2 — ходила такая мысль в кулуарах. Но тут было бы хорошо Вадима услышать.
          На одном из слайдов презентации была графика с отображением всех сервисов и связями между ними. Из действительно много (но, да, это не говорит ничего о размере каждого).
            +1
            >Сложно менять код одновременно везде
            Тут как раз ключевое не в том, что код сложно менять как таковой, а речь идет о каких-то больших рефакторингах которые затрагивают много сервисов.
            0

            твиттер борется с этой проблемой использованием монорепозиториев и RPC кодогенераторов.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое