Pantene742,
не совсем так.
Грубо, NodeJS == SPA, и только для этого нода и сделана (ну, исключая различные "сервисные" направления).
Erlang - это достаточно узкоспециализированное направление, в основном работа с параллельными потоками, миллионы соединений. А остальное прикладное бытовое на нем ваять - очень сложно. Поэтому к нему и цепляют другие, более универсальные языки.
И уж никак ноду и эрланг нельзя сравнивать. Теплое и мягкое...
Любой материал надо начинать с оглавления - там все темы расписаны.
И оттуда же надо брать нужный материал, а не читать все подряд. Сейчас столько материала с такой большой скоростью дается прогрессом в IT - все прочитать просто физически невозможно успеть.
Любой проект все равно переделывать придется раз 5-6, а то и более.
Начинать с архитектуры, и, желательно, в картинках - очень многие вопросы встают на свои места сразу. Чем гибче будет архитектура - тем меньше переделывать придется.
А на чем делать - под каждую задачу - свой инструмент. Время монолитов в историческом понимании уже прошло.
Anton Mashletov,
Go - это нечто третье, продукт, который забрал много хорошего из тех же PHP/Python, но добавил ряд других недостатков, уже своих. А так - как альтернатива тоже неплохо.
Оптимус Пьян,
вот одно из направлений применения ноды. Действительно, удобнее.
Хотя, китайцы сделали Workerman - достаточно неплохой демон для ws можно сделать.
Old Odessa,
А ответ то прост - нет ничего универсального! Нет!
Сейчас в тренде - каждому инструменту - свое место.
Т.е. под каждую задачу выбирается свой, наиболее оптимальный, инструмент. И это также может быть и обсуждаемый NodeJS.
А в 2017 году выбор инструментов ну очень хороший, и он не ограничивается php, хотя его прокачали тоже достаточно неплохо.
И учить ноду или не учить - личное дело каждого, но иметь представление что это, как работает и где его можно использовать, я думаю необходимый минимум. IMHO.
mitaichik,
допустим, клиенту нужен обработанный результат запросов с трех сервисов по внутренней бизнес-логике, в первом варианте эти три запроса может сделать сам клиент и сам же клиент обработать результаты этих запросов для нужных ему действий, а в другом варианте клиент делает один запрос на прослойку middleware, а далее уже сам middleware делает эти три запроса на сервисы, получает результат, обрабатывает, преобразует в нужный клиенту формат и отдает уже готовый агрегированный результат клиенту. Прослойка middleware делает клиенты более независимыми и унифицирует формат обмена данными.
Да, вы верно говорите, можно через nginx проксировать запросы на сервисы.
Но в каком тогда месте агрегировать результаты запросов? Я не хочу вешать этот функционал на клиента, хотя это один из архитектурных вариантов.
Мне нужно чтобы клиент получал готовый результат в нужном ему формате, а всю работу по агрегации и обработке данных делал middleware. Таким образом избавляем разнотипных клиентов от написания для каждого из них своего собственного блока агрегации и обработки. Я хочу избавить клиента от лишней работы.
Да, читал про врата еще до написания этого вопроса. Приблизительно похоже что мне нужно. Но не совсем то.
Давайте еще раз попробую.
Мне нужно провести границу между middleware и сервисами, причем так, чтобы ее можно было реализовать одним и тем же способом и на монолите и на распределенной системе на разных машинах.
Например, через AMQP на RabbitMQ возможно это сделать: т.е. консьюмеры могут быть и на одной машине и на удаленных. Т.е. чтобы быстро попилить монолит на сервисы будет нужно лишь поменять настройки очередей (фактически поменять localhost на ip удаленной машины), а все остальные элементы в цепочке обработки запроса от клиента будут без изменения.
Но при работе на AMQP вырастает время исполнения запроса в целом за счет накладных расходов очередей и дополнительных HTTP соединений.
Отсюда и вопрос возник то основной - как лучше построить взаимодействие системы клиент-middleware-сервисы? А не просто вопрос как раскидать запросы с клиента...
Ну, если быть точным, то, конечно, вы правильно говорите, например, в части очередей: планируется использование rabbitmq, возможно kafka в дальнейшем.
если смотреть на мою картинку, то слой 2 и слой 3 могут быть на одной машине (без Docker, в монолите), а при переходе на распределенную структуру слои 2 и 3 разделяются по разным машинам. Вот я и хочу понять, как лучше сделать архитектурно этот желтый участок, чтобы сохранить остальные части без изменений (больших изменений)
Для связи клиентов и сервисов.
Сервисы ведь могут быть реализованы и в монолите посредством api.
А я не понимаю как эту связь с монолита перетащить в распределенную систему микросервисов (пока не будем трогать Docker, считаем, что все сервисы на разных машинах будут).
Можете вкратце написать всю цепочку прохождения запроса-ответа с клиента на сервис и обратно с указанием используемых протоколов и архитектурных блоков?
Например: клиент (запрос авторизации) -> протокол HTTP, данные(логин, пароль) -> ... -> ... сервис выдачи токена по запросу (токен) -> ... -> ... клиент получил токен(протокол HTTP)
Александр Кузнецов,
вот и мне непонятен :)
Попробуем так: можете вкратце написать всю цепочку прохождения запроса-ответа с клиента на сервис и обратно с указанием используемых протоколов и архитектурных блоков?
Например: клиент (запрос авторизации) -> протокол HTTP, данные(логин, пароль) -> ... -> ... сервис выдачи токена по запросу (токен) -> ... -> ... клиент получил токен(протокол HTTP)
Спасибо за развернутый ответ, но это немножечко не то.
Добавлю еще вводных данных: я хочу сначала сделать монолит (как, собственно, и рекомендуют все), протестировать его работу в продакшне в ограниченном масштабе, а затем безболезненно, с минимальными затратами разобрать его по сервисам. Клиенты и сервисы будут сразу делаться под микросервисы, а вот middleware нужно очень грамотно подумать как сделать.
Максим Тимофеев,
Я этот материал прочитал уже не раз, но все равно понимания четкого не возникло, поэтому и сюда пишу. Хотелось бы услышать сравнение вариантов исполнения (внутренних архитектур) с обоснованием. Почему так лучше, а не иначе. Про это нигде не пишут толком. Кусочная отрывочная информация везде.
Конкретизирую.
Клиентом может быть что угодно: вебсайт, десктопное или мобильное приложение. Транспорт, наверное HTTP, может что-то другое. Запросы идут на api шлюз (агрегатор), далее на сервисы.
С клиентами и сервисами понятно - как их делать вопросов нет - разные языки, стеки и т.д. Интересует именно часть шлюза-агрегатора, как он архитектурно устроен, это монолитное целое или шлюз отдельно, агрегатор отдельно, какой функционал его частей, как они взаимодействуют, etc.
В общем в этом месте затык и непонятки.
Почему рассматриваю микросервисы, а не монолит - архитектура должна быть независимой, динамичной и расширяемой.
Спасибо за оперативность!
С Vue недавно работаю, не все еще с ходу помню.
Напомните, пожалуйста - если роутер находит декларированный ранее именованный путь, то * не будет срабатывать? Так?
Evgeny Kulakov:
Компонент универсальный для разных типов параметров с четкими входными и выходными данными, поэтому раздробить, конечно, можно, но потеряется универсальность. Зато теперь можно вставить куда угодно и только данные менять - и всё! Ну, и, документирование, документирование и еще раз документирование - всего и вся ;)
не совсем так.
Грубо, NodeJS == SPA, и только для этого нода и сделана (ну, исключая различные "сервисные" направления).
Erlang - это достаточно узкоспециализированное направление, в основном работа с параллельными потоками, миллионы соединений. А остальное прикладное бытовое на нем ваять - очень сложно. Поэтому к нему и цепляют другие, более универсальные языки.
И уж никак ноду и эрланг нельзя сравнивать. Теплое и мягкое...