我的问题与正在处理的应用程序架构有关。目前，我们在每个盒子上本地安装服务器，服务器从客户端获取数据并对其进行某种处理，然后根据输出数据生成输出并打印收据，并将输出数据存储在中央数据库中每小时从本地服务器上的客户端上传。
我担心在每个客户端机器上本地安装服务器是一种好习惯，还是拥有集中式服务器的最佳方法。当被问及时，有人建议如果我们使用集中式服务器而不是延迟，速度和带宽将成为考虑因素，因为每个客户端请求都会到达服务器，从而增加执行时间，减少带宽和延迟也会受到严重影响。
笔记：
应用业务线是运输和供应链物流，应用程序生成从源头到目的地运输包裹所需的所有路线、评级和其他标签相关信息。前任。Apple、Dell 运送了数百万个包裹，因此这台服务器完成了生成标签、路由和评级详细信息的所有工作......希望这会让图片更清晰 :)
这里客户端处理数以百万计的事务，因此请求命中率非常高。
谢谢。
客户端-服务器环境（包括 Web）各有利弊，因此应用程序的上下文至关重要。在您的方案中，您有分布式服务器，因此工作负载是平衡的。但是，在维护每台服务器（软件、操作、可靠性等）方面，您会做噩梦。集中式服务器可以提供更好的维护/监控/等，但也会增加工作量。
您的情况的答案很大程度上取决于您的应用程序的需求。虽然数以百万计的事务听起来很多，但设计良好的应用程序可以相当合理地处理这些负载。但是，您可能会在这些事务请求中发送大量数据，这可能会使该过程繁重且不可靠。同样，应用程序上下文非常重要。
根据您提供的注释，听起来好像有一些本地服务器处理可以处理实时事务，但是按计划将处理/汇总的数据异步加载到中央数据库。这当然不是一个糟糕的方法，尽管它确实增加了环境的复杂性。
如果您可以提供有关您的应用程序的更多详细信息，我将很乐意编辑我的回复。
希望这可以帮助。
这取决于您拥有什么样的系统以及您的要求是什么。
集中式服务器模型的优点之一是您可以独立扩展客户端的数量和服务器的数量，以充分利用您的硬件，并且它还允许在您的一台服务器发生故障时提供冗余。例如，SOA 环境中的 Web 服务适合这种模型。这确实会增加延迟，如果您有带有 SLA 的实时系统，需要在几毫秒范围内做出响应，那么这可能不是可行的方法。
因为看起来您的响应时间比现在的响应时间要快，所以您现在拥有的可能是一个相当合理的解决方案。
如果您正在寻找一种更接近实时的方法，那么按计划将数据同步回数据库可能会有所不同，也许消息队列会起作用。这可能也会使事情变得更简单一些。
这两种方法都可以成功。
存储转发系统的缺点是您不会在装运站的中心位置获得最新信息。更全连接的集中式系统的技术缺点不一定是带宽和事务吞吐量，因为可以通过更多资源来缓解这些问题（这是成本问题，而不是技术问题），但是全连接系统具有更多故障点并且没有本地后备选项。
在成本方面，虽然较胖的客户端具有较低的带宽成本，但管理客户端会增加管理成本。通常，可以减轻的管理成本是劳动力成本和支持成本，它们通常超过商品技术成本。
正如其他人所说，这一切都取决于你在做什么。
然而，最重要的事情是你跨越机器边界的次数。如果你能把它减到最小，你的身体就会很好。一般来说，我会尽可能避免使用 RPC 机制，因为这将是两个机器边界交叉 :)
在每台本地机器上都有一个“服务器”的问题很简单——你如何保持一致的状态？
Also, your network topology will be an important factor. If everything's on a local subnet (ideally on the same switch), latency won't be an issue unless you have horribly designed network code. If you're going over the cloud, it's a different story.