Web 应用中的 SOA 性能答案

【问题标题】：SOA performance in a webappWeb 应用中的 SOA 性能
【发布时间】：2015-09-16 17:16:27
【问题描述】：

我正在为在传统后端（比如说管理一切的 Django 实例）和面向服务的架构（类似于 LinkedIn）的 Web 应用程序之间做出选择而苦苦挣扎。我对 SOA 的意思是有一个完全独立的数据访问接口——比如说 Ruby + Sinatra——查询数据库，一个独立的聊天应用程序——Twisted——通过它的 API 使用，一个 Django Web 服务器使用这些 API 为内容等。

我可以看到将项目中的所有内容模块化并仅通过 API 访问的优势：可扩展性、测试等。但是，这不会损害网站性能吗？我想所有模块都将通过 HTTP 请求进行通信，所以 这种架构不会给网站中的所有内容增加很多延迟？有比 HTTP 更好的替代方案吗？

其次，关于开发的便利性，这真的会给我们的开发人员增加很多复杂性吗？尤其是在我们获得 MVP 之前的第一阶段。

编辑：我们是一个由两名开发人员和一名设计师组成的小型团队，但我们没有最后期限，因此如果能带来更多技术价值，我们可以处理一些额外的工作

【问题讨论】：

另一种方法是将您的代码模块化，您将在不同的存储库中添加一个 RESTful 接口，然后使用您的包管理器将其引入。这迫使您考虑如何在没有真正基于网络的 API 的延迟的情况下与之交互。这样做的好处是，如果您以后确实希望向其添加 API，这样做很容易，因为您还没有将应用程序和模块焊接在一起。

标签： django web architecture flask soa

【解决方案1】：

简短的回答，是的，SOA 肯定会用封装和可重用性来换取延迟。答案很长，这取决于（一如既往）你是如何做到的。

延迟对您的应用程序的影响程度与您的服务的精细程度成正比。如果您提供非常细粒度的服务，您将不得不进行数百次顺序调用来组装用户体验。如果你做的是极其粗粒度的服务，你将不会从你的服务中获得任何可重用性；因为它们与您的应用程序的耦合过于紧密。

有 HTTP 的替代方案，但如果您要使用定制的东西，您需要问自己，您为什么要使用服务？为什么不直接使用库，完全避开网络层？

从 API 开始，您肯定会增加项目的成本和复杂性。这必须通过 API 为您提供的灵活性来平衡。在这种情况下，您可能会从内部将 API 结构化到您的代码库中受益，但只是将它们作为模块调用。或者构建库而不是独立的 API。

这在很大程度上取决于您的项目有多大。你是一个由 1-3 名开发人员组成的团队，想要获得你的 MVP 吗？或者您是一家拥有 20 到 100 名开发人员的企业，他们都需要想办法在不互相干扰的情况下划分项目？

【讨论】：

使用 RabbitMQ 之类的东西在服务之间进行 UDP 通信怎么样？如果我们所有的节点都托管在同一个地方，这将解决延迟问题。
如果您的所有节点都托管在同一个地方，请使用本地环回地址，并保留 HTTP。我经常使用这个想法，但扩展范围通常会胜过单体部署。