每当有人谈论基于服务的架构时，他们经常会提到可扩展性，而且往往是同时提到的。但是，似乎使用服务会增加而不是减少开销，因为现在涉及到一个协议，如 SOAP 或 REST。那么，当 Web 应用程序的用户数量增加一个数量级时，基于 Web 服务的架构真的会增加性能优势吗？还是只是将可扩展性需求转移到服务上，而不是核心应用程序上？
cdeszaq
问问题
562 次
6 回答
3
可扩展性和性能是两个不同的东西。是的，基于服务的方法确实增加了网络协议的开销，但对于能够在域上的任何应用程序中快速采用经过良好测试的服务的好处而言，这是最小的牺牲。
如果网络的开销对您要构建的系统来说是一个交易破坏者，那么显然 SOA 对您来说是错误的选择。请记住，并非必须通过 HTTP 访问任何服务。我想您会惊讶于某些协议（如net.tcp）的速度有多快。
于 2009-03-12T13:56:22.033 回答
2
请记住，您可以扩展 Web 服务以在多个服务器上运行，而不会影响客户端。这对于紧密耦合的系统来说效果不佳。
于 2009-03-12T14:03:52.920 回答
1
正确设计的 SOA 允许系统中的每个组件独立于所有其他组件工作并异步并行运行，因此性能和可扩展性（两个不同的东西）仅受系统中最慢/最不可扩展的部分的限制，而不是所有组件串行执行所需的总时间。
SOA 并不适用于所有解决方案，因此如果您没有看到对您的特定情况有任何明显好处，那么可能没有任何好处。
于 2009-03-12T13:57:36.740 回答
1
Web 服务不会免费为您提供可伸缩性。事实上，构建一个无法扩展的服务非常容易。
它们给你的是建立可扩展性的机会。而且，通过具有良好定义的服务接口，您可以在需要时将服务的快速且肮脏的不可扩展的实现换成更好的实现。
重要的是不要忘记“SOA”中的“A”。随便创建一堆服务就可以搞得一团糟。确保你有一个架构。
朝着可伸缩性迈出的一大步是从基本的、同步的、查询/响应类型的服务（例如 SOAP RPC）转向异步服务。参见 Hohpe 和 Woolf 的“企业集成模式”
于 2009-03-12T14:04:45.913 回答
0
RESTafarians 会提醒您，REST 不是一种协议——它是一种架构风格。REST 是一种直接使用 HTTP 的方式，无需 SOAP 使用的包装器来提供服务模型。REST 更接近于 SOAP。仅凭这一点并不能使一个比另一个更好，它们都有自己的位置。
服务模型的可伸缩性与“服务”（如在具有大写 W 和大写 S 的 Web 服务中）没有直接关系，而是与这些服务的无状态性质直接相关。构建良好的 Web 应用程序也具有可扩展性，可以说与任何服务驱动架构一样具有可扩展性。
两种模型之间的区别之一是，没有“服务”的 Web 应用程序以二进制级别与生活在同一进程中的引用模块进行交互——不需要序列化。Web 服务（SOAP 或 REST）引入了某种级别的序列化，增加了开销。但是，考虑到它提供的重用，这种开销通常被认为是值得的（即，在内部驱动您的应用程序的相同 Web 服务也可以用来使业务合作伙伴满意）。
一种好的架构是将服务类（不是 Web 服务，它会很快变得混乱！在这种情况下，服务是指服务于低级业务流程的类）直接在进程中向本地应用程序公开——利用谈话的能力二进制到这个服务。但是，对于业务合作伙伴和其他服务用途，在这些已经测试过的服务类之上放置一个薄的 Web 服务层，以提供与 Web 服务相同的服务层。
于 2009-03-12T14:21:28.070 回答
-2
好的，让我们首先定义“可扩展性”。大多数东西都会扩展：如果你需要更多的容量，大致上，你可以简单地投入更多的硬件。但有些架构“更具可扩展性”——这是什么意思？它与成本有关：如果每单位增加容量的成本较低，则架构“更具可扩展性”。
在任何架构中，可扩展性通常具有三个范围：第一部分有固定成本，因此在一个区间内它是线性的，斜率为 0；超过那个点，斜率会增加，并且在某些时候增加容量通常是非常昂贵的。
如果描述每单位增加容量的成本的函数在大范围内大致呈线性，我们就说系统是“线性可扩展的”。显然，希望该斜率更小。
所以，现在，当有人问起 SOA、SOAP 或 REST 或其他任何东西的“可扩展性”时，这就是他们所说的。
面向服务的架构被称为“更具可扩展性”，因为添加更多容量相对便宜，尽管正如您所说，可能存在开销使您需要更多容量来为单个用户提供服务。这是因为管理大型系统的大部分成本和复杂性来自维护会话状态的需要，即跟踪调用之间发生的情况。面向服务的体系结构通过使每个调用相对独立于下一个调用来避免这种情况，RESTful 体系结构是限制情况——所有会话状态都在表示中编码，因此系统的其余部分不需要知道它。当您想增加容量时，您需要做的就是添加另一台服务器；简单的负载平衡足以将消息路由到新的消息。
（请注意，这本质上也更具容错性：如果一个服务器死了，另一个服务器或多或少会自动获取请求，并且不会丢失任何会话。）
需要大量会话状态的体系结构（如某些 J2EE 系统）往往无法很好地扩展，因为您需要大量额外的复杂性来管理会话状态。
您在基于 CGI 的旧架构中看到的那种限制情况是每个用户会话都需要一个完整的重量级进程。我见过一些系统，其中 fork/exec 占负载的 40-50%，需要一个复杂的软件负载平衡装置来确保请求总是到达举行会话的机器，以及在哪里简单地用完进程槽是一个主要问题。一个这样的系统需要购买一个全新的高端 Starfire 服务器来增加容量。
于 2009-03-12T14:13:30.540 回答