IBM 的 Kyle Brown 在其评论文章开始描述了一种常见的情景：“许多人因以不恰当的方式使用Web 服务和XML 而给他们自己挖了一个坑”。在他的评论中，Kyle 介绍了三个常见的痛点，解释了它们为何会发生并提供了一些替代方法。
我的消息吃了我的服务器！ Kyle 指出，通常，Web 服务开发者开始经历“内存溢出”的错误或者奇怪的“性能问题”时，总是会发现服务器拥有极高的处理负载，CPU 使用率接近 100%，以及较低的吞吐量和高网络延迟。导致这些症状的典型原因是非常大的（有时会达到 50 MB 或者更大）消息。而且，这些大消息往往包含了非常大的、作为 XML 消息主体的、采用 base-64 编码的二进制编码信息。导致其发生的原因通常是：
……开发者不理解技术的局限性：XML 处理对解决许多问题都有用，但是你必须认识到消息是要被解析的——并且在大多数……产品中，这就意味着许多或者所有的消息都会驻留在内存中。
Kyle 建议采用如下方法来改善这种情况：
- 不要发送冗余信息。在许多情况下，发送二进制数据时，你可能会发现消息高度重复。如果是这样，你可能就要考虑在 HTTP 层面使用压缩技术来改善你的网络延迟。虽然这不会帮助你处理负载，但可能有助于减轻其中一个问题。
- 在 XML 消息体中，根本不要嵌入二进制信息。这是较好的解决方法，还有几种不同的途径可以实现这一效果。比如，你可以使用带有附件的 SOAP 或者消息传输优化机制（MTOM）绕过解析开销，尽管这无助于网络延迟问题。
- ……还有一个更好的办法，使用 SOAP 根本不发送大的二进制 blob。替代方法，通过受控的文件传输系统，使用一个“带外数据”传输……或者“声明标签（claim Check，参见《EIP 模式》或这里）”模式，避免在 SOAP 和 HTTP 上发送大的二进制文件。
不好意思，你的数据正在显示。根据 Kyle 所说，另一个典型的 Web 服务的“性能问题” 是，使用 Web 服务的层面非常、非常低——通常 Web 服务跟一个 SQL 语句相关，这是因为：
误解了 SOA 架构原则。一个优秀 SOA 架构的关键原则是你的服务应该具有高复用性。
根据 Kyle 所说，这些情况通常发生在：
……如果设计是根据现有代码“自上而下”衍生出服务，这类服务就会出现；通常，开发者会看着他们现有的架构图并且决定将架构中的每一层（包括表现层）转变成服务集。
相反，在 SOA 架构的正确位置使用粗粒度的 Web 服务会更好。再次强调，检查一个架构的标准分层模型，通常在架构中会有一个明确定义的地方已经封装了系统业务逻辑。可以使用“远程门面模式（Remote Facade Pattern）”来包装这些服务，以便用合适的方式来暴露基于模型的服务。
模式（Schema）？我们不需要任何发臭的模式！ Kyle 指出，通常开发者试图重用现有代码来生成和解析作为 Web 服务实现基础的 XML。这些实现通常使用 XML 解析器来编组 / 解组消息，同时使用 Java HTTP 类来发送和接收 XML 文档。使用 Web 服务时，通用的方法是，创建使用模式元素的 WSDL 文档，使 XML 不受阻地通过，然后在现有代码中对它们进行解析。
这个问题的症状是组织没有看到 SOA 承诺的好处，而且维护他们的解决方案似乎比以前使用 Web 服务的时候更难（而不是更容易）
简单的解决方案是，每当写 Web 服务时，不管使用 WS-* 标准还是使用 REST 方法，都要确保你创建了代表你文档结构的完整准确的 XML 模式。
如果你正在构建 WS-* Web 服务，那么这个 XML 应该被包含在描述你的 Web 服务的 WSDL 之中。即使你在使用 REST 方法，拥有易于访问的 XML 模式将鼓励你的服务被重用。
避免 Kyle 描述的陷阱似乎是个常识。不幸的是，我们的业界证明了，除非很好的理解和治理 SOA 实现，否则我们会继续一次又一次地重复犯同样错误。
查看英文原文： Avoiding Three Common Mistakes when Implementing XML and Web Services
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论