NS
да я не правильно выразился, я имел ввиду что метрики это события от юзеров в вебе
Size: a a a
2020 May 06
S
А кто-нибудь пользовался StatsD для метрик?
S
Раз уж пошла такая карусель
NS
да я не правильно выразился, я имел ввиду что метрики это события от юзеров в вебе
ещё раз себя поправлю, метрики строяться на основе эвентов юзеров в вебе
MZ
цель заложить маштабирование в архитектуру
Если цель именно в масштабировании сервиса, то весь потенциал конечно раскроет kubernetes.
Если есть желание его покорить, можно начать с облачного k8s(GCE, AWS, DigitalOcean) в 3+ инстанса за 15-20 баксов в месяц и по свободной информации в инете развернуть минимальный минимальный тестовый стенд текущего сервиса.
Если есть желание его покорить, можно начать с облачного k8s(GCE, AWS, DigitalOcean) в 3+ инстанса за 15-20 баксов в месяц и по свободной информации в инете развернуть минимальный минимальный тестовый стенд текущего сервиса.
MZ
А дальше и опыт начнет капать и больше понимания будет как оно все запускается, живет и поддерживается.
NS
да план примерно такой, но для того что бы развернуть все это в кубике, нужно сервисы друг от друга "оторвать"
MZ
Можно еще конечно попробовать Docker Swarm через docker-compose. Но по мне так время будет потрачено в пустую. А после постижения k8s устройство и работа swarm и так будет понятна.
NS
swarm не рассматриваю, пока, он насколько я понял не развиваеться а только поддерживаеться
NS
да и кубик вроде как стандарт "де факто"
MZ
да план примерно такой, но для того что бы развернуть все это в кубике, нужно сервисы друг от друга "оторвать"
Разорвать в твоем случае это начать обращаться из сервиса в редис не просто по порту 6379 на localhost, а по порту и IP контейнера. Только в k8s это будет уже dns-имя сервиса натравленного label пода с контейнеров redis.
MZ
да и кубик вроде как стандарт "де факто"
Не то что бы стандарт. Он просто молодец и справляется со всеми правильно поставленными ему задачами.
NS
да я примерно так же думал, в моем случаи оторвать это убрать жесткую зависиместь между компонентами системы
S
swarm не рассматриваю, пока, он насколько я понял не развиваеться а только поддерживаеться
Развиваться сворм перестал год назад
S
Даже ишью неохотно закрывают
MZ
У тебя зависимости между компонентами останутся как и были. У тебя уйдет зависимость от конкретного хоста.
NS
конечно она останеться эти компоненты не имеют смысла по отдельности
MZ
Ты можешь и сейчас один из 10 сервисов запустить в бриджовой сети и указать адрес редиса не как 127.0.0.1:6379, а IP машины(192.168.1.10) и порт 6379
NS
если описать docker network и жеско ему задать gateway то можно будет обращаться по ип gateway для доступа к хост машину, я так понял из документации, ещё не пробовал)