(java || kotlin) && devOps
368 subscribers
6 photos
1 video
6 files
306 links
Полезное про Java и Kotlin - фреймворки, паттерны, тесты, тонкости JVM. Немного архитектуры. И DevOps, куда без него
Download Telegram
Всем привет!

Продолжая тему в DNS - какие у этой технологии минусы при использовании как Service Discovery. Я рассматриваю общий случай, а не случай, когда DNS внутри облака.

1) скорость ответа. Во-первых для сайтов требования по времени отклика в общем случае слабее, чем для вызовов API. На одну страницу сайта может быть десятки вызовов API. Во-вторых регистраторов доменов и провайдеров в мире очень много, поэтому много DNS серверов, они находятся в разных сетях, доступность между сетями сильно отличается, DNS сервера выстраиваются в цепочки - т.об. в целом объяснимо, почему время отклика может быть достаточно большим.

2) решается проблема времени отклика в DNS кэшированием. В первую очередь на ближайших к пользователю DNS серверах - т.е провайдерских. Но это тоже может быть проблемой. Все, у кого есть свой домен и кто обновлял у него хостинг - могут подтвердить)

3) механизмы балансировки в DNS не сильно развиты. Да, DNS может балансировать нагрузку на несколько IP адресов, может даже в гео-балансировку, но все равно по возможностям сильно уступает тому же nginx с плагинами. Т.к. nginx может получить больше информации о клиенте, прочитав заголовки запроса, включая куки.

4) в DNS нет концепции порта. Исторически для http стандартный порт 80, https - 443, для других протоколов тоже есть стандартные порты. Если не хочешь стандартный - указывай его явно в URL, это не проблема DNS) В облаке типичны кейсы, когда на одном хосте несколько сервисов на разных портах, и хардкодить порт плохо.

И если первая проблема может быть решена путем контроля всей цепочки DNS серверов в облаке, то остальные - нет, т.к. это особенности протокола.

#dns