Здравствуйте, Sharov, Вы писали:
S>>>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь? F>>если используется какой-нить распределённый конфиг, то днс можно и не использовать, имена будут в конфиге. S>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
"распределённый конфиг" — это что-то типа NoSQL-бд.
к нему все цепляются, читают содержимое, подписываются на изменения полей.
там нет понятия "распространение".
Здравствуйте, neFormal, Вы писали:
S>>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
F>"распределённый конфиг" — это что-то типа NoSQL-бд. F>к нему все цепляются, читают содержимое, подписываются на изменения полей. F>там нет понятия "распространение".
Вообще-то есть, иначе это не распределенный конфиг. Т.е. изменения могут дойти не сразу. Отсюда, видимо, все эти service discovery и т.д.
Здравствуйте, Sharov, Вы писали:
S>>>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах. F>>"распределённый конфиг" — это что-то типа NoSQL-бд. F>>к нему все цепляются, читают содержимое, подписываются на изменения полей. F>>там нет понятия "распространение". S>Вообще-то есть, иначе это не распределенный конфиг. Т.е. изменения могут дойти не сразу.
если ты записал что-то в БД, её изменения сразу станут доступны клиентам? сразу. вот и тут то же самое.
S>Отсюда, видимо, все эти service discovery и т.д.
сервис дискавери — это про другое. это про "более позднее связывание".
S>С этим понятно, а вообще общение между сервисами в подобной архитектуре идет ведь через dns? Т.е. без dns highload архитектуру не построишь?
Эмм. Вы смешиваете три несвязанные вещи.
1. Микросервисы
2. Highload
3. DNS
Что может мне помешать поставить взрослый load-balancer с фиксированным IP-адресом и раскидывать запросы по стоящим за ним серверам? Вот есть, к примеру, очень популярный сервис с общеизвестным адресом 8.8.8.8 — чем вам не highload? При этом никаких микросервисов там нет, и никакого round-robin тоже нету.
Никто не может мне помешать делать "внешний" load-balancing путём возврата 302 на входящие запросы, раскидывая клиентов по настоящим адресам сервис-нодов.
И это мы ещё даже не начали копать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали:
S>Ну это явно неудобно. И как его распространять? Т.е. для небольших решений, до 2-х десятков сервисов, еще куда ни шло, иначе швах.
Неудобно != невозможно. Существуют вполне себе готовые архитектуры, которые именно так и работают.
Вы же понимаете, что DNS — это не чудо господне, а всего лишь распределённая иерархическая СУБД? Причём у неё единожды и навсегда зафиксированная архитектура.
Поэтому если вас не устраивает тот механизм распространения, который применяется в DNS, то нет ничего сверхъестественного в использовании своей собственной архитектуры по распространению изменений.
И опять-таки: DNS не является ни единственным, ни самым лучшим механизмом балансирования нагрузки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Никто не может мне помешать делать "внешний" load-balancing путём возврата 302 на входящие запросы, раскидывая клиентов по настоящим адресам сервис-нодов. S>И это мы ещё даже не начали копать.
А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do?
Здравствуйте, Sharov, Вы писали:
S>А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do?
Не очень понятно, что вы имеете в виду. У запроса жизненный цикл простой — он начался и закончился. Это никак не зависит от архитектуры
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>А внутри сервисы как между собой общаются, через что, если убрать статичный конфиг\базу? Т.е. какой жизненный цикл запроса http://account/service/api/do? S>Не очень понятно, что вы имеете в виду. У запроса жизненный цикл простой — он начался и закончился. Это никак не зависит от архитектуры
Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А.
Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B.
И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
Здравствуйте, Sharov, Вы писали:
НС>>Ты тоже путаешь микросервисы с кластером. Микросервисы это про код, а не про инстансы. S>Микросеривсы -- это идея, подход. Кластеры -- одна из возможных реализаций.
Еще раз нет. Открой статью в википедии и вдумчиво почитай, что обепринято понимать под микросервисами. Кластеризация однотипных инстансов это точно не оно.
Здравствуйте, scf, Вы писали:
НС>>Services form information barriers scf>Вообще-то это считается преимуществом
Кем считается?
НС>>Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process scf>Да, но эти затраты невелики
Голословно.
scf> и чувствительны исключительно для синхронного кода, когда запросы идут по очереди, а не параллельно.
Фигня.
НС>>Ну и ссылочку еще добавлю. Оно всегда вылазит, когда мы от хипста-демок переходим к реальным энтерпрайз системам. scf>я бы сказал, что в реальных системах consistency нужно для небольшого подмножества данных, которое и следует хранить в одной базе с транзакциями.
Вот только жизнь типичного реального сервиса вокруг этих данных в основном и сосредоточена. А обвешивание по периметру микросервисами второго плана как правило особой ценности не несет.
Здравствуйте, mrTwister, Вы писали:
НС>>Не делай. Конкуренты сделают это за тебя. T>... НС>>А потому микросервисы на помоечку. T>Дак я не понял: на помоечку, или конкуренты их сделают за меня?
Здравствуйте, Sharov, Вы писали:
S>>> Я так понимаю, что в основе всех S>>>высоконагруженных сервисов и тем более микросервисов находится dns. Т.е. мне возвращается куча адресов необходимого сервиса, после чего по определенному алгоритму я выбираю один из. Так?
vsb>>Это самый простой вариант. Не обязательно так. Я видел, когда люди в БД хранили адреса, например. Опять же желательно мерять нагрузку и отдавать наименее загруженный сервер. Если между запросами состояние, желательно одного клиента посылать на один и тот же сервер. Вообще по-моему обычно впереди стоит лоад балансёр, который по определенному алгоритму перенаправляет запросы на один из серверов за ним. А для юзера этого сервиса это выглядит как один сервер.
S>Речь идет именно о возможности использовать доменные имена. Т.е. я у себя в сервисе прописываю account.mysite.com и все. Далее, когда мне будет нужен соотв. функционал, я делаю запрос по http://account.mysite.com/api1 и S>инфраструктура мне вернет какой-нибудь инстанс. Доменные имена использовать проще, нежели ip, кмк.
Над DNS обычно мало контроля. Протокол старинный, мало кто готов написать DNS-сервер со своей логикой. С точки зрения клиента ещё хуже, общеупотребительные библиотеки кешируют ответы, если есть промежуточный сервер, он тоже может закешировать и тд. Это удобно, когда нужно абсолютный минимум от масштабирования. Но если тебе надо направлять на нужный сервер в зависимости от значения HTTP Cookie, то, конечно, тут уже DNS не подойдёт.
S>Из того, что я на эту тему читал, loadbalancer и есть dns сервер, ну или dns следующий в цепочке обработчиков запроса.
Load Balancer это концепция, некая сущность, которая распределяет нагрузку. DNS это один из вариантов. Другой вариант это reverse proxy, это сервер, который принимает HTTP-соединения (ну в общем случае не HTTP, но щас всё HTTP), возможно делает какие-то манипуляции с ними и пробрасывает уже тому серверу, который его будет обрабатывать. Т.е. по сути вся работа тут передавать байты от клиента к одному из рабочих серверов и назад.
Здравствуйте, scf, Вы писали:
scf>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.
Здравствуйте, Sharov, Вы писали:
S>А правильно ли я понимаю, вызывая, например, account-api.mysite.com мне dns вернет адрес(а)всех хостов, реализущих данный сервис?
Нет. Он вернет какой то один. Называется round robin dns. Я ссылку выше давал, сходи и почитай.
S> Я так понимаю, что в основе всех S>высоконагруженных сервисов и тем более микросервисов находится dns.
Нет. Это самый примитивный и старый способ. В современных сервисах как правило используется reverse proxy с набором правил и health check.
Здравствуйте, Sharov, Вы писали:
S>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А. S>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B. S>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
У каждого сервиса собственный LB, для остальных сервисов он выглядит монолитом. В чем проблема?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, scf, Вы писали:
scf>>Не совсем понятен вопрос. если n экземпляров микросервиса и одна БД, то проблема согласованности перекладывается на БД.
НС>Это и есть обещанная изоляция по данным?
конкретные претензии есть, или опять "голословно" "фигня" и поиск каких-то авторитетов, как будто своих мозгов нет?
НС>У каждого сервиса собственный LB, для остальных сервисов он выглядит монолитом. В чем проблема?
Ясно, благодарю. Мне казалось, что уж тут-то dns должен быть во всю, ибо взаимодействие идет на уровне http запросов. Видимо его функционала для
действительно нагруженных случаев мало, отсюда рост использования RP и проч. инструментов.
Здравствуйте, Sharov, Вы писали:
S>Итак, имеется backend высоконагруженного сервиса. Т.е. у меня сотни сервисов типа А, типа B,С,D и т.д. Пришел запрос от пользователя сервису А. S>Для работы сервиса А необходимы сервисы типа B,C,D. Сервис А отрпавляет запрос http://account/service/api/do сервису B. S>И вот у меня вопрос -- как при такой архитектуре, типовой для HL -- отработает сервис А, если ему нужны B,C,D коих инстансов каждого в системе под сотню?
— сервис A делает запрос на какой-то адрес, там его встречает балансер инстансов сервиса B
— балансер смотрит на какие-нить признаки и выбирает инстанс-обработчик, прокидывает ему запрос
— инстанс получает запрос, выполняет действия, возвращает ответ
— сервис A получает свой ответ
