Итак, я создаю облачную службу, в которую добавляю одну веб-роль (виртуальная машина с IIS), один воркер (виртуальная машина без IIS) и общую библиотеку классов. После публикации моим ролям присваивается ip-адрес и разные порты. То есть сразу есть tcp сеть, ручные настройки минимальны и могут делаться в самой студии. Можно, к примеру, сделать общедоступную точку доступа для воркера, но мне это не нужно. Мой воркер будет скрыт от внешних глаз и на нём будет висеть wcf-сервер, а общаться мои роли будут по быстрой локальной сети.
Общие классы я выношу в библиотеку (которую подключаю ко всем ролям), к примеру, интерфейс и канал связи:
[ServiceContract]
public interface IwcfChat
{
[OperationContract]
string SendMessage(string userId, string userName, string text);
[OperationContract]
string GetMessages(string userId, string userName);
}
//================
public sealed class wcfChat:IDisposable
{
IwcfChat _channel;
ChannelFactory<IwcfChat> factory = null;
public wcfChat()
{
NetTcpBinding b = new NetTcpBinding();
b.Security.Mode = SecurityMode.None;
b.Security.Message.ClientCredentialType = MessageCredentialType.None;
#if(DEBUG)
EndpointAddress address = new EndpointAddress("net.tcp://127.255.0.1:9003/wcfChat");
#else
EndpointAddress address = new EndpointAddress("net.tcp://"+spr.wcfIP+":9003/wcfChat");
#endif
factory = new ChannelFactory<IwcfChat>(b, address);
factory.Faulted += OnChannelFaulted;
factory.Open();
}
public IwcfChat channel
{
get
{
if (factory != null && factory.State == CommunicationState.Opened)
{
if(_channel==null) _channel = factory.CreateChannel();
return _channel;
}
return null;
}
}
void OnChannelFaulted(object sender, EventArgs e)
{
factory.Abort();
}
public void Dispose()
{
factory.Close();
}
}
Методы в веб-роли вызываю так:
using (var chat = new wcfChat())
{
res = chat.channel.SendMessage(id, name, text);
}
Соответственно, в воркере у меня реализация методов из интерфейса (SendMessage, GetMessage), не буду их расписывать, а так же в воркере при старте выполняется код, который делает его хостом для wcf:
public override bool OnStart()
{
// Задайте максимальное число одновременных подключений
ServicePointManager.DefaultConnectionLimit = 12;
// Create the host
ServiceHost host = new ServiceHost(typeof(wcfChat));
// Read config parameters
string hostName = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["port"].IPEndpoint.Address.ToString();
// Create Metadata
ServiceMetadataBehavior metadatabehavior = new ServiceMetadataBehavior();
host.Description.Behaviors.Add(metadatabehavior);
Binding mexBinding = MetadataExchangeBindings.CreateMexTcpBinding();
string mexendpointurl = string.Format("net.tcp://{0}:{1}/wcfChatMetadata", hostName, 8003);
host.AddServiceEndpoint(typeof(IMetadataExchange), mexBinding, mexendpointurl, new Uri(mexendpointurl));
// Create end point
string endpointurl = string.Format("net.tcp://{0}:{1}/wcfChat", hostName, 9003);
host.AddServiceEndpoint(typeof(IwcfChat), new NetTcpBinding(SecurityMode.None), endpointurl, new Uri(endpointurl));
// Open the host
host.Open();
// Trace output
Trace.WriteLine("WCF Listening At: " + endpointurl);
Trace.WriteLine("WCF MetaData Listening At: " + mexendpointurl);
return base.OnStart();
}
Тут я показал методы типа string, но тип возвращаемого значения может быть абсолютно любой, к примеру, сложный класс, который описан в моей общей библиотеке. Всё, никаких других настроек в вебконфигах, никаких упаковок в xml или SOAP у меня нет. Нет автоматически генерируемых файлов контрактов. Когда я пытался это сделать, в интернетах при поиске информации про wcf всегда всплывает настройка под http со всеми этими упаковками/распаковками. Да, wcf технология изначально придумана для связи разнородных систем, где необходимо сериализовать и передавать как строку. Но если у нас один язык программирования, а клиент и сервер wcf — это всё наша разработка, то не нужно городить огород, всё прекрасно работает.
Таким образом у меня получается распределенный сервер, для затратных операций я делаю отдельный воркер, тут, к примеру, показан чат. Все функции чата вынесены в отдельную виртуальную машину и я могу увеличивать производительность как самого сайта (веб-роли), так, отдельно, и чата.
Такая архитектура мне кажется правильной и может выдержать более сильную нагрузку, чем монолитный проект. Так же всё это разрабатывается и отлаживается как один проект в студии, то есть при вызове метода по wcf я могу в отладке пройти глубже в код, без сообщений типа «внутри отлаживать я не могу, не знаю что там происходит, вот такой вернулся результат».
С Азуровскими инструментами это делается всё легко и просто, я запускаю весь проект одной кнопкой и отлаживаюсь по нему как по одному проекту. Я помню когда-то давно, на одном из проектов была похожая архитектура, но я был молод, и мне там было очень сложно: какие-то фасады, и, если параметры у метода менялись, я изменения в четырёх местах вносил.
Мне нужно нечто подобное сделать на обычных серверах. Не на своих физических серверах, а на vds/vps виртуалках у какого-нибудь обязательно российского хостера. Я нашел забавную технологию у одного из хостеров (1gb.ru), называется ресурс Windows Azure Pack / COSN. По описанию это урезанная версия Азуры и всё должно было бы «взлететь». Конечно же, у них есть пробный период, я посмотрел. В браузере управление как-будто из старой версии портала Азуры (если кто помнит).
Из возможностей есть только создание виртуальных машин, объединение их в сеть (вручную), есть service bus — и всё. Так же нет возможности загрузить эту подписку в студию, а в этом и есть многое из удобств. Плюс нет возможности создания облачной службы. В описании сказано, что это «частное облако» будет дорабатываться и дополняться возможностями с оригинальной Азуры, но поддержка сказала, что всё уже давно заморожено, и вообще, это несовместимые технологии («этот Azure Pack совершенно по смыслу не совместим с настоящим Azure. Там что есть, то есть, и есть там маловато. Идеи там общие, но реализация разная совершенно, API разные и так далее.» (с)).
Если кратко — то не подходит.
Ищем дальше. Я пробегаюсь по виндовым хостерам, ищу возможность аренды обычных vps/vds но с возможностью организовать локальную сеть между ними. У многих попросту отсутствует такая возможность. Да, можно арендовать виртуалку, поднять на ней VPN и другой виртуалкой зацепиться к этой сети. Но такая «локальная» сеть натягивается поверх http, поэтому заведомо медленнее. Я уж было подумал, что у меня ничего не получится, но у хостера 1cloud вижу искомое «Всего в пару кликов бесплатно объединяйте ваши виртуальные машины в частную сеть с пропускной способность 1Гбит/с.» Кстати, у них есть обычные сервера в Питере и высокопроизводительные в Москве. Поддержка говорит, что на московской инфраструктуре разворачиваются локальные сети с пропускной способностью 10Гбит/с.
Отлично, попробуем сделать то же самое, что выше, только для обычного хостинга.
В студии создаем решение, я назвал его sharedTest, в которое добавляем:
1. MVC приложение с аналогичным названием.
2. Библиотеку классов windows, я назвал просто Lib
3. Консольное приложение windows, я назвал его worker
Далее, необходимо связать эти проекты воедино, для этого жмём правой кнопкой на наше решение и идём в свойства
Тут необходимо в запускаемом проекте выбрать пункт, что у меня несколько запускаемых и мой Worker поднять повыше, чем сайт.
Тут же следующее свойство — зависимость проектов. Библиотека не зависит ни от кого. Сайт sharedTest зависит и от библиотеки и от воркера. Воркер зависит только от библиотеки.
Не забудем в свойствах воркера (так же правой кнопкой и свойства) указать запускаемый объект, чтобы вначале запускался воркер и никого не ждал.
Следующий шаг — добавляем зависимости. В библиотеке Lib правой кнопкой по связям (Reference) -> добавить ссылку… и нам понадобится пакет System.ServiceModel. Этот же пакет нам нужен и в воркере. Таким же образом в сайте и воркере добавляем ссылку на нашу библиотеку из проекта Lib.
В библиотеку помещаем (удобно отдельными файлами) public interface IwcfChat и public sealed class wcfChat:IDisposable (мой первый листинг наверху). Так же там находится справочник с общими настройками или структурами, там у меня лежит только айпи адрес (откуда я его взял будет немного позже).
public static class spr
{
public static string wcfIP = "10.0.0.6";
}
Сделаем наш воркер хостом для службы (аналогично верхнему листингу, только перенес в функцию Main, т.к. у меня консольное приложение)
class Program
{
static void Main(string[] args)
{
// Задайте максимальное число одновременных подключений
ServicePointManager.DefaultConnectionLimit = 12;
// Create the host
ServiceHost host = new ServiceHost(typeof(wcfChat));
// Read config parameters
#if (DEBUG)
string hostName = "127.255.0.1";
#else
string hostName = spr.wcfIP;
#endif
// Create Metadata
ServiceMetadataBehavior metadatabehavior = new ServiceMetadataBehavior();
host.Description.Behaviors.Add(metadatabehavior);
Binding mexBinding = MetadataExchangeBindings.CreateMexTcpBinding();
string mexendpointurl = string.Format("net.tcp://{0}:{1}/wcfChatMetadata", hostName, 8003);
host.AddServiceEndpoint(typeof(IMetadataExchange), mexBinding, mexendpointurl, new Uri(mexendpointurl));
// Create end point
string endpointurl = string.Format("net.tcp://{0}:{1}/wcfChat", hostName, 9003);
host.AddServiceEndpoint(typeof(IwcfChat), new NetTcpBinding(SecurityMode.None), endpointurl, new Uri(endpointurl));
// Open the host
host.Open();
Console.WriteLine("Host opened on "+hostName);
Console.ReadLine();
}
}
Порты 8003 и 9003 я взял из головы, главное, чтобы они не были стандартными и не были заняты.
Добавляем в воркер класс wcfChat — реализацию нашего интерфейса
using Lib;
namespace Worker
{
class wcfChat : IwcfChat
{
public string SendMessage(string userId, string userName, string text)
{
return "Sending message....";
}
public string GetMessages(string userId, string userName)
{
return "Get messages";
}
}
}
Не стал тут ничего расписывать, но значения приходят. Самое время попробовать — модифицируем наш контроллер Home и его представление
public ActionResult Index(bool isGet = true)
{
string res = "";
using (var chat = new wcfChat())
{
res = isGet ? chat.channel.GetMessages("1", "name") : chat.channel.SendMessage("1", "name", "text");
}
return View((object)res);
}
@model string
@{
ViewBag.Title = "Home Page";
}
<br /><br />
<div>@Model</div>
Запускаем и видим, что всё работает:
Отлично, осталось совсем немного — выложить проект у хостера, напомню, я работаю с 1cloud. Регистрируемся, через панель управления создаем две виртуальные машины нужной нам конфигурации (я взял минимальные в Питерском ЦОДе, но это без разницы). Тестовый период у них несколько часов, поддержка расширила мне по просьбе, и вообще молодцы, идут навстречу.
Далее создаем локальную сеть, тоже парой кликов, второй пункт из панели управления, я назвал её testLocal. Кстати, я выключил флажок динамичных айпишников (DHCP), так как мой сервис зависит от статичного айпишника, из-за этого придется еще немного повозиться.
После создания, всё так же в панели управления, заходим в каждый сервер, идём на вкладку Настройки, находим Частные сети и переключаем флажок, что мы пользуемся вновь созданной сетью. Этот флаг добавит нам новый адаптер и новую сеть внутри виртуальной машины. Там же нам выдаётся внутренний айпишник, у меня это были 10.0.0.5 и 10.0.0.6 для сайта и воркера. Чтобы сеть заработала лезем по удаленному рабочему столу (RDP) на свои виртуалки и вручную вбиваем эти значения в настройки сети. Инструкции для тех, кто не разбирается, лежат там же рядом.
Хочу предупредить, что сразу у меня не заработало. Я указал сети общедоступными, поэтому пришлось их переделывать в частные вот так . А так же нужно добавить мои используемые порты в исключения брандмауэра. Для этого я вызвал запуск (Run) клавиши win+R и набрал там netsh.exe
после чего в командной строке набрал команду
firewall set portopening protocol = TCP port = 9003 name = myService mode = ENABLE scope = SUBNET profile = CURRENT
Теперь расскажу о публикации. Я настроил IIS по этому мануалу. Проверить работоспособность можно из браузера по внешнему айпишнику. Картиночка из IIS говорит нам о том, что всё работает.
Я ничего не делал ни с ftp, ни, тем более, с настройкой публикации из системы контроля версий, это тема другой статьи. Я подправил айпишник на выданный, опубликовал моё веб-приложение в файловую систему и ручками закинул в папочку C:\inetpub\wwwroot на сервере. Обновил страницу и увидел ожидаемую ошибку по адресу Home/Index, так как службы еще не было.
Собственно, мой воркер я так же опубликовал в файловую систему, получился установочник. Тут единственное, нужно не запутаться с DEBUG/RELEASE. Всю папочку я перетащил на рабочий стол второй виртуалки, левой кнопкой мыши установил и запустил. Вылезло моё чёрное окно, которое говорило, что сервис работает. Обновляем сайт, видим, что всё удалось.
Таким образом я получил работоспособный распределенный сервер. Чат я привел как пример, хотя в комментариях говорят, что за это нужно бить по рукам ) Вообще эту технологию я использую в браузерной игре, где функции расчета поединка вынесены на отдельный сервер. Из плюсов то, что я могу повысить производительность только одного конкретного сервера, если мне будет необходимо. Таким же образом можно сделать и для двух веб-сайтов, к примеру, обрабатывать фотографии будет первый сервер, а для хранения изображений будет использоваться второй сервер на поддомене (передача изображения идёт один раз, а дальше второй лишь отображает).
Естественно, реализация не идеальна, это лишь оправная точка. Необходимо настроить корректную и удобную публикацию. К тому же тут жесткая связь 1 к 1, а если нужно будет несколько воркеров, то необходим будет балансировщик нагрузки. Так же, по-хорошему, нужно избавиться от статичных внутренний айпишников. Ну и в целом для быстродействия нужно будет заменить wcf связь на реализацию напрямую через tcp сокеты.
Комментарии (30)
netpilgrim
15.07.2016 00:35Вам сюда: toster.ru
Jeer
15.07.2016 10:44Спасибо. Чтобы мне задать правильный вопрос, вначале нужно объяснить, что я делаю и что хочу получить, а это, как видите, заняло много места и хватило на целую статью. Когда я пытался сделать именно так, у меня были трудности с поиском информации, ведь существует несколько способов настроить распределенную систему, и очень много запросов приводят к wcf по http(s) (в различных вариациях). Еще были варианты настройки через сокеты. Но это всё не то, что мне было нужно. И, так как я долго возился с этим вопросом, надеюсь, что моя статья пригодится людям, которые ищут именно такой способ. А отдельно вопросы, без этой статьи, мне не дадут никаких ответов
ZOXEXIVO
15.07.2016 10:29+1За WCF-чаты нужно по рукам бить
Jeer
15.07.2016 10:53Что не так с чатом? Можно и под чат выделить сервер. У меня нет задержки на отклики из-за того, что нет сериализации/десериализации и вызовы происходят по локальной сети, очень быстрому каналу передачи. Это я как пример и возможность: таким способом я выношу затратные функции обсчета поединка в браузерной игре и обсчета подземелий. Но и для чата не вижу проблем и неудобств, поясните? Очень хочу сделать всё красиво и изящно, вынося чат на отдельный сервер я уменьшаю нагрузку с основного, подскажите как это можно сделать более правильно?
lair
15.07.2016 10:56У меня нет задержки на отклики из-за того, что нет сериализации/десериализации
Правда нет? А как у вас данные по локальной сети передаются, чудом?
Jeer
15.07.2016 11:07Ну это само собой. Но этот вариант — самое быстрое, что я могу предложить. Я правда хочу понять и разобраться как сделать правильно. Вы говорите мне: «так делать нельзя». Я не отрицаю, но этого мало. Подскажите, как можно сделать? Естественно, если я делаю распределенные функции у меня появятся задержки на передачу. Но так я разгружаю основной сервер, что при большой нагрузке может дать и отклик быстрее.
lair
15.07.2016 11:16Но этот вариант — самое быстрое, что я могу предложить.
А вам так важна эта скорость? Если да, то уверены ли вы, что сам WCF (который, в общем-то, весьма тяжелый) не дает вам избыточного оверхеда?
Все взаимодействие у вас синхронное. Сколько ресурсов вы бессмысленно теряете на блокировках?
Ну и вообще, кроме WCF есть много других технологий для распределенных систем.
Jeer
15.07.2016 11:31Это я и пытаюсь выяснить. Я понимаю, что есть другие технологии для распределенных систем, но я о них не знаю.
В третий раз вы мне говорите, что так, как я делаю, делать не надо. Но не говорите как переделать? Я же не требую от вас готового решения для меня, но хоть что-то можете сказать? какой подход использовать? Какую технологию? Чем можно заменить мой подход?
Если вы действительно хотите мне помочь, то критика должна быть конструктивной, а вы просто говорите: «так делать не надо, есть много других технологий». Мне такие фразы никак не помогут и не приблизят ни на шаг к правильному решению.lair
15.07.2016 11:47Для начала я задал вам пару весьма конкретных вопросов. У вас уже есть на них ответы?
А вообще — берете WebAPI, Akka.net, ServiceStack, Thrift и сравниваете.
Jeer
15.07.2016 12:33Уже какая-то конкретика, за это спасибо.
Дальше начала мы с вами и не продвинулись. На ваши «весьма конкретные вопросы» я ответил, но могу еще раз. Скорость — всегда важна. Я не говорил, что мой вариант самый быстрый, наоборот, хочу узнать как делать такие вещи правильно. Синхронные вызовы можно заменить на асинхронные. Тяжелый wcf — что в моих трёх строчках вы увидели тяжелого? Создание каналов через ChannelFactory?
Про передачу данных еще был вопрос, транспортные расходы всегда будут. Я знаю только два канала передачи данных — это http и tcp. Http — медленнее и решения, основанные на этом канале будут медленнее (предложенные WebAPI и ServiceStack).
Вообще, стандартные решения от майкрософт для сервисов — это WebAPI и wcf. С одной стороны вы говорите не использовать стандартные решения, с другой стороны самих их предлагаете, ладно.
Thift, как видно из описания, фреймворк для облегчения взаимодействия между кодом написанным на разных языках. По описанию мне не подходит. Он использует tcp канал, вопрос вам, сильна ли разница этой избыточной библиотеки и стандартного ChannelFactory?
Про Akka.net я почитаю, спасибо.
А еще вы пытаетесь язвить тем, что умнее, хотя я пришел за помощью и сразу сказал, что у меня немного опыта. Не очень приятно слушать вашу желчь.lair
15.07.2016 12:50Тяжелый wcf — что в моих трёх строчках вы увидели тяжелого?
Сам WCF с его (часто избыточной) инфраструктурой.
Скорость — всегда важна.
Нет, в том-то и дело.
Http — медленнее и решения, основанные на этом канале будут медленнее
Вы делали конкретные измерения, которе могут это подтвердить?
С одной стороны вы говорите не использовать стандартные решения
Где я это говорю?
Thift, как видно из описания, фреймворк для облегчения взаимодействия между кодом написанным на разных языках. По описанию мне не подходит
Ничто не мешает использовать его между кодом, написанным на одном языке.
Он использует tcp канал, вопрос вам, сильна ли разница этой избыточной библиотеки и стандартного ChannelFactory?
Эээ… а как вы вообще сравниваете протокол (с имплементацией) с одним классом, решающим конкретную задачу?
Но вообще, между thrift и стандартными WCF-сериализаторами есть фундаментальная разница — там где WCF использует рефлексию (которая заведомо медленная), thrift использует кодогенерацию. Вот вам и разница в производительности.
Jeer
15.07.2016 13:22Сергей, я не знаю, чем вам так насолил.
Тут я не использую избыточность от wcf, к ней я отношу контракты, автоматически генерируемые файлы и сериализацию/десереализацию в xml и подобные форматы. Быстрее можно сделать, написав взаимодействие серверов напрямую через сетевые сокеты, я не готов сейчас этим заниматься.
Скорость влияет на отклик системы, который важен для пользователя. Всегда важен.
Конкретные измерения http и tcp? При одной и той же реализации wcf можно установить способ передачи данных (NetTCPBinding, HttpBinding). От меня вы чего хотите, чтобы я вам цифры привел? посмотрите сами. Могу другими словами: при net.tcp идёт sender -> net.tcp -> receiver. По HTTP идёт так sender -> http -> tcp -> http -> receiver. Я не буду ставить тесты, моя реализация будет быстрее реализации через WebAPI. Вы чётко говорите не использовать моё (стандартное решение от Microsoft), а взамен предлагаете WebAPI (другое стандартное решение от Microsoft).
С вами обсуждение началось, потому что вы несколько раз сказали «у вас всё неправильно», я услышал предложение использовать три сторонних библиотеки, и обязательно их посмотрю. На это нужно время, а, возможно, будет проще и быстрее сделать взаимодействие серверов через сокеты.
На самом же деле, мой основной вопрос был как правильно создать в студии эту «неправильную» архитектуру" распределенного сервера для обычного хостинга, где есть возможность только арендовать vds, а не для азуры. Отлаживать и публиковать.lair
15.07.2016 13:46Сергей, я не знаю, чем вам так насолил.
Вам уже сказали — этому посту место на тостере, а не здесь.
Тут я не использую избыточность от 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, либо компоновать все сервисы локально в памяти, благо, это тривиально при правильной декмопозиции (а для акторов — тривиально по определению).
Jeer
15.07.2016 14:30Моя статья рассказывает как правильно и без лишних телодвижений настроить wcf по tcp в азуровском проекте. Я обязательно дополню её, как только разберусь во всех вопросах. И так как у меня были сложности с поиском информации по этой теме и то, что уже несколько людей добавили эту статью в избранное говорит о том, что её место тут. В любом случае я не знаю как перенести её и не хочу об спорить о местоположении.
Про скорость я вам сказал, тестов много, они гуглятся легко, вот пример wcf-relative-binding-speeds. В два раза быстрее.
Согласен про мои некорректные фразы про wcf, я лишь хотел сказать, что такая реализация делается проще и быстрее (из возможных реализаций именно на wcf), чем то, что гуглится вначале по таким запросам.
Вы говорите, что моё решение неэффективно, потому что транспортные расходы сводят на нет все преимущества распределенной системы. Это и есть именно та мысль, что не нужно использовать такое решение. Что можно с ним сделать?
1. Вернуться на монолитный сервер. Это сразу нет.
2. Доработать, а именно добавить асинхронность на запросы. Либо вовсе уйти от wcf и написать прямые вызовы по сети. Что вы думаете о таком решении?
3. Воспользоваться сторонними библиотеками. Я их посмотрю, но пока во всём разберусь, будет не быстро. Если вы говорите, что это самый правильное решение, я посмотрю гораздо внимательнее и, если всё получится, то остановлюсь на этом решении.
Создать как отдельные проекты в решении. Это я и спрашивал. Так как я много не знаю, то могло оказаться, что есть другой способ, уточнить стоило. С этим ладно.
Про отладку, если это отдельные проекты, то при пошаговой отладке при вызове удаленного метода, курсор не будет проходить в него, а студия будет выдавать информационное сообщение, что вызван удаленный метод и вернулся такой результат. А чтобы попасть внутрь, нужно вручную заходить в этот метод и ставить точку останова. Это неудобно. И про это стоило спросить, быть может как-то можно создать такое решение не отдельными проектами, чтобы таких неудобств не было.
А самое главное, когда я арендую у хостинга два vds, то между ними нет локальной сети. По этому вопросу я вообще ничего не могу сказать, я таким не занимался. Тут хочу услышать, что либо нет возможности настроить локальную сеть, и тогда моё решение вообще нельзя будет перенести на обычные хостинги. Либо можно сделать через поддержку хостинга. Либо можно настроить самому руками и что нужно будет для этого сделать.lair
15.07.2016 14:35Про скорость я вам сказал, тестов много, они гуглятся легко, вот пример wcf-relative-binding-speeds. В два раза быстрее.
Угу, внутри WCF. Но речь-то идет про WCF vs WebAPI.
Согласен про мои некорректные фразы про wcf, я лишь хотел сказать, что такая реализация делается проще и быстрее (из возможных реализаций именно на wcf), чем то, что гуглится вначале по таким запросам.
И содержит больше одной ошибки, ага.
Вы говорите, что моё решение неэффективно, потому что транспортные расходы сводят на нет все преимущества распределенной системы.
Нет, этого я тоже не говорю.
Доработать, а именно добавить асинхронность на запросы. Либо вовсе уйти от wcf и написать прямые вызовы по сети. Что вы думаете о таком решении?
Я думаю, что любые оптимизации по производительности обязательно должны сопровождаться двумя вещами: постоянными измерениями и четко поставленной измеримой целью. У вас я не вижу ни того, ни другого.
Про отладку, если это отдельные проекты, то при пошаговой отладке при вызове удаленного метода, курсор не будет проходить в него, а студия будет выдавать информационное сообщение, что вызван удаленный метод и вернулся такой результат.
Только в том случае, если вы используете multiple startup projects и раздельную композицию. Если у вас все скомпоновано локально, то не важно, сколько у вас проектов.
А самое главное, когда я арендую у хостинга два vds, то между ними нет локальной сети.
А это вообще вопрос к хостингу, очевидно.
И да, как уже говорилось, вопросы — на Тостер.
Jeer
15.07.2016 16:24про WCF vs WebAPI perfomance цифр так же очень много. Поверх HTTP webAPI работает быстрее, чем wcf на, примерно, 10%.
Внутри wcf я привел пример теста на разных каналах и цифры показывают, что по tcp работает в два раза быстрее. Не нужен отдельный тест, чтобы понимать, что wcf на tcp работает быстрее, чем webAPI, и даже можно грубо сказать, что быстрее, примерно, на 40%.
Про эффективность я теперь совсем не понимаю, то есть вы просто указываете на недостатки текущей системы. Я предложил варианты решения недостатков. Для постоянных измерений мне нужно вначале сделать несколько реализаций, а я всего лишь спрашиваю, как сделать распределенную систему правильно. Это чётко поставленная цель, она подразумевает максимальную производительность (которая включает в себя скорость передачи данных) и удобство разработки.
Еще вы постоянно начали повторять, что я неправильно понимаю ваши высказывания, давайте разложим по полочкам:
сам WCF (который, в общем-то, весьма тяжелый) дает мне избыточный оверхед.
Все взаимодействие у меня синхронное. Много ресурсов бессмысленно теряется на блокировках.
Кроме WCF есть много других технологий для распределенных систем.
Отклик, из-за использования wcf, уже за границей восприятия и его влияние на отклик на три порядка больше (это в тысячу раз?).
Я правильно понимаю ваши доводы, хотя вы и говорили их в форме вопросов, ничего не перепутал? Из этого я могу сделать вывод о том, что моя реализация неэффективна, что нужно переходить на другие технологии. Каких-либо стандартов реализации распределенного сервера не существует, можно только воспользоваться чьими-то разработками, например thrift, Akka.net и Orleans.
Поправьте, если ошибаюсь.lair
15.07.2016 16:33про WCF vs WebAPI perfomance цифр так же очень много. Поверх HTTP webAPI работает быстрее, чем wcf на, примерно, 10%.
Внутри wcf я привел пример теста на разных каналах и цифры показывают, что по tcp работает в два раза быстрее. Не нужен отдельный тест, чтобы понимать, что wcf на tcp работает быстрее, чем webAPI, и даже можно грубо сказать, что быстрее, примерно, на 40%.
Первое правило работы с производительностью: меряйте. Нельзя переносить проценты из одного теста на другой.
Про эффективность я теперь совсем не понимаю, то есть вы просто указываете на недостатки текущей системы.
Я указываю на ошибки в ваших утверждениях в первую очередь.
а я всего лишь спрашиваю, как сделать распределенную систему правильно
Нет единого "правильно".
Это чётко поставленная цель, она подразумевает максимальную производительность (которая включает в себя скорость передачи данных) и удобство разработки.
Максимальная производительность прямо противоречит удобству разработки. Вы не можете ставить цель, которая предполагает одновременного достижения и того, и другого.
Отклик, из-за использования wcf, уже за границей восприятия и его влияние на отклик на три порядка больше (это в тысячу раз?).
Этого я не говорил.
Из этого я могу сделать вывод о том, что моя реализация неэффективна, что нужно переходить на другие технологии.
Ваша реализация — неэффективна. Надо ли переходить на другие технологии — открытый вопрос.
Каких-либо стандартов реализации распределенного сервера не существует, можно только воспользоваться чьими-то разработками, например thrift, Akka.net и Orleans.
Поправьте, если ошибаюсь.
Каких-либо стандартов не существует (равно как и понятия "распределенный сервер"), для разработки можно воспользоваться любым решением, удовлетворяющим поставленному набору требований.
dmitrii_mikhailov
15.07.2016 12:20Orleans, как вариант, думаю подошел бы.
Jeer
15.07.2016 12:44Спасибо, посмотрю. На самом деле очень удивлен, что необходимо пользоваться сторонними библиотеками. Когда-то в голове отложилось, что есть монолитное решение и можно сделать распределенное решение, которое обладает рядом преимуществ. Разговоры ведутся давно, надеялся, что есть уже всё готовенькое и стандартное. Вот теперь коснулся этой темы и какой-то ужас.
chibitko
15.07.2016 15:28А меня WCF полностью устраивает, но в качестве сериализатора лучше использовать ProtoBuf (https://habrahabr.ru/post/119510/), тогда проигрыш перед Thrift будет меньше.
foxmuldercp
15.07.2016 16:36Да, Visual Studio затачивается на Azure.
Но можно сделать и свой Azure https://www.microsoft.com/ru-ru/server-cloud/products/windows-azure-pack/features.aspxJeer
15.07.2016 16:54Привет, да, именно этой технологии я уделил один абзац. Я увидел её у хостера 1gb.ru, у них не хватает нескольких пунктов, например базы данных, а, самое главное, нет облачной службы. Так же нет и синхронизации со студией. А портал похож на старый
SychevIgor
15.07.2016 17:04Azure Pack- это не Azure от слова вообще. В нем можно дать доступ к базам данных, но это будет обычный sql server, а не paas.
К концу года обещали Azure Stack и вот с этим обещали работу как с нормальным Azure, но в своем датацентре
foxmuldercp
17.07.2016 21:22Что хостер сделал, то и доступно. у меня например вообще ничего, кроме управления виртуалками не было настроено
SychevIgor
15.07.2016 17:05P.S. Windows Azure переименовали в Microsoft Azure года 2-3 назад вроде… Т.к. мы не завязываемся на Windows и уже давно на много шире чем windows.
HexGrimm
Service Fabric вам в помощь
Jeer
Спасибо, пойду поковыряю этот вопрос