Предложения по разработке службы Windows с C # - PullRequest
0 голосов
/ 12 сентября 2009

Я занимаюсь разработкой распределенного приложения, в котором на каждом распределенном сайте будет запущено 2-уровневое клиент-серверное приложение на основе winform (есть конкретные причины не заходить в веб-архитектуру). Локальный сервер приложений будет отвечать за связь с центральным сервером, а локальные рабочие станции, в свою очередь, будут связываться с локальным сервером.

Я собираюсь разработать одну или несколько служб Windows для достижения следующих целей. Я предполагаю, что некоторые из них будут работать на локальном сервере, а некоторые на локальных рабочих станциях. Центральный сервер - это просто база данных SQL Server, поэтому с этой стороны не нужно разрабатывать никаких служб, только операторы DML будут запускаться с локального сервера.

Цели службы Windows

  1. Синхронизация локальных данных с данными с центрального сервера (оба конца SQL Server) по расписанию
  2. Автоматическое резервное копирование базы данных по расписанию
  3. Автоматическая загрузка обновлений программного обеспечения с сайта поставщика по расписанию
  4. Обеспечение управления лицензиями на программное обеспечение путем мониторинга подключенных рабочих станций
  5. Обмен сообщениями в интрасети между рабочими станциями и / или локальным сервером (например, немного более богатая утилита NET SEND)
  6. Управление развертыванием обновлений с локального сервера на рабочие станции

Хотя у меня есть что-то на уме, я немного запутался в принятии решения, и мне нужно перепроверить свои мысли у таких экспертов, как вы. Ниже приведены мои запросы -

  1. Сколько служб должно работать на локальном сервере? Пожалуйста, укажите отдельные сервисные роли.

  2. Сколько сервисов должно работать на рабочих станциях? Пожалуйста, укажите отдельные сервисные роли.

  3. Поскольку некоторые службы должны будут запрашивать локальную базу данных SQL, откуда службы должны читать строку подключения? реестр? Конфиг файл? Любое другое место?

  4. Если один сервис выделен для выполнения нескольких задач, например, как служба планировщика, что должно быть лучшим / оптимальным способом в отношении производительности для управления запланированными задачами а. Сборка библиотек классов .NET для запланированных задач и их раскрутка в отдельных потоках. б. Сборка исполняемых сборок .NET для запланированных задач и запуск исполняемых файлов

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

Заранее благодарю всех.

Ответы [ 3 ]

2 голосов
/ 12 сентября 2009

Сколько сервисов должно работать на локальном сервере?

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

Сколько сервисов должно работать на рабочих станциях?

Я бы использовал только один, потому что это сделает его единственной точкой отказа. Пользователь заметит, если служба на рабочей станции не работает. В этом случае необходимо запустить только одну службу.

Поскольку некоторые службы должны будут запрашивать локальную базу данных SQL, откуда службы должны читать строку подключения? реестр? Конфиг файл? Любое другое место?

Обычно я бы помещал строку подключения в app.config. .NET Framework также предлагает средства для шифрования строки подключения.

Если один сервис выделен для выполнения нескольких задач, например, как служба планировщика, каким должен быть наилучший / оптимальный способ в отношении производительности для управления запланированными задачами a. Сборка библиотек классов .NET для запланированных задач и их раскрутка в отдельных потоках. B. Сборка исполняемых сборок .NET для запланированных задач и запуск исполняемых файлов

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

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

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

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

Самое важное: Не следуйте ни одному из моих советов, если вы найдете более простой способ достижения своих целей. Начните с простого дизайна. Не переигрывай! Решения с (несколькими) сервисами и расписанием, как правило, усложняются с каждой добавленной функцией. Особенно, когда вам нужно, чтобы службы общались друг с другом.

1 голос
/ 12 сентября 2009

Я не думаю, что есть один ответ на этот вопрос, некоторые, вероятно, будут использовать только один сервис, а другие будут модульно преобразовывать каждый домен в сервис и добавлять сервисы корпоративных транзакций и т. Д. Вопрос скорее в SOA, чем в C #, и вы могли бы подумать прочтите некоторые книги по SOA, чтобы найти свой шаблон.

0 голосов
/ 12 сентября 2009

Это не дает конкретного ответа на ваши вопросы, но нужно учитывать одну вещь: вы можете запускать несколько служб в одном процессе. Метод ServiceBase.Run принимает массив экземпляров ServerBase для запуска. Это технически разные сервисы, которые отображаются в диспетчере управления сервисами как таковые, но выполняются внутри одного и того же процесса. Опять же, просто что-то, чтобы рассмотреть в более широком контексте ваших вопросов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...