通信协议的可维护性 - 重叠或单个请求

本文关键字：单个 请求 重叠 可维护性 通信协议 | 更新日期: 2023-09-27 18:32:19

我目前正在将一个有点广泛的通信协议重新加工成更容易使用的东西，这是一个固执己见的问题，但根据您的经验，随着代码变得越来越大，这两个想法中的哪一个更容易维护。

有一个客户端和一个服务器。服务器具有客户端可能需要的信息片段，A，B，C，D等。一条信息不是一组数据，如名称，而是名称列表。通常为列的全部内容。客户通常会希望这些东西成组，如ABC，DEF，ABD等。没有大量的重叠（这意味着，通常 80% 的 A 请求也是对 B 和 C 的请求）。

随着系统变得越来越大，维护通信协议工作的系统是否更容易

，例如： 
Request 1: Server returns ABC
Request 2: Server returns ABD

或

Request 1: A
Request 2: B
Request 3: C

等

我倾向于使用第一个，因为它似乎使代码更容易阅读和使用，并且对组（如 ABC）有特殊请求通常可以让服务器在其数据库上运行更少的查询以获取所需的信息。但是代码库将变得比现在大得多，并且由于我已经花时间彻底检查客户端和服务器的通信方式，我想听听这里的人们对非此即彼方法的一些经验。

编辑：请注意，我不仅在谈论网络流量，而且还在谈论服务器如何处理这些请求之类的事情。如果客户端发出三个单独的请求，服务器将不得不进行三个数据库查询，因为分组请求很可能作为单个查询运行。

通信协议的可维护性 - 重叠或单个请求

我认为这是一个"过早优化"的情况。

  1. 您不知道是否真的会出现性能问题。
  2. 你要的是你所说的更复杂的代码，用于感知到的性能问题。
  3. 实际上，第二个选项的性能可能更差（考虑哪个更重 - 接受连接并处理请求，还是发送稍长的响应）？

现在，您更有可能发现任何瓶颈或性能问题都可能与您查找此信息的位置（例如，在数据库中）有关。在这种情况下，您可以在不影响协议的情况下调整该端的性能（例如，您可以缓存数据库返回的值）。

（

2）会更简单，但（1）效率要高得多，而且没有那么复杂。我会选择（1）。它为您提供最佳的长期战略。

当您考虑它时，请求输入是 （2） 中的 T 或 （1） 中的 T[]。使用数组并不复杂。

好吧，如果性能不是问题，你应该保留更简单的协议，它将提供你需要的一切，并保持代码更小更整洁。

如果性能是一个问题 - 它有多大的问题？这足以保证增加的复杂性吗？

相关文章：