Как сделать service discovery для клиентских приложений?
Иду по пути микросервисного подхода во фронденде. Уже есть наработки, каждый сервис в которых предоставляет fullstack части, то есть предоставляет свою клиентскую часть (отдельные процессы, которые слушают свои порты)
Взаимодействуют клиентские части через postMessage и находятся в iframe'ах (таким образом не нужно городить что-то вроде Web Components и при разработке hot reload работает из коробки).
Запускается это через docker compose, и в случае одной машины все находится просто на разных портах. Для внедрения вьюшек микросервисов на клиентской стороне необходимо знать, где находится определенный сервис.
Неудобства в том, что нужно вручную прописывать порты и в каждом сервисе указывать хост и порт, по которому нужно обращаться к другому сервису. Есть ли какие-то способы, близкие к Auto-discovery подобно CoteJS, чтобы такие вещи решались автоматически, а при обращении к сервису достаточно было указать его идентификатор?
В природу микросервисов входит останавливаться и запускаться динамически.
Вам по сути нужны все те же инструменты, что и для service discovery на backend.
И проверять для каждого запроса куда слать (или предпринимать попытку слать на другой в случае облома с текущим).
На данный момент нашел для себя более удобный и просто вариант:
Docker Swarm + Traefik.
В существующих docker-compose.yml всего-навсего пришлось изменить build на image, прописать команды для предварительного сбора образов и добавить метки для traefik.
Через Swarm могу развернуть масштабиремые контейнеры на нескольких машинах, на которые (в нужный микросервис) будет перенаправлять Traefik согласно поддомену (метка traefik.frontend.rule=Host:...)
Виталий Столяров, вы обязаны задавать конфигурацию вашей инфраструктуры - это никто за вас не сделает. Когда сервис запускается он должен посылать heartbeat на Service Discovery "я такой-то app, запущен тут и я жив"
Только так это и происходит. А в консуле и задаёте то какие у вас приложения должны запускаться
Виталий Столяров, сервис сам должен сказать на каком порту он поднялся. IP вычисляется уже SD. И после этого SD знает все инстансы, поднятые для каждого сервиса. Как-то так общая схема выглядит. Дальше уже ваше дело как архитектора придумать чтобы на одном порту не запустились больше одного инстанса
Иван Шумов, выше вопрос в поиске инструменты, который решает это сам. Собственно, на бэке Cote.js хорошо с этим справляется, для клиентской стороны не находил подобного
Виталий Столяров, ни один service Discovery не должен знать о вашей архитектуре. Тут даже облака бессильны. Даже в Амазоне самое лучшее что вы можете сделать - связку Route53 (dns) + CloudFront (CDN) + Elastic Load Balancer (балансировщик) + ec2 autoscaling group (автоматическое горизонтальное масштабирование) + ec2 (сами инстансы). Но даже тут вам придется конфигурировать сеть
Виталий Столяров, по тому что есть несколько слоев, в частности группировка инстансов по сервисам и безопасность (вы же не хотите из ниоткуда левый инстанс)
немного опробовал его, и не нашел service discovery, так как вручную нужно после запуска каждого сервиса прописывать его в конфиге
Что то вы не то пробовали.
Service Discovery у Consul из коробки и автоматом.
От вас требуется только регистрация вашего софта в Консуле при запуске.
Если вам в ломы переписать свой софт так, чтобы Консул о вашем приложении узнал, то можете попытаться использовать Registrator вместе с Consul. Но я бы подправил пару строчек в коде.
yayashitoya, вот и я удивился изначально. Даже при том что сам не работал - у Hashicorp прекрасные продукты и если они говорят что у них есть SD - значит у них образцовый SD
yayashitoya, то есть сам бэк должен говорить Consul, что инстанс такого-то сервиса был поднят? Фактически, consul является единой точкой входа. Упадет он, упадет все.
Но пока вопрос стоит в том, чтобы распределять сервисы по поддоменам. Сейчас через nginx проксирую запросы с поддоменов на конкретные порты.
Скорее, Consul это не совсем то, что мне нужно. Хотелось бы автоматизировать именно процесс выбора порта в Docker Compose и автоматически расшаривать их. Так, чтобы не влезать в исходный код, который должен отвечать только за бизнес задачи, и меньше выполнять рутиных действий
сейчас не совсем ясно преимущество Consul перед Swarm. Работали ли вы с Docker swarm ?
Swarm - это система целая. "Все в одном". И Service Discovery там всего лишь одна из функций.
Consul - отдельная узкоспециализированная программа. Consul vs. Other Software
Которая умеет Service Discovery и умеет храненить конфигурационную информации произвольного вида - все это в кластере, создаваемом несколькими экземплярами Consul (по уму нужно на каждой ноде/сервере свой отдельный Консул, который будет "дружить" со всеми своими коллегами в кластере).
Прелесть Консула, что вы можете задать вопрос любому экземпляру Консула в кластере.
Они все работают с одной и той же информацией и как-то там сами синхронизируются и как-то там сами решают между собой вопросы о выпадении ноды/сервера из кластера или добавлении ноды/сервера в кластер (эти вещи - перестройку количества машин в кластере - Консул реализует даже получше, чем расхваливаемый Kubernetes).
Жесткий split brain, полагаю, все равно будет проблемой как и у всех прочих. Но если это органическая проблема (множество датацентров), то можно попробовать еще и сконфигурировать Консул с поддержкой федераций для минимизации подобной ситуации.
P.S.:
Поддержка Docker Swarm уже постольку-поскольку. Разработчики бросили свои силы на интеграцию с Kubernetes. Я бы не стал закладываться в серьезном проекте на Docker Swarm.
Незавидная судьба Docker'а была приближена ростом Kubernetes. Docker не сделал никаких подвижек в сторону поддержки Kubernetes, облюбованного сообществом свободного ПО инструмента контейнерной оркестрации. Всё внимание компании было отдано конкурирующему продукту — Docker Swarm. Это решение было принято несмотря на то, что Kubernetes как раз ставил во главу угла контейнеры именно на основе Docker. Кстати сказать, Docker Captains в начале года подтвердили, что обсуждения Kubernetes в статьях, на митапах и конференциях компанией не одобрялись.
И на dockercon17 повторялась эта анти-Kubernetes мантра. А потом, внезапно, на dockercon EU 17 Docker решили поставить всё на Kubernetes. Внезапная перемена настроения, очевидно была связана с уверенным ростом господства Kubernetes. И ситуация эта подкрепилась ещё тем, что Docker стал спонсором и участником на KubeCon + CloudNativeCon North America 2017
yayashitoya, почему же? На одном проекте у нас все в AWS ECS, там конечно без него. Конфигурирую сейчас проект для себя, и флоу с деплоем вместе с Compose выглядит менее удручающим, чем каждый сервис отдельно (сервис - контейнер, а так в каждом микросервисе свои контейнеры - фронт, бэк и т.д.)
Во многих источниках на первом месте по популярности стоит Docker. В общем много противоречий.
Вы используете только Consul? Есть ли где-то примеры минимально сконфигурированных микросервисов ?
почему же? На одном проекте у нас все в AWS ECS, там конечно без него. Конфигурирую сейчас проект для себя, и флоу с деплоем вместе с Compose выглядит менее удручающим, чем каждый сервис отдельно (сервис - контейнер, а так в каждом микросервисе свои контейнеры - фронт, бэк и т.д.)
Во многих источниках на первом месте по популярности стоит Docker. В общем много противоречий.
Сам-то Docker - не проблема в production.
а Docker-Compose не предназначен для этого, только для отладки
Для production - это Docker Swarm, Kubernetes c Docker, Mesos, Nomad c Docker или без Docker и т.п.
Но для фронтенда полноценная оркестрация не нужна. Выполняется же код не на серверах. И Docker фронтенду не нужен.
Код на серверной части выполняется разве что для развертывания фронтенда и его тестирования (gulp, grunt, webpack, rollup или что там у вас). Реализовывать ли выполнение этого кода в кластере или нет - можно по разному решить. И да, возможно, в этом случае на серверной стороне будет нужен Docker.
у вас, случаем, на фронтенде не только ли статика?
Вы наверное промахнулись автором?
Виталий Столяров,
Кстати, да.
Статика там на фронтенде или не статика - но зачем там вообще какой-то кластер?
С точки зрения клиента - веб-фронтенд - это всего лишь файлы.
Требуется организовать надежную отдачу файлов CSS/JS/прочих в браузер? Это CDN решается.
Или вы фронтендом называете что-то другое?
yayashitoya, на клиенте только статика. Но она тесно связано с бэков в том плане, что каждый сервис предоставляет клиенту свою статику.
Коцепция в том, что пока работает сервис, пока пользователю и будет предоставляться статика. Какой смысл в клиентской части, когда бэк упал? И как деплоить вместе клиент и бэк, чтобы арантировать их конистентность?
Вопрос по другому: есть ли у Вас примеры масштабруемых сервисов с auto discovery или хотя бы best practice?
А пока настройка конфигураций и деплоя занимает уйму времени
Виталий Столяров, Если у вас на клиенте только статика то это SPA, а это значит что:
1. Для этого идеально подходит связка AWS S3 + CloudFront
2. Фронт (внимание) ОБЯЗАН иметь обработку бэкэнда на предмет доступности API и предоставлять пользователю качественный UX.
Вот и все - вы действительно не с той стороны к вопросу подошли
Иван Шумов, какие есть инструменты для удобного деплоя статики совместно с сервисом, чтобы гарантировать их совместимость (чтобы нельзя было по ошибке задеплоить бэк и оставить фронт неактуальным) и отказоустойчивость (упадет один фронт, значит все плевали на то, что бэк в кластере) ? Даже как дела обстоят с проксированием запросов с клиента на бэк?
Виталий Столяров, AWS S3 масштабируется бесконечно и не может упасть. у него SLA по доступности 99.99 и eleven nines of durability. Добавьте к этому CDN и вы получаете систему, которая вообще никогда не умрет
Виталий Столяров, это не тот инструмент, который можно взять и за 5 минут написать конфигурацию по памяти) стоит обратиться к документации. Если вы ищете "готовое и и з коробки" то стоит распрощаться с розовыми очками
Виталий Столяров, все там хорошо) только не путайте DevOps и ci/cd, ведь это всего лишь одна часть. Да и оптимизировать кастомную инфраструктуру роботы не могут. Если бы могли то архитекторы и девопсы столько не получали - тут надо иметь не только знания, но и желание этим заниматься
ну хз, есть несколько статей "Docker Compose in production".
Ну мало ли кто эти статьи писал.
Сейчас и джуны зачастую бумагомарательством занимаются.
Можно. Но не рассчитан он на нагрузки и плохо тестировал для того, чтобы в production запускать.
как-то ненадежно, когда конфигурация ддля дева и прода сильно отличается
В этом есть свой резон.
Тогда подымайте для отладки полноценную среду production.
Какой-нибудь Kubernetes.
Для отладки на машине разработчика - есть специальные быстроустанавливаемые дистрибутивы, типа mini-kube. Будет вам совместимость с большим Kubernetes тем, что в production.
Коцепция в том, что пока работает сервис, пока пользователю и будет предоставляться статика. Какой смысл в клиентской части, когда бэк упал? И как деплоить вместе клиент и бэк, чтобы арантировать их конистентность?
Это отдельная задача. Называется "управление версиями конфигураций".
Штука настолько разнообразная, что тот же автор Consul и Nomad, фирма Hashicorp, на этом делает отдельный бизнес - называется Atlas.
Helm к Kubernetes, к примеру, отслеживает зависимости сервисов.
Но проще, да, деплоить как единое целое.
А пока настройка конфигураций и деплоя занимает уйму времени
Почему?
Возьмите готовые инструменты для всего Kubernetes + Helm.
Или возьмите специализированные инструменты для deployment и service discovery - Nomad и Consul.
ладно, есть примеры микросервисов на Terraform? Простые примеры, без лишних overhead
Terraform - это для инфраструктуры (добавить дисков, добавить нод) - микросервисы тут постольку поскольку.
Это разве что помощь для автомасштабирования по железу.
yayashitoya, то есть Swarm вы не рассматриваете как более простую алтернатику Kubernetes ?
Наверное, в этом есть смысл, так как в последнее версии я столкнулся оказывается с багом https://github.com/docker/machine/issues/4608
Не похоже на совпадение, вероятно такое у них часто происходит
Вы вполне можете и монолит запускать в нескольких экземплярах.
Поддерживать разрастающийся монолит - боль. Чем дальше, тем больнее
Микросервисы - слишком много накладных расходов на разработку и поддержку для одного.
понятное дело, что чем-то приходится жертвовать. Но все же важна слабая связность и возможность взаимодействия и развертывания разных окружений, чтобы работая над одним не сломать другое
Но все же важна слабая связность и возможность взаимодействия и развертывания разных окружений, чтобы работая над одним не сломать другое
Это всего лишь вопрос правильной архитектуры и самодисциплины.
В монолите у вас есть возможность залезть напрямую, нарушить принципы слабой связанности.
В микросервисах такой возможности нет физически.
Стоит ли огород городить или может самодисциплины достаточно?
С микросервисами, кроме накладных расходов, у вас будет еще и архитектурные проблемы с обратным знаком - если вдруг не так разобъете, то придется JOIN-ить микросервисы - вот это будет боль по производительности.
yayashitoya, вы на практике пробовали SOLID ? И сранивали ресурсозатратность при соблюдении SOLID и жестком разграничении ответственности по сервисам?
В микросервисах такой возможности нет физически.
И я о том же.
Стоит ли огород городить или может самодисциплины достаточно?
Нет, не достаточно. Часто бывают моменты, когда хочется сделать быстрее, иначе приходится тратить много времени на то, чтобы при добавлении каждой фичи вспоминать "а есть ли уже что-то похожее, чтобы все было по DRY" или "че там у нас по каждому принципу SOLID".
Вот честно, не ощущаю кардинального улучшения соблюдая слабую связность в одной кодовой базе, когда даже при модификации одной фичи приходится видеть массивное дерево проекта
вы на практике пробовали SOLID ? И сранивали ресурсозатратность при соблюдении SOLID и жестком разграничении ответственности по сервисам?
Зачем?
Любому программисту, знающему как там внутри устроено очевидно, что один вызов локальной функции (даже пусть и с использованием VMT) будет на порядки быстрее, чем вызов той же самой функции + работа с сетью + кодировка/расходировка + второй вызов (на стороне клиента и сервера соответственно).
Плюс ошибки сети + service discovery + установка нового соединения если сервис упал.
Виталий Столяров, вот тот случай когда в начале мы с вами разошлись во мнениях, а сейчас я вас поддержу. Микросервисная архитектура это очень хорошо, надо только в обязательном порядке построить хорошую интергацию, delivery и не забыть что начинать надо с проектирования и документации. А то потом можно вечность искать уже запущеный полезный микросервис и думать как он работает. Сам перевожу пока ещё небольшой проект на это и планирую таким образом запустить ещё несколько крупных
я имею в виду человеческие ресурсы. По моему, все движется к тому, что легче докупить железа, чем нанять/доучить разработчика
микросервисы - не упрощение работы по большому счету.
но да - это возможность каждому недостаточно квалифицированному разработчику предоставить возможность ковыряться со своим говнокодом.
такой плюс у микросервисов есть - они допускают существенное раздутие штатов разработчиков, и никто не мешает особо друг другу, ага.
