Первое, что вам нужно сделать, это сделать шаг назад и подумать, насколько критична производительность для этого приложения. Вам действительно нужно обрабатывать сообщения одновременно? Это важно для миссии? Или ты просто думаешь , что тебе это нужно? Вы использовали профилировщик на своем сервисе, чтобы найти реальные узкие места процессов и оптимизировать их?
Причина, по которой я спрашиваю, заключается в том, что вы упомянули, что хотите 8 одновременных процессов - однако, если вы сделаете это приложение однопоточным, это значительно уменьшит сложность, время разработки и тестирования ... И так как вы хотите только 8, это почти не стоит ...
Во-вторых, поскольку вы можете обрабатывать только параллельные сообщения на одном и том же объекте - как часто вы действительно будете получать параллельные запросы от вашего клиента на получение одного и того же объекта ? Стоит ли добавлять так много уровней сложности для варианта использования, который может появляться не очень часто?
Я бы поцеловал. Я бы использовал MSMQ через WCF и сохранил бы мой сервис WCF как одиночный. Теперь у вас есть мощность, заказанная надежность MSMQ, и вы теперь соответствуете вашим реальным требованиям. Затем я проверил бы его при высокой нагрузке с реалистичными данными и запустил профилировщик, чтобы найти узкие места , если я обнаружил, что это было слишком медленно. Только тогда я справлюсь со всеми дополнительными трудностями создания гораздо более сложного приложения для управления параллелизмом только для конкретных случаев использования ...
Один из подходов, который следует рассмотреть, - это создание центральной службы «сторожевого устройства» или «служебной шины», которая получает все сообщения от клиентов и затем передает эти сообщения фактическим рабочим службам. Когда он получает запрос, он затем обнаруживает, обрабатывает ли другой из его клиентов уже сообщение для того же объекта - если это так, он отправляет его той же службе, которой отправил другое сообщение. Таким образом, вы можете одновременно обрабатывать одни и те же сообщения для данной сущности и ничего более ... И у вас есть простота плавной масштабируемости ... Однако я бы сделал это, только если бы мне это было абсолютно необходимо, и это было доказано с помощью профилирования и тестирования и не потому, что «мы думаем, что нам это нужно» (см. руководителя YAGNI:))