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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Но если вы остаетесь синхронным ФОС, вы также можете посмотреть на these knobs для адаптера WCF на вашем посыл хосте (я думаю, что вам нужно, чтобы перейти через к WCF-пользовательский адаптеру, если не уже)

Answer 4

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

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

Answer 5

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

Примечания:

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

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