Шина NService: отличные проблемы развертывания - PullRequest
Новая
       7

Шина NService: отличные проблемы развертывания

1 голос
/ 29 июля 2010

Пожалуйста, рассмотрите следующие вопросы в контексте нескольких публикаций от уменьшенного издателя (с использованием хранилища подписок БД) и нескольких подписок с уменьшенными подписчиками (с помощью распространителей), где установка и удаление происходят регулярно для первоначальных развертываний, обновлений и т. Д.использование автоматических MSI.

  1. Использование хранилища подписок БД, что произойдет, если БД выйдет из строя?Если для публикации сообщения требуется доступ к БД подписки, как оно будет доставлено?Это потеряется?Будет ли вызов Bus.Publish вызвать исключение?
  2. Предполагается, что вам не нужно развертывать простои: что если вы хотите переместить базу данных подписки для определенной публикации на другой сервер?Как вы управляете переходом, подобным этому?
  3. Тот же вопрос задается дистрибьютору на стороне абонента: что, если вы хотите переместить конечную точку дистрибьютора?Один из сценариев, о котором я могу подумать: если у вас несколько подписок, использующих один компьютер-распространитель, может быть сложно переместить некоторые из них на другой сервер-распространитель, чтобы уменьшить нагрузку.
  4. Что бы установить / удалитьсценарии похожи на такую ​​установку (как изначально, так и для непрерывных обновлений)?Похоже, вы хотели бы иметь некоторые специальные сценарии установки / удаления для развертывания «логической публикации» и базы данных подписки, а также для «логических подписок» и распространителей.Экземпляры издателя не нуждаются в какой-либо специальной логике установки / удаления (поскольку они просто начинают публиковать сообщения с использованием настроенной БД подписки, а затем останавливаются при их удалении).Рабочим узлам подписчика не потребуется ничего особенного при установке, кроме правильной конфигурации конечной точки распространителя, но потребуется логика удаления, чтобы убедиться, что они удалены из списка распространителей рабочих узлов.

Ответы [ 2 ]

0 голосов
/ 01 августа 2010

На ваш первый вопрос о высокой доступности базы данных подписки вы можете использовать кластер для восстановления после отказа.Если БД не работает, Bus.Publish выдаст исключение, да.Рекомендуется хранить базу данных подписки отдельно от вашей прикладной базы данных, чтобы избежать ее отключения при обновлении приложения.Это не обязательно должен быть отдельный сервер БД, с отдельной БД на том же сервере БД все будет в порядке.

При перемещении серверов это обычно выполняется на уровне DNS, где в течение определенного периода времениОба будут работать, пока не прекратится общение.

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

0 голосов
/ 29 июля 2010
  1. В конце концов, издатель потерпит неудачу, и сообщения будут накапливаться во внутренней очереди.Вам нужно будет спланировать размер диска, который вам нужен, чтобы справиться с этим, исходя из размера сообщения и того, как долго вы хотите ожидать появления БД.Оттуда зависит, сколько времени вы можете справиться.Вы можете использовать зеркалирование или кластеризацию БД, чтобы уменьшить время простоя БД.
  2. Технологии зеркалирования и кластеризации также могут помочь в этом.Зависит от того, хотите ли вы выполнить аварийное переключение вручную или автоматически, и где вы это делаете (удаленные сайты?).
  3. Кластеризация MSMQ может помочь вам в этом.Если вы хотите удалить дистрибьютора и переместить его в кластер, все будет в порядке.Другая возможность - выставить своих дистрибьюторов по протоколу HTTP и распределить их нагрузку за программным или аппаратным решением балансировки нагрузки.За балансировщиком нагрузки вы можете более свободно перемещать вещи.
  4. Похоже, вы уже хорошо разбираетесь в этом :)
...