BizTalk: как ограничить количество подключений к сервису wcf?

Question

Я разработал приложение BizTalk, которое получает на вход файл, содержащий кучу сообщений.Я использую компонент дизассемблера BizTalk XML, чтобы «дебатировать» файл в отдельных сообщениях.Каждое из этих сообщений извлекается из MessageBox оркестровкой, которая преобразует сообщение и вызывает службу wcf.

Проблема, с которой я сейчас сталкиваюсь, состоит в том, что каждый пакет содержит 1000 сообщений и что все эти 1000 сообщений кажутсяпозвонить в службу wcf сразу.Служба wcf «бомбардируется» этими сообщениями и настроена на параллельную обработку только 10 сообщений (каждый вызов должен обрабатывать данные и помещать данные в базу данных) и возвращает кучу исключений «Too Busy» обратно в BizTalk.Я настроил адаптер wcf на повторную попытку подключения через 1 минуту.

Конечный результат заключается в том, что BizTalk сначала запускает сообщения, а затем бомбардирует службу wcf всеми 1000 сообщениями, получая кучу исключений "Слишком занят", затем ждет, пока ничего не делает, пока не пройдет 1 минута, затем снова разбомбит и т. д.

Обработка была бы намного более эффективной, если бы я мог настроить BizTalk для открытия максимум 10 соединений с этой конкретной службой wcf, но, насколько я знаю, это невозможно.(Служба wcf настроена на использование net.tcp.)

Я уже пробовал регулировать настройки хоста несколькими различными способами, но он либо не помогает, либо делает приложение невыносимо медленным.Кроме того, регулирование в BizTalk, по-видимому, реализовано таким образом, что сначала он бомбардирует службу, затем замечает, что она выполняет бомбардировку, затем некоторое время ждет бездействия, а затем поднимает газ и снова начинает бомбардировку.Похоже, что лучше обрабатывать запросы / сообщения, чтобы они были более равномерно распределены во времени.Я хотел бы настроить адаптер WCF для получения максимум 4 сообщений в секунду, например.Возможное регулирование теперь говорит примерно так: через скользящее окно в 5 секунд я хочу активировать регулирование, если имеется более 20 сообщений.Но это не то же самое, потому что это позволяет эффект "взрыв".

Есть идеи, как я могу улучшить пропускную способность?

Answer 1

Используйте шаблон синглтона BizTalk .Это безобразноНо элегантная архитектура BizTalk создает уродство, когда встречается с реальным миром.

Answer 2

Для адаптеров WCF на основе SOAP, HTTP и HTTP вы можете использовать параметры connectionManagement и ограничить число подключений там.Вы можете точно указать, сколько одновременных соединений разрешено каждому экземпляру хоста BizTalk. Настройка SOAP, HTTP и HTTP-адаптеров WCF на основе одновременных подключений

Примечания:

1. Это ограничивает количество подключений на ХостInstance .Таким образом, если у вас есть несколько портов отправки на разных хостах или у вас есть несколько экземпляров хоста на хост, общее число выполненных соединений все равно может превышать это число.

2. Это только для WCAP-адаптеры SOAP, HTTP и HTTP .Не для других адаптеров WCF, как отмечено rvdginste

Answer 3

Этому вопросу уже более года, но я просто хочу добавить ответ на случай, если у кого-то возникнет такая же проблема.

Я попытался поиграть с дросселирующей конфигурацией хоста BizTalk. Это не помогло. На самом деле я не пытался использовать шаблон синглтона, потому что это то, чего я не хочу: мы создали мощную сервис-ориентированную архитектуру, которая может легко обрабатывать несколько сообщений параллельно, и я не хочу полностью отменять это, вводя шаблон синглтона .

Так что же я тогда делал? Сначала я снова подумал, что на самом деле требуется: нам нужно обработать кучу файлов, каждый из которых содержит 1000 сообщений. Порядок, в котором обрабатывается сообщение внутри файла, не имеет значения. Порядок, в котором обрабатываются файлы, важен. Обычно мы должны обработать сначала файл 1, затем 2, затем 3 и так далее. Тем не менее, он не настолько строг, порядок только для диапазонов файлов, например, сначала должен быть обработан диапазон 1-5, затем диапазон 6-8, но в пределах диапазона порядок файлов не важен. Таковы были требования.

Первое, что я изменил, вместо того, чтобы обрабатывать 1 сообщение за раз, я изменяю службу, чтобы принимать набор сообщений, чтобы я мог обрабатывать 1 файл за раз. Обрабатывая по 1 файлу за раз, происходит только 1 вызов службы WCF, что дает преимущество в том, что между BizTalk и службой WCF намного меньше болтовни. Однако обратите внимание, что это делает код на стороне службы WCF более сложным, поскольку каждое сообщение по-прежнему должно обрабатываться независимо от других (делает обработку ошибок более сложной). Если нам удастся обработать ограниченное количество файлов одновременно, мы также сможем избежать слишком занятой ошибки.

Наряду с фактической обработкой сообщений служба WCF также предоставляет вызовы для «регистрации» обработки файла. Это код на стороне сервера, который проверяет, может ли файл быть обработан в это время: он учитывает порядок файлов и гарантирует, что файл (диапазон) может быть зарегистрирован только тогда, когда предыдущий файл (диапазон) уже обработанный. Эти регистрационные вызовы пытаются зарегистрировать файл (диапазон) в цикле с ожиданием внутри. Вызов пытается зарегистрировать файл, если он не принят, он ждет, а затем пытается снова. Мне не очень нравится это решение, но оно работает.

Итак, в конце концов, у меня есть решение, которое учитывает порядок диапазонов файлов, и рядом с ним есть конфигурация того, сколько файлов можно обрабатывать параллельно. Это означает, что я больше не получаю слишком занятых ошибок. Не совсем доволен моим решением, но оно работает и очень стабильно. Прошлый год он работал без проблем.

Answer 4

Состояния регулирования хоста в BizTalk являются механизмом самосохранения для доступности самого BizTalk - я бы не стал слегка их менять.

Как и в случае с одноэлементной идеей Игала, вы можете делать грязные вещи в BizTalk, чтобы предотвратить перегрузку вашего приложения вызовами WS, но ИМХО в конечном итоге вы можете нанести ущерб масштабируемости вашего сервера BizTalk, сделав это. Может показаться, что синхронные вызовы к вашему приложению могут быть проблемой - возможно, посмотрите, как перейти к асинхронному использованию MSMQ?

Но если вы остаетесь синхронным wcf, вы также можете посмотреть эти ручки для адаптера WCF на принимающем хосте (я думаю, что вам нужно перейти к адаптеру WCF-Custom, если это еще не сделано )

Answer 5

Я использовал шаблон Instance Controller много раз, и, похоже, он работает хорошо. Идея состоит в том, что вы оборачиваете свое реальное сообщение в полезную нагрузку оркестровки. Когда пришло время позвонить в ваш сервис, вы вместо этого передаете его в оркестровку, которая обезвоживает, если запущено слишком много оркестровок. Это простая концепция, и она хорошо работает.

Я скажу, что блог очень * устарел .. но идея работает.