Мы устранили ошибку 429 с помощью шлюза Kubernetes и сэкономили на 30% стоимость сервера.

В прошлом месяце наша команда чуть не рухнула:13% запросов пользователей на решение адресов были отклонены 429После полдневного проверки было обнаружено, что правила ограничения потока, выделенные ранее отдельно каждому микросервису, слишком мертвы, трафик модуля логистического запроса увеличился в три раза, и другие свободные ресурсы просто не могут быть использованы.

Мы всегда думали, что Kubernetes-шлюз - сложный компонент, используемый только крупными компаниями, и мы были вынуждены выйти на строй менее чем за неделю, и это было намного лучше, чем мы ожидали.

Что такое шлюз Kubernetes?

Проще говоря, это единый вход трафика для всего вашего кластера Kubernetes, где все внешние запросы поступают, а затем перенаправляются на соответствующий сервис backend, и мы используем один экземпляр с открытым исходным кодом, который может выдерживать 12 000 запросов в секунду, поэтому небольшим командам не приходится бороться с узкими местами производительности.

Три преимущества, которые мы получаем.

Первое наиболее интуитивно понятно: правила ограничения потока, наконец, не устанавливаются отдельно для каждого сервиса.Раньше мы хотели изменить порог ограничения потока семи или восьми микросервисов, чтобы изменить одну проблему, теперь мы делаем динамическое ограничение потока непосредственно на уровне шлюза, свободные ресурсы сервера могут автоматически наклоняться к модулям с высоким трафиком, в это Рождество наши 429 сообщения об ошибке прямо снизились до 0.

Второе - это затраты на провинции.Ранее мы выделяли по два дополнительных сервера для каждого из трех основных сервисов, чтобы выдержать пиковую нагрузку, и в большинстве случаев использование ресурсов составляло 20%, а теперь шлюзы могут автоматически балансировать нагрузку, и мы увеличили емкость на шесть серверов, что привело к снижению стоимости облака на 30%.

Третье - это не требует повторного повторения этой общей логики между доменами и аутентификацией.Раньше каждый новый сервис был запущен в сети, и коды проверки JWT должны были быть написаны на задней части, а теперь это делается непосредственно на уровне шлюза, и у нас есть 3 человека на задней части, которые могут работать по меньшей мере полдня в неделю на написании бизнес-кода.

Не слушайте только хорошего, мы прочно ступаем на эти две ямы.

Первая яма - это настройка временного истечения по умолчанию для слишком ямы.В первый день мы обнаружили, что 5% запросов на решение адресов истекли, проверили полдня, чтобы обнаружить, что время истечения по умолчанию шлюза составляет 30 секунд, но сама наша служба решения адресов будет работать максимум 40 секунд, изменив правила сразу же возобновится, перед запуском обязательно проверьте порог времени истечения для своего бизнес-интерфейса.

Вторая яма заключается в том, чтобы не кладить все функции с самого начала.Сначала мы хотели включить все функции журналов, ограничения потока, WAF, публикации оттенков серого сразу, в результате неправильной конфигурации, что привело к тому, что весь вход в кластер был прерван на 20 минут, позже мы сначала только открыли маршрутизацию и ограничение потока, работали 3 дня, стабилизировались, а затем медленно добавляли другие функции, больше не было проблем.

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

Применимость:

• У вас уже более пяти микросервисов, и каждый раз, когда вы меняете общую конфигурацию, вы меняете несколько мест назад.
• Часто встречаются пиковые трафики, а ресурсы не могут быть гибко распределены между различными службами
• Команда поддержки менее пяти человек не хочет тратить время на повторение общей логики.

Не переживайте ситуацию:

• У вас есть 2 микросервиса, трафик стабильный в течение года, сейчас пересылка с NGINX не имеет никаких проблем.
• Никто в команде не знает основы Kubernetes, не надо стремиться к новым технологиям.

2 советы для маленьких людей, которые впервые начинают работать.

Не нужно запутывать выбор модели, небольшая команда напрямую использует APISIX или Kong с открытым исходным кодом, комплектная документация полная, в случае возникновения проблем, есть основное решение, не нужно покупать коммерческую версию, функции бесплатной версии вполне достаточны.

Прежде чем выйти на сеть, сначала вырезайте 10% трафика в течение 24 часов, сосредоточитесь на том, нет ли времени истечения, запрос был ошибочно перехвачен, нет проблем и полностью вырезайте, не приходите и направляйте весь трафик.

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