Вопросы архитектуры: подход централизованного сервера v / s локализованный сервер

Question

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

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

Примечание:

Сфера деятельности приложения - логистика доставки и цепочки поставок, приложение генерирует всю информацию о маршрутизации, рейтинге и другой информации, связанной с этикеткой, которая необходима для доставки посылки из источника в пункт назначения. Ex. Apple, Dell поставляют миллионы и миллионы пакетов, и поэтому этот сервер выполняет всю работу по генерации меток, маршрутизации и рейтинговых деталей ... Надеюсь, это сделает картину более четкой:)

Здесь клиент обрабатывает миллионы и миллионы транзакций, поэтому соотношение количества запросов очень велико.

Спасибо.

Answer 1

Как уже говорили другие, все зависит от того, что вы делаете.

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

Проблема с наличием «сервера» на каждом локальном компьютере проста - как вы поддерживаете согласованное состояние?

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

Answer 2

Это зависит от того, какая у вас система и каковы ваши требования.

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

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

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

Answer 3

Оба подхода могут успешно работать.

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

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

Answer 4

Клиент-серверные среды (включая Интернет) имеют свои преимущества и недостатки, поэтому контекст вашего приложения имеет решающее значение. В вашем сценарии у вас есть распределенные серверы, поэтому рабочая нагрузка сбалансирована. Однако у вас есть кошмар с точки зрения обслуживания каждого сервера (программное обеспечение, операции, надежность и т. Д.). Централизованный сервер обеспечивает лучшее обслуживание / мониторинг и т. Д., Но также несет повышенную рабочую нагрузку.

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

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

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

Надеюсь, это поможет.