Signadot спонсировал этот пост.
На прошлой неделе я общался с вице -президентом по технике, который сделал наблюдение, которое застряло со мной: «Когда у нас было пять микросервисов, тестирование было на самом деле проще, чем наш старый монолит. В 50 услуг это стало нашим самым большим узким местом».
Это не редкость. Большинство команд испытывают период медового месяца с микросервисами, где тестирование кажется управляемым, даже элегантным. Тогда что -то меняется. То, что когда -то было конкурентным преимуществом, становится сопротивлением скорости. Вопрос в том, почему микросервисы тестируют сложность, кажется, растут в геометрической прогрессии, а не линейно?
Обманчивые первые дни
Вначале тесты на микросервисы напоминают дыхание свежего воздуха. У вас есть чистые границы обслуживания и сфокусированные тестовые люксы, и каждая команда может двигаться самостоятельно. Тестирование платежной услуги? Поверните сервис, наденьте службу пользователя, и все готово. Простой.
Этот ранний успех создает разумное предположение, что сложность тестирования будет масштабироваться пропорционально количеством услуг и разработчиков. В конце концов, если каждая услуга может быть проверена в изоляции, и вы увеличиваете свою инженерную команду наряду с вашими услугами, почему бы не масштабировать усилия по тестированию линейно?
Это логическое предположение. И это совершенно неправильно.
Скрытые экспоненциальные силы
Реальность такова, что сложность тестирования в микросервисах растет в геометрической прогрессии из -за нескольких составных факторов, которые не очевидны, когда вы начинаете.
Точки интеграции умножаются быстро
С пятью услугами у вас может быть восемь или 10 точек интеграции для тестирования. Но точки интеграции не масштабируются линейно — они масштабируются на основе взаимосвязанности вашей системы.
Источник: Signadot.
Подумайте об этом: каждая услуга не просто звонит еще одному сервису. Типичный микросервис может интегрироваться с четырьмя и шестью другими службами — аутентификацией, ведением журнала, хранением данных, службами уведомлений, а также двумя или тремя услугами бизнес -логики. По мере роста вашей архитектуры услуги становятся более взаимосвязанными, а не меньше. Эта служба заказов не просто разговаривает с инвентаризацией; Он также попадает в обработку платежей, управление пользователями, доставку, аналитику и регистрацию аудита.
Результат? Точки интеграции растут намного быстрее, чем количество услуг, создавая сеть зависимостей, которые должны быть подтверждены.
Каждый новый сервис не просто добавляет свои собственные требования к тестированию. Он потенциально взаимодействует с несколькими существующими услугами, создавая сеть зависимостей, которые должны быть подтверждены. То, что началось как простое тестирование точки-точки, становится сложной и растягивающейся задачей проверки.
Выдетельное обслуживание становится неустойчивым
Измешные стратегии, которые прекрасно работают в небольшом масштабе, становятся бедствиями в больших масштабах. Одно изменение API может потребовать обновления десятков макетов в разных кодовых базах, принадлежащих разным командам.
Директор по инжинирингу платформы недавно сказал мне: «Мы подсчитали, что наши команды тратят 40% своего времени тестирования, просто поддержав макет».
Умножение окружающей среды спирали из -под контроля
С пятью услугами поддержание трех -четырех тестовых среды на команду кажется разумным. Масштабируйте до 50 услуг в 15 командах, и вдруг вам понадобится 45-60 сред. Затраты на инфраструктуру и оперативная сложность становятся ошеломляющими.
Один из наших клиентов ежегодно тратил 2 миллиона долларов на предварительную среду, прежде чем он переосмыслил свой подход. Команда OPS тратила больше времени на поддержание тестовой инфраструктуры, чем на создание новых возможностей.
Усиление узкого места постановки
Возможно, самая болезненная задача масштабирования — это то, что происходит с общей ставкой. С несколькими услугами разумно хорошо провести работы. Несколько команд могут координировать развертывание, и когда что -то сломается, виновник обычно очевиден.
Но когда вы добавляете услуги и команды, постановка становится либо пробкой, либо свободной для всех-и оба катастрофические.
Источник: Signadot.
Вариант 1: Эксклюзивная очередь доступа
Некоторые организации осуществляют строгое планирование, где команды получают эксклюзивный доступ к постановке. Я видел, как команды ждали восемь или более часов своей очереди, с сложными системами координации — Slackbots, Calendars развертывания и другими механизмами — для управления очередью.
Математика здесь жестока. Если у вас есть по 20 команд, каждый из которых нуждается в доступе к размещению два раза в неделю, и каждая сессия тестирования занимает два часа, вам нужно 80 часов работы в неделю. Но у вас всего 40 часов (одна среда, с понедельника по пятницу). Средняя полностью загруженная инженерная стоимость в размере 150 долларов в час, время ожидания переводится на тысячи долларов в течение еженедельника по утерянной производительности. Одна организация, с которой мы работаем, рассчитывали, что она горела 400 000 долларов в год только на инженеров, ожидающих постановки доступа.
Вариант 2: хаос общего доступа
Чаще всего команды разделяют постановку одновременно без координации. Не ожидая, но теперь несколько команд развертывают и тестируют одновременно. Сбои теста становятся бессмысленными — это ваш код или чужое развертывание, которое сломало поток?
Это создает извращенный результат: разработчики теряют доверие к результатам тестов и начинают игнорировать неудачи, предполагая, что они связаны с окружающей средой. Команды подталкивают код до производства, несмотря на неудачные тесты, что приводит к инцидентам производства. Сама среда, предназначенная для того, чтобы поймать ошибки до того, как производство станет источником ложной уверенности.
Когда команды начинают играть в систему
По мере того, как тестирование становится более болезненным, команды начинают развивать обходные пути, которые усугубляют основные проблемы:
- Запасывание изменений: Вместо того, чтобы тестировать отдельные функции, команды объединяют несколько изменений вместе, чтобы «оптимизировать» время постановки. Это делает отладку экспоненциально сложнее, когда что -то ломается.
- Тестирование ярлыков: Команды пропускают тесты интеграции и надеются на лучшее, или проверяют только «счастливый путь», чтобы сэкономить время. Качество неизбежно страдает.
- Корпление окружающей среды: Команды начинают резервировать стажирующие условия дольше, чем необходимо, создавая искусственную дефицит.
- Параллельные прилавки для развития: Команды начинают координировать свои циклы разработки, чтобы избежать постановки конфликтов, разрушая независимость, которую обещали микросервисы.
Разрыв экспоненциальной кривой
Команды, которые успешно масштабируют тестирование микросервисов, выяснили, как сломать эту экспоненциальную кривую. Они отошли от попыток дублировать производственные среды для тестирования и вместо этого сосредоточены на создании изолированных кусочков их производственной среды.
Вместо того, чтобы раскручивать 50 услуг для каждого тестового сценария, они раскручивают только два или три сервиса, которые модифицируются и направляют трафик тестирования на производственные версии всего остального. Эта умная эфемерная среда подходит к росту сложности, сохраняя при этом тестирование с высокой точностью.
Вот как это нарушает каждую из экспоненциальных проблем масштабирования:
- Сложность интеграции: Вместо того, чтобы тестировать более 200 точек интеграции, вы тестируете только четыре -шесть точек интеграции для ваших измененных услуг против реальных зависимостей.
- Ихническое обслуживание: Никаких макетов не требуется-ваши изменения теста на фактические производственные услуги, исключая накладные расходы на техническое обслуживание.
- Умножение среды: Одна общая базовая среда поддерживает неограниченное изолированное тестирование с помощью маршрутизации на уровне запросов, что значительно снижает затраты на инфраструктуру.
- Постановка узких мест: Каждый разработчик получает свою собственную изолированную среду тестирования мгновенно, без каких -либо очередей и никаких вмешательства от изменений других команд.
Один клиент объяснил это прекрасно: «Мы перестали пытаться воссоздать весь мир для каждого теста. Вместо этого мы создаем небольшой пузырь изменений и проверяем, как он взаимодействует с реальным миром».
Путь вперед
Тестирование микросервисов не должно стать экспоненциально сложным по мере масштаба. Ключ-рано, что традиционные подходы к тестированию не масштабируются выше 10-15 услуг и принятие тестирования, которое линейно растет с вашей архитектурой.
В Signadot мы создали платформу, которая позволяет именно в условиях этой проблемы, позволяя командам проверять индивидуальные изменения против производственных зависимостей без экспоненциальной сложности. Если вы попадаете в стену тестирования, попробуйте бесплатно и посмотрите, как линейное масштабирование все меняет.
Signadot-это платформа для тестирования Kubernetes для микросервисов. Используя Signadot, инженерные команды «сдвигаются налево», чтобы выяснить проблемы раньше и повысить доверие. Узнайте больше новейших из Signadot Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Арджун Айер, генеральный директор Signadot, является опытным экспертом в облачной местной области с глубокой страстью к улучшению опыта разработчика. У Арджуна хвастается более чем 25-летним опытом работы в отрасли, есть богатая история разработки программного обеспечения для интернет-масштаба и … Подробнее от Arjun Iyer
