5

一段时间以来，我一直在研究通过套接字传输 xml 的系统。而且我从来没有真正理解过选择 xml 而不是套接字而不是自定义协议的真正优势是什么。

但是我确实看到很多开发人员（特别是最初的 Web 开发人员）设置了这种实现方式（xml over sockets）。

我确实明白这更“人类可读”（这就是我一直听到的）。

但，

  • Xml 携带大量字符，导致大量消息，而实际上内容非常小而简单。

  • 消息大小各不相同，因此您需要保证以特定字符或字符串模式终止消息。

  • 解析xml时开销更大

由于所有这些原因，当我可以使用使用固定大小消息的自定义协议设置我的系统时，我仍然怀疑是否考虑将 XML over Sockets 用于新系统。避免传输大量消息和性能命中在客户端大小上解析 xml。

我这样想有错吗？就系统架构而言，什么是“最好的”？

问候

4

7 回答 7

6

在通过网络传输数据时，传统上使用 XML 的主要原因是它是可扩展的。它可以扩展您的应用程序并将其转变为其他应用程序在您的基础上构建的潜在平台，或者它使其他应用程序能够更轻松地与您集成，而无需解决已经解决的问题。

毕竟，这就是开发人员有偿做的事情。解决新问题。不创建它们。

Ryan Tomayko 在他的博客文章“我如何向我的妻子解释 REST”中谈到了这一点，当时他强调使用标准意味着世界各地的单个系统可以联网以形成庞大的、有凝聚力的但独立的系统。

当您使用自己的自定义协议时，您基本上将您的应用程序限制为仅在它自己的小世界中进行通信。然后，当需要将其与另一个系统粘合在一起时，两端都需要进行更多的集成工作。

话虽如此，JSON 作为 XML 的替代品开始获得很大的吸引力。它更轻量级，被多个平台理解，实际上是 Web 语言 JavaScript 的原生语言。

任何一种选择都很棒，因为您使用的东西是所有有经验的开发人员都可以轻松理解的，并且每个系统都可以使用。

于 2012-05-21T07:42:14.503 回答
4

使用自定义协议不是一个好主意，因为这意味着在开发和测试方面需要付出很多努力，而这是不必要的。此外，除非您付出大量努力以通用方式设计它，否则它将是一个特定的实现。使用 XML，传输本身不会与您的应用程序捆绑在一起。由于 XML 灵活且可扩展，它允许您更改结构和内容而不影响传输。

但是，正如您所指出的，使用 XML 有其自身的一系列缺点。确实，它涉及不必要的重量转移。但是，像 JSON 这样的替代方案将是解决这些问题的好主意。

于 2012-05-21T07:46:50.827 回答
4

这里没有“最佳”决定，这完全取决于您的要求。如果您需要非常高的性能，那么您应该使用一些带有小消息的自定义二进制协议。然而，这也带来了缺点。XML 的主要优点是它是一种非常标准化的格式，易于从各种平台和应用程序中读取。例如，使用自定义协议，您将需要实现消息的序列化和反序列化。此外，XML 比自定义格式更具可扩展性。

总而言之，这实际上取决于您系统的要求。

于 2012-05-21T07:40:49.150 回答
3

协议在套接字上运行的事实与这个问题没有直接关系。

这么多人选择将 XML 用于其协议的表示层的原因主要是因为它避免了指定和实现您自己的表示层的工作量和成本。是的，如果您想在消息大小、更改的可能性、实施成本和其他因素之间进行不同的权衡，那么您很可能能够设计出一种比 XML 更好地针对这些要求进行优化的协议。或者，考虑到很多非常优秀的人参与了 XML 设计，您可能会设计一些更糟糕的东西（通常是因为您的长期需求不是您认为的那样 - 例如，您最终可能会设计一些东西出色的表现，但变革的潜力很差）。但无论你的设计做得好还是坏，

于 2012-05-21T08:57:50.580 回答
3

设计决策都是关于权衡的。您已经列举了 XML 为您提供的东西——可读性和自我描述。它还带有描述语言（XSD），非常便携等。

但是这些优点伴随着你提到的缺点。因此，让我们一一解决：

冗长

是的，XML 很冗长，既是自描述的又是基于文本的。如果性能是一个问题，这只是一个真正的问题。是吗？积极的权衡呢？

请注意，这里一个合理的替代方案是 JSON，它同样可读但效率更高。

不同大小

是的，但这取决于连接层。如果您没有持久连接（例如 HTTP），或者您正在使用提供其自己的“框架”的协议（例如 AMQP 或 JMS），那么这不是问题 - 传输层会处理它。如果您打算重新发明这个轮子，是的，不同的有效负载会使协议变得更加困难。但是协议（尤其是所有边缘情况）已经够难了。

解析开销

这与冗长直接相关。

于 2012-05-21T07:40:08.623 回答
2

正如您所解释的那样，XML 有其自身的优点和缺点。当您想要减少网络流量的替代方案时，您可以考虑http://code.google.com/p/protobuf/压缩数据并拥有自己的编组技术。另一个在 Web 技术中广为人知的是 JSON。

在系统架构方面什么是最好的：嗯，我们需要定义它是 Web 还是企业系统集成等等。这完全取决于您设计的系统。

于 2012-05-21T07:41:20.500 回答
2

重新发明轮子从来都不是一个好主意。我会坚持使用标准 HTTP 协议并使用可互操作的数据交换格式，例如 XML 或 JSON。如果您使用行业标准协议而不是重新发明自定义协议，您会发现更多的工具和支持。这是就最佳实践而言。当然，如果您有一些非常具体的要求，则可能有充分的理由来实现更多定制的东西。

于 2012-05-21T07:37:57.293 回答