Комментарии 30
Service Fabric вам в помощь
Вам сюда: toster.ru
Спасибо. Чтобы мне задать правильный вопрос, вначале нужно объяснить, что я делаю и что хочу получить, а это, как видите, заняло много места и хватило на целую статью. Когда я пытался сделать именно так, у меня были трудности с поиском информации, ведь существует несколько способов настроить распределенную систему, и очень много запросов приводят к wcf по http(s) (в различных вариациях). Еще были варианты настройки через сокеты. Но это всё не то, что мне было нужно. И, так как я долго возился с этим вопросом, надеюсь, что моя статья пригодится людям, которые ищут именно такой способ. А отдельно вопросы, без этой статьи, мне не дадут никаких ответов
За WCF-чаты нужно по рукам бить
Что не так с чатом? Можно и под чат выделить сервер. У меня нет задержки на отклики из-за того, что нет сериализации/десериализации и вызовы происходят по локальной сети, очень быстрому каналу передачи. Это я как пример и возможность: таким способом я выношу затратные функции обсчета поединка в браузерной игре и обсчета подземелий. Но и для чата не вижу проблем и неудобств, поясните? Очень хочу сделать всё красиво и изящно, вынося чат на отдельный сервер я уменьшаю нагрузку с основного, подскажите как это можно сделать более правильно?
У меня нет задержки на отклики из-за того, что нет сериализации/десериализации
Правда нет? А как у вас данные по локальной сети передаются, чудом?
Ну это само собой. Но этот вариант — самое быстрое, что я могу предложить. Я правда хочу понять и разобраться как сделать правильно. Вы говорите мне: «так делать нельзя». Я не отрицаю, но этого мало. Подскажите, как можно сделать? Естественно, если я делаю распределенные функции у меня появятся задержки на передачу. Но так я разгружаю основной сервер, что при большой нагрузке может дать и отклик быстрее.
Но этот вариант — самое быстрое, что я могу предложить.
А вам так важна эта скорость? Если да, то уверены ли вы, что сам WCF (который, в общем-то, весьма тяжелый) не дает вам избыточного оверхеда?
Все взаимодействие у вас синхронное. Сколько ресурсов вы бессмысленно теряете на блокировках?
Ну и вообще, кроме WCF есть много других технологий для распределенных систем.
Это я и пытаюсь выяснить. Я понимаю, что есть другие технологии для распределенных систем, но я о них не знаю.
В третий раз вы мне говорите, что так, как я делаю, делать не надо. Но не говорите как переделать? Я же не требую от вас готового решения для меня, но хоть что-то можете сказать? какой подход использовать? Какую технологию? Чем можно заменить мой подход?
Если вы действительно хотите мне помочь, то критика должна быть конструктивной, а вы просто говорите: «так делать не надо, есть много других технологий». Мне такие фразы никак не помогут и не приблизят ни на шаг к правильному решению.
В третий раз вы мне говорите, что так, как я делаю, делать не надо. Но не говорите как переделать? Я же не требую от вас готового решения для меня, но хоть что-то можете сказать? какой подход использовать? Какую технологию? Чем можно заменить мой подход?
Если вы действительно хотите мне помочь, то критика должна быть конструктивной, а вы просто говорите: «так делать не надо, есть много других технологий». Мне такие фразы никак не помогут и не приблизят ни на шаг к правильному решению.
Для начала я задал вам пару весьма конкретных вопросов. У вас уже есть на них ответы?
А вообще — берете WebAPI, Akka.net, ServiceStack, Thrift и сравниваете.
Уже какая-то конкретика, за это спасибо.
Дальше начала мы с вами и не продвинулись. На ваши «весьма конкретные вопросы» я ответил, но могу еще раз. Скорость — всегда важна. Я не говорил, что мой вариант самый быстрый, наоборот, хочу узнать как делать такие вещи правильно. Синхронные вызовы можно заменить на асинхронные. Тяжелый wcf — что в моих трёх строчках вы увидели тяжелого? Создание каналов через ChannelFactory?
Про передачу данных еще был вопрос, транспортные расходы всегда будут. Я знаю только два канала передачи данных — это http и tcp. Http — медленнее и решения, основанные на этом канале будут медленнее (предложенные WebAPI и ServiceStack).
Вообще, стандартные решения от майкрософт для сервисов — это WebAPI и wcf. С одной стороны вы говорите не использовать стандартные решения, с другой стороны самих их предлагаете, ладно.
Thift, как видно из описания, фреймворк для облегчения взаимодействия между кодом написанным на разных языках. По описанию мне не подходит. Он использует tcp канал, вопрос вам, сильна ли разница этой избыточной библиотеки и стандартного ChannelFactory?
Про Akka.net я почитаю, спасибо.
А еще вы пытаетесь язвить тем, что умнее, хотя я пришел за помощью и сразу сказал, что у меня немного опыта. Не очень приятно слушать вашу желчь.
Дальше начала мы с вами и не продвинулись. На ваши «весьма конкретные вопросы» я ответил, но могу еще раз. Скорость — всегда важна. Я не говорил, что мой вариант самый быстрый, наоборот, хочу узнать как делать такие вещи правильно. Синхронные вызовы можно заменить на асинхронные. Тяжелый wcf — что в моих трёх строчках вы увидели тяжелого? Создание каналов через ChannelFactory?
Про передачу данных еще был вопрос, транспортные расходы всегда будут. Я знаю только два канала передачи данных — это http и tcp. Http — медленнее и решения, основанные на этом канале будут медленнее (предложенные WebAPI и ServiceStack).
Вообще, стандартные решения от майкрософт для сервисов — это WebAPI и wcf. С одной стороны вы говорите не использовать стандартные решения, с другой стороны самих их предлагаете, ладно.
Thift, как видно из описания, фреймворк для облегчения взаимодействия между кодом написанным на разных языках. По описанию мне не подходит. Он использует tcp канал, вопрос вам, сильна ли разница этой избыточной библиотеки и стандартного ChannelFactory?
Про Akka.net я почитаю, спасибо.
А еще вы пытаетесь язвить тем, что умнее, хотя я пришел за помощью и сразу сказал, что у меня немного опыта. Не очень приятно слушать вашу желчь.
Тяжелый wcf — что в моих трёх строчках вы увидели тяжелого?
Сам WCF с его (часто избыточной) инфраструктурой.
Скорость — всегда важна.
Нет, в том-то и дело.
Http — медленнее и решения, основанные на этом канале будут медленнее
Вы делали конкретные измерения, которе могут это подтвердить?
С одной стороны вы говорите не использовать стандартные решения
Где я это говорю?
Thift, как видно из описания, фреймворк для облегчения взаимодействия между кодом написанным на разных языках. По описанию мне не подходит
Ничто не мешает использовать его между кодом, написанным на одном языке.
Он использует tcp канал, вопрос вам, сильна ли разница этой избыточной библиотеки и стандартного ChannelFactory?
Эээ… а как вы вообще сравниваете протокол (с имплементацией) с одним классом, решающим конкретную задачу?
Но вообще, между thrift и стандартными WCF-сериализаторами есть фундаментальная разница — там где WCF использует рефлексию (которая заведомо медленная), thrift использует кодогенерацию. Вот вам и разница в производительности.
Сергей, я не знаю, чем вам так насолил.
Тут я не использую избыточность от wcf, к ней я отношу контракты, автоматически генерируемые файлы и сериализацию/десереализацию в xml и подобные форматы. Быстрее можно сделать, написав взаимодействие серверов напрямую через сетевые сокеты, я не готов сейчас этим заниматься.
Скорость влияет на отклик системы, который важен для пользователя. Всегда важен.
Конкретные измерения http и tcp? При одной и той же реализации wcf можно установить способ передачи данных (NetTCPBinding, HttpBinding). От меня вы чего хотите, чтобы я вам цифры привел? посмотрите сами. Могу другими словами: при net.tcp идёт sender -> net.tcp -> receiver. По HTTP идёт так sender -> http -> tcp -> http -> receiver. Я не буду ставить тесты, моя реализация будет быстрее реализации через WebAPI. Вы чётко говорите не использовать моё (стандартное решение от Microsoft), а взамен предлагаете WebAPI (другое стандартное решение от Microsoft).
С вами обсуждение началось, потому что вы несколько раз сказали «у вас всё неправильно», я услышал предложение использовать три сторонних библиотеки, и обязательно их посмотрю. На это нужно время, а, возможно, будет проще и быстрее сделать взаимодействие серверов через сокеты.
На самом же деле, мой основной вопрос был как правильно создать в студии эту «неправильную» архитектуру" распределенного сервера для обычного хостинга, где есть возможность только арендовать vds, а не для азуры. Отлаживать и публиковать.
Тут я не использую избыточность от wcf, к ней я отношу контракты, автоматически генерируемые файлы и сериализацию/десереализацию в xml и подобные форматы. Быстрее можно сделать, написав взаимодействие серверов напрямую через сетевые сокеты, я не готов сейчас этим заниматься.
Скорость влияет на отклик системы, который важен для пользователя. Всегда важен.
Конкретные измерения http и tcp? При одной и той же реализации wcf можно установить способ передачи данных (NetTCPBinding, HttpBinding). От меня вы чего хотите, чтобы я вам цифры привел? посмотрите сами. Могу другими словами: при net.tcp идёт sender -> net.tcp -> receiver. По HTTP идёт так sender -> http -> tcp -> http -> receiver. Я не буду ставить тесты, моя реализация будет быстрее реализации через WebAPI. Вы чётко говорите не использовать моё (стандартное решение от Microsoft), а взамен предлагаете WebAPI (другое стандартное решение от Microsoft).
С вами обсуждение началось, потому что вы несколько раз сказали «у вас всё неправильно», я услышал предложение использовать три сторонних библиотеки, и обязательно их посмотрю. На это нужно время, а, возможно, будет проще и быстрее сделать взаимодействие серверов через сокеты.
На самом же деле, мой основной вопрос был как правильно создать в студии эту «неправильную» архитектуру" распределенного сервера для обычного хостинга, где есть возможность только арендовать vds, а не для азуры. Отлаживать и публиковать.
Сергей, я не знаю, чем вам так насолил.
Вам уже сказали — этому посту место на тостере, а не здесь.
Тут я не использую избыточность от wcf, к ней я отношу контракты, автоматически генерируемые файлы и сериализацию/десереализацию в xml и подобные форматы
Вы не используете контракты? А вот это что:
factory = new ChannelFactory<IwcfChat>(b, address);
// ...
_channel = factory.CreateChannel();
// ...
chat.channel.SendMessage(id, name, text);У вас радостно работают и прокси, и форматирующий, и транспортный уровни WCF.
Скорость влияет на отклик системы, который важен для пользователя. Всегда важен.
Даже если (а) отклик уже за границей восприятия и/или (б) есть другие факторы, чье влияние на отклик на три порядка больше?
От меня вы чего хотите, чтобы я вам цифры привел?
Да. Это же вы утверждаете, что http всегда будет медленнее.
Вы чётко говорите не использовать моё (стандартное решение от Microsoft)
Нет, не говорю.
На самом же деле, мой основной вопрос был как правильно создать в студии эту «неправильную» архитектуру" распределенного сервера для обычного хостинга, где есть возможность только арендовать vds, а не для азуры. Отлаживать и публиковать.
В студии создать — как обычно, k отдельных проектов в одном solution. Публиковать через систему управления релизами (октопус, ну или что там MS сейчас выпускает для TFS). Отлаживать — в зависимости от вкусов, либо через multiple startup projects, либо компоновать все сервисы локально в памяти, благо, это тривиально при правильной декмопозиции (а для акторов — тривиально по определению).
Моя статья рассказывает как правильно и без лишних телодвижений настроить wcf по tcp в азуровском проекте. Я обязательно дополню её, как только разберусь во всех вопросах. И так как у меня были сложности с поиском информации по этой теме и то, что уже несколько людей добавили эту статью в избранное говорит о том, что её место тут. В любом случае я не знаю как перенести её и не хочу об спорить о местоположении.
Про скорость я вам сказал, тестов много, они гуглятся легко, вот пример wcf-relative-binding-speeds. В два раза быстрее.
Согласен про мои некорректные фразы про wcf, я лишь хотел сказать, что такая реализация делается проще и быстрее (из возможных реализаций именно на wcf), чем то, что гуглится вначале по таким запросам.
Вы говорите, что моё решение неэффективно, потому что транспортные расходы сводят на нет все преимущества распределенной системы. Это и есть именно та мысль, что не нужно использовать такое решение. Что можно с ним сделать?
1. Вернуться на монолитный сервер. Это сразу нет.
2. Доработать, а именно добавить асинхронность на запросы. Либо вовсе уйти от wcf и написать прямые вызовы по сети. Что вы думаете о таком решении?
3. Воспользоваться сторонними библиотеками. Я их посмотрю, но пока во всём разберусь, будет не быстро. Если вы говорите, что это самый правильное решение, я посмотрю гораздо внимательнее и, если всё получится, то остановлюсь на этом решении.
Создать как отдельные проекты в решении. Это я и спрашивал. Так как я много не знаю, то могло оказаться, что есть другой способ, уточнить стоило. С этим ладно.
Про отладку, если это отдельные проекты, то при пошаговой отладке при вызове удаленного метода, курсор не будет проходить в него, а студия будет выдавать информационное сообщение, что вызван удаленный метод и вернулся такой результат. А чтобы попасть внутрь, нужно вручную заходить в этот метод и ставить точку останова. Это неудобно. И про это стоило спросить, быть может как-то можно создать такое решение не отдельными проектами, чтобы таких неудобств не было.
А самое главное, когда я арендую у хостинга два vds, то между ними нет локальной сети. По этому вопросу я вообще ничего не могу сказать, я таким не занимался. Тут хочу услышать, что либо нет возможности настроить локальную сеть, и тогда моё решение вообще нельзя будет перенести на обычные хостинги. Либо можно сделать через поддержку хостинга. Либо можно настроить самому руками и что нужно будет для этого сделать.
Про скорость я вам сказал, тестов много, они гуглятся легко, вот пример wcf-relative-binding-speeds. В два раза быстрее.
Согласен про мои некорректные фразы про wcf, я лишь хотел сказать, что такая реализация делается проще и быстрее (из возможных реализаций именно на wcf), чем то, что гуглится вначале по таким запросам.
Вы говорите, что моё решение неэффективно, потому что транспортные расходы сводят на нет все преимущества распределенной системы. Это и есть именно та мысль, что не нужно использовать такое решение. Что можно с ним сделать?
1. Вернуться на монолитный сервер. Это сразу нет.
2. Доработать, а именно добавить асинхронность на запросы. Либо вовсе уйти от wcf и написать прямые вызовы по сети. Что вы думаете о таком решении?
3. Воспользоваться сторонними библиотеками. Я их посмотрю, но пока во всём разберусь, будет не быстро. Если вы говорите, что это самый правильное решение, я посмотрю гораздо внимательнее и, если всё получится, то остановлюсь на этом решении.
Создать как отдельные проекты в решении. Это я и спрашивал. Так как я много не знаю, то могло оказаться, что есть другой способ, уточнить стоило. С этим ладно.
Про отладку, если это отдельные проекты, то при пошаговой отладке при вызове удаленного метода, курсор не будет проходить в него, а студия будет выдавать информационное сообщение, что вызван удаленный метод и вернулся такой результат. А чтобы попасть внутрь, нужно вручную заходить в этот метод и ставить точку останова. Это неудобно. И про это стоило спросить, быть может как-то можно создать такое решение не отдельными проектами, чтобы таких неудобств не было.
А самое главное, когда я арендую у хостинга два vds, то между ними нет локальной сети. По этому вопросу я вообще ничего не могу сказать, я таким не занимался. Тут хочу услышать, что либо нет возможности настроить локальную сеть, и тогда моё решение вообще нельзя будет перенести на обычные хостинги. Либо можно сделать через поддержку хостинга. Либо можно настроить самому руками и что нужно будет для этого сделать.
Про скорость я вам сказал, тестов много, они гуглятся легко, вот пример wcf-relative-binding-speeds. В два раза быстрее.
Угу, внутри WCF. Но речь-то идет про WCF vs WebAPI.
Согласен про мои некорректные фразы про wcf, я лишь хотел сказать, что такая реализация делается проще и быстрее (из возможных реализаций именно на wcf), чем то, что гуглится вначале по таким запросам.
И содержит больше одной ошибки, ага.
Вы говорите, что моё решение неэффективно, потому что транспортные расходы сводят на нет все преимущества распределенной системы.
Нет, этого я тоже не говорю.
Доработать, а именно добавить асинхронность на запросы. Либо вовсе уйти от wcf и написать прямые вызовы по сети. Что вы думаете о таком решении?
Я думаю, что любые оптимизации по производительности обязательно должны сопровождаться двумя вещами: постоянными измерениями и четко поставленной измеримой целью. У вас я не вижу ни того, ни другого.
Про отладку, если это отдельные проекты, то при пошаговой отладке при вызове удаленного метода, курсор не будет проходить в него, а студия будет выдавать информационное сообщение, что вызван удаленный метод и вернулся такой результат.
Только в том случае, если вы используете multiple startup projects и раздельную композицию. Если у вас все скомпоновано локально, то не важно, сколько у вас проектов.
А самое главное, когда я арендую у хостинга два vds, то между ними нет локальной сети.
А это вообще вопрос к хостингу, очевидно.
И да, как уже говорилось, вопросы — на Тостер.
про WCF vs WebAPI perfomance цифр так же очень много. Поверх HTTP webAPI работает быстрее, чем wcf на, примерно, 10%.
Внутри wcf я привел пример теста на разных каналах и цифры показывают, что по tcp работает в два раза быстрее. Не нужен отдельный тест, чтобы понимать, что wcf на tcp работает быстрее, чем webAPI, и даже можно грубо сказать, что быстрее, примерно, на 40%.
Про эффективность я теперь совсем не понимаю, то есть вы просто указываете на недостатки текущей системы. Я предложил варианты решения недостатков. Для постоянных измерений мне нужно вначале сделать несколько реализаций, а я всего лишь спрашиваю, как сделать распределенную систему правильно. Это чётко поставленная цель, она подразумевает максимальную производительность (которая включает в себя скорость передачи данных) и удобство разработки.
Еще вы постоянно начали повторять, что я неправильно понимаю ваши высказывания, давайте разложим по полочкам:
сам WCF (который, в общем-то, весьма тяжелый) дает мне избыточный оверхед.
Все взаимодействие у меня синхронное. Много ресурсов бессмысленно теряется на блокировках.
Кроме WCF есть много других технологий для распределенных систем.
Отклик, из-за использования wcf, уже за границей восприятия и его влияние на отклик на три порядка больше (это в тысячу раз?).
Я правильно понимаю ваши доводы, хотя вы и говорили их в форме вопросов, ничего не перепутал? Из этого я могу сделать вывод о том, что моя реализация неэффективна, что нужно переходить на другие технологии. Каких-либо стандартов реализации распределенного сервера не существует, можно только воспользоваться чьими-то разработками, например thrift, Akka.net и Orleans.
Поправьте, если ошибаюсь.
Внутри wcf я привел пример теста на разных каналах и цифры показывают, что по tcp работает в два раза быстрее. Не нужен отдельный тест, чтобы понимать, что wcf на tcp работает быстрее, чем webAPI, и даже можно грубо сказать, что быстрее, примерно, на 40%.
Про эффективность я теперь совсем не понимаю, то есть вы просто указываете на недостатки текущей системы. Я предложил варианты решения недостатков. Для постоянных измерений мне нужно вначале сделать несколько реализаций, а я всего лишь спрашиваю, как сделать распределенную систему правильно. Это чётко поставленная цель, она подразумевает максимальную производительность (которая включает в себя скорость передачи данных) и удобство разработки.
Еще вы постоянно начали повторять, что я неправильно понимаю ваши высказывания, давайте разложим по полочкам:
сам WCF (который, в общем-то, весьма тяжелый) дает мне избыточный оверхед.
Все взаимодействие у меня синхронное. Много ресурсов бессмысленно теряется на блокировках.
Кроме WCF есть много других технологий для распределенных систем.
Отклик, из-за использования wcf, уже за границей восприятия и его влияние на отклик на три порядка больше (это в тысячу раз?).
Я правильно понимаю ваши доводы, хотя вы и говорили их в форме вопросов, ничего не перепутал? Из этого я могу сделать вывод о том, что моя реализация неэффективна, что нужно переходить на другие технологии. Каких-либо стандартов реализации распределенного сервера не существует, можно только воспользоваться чьими-то разработками, например thrift, Akka.net и Orleans.
Поправьте, если ошибаюсь.
про WCF vs WebAPI perfomance цифр так же очень много. Поверх HTTP webAPI работает быстрее, чем wcf на, примерно, 10%.
Внутри wcf я привел пример теста на разных каналах и цифры показывают, что по tcp работает в два раза быстрее. Не нужен отдельный тест, чтобы понимать, что wcf на tcp работает быстрее, чем webAPI, и даже можно грубо сказать, что быстрее, примерно, на 40%.
Первое правило работы с производительностью: меряйте. Нельзя переносить проценты из одного теста на другой.
Про эффективность я теперь совсем не понимаю, то есть вы просто указываете на недостатки текущей системы.
Я указываю на ошибки в ваших утверждениях в первую очередь.
а я всего лишь спрашиваю, как сделать распределенную систему правильно
Нет единого "правильно".
Это чётко поставленная цель, она подразумевает максимальную производительность (которая включает в себя скорость передачи данных) и удобство разработки.
Максимальная производительность прямо противоречит удобству разработки. Вы не можете ставить цель, которая предполагает одновременного достижения и того, и другого.
Отклик, из-за использования wcf, уже за границей восприятия и его влияние на отклик на три порядка больше (это в тысячу раз?).
Этого я не говорил.
Из этого я могу сделать вывод о том, что моя реализация неэффективна, что нужно переходить на другие технологии.
Ваша реализация — неэффективна. Надо ли переходить на другие технологии — открытый вопрос.
Каких-либо стандартов реализации распределенного сервера не существует, можно только воспользоваться чьими-то разработками, например thrift, Akka.net и Orleans.
Поправьте, если ошибаюсь.
Каких-либо стандартов не существует (равно как и понятия "распределенный сервер"), для разработки можно воспользоваться любым решением, удовлетворяющим поставленному набору требований.
Orleans, как вариант, думаю подошел бы.
Да, про акку вспомнил, а про орлеан забыл. Нелепо.
Спасибо, посмотрю. На самом деле очень удивлен, что необходимо пользоваться сторонними библиотеками. Когда-то в голове отложилось, что есть монолитное решение и можно сделать распределенное решение, которое обладает рядом преимуществ. Разговоры ведутся давно, надеялся, что есть уже всё готовенькое и стандартное. Вот теперь коснулся этой темы и какой-то ужас.
Я думаю, ZOXEXIVO предлагает использовать что-то более легковесное, например SignalR.
А меня WCF полностью устраивает, но в качестве сериализатора лучше использовать ProtoBuf (https://habrahabr.ru/post/119510/), тогда проигрыш перед Thrift будет меньше.
Да, Visual Studio затачивается на Azure.
Но можно сделать и свой Azure https://www.microsoft.com/ru-ru/server-cloud/products/windows-azure-pack/features.aspx
Но можно сделать и свой Azure https://www.microsoft.com/ru-ru/server-cloud/products/windows-azure-pack/features.aspx
Привет, да, именно этой технологии я уделил один абзац. Я увидел её у хостера 1gb.ru, у них не хватает нескольких пунктов, например базы данных, а, самое главное, нет облачной службы. Так же нет и синхронизации со студией. А портал похож на старый
Azure Pack- это не Azure от слова вообще. В нем можно дать доступ к базам данных, но это будет обычный sql server, а не paas.
К концу года обещали Azure Stack и вот с этим обещали работу как с нормальным Azure, но в своем датацентре
К концу года обещали Azure Stack и вот с этим обещали работу как с нормальным Azure, но в своем датацентре
Что хостер сделал, то и доступно. у меня например вообще ничего, кроме управления виртуалками не было настроено
P.S. Windows Azure переименовали в Microsoft Azure года 2-3 назад вроде… Т.к. мы не завязываемся на Windows и уже давно на много шире чем windows.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хостим облачную службу Azure на обычных vds