SOA应用程序中的SOA性能

Question

我正在为一个传统的后端(假设一个Django实例管理一切)和一个类似于LinkedIn的web应用程序的面向服务的体系结构之间的决定而苦苦挣扎。我的意思是SOA有一个完全独立的数据访问接口(比方说Ruby + Sinatra )，它查询数据库，一个独立的聊天应用程序Twisted，通过其API使用Twisted，一个Django web服务器使用这些API来服务内容，等等。

我可以看到只有通过API才能对项目中的所有内容进行模块化和访问的优点:可伸缩性、测试等。然而，这难道不会损害站点的性能吗？我想所有模块都会通过HTTP请求进行通信，所以，这个框架会给站点中的所有内容增加很多延迟吗？有比HTTP更好的选择吗？

第二，关于开发的易用性，这真的会给我们的开发人员增加很多复杂性吗?特别是在第一阶段，直到我们得到了一个MVP。

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

Answer 1

简单地说，是的，SOA无疑将封装和可重用性转换为延迟。长话短说，这取决于你是如何做到的。

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

HTTP有其他的选择，但是如果您要使用自定义的东西，您需要问自己，为什么要使用服务？你为什么不直接使用库，完全避开网络层呢？

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

这在很大程度上取决于项目的规模。你是一支由1-3名开发人员组成的团队吗？或者你是一家拥有20-100个开发人员的企业，他们都需要想出一种方法来划分一个项目，而不需要互相影响？