Проектирование клиент-серверной программы, вопрос дизайна (.Net)

Question

Мы разрабатываем клиент-серверную программу, и мне нужна некоторая помощь с дизайнерским решением.

Серверная часть программы будет работать как служба на нескольких серверах Windows, служба отслеживает эти серверы, при необходимости служба отправит нам отчет по электронной почте.

Клиент будет использоваться для контроля и управления службами, запущенными на серверах, но не всегда будет запущен.

Мой вопрос заключается в том, где и как я должен хранить конфигурацию для сервиса.Настройки (smtp и т.д.) Будут определены на клиенте, но службам, работающим на удаленных серверах (их может быть много), необходимо обновить настройки, а также сохранить эти настройки до тех пор, пока они снова не будут обновлены.

Я могу предложить два варианта: центральный общий ресурс Windows, откуда службы считывают настройки, или когда клиент нажимает "Сохранить", настройки сохраняются в определенном месте на каждом сервере.

Что бы вы сделали?Есть что-нибудь, о чем мне следует знать?

Спасибо

Answer 1

У меня нет опыта работы с такими сервисами, но я мог бы предложить хранить настройки в центральной базе данных, к которой все они имеют доступ.Таким образом, каждый раз, когда вы создаете новый сервер, вы создаете новую запись настроек в базе данных.

Просто включаю это в обсуждение.

Answer 2

Я разработал систему, которая включает в себя клиент и несколько серверов.Требования к моей системе включают в себя, чтобы она была очень надежной и высокодоступной (что может не соответствовать вашим требованиям).С этой точки зрения, вот несколько мыслей:

• Если вы храните настройки в центральном расположении - либо в общей файловой системе, либо в базе данных, - вы создали единую точку отказа в вашей распределенной системе.Обходным решением было бы сохранить настройки в 2 или более центральных местах.Но как вы гарантируете, что 2 или более местоположения синхронизированы?)

• Если вы сохраняете настройки на каждом сервере, что, если произойдет сбой связи клиент-сервер с одним сервером в тот момент, когда вы пытаетесь сохранить настройки, или что, если один из серверов не работает.Теперь у вас возникла ситуация, когда серверы не согласны с тем, каковы настройки.Итак, опять же, как вы гарантируете, что несколько серверов синхронизированы?

• Итак....подумайте о том, как вы можете надежно синхронизировать серверы и как они могут обнаруживать, когда они не синхронизированы.В моей системе существует схема master / slave между серверами, сердцебиения с порядковыми номерами, чтобы подчиненные устройства могли постоянно быть уверены, что они синхронизированы и не пропустили ни одного сообщения.Если мастер не работает, система деградирует, но все еще работает, так что этот мастер не является единственной точкой катастрофического отказа.

Answer 3

Здесь есть ряд вещей, которые следует учитывать.

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

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

Вы можете преодолеть это, введя множество механизмов IPC, т. е.Очереди, общая память, каналы, Сокеты между многими службами.Я бы предложил разделяемую память, если службы не распределены, или очереди на центральном сервере или базе данных, если это не так;как лучший вариант.Однако службам все еще необходимо сотрудничать, чтобы дать другим службам подсказку об обновлении параметров.