blocks|key|3678658|text|可伸缩性和性能是两回事。是的，基于服务的方法确实增加了网络协议的开销，但对于能够在域中的任何应用程序中快速采用经过良好测试的服务的好处来说，这是最小的牺牲。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3678659|如果网络开销破坏了您想要构建的系统，那么显然SOA对您来说是错误的选择。请记住，并不是任何时候都必须通过HTTP访问服务。我想你会惊讶于某些协议(如net.tcp)能有多快。|offset|length|style|CODE|3678660|entityMap^0|0|22|7|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Scalability and performance are two separate things. Yes, a service based approach does add the overhead of a network protocol, but this is a minimal sacrifice for the benefits of being able to rapidly adopt well-tested services in any application on the domain.

If the overhead of the network is a deal-breaker for the system you want to build then clearly SOA is the wrong choice for you. Remember that not ever service must be accessed over HTTP. I think you would be surprised how fast some protocols (like <code>net.tcp</code>) can be.

blocks|key|458970|text|请记住，您可以向外扩展web服务以在多个服务器上运行，而不会影响客户端。这在紧密耦合的系统中不能很好地工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|458971|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Remember that you can scale out a web service to run on multiple servers, without affecting the clients. That doesn't work so well with a tightly-coupled system.

blocks|key|4524019|text|设计合理的SOA允许系统中的每个组件独立于所有其他组件工作，并异步并行运行，因此性能和可伸缩性(两个不同的东西)都只受到系统中最慢/最不可伸缩的部分的限制，而不是所有组件串行执行所需的总时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4524020|然而，SOA并不适合所有的解决方案，所以如果您看不到对您的特定情况有任何明显的好处，那么可能没有任何好处。|4524021|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A properly-designed SOA allows each component in the system to work independently of all the others and run asynchronously in parallel, so both performance and scalability (two different things) become limited only by the slowest/least scalable piece in your system, rather than the total time it takes for all components to execute in serial.

SOA is not appropriate for all solutions though, so if you don't see any clear benefit for your particular case, then there may be none.

blocks|key|459001|text|Web服务不会免费为您提供可伸缩性。事实上，构建一个不能伸缩的服务非常容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|459002|它们为您提供了构建可伸缩性的机会。而且，通过定义良好的服务接口，您可以在需要时用更好的实现替换出服务的快速、肮脏、不可伸缩的实现。|459003|重要的是不要忘记“SOA”中的“A”。你可以通过随意创建一堆服务来搞得一团糟。确保你有一个架构。|459004|迈向可伸缩性的一大步是从基本的同步查询/响应类型服务(如SOAP+RPC)转向异步服务。参见Hohpe和Woolf的“企业集成模式”|459005|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Web services don't give you scalability for free. In fact it's pretty easy to build a service that won't scale.

What they do give you is opportunities to build in scalability. And, by having well defined service interfaces, you can swap out a quick-and-dirty non-scalable implementation of a service with a better implementation when you need it.

The important thing is not to forget the 'A' in 'SOA'. You can make a huge mess by just wantonly creating a bunch of services. Make sure you have an architecture.

One huge step towards scalability is moving away from the basic, synchronous, query/response type services (such as SOAP RPC), towards asynchronous services. See Hohpe and Woolf's 'Enterprise Integration Patterns'

blocks|key|459091|text|RESTafarians会提醒您REST不是一个原型--它是一种架构风格。REST是一种直接使用HTTP来提供服务模型的方法，而不使用SOAP使用的包装器。REST更接近SOAP的线路。单凭这一点并不能让其中一个变得更好，它们都有自己的位置。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|459092|服务模型的可伸缩性与“服务”(在大写为W和大写S的Web服务中)的可伸缩性并不是直接相关，而是与这些服务的无状态特性直接相关。构建良好的Web应用程序也是可伸缩的，可以说与任何服务驱动的体系结构一样具有可伸缩性。|459093|这两个模型之间的区别之一是，没有“服务”的Web应用程序与同一进程中的引用模块以二进制级别进行交互--不需要序列化。Web服务(SOAP或REST)引入了某种程度的序列化，从而增加了开销。然而，考虑到它提供的重用，这种开销通常被认为是值得的(即，在内部驱动应用程序的相同Web服务也可以用来让业务合作伙伴满意)。|459094|一个好的体系结构是公开服务类(而不是Web服务，它很快就会变得令人困惑！在此上下文中的服务是指为低级业务流程提供服务的类)，这些类直接在流程中为本地应用程序提供服务--利用与此服务进行二进制对话的能力。但是，对于业务合作伙伴和其他服务用途，可以在这些经过测试的服务类之上添加一个薄的Web服务层，以提供与Web服务相同的服务层。|459095|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

RESTafarians will remind you that REST isn't a prototol--it's an architectural style. REST is a way to use HTTP directly, without the wrappers that SOAP uses, to provide a services model. REST is much closer to the wire that SOAP. That alone doesn't make one better than the other, they both have their place.

The scalability of a services model isn't so much directly related to "services" (as in Web Services with a capital W and a capital S) than it is to the stateless nature of these services. Well built Web apps are also scalable and could be argued to be as scalable as any services-driven architecture. 

One of the differences between the two models is that the Web app without "services" is interacting with referenced modules living in the same process at a binary level--no serialization necessary. Web services (SOAP or REST) introduces some level of serialization that adds overhead. This overhead though, is often deemed worthly given the resuse it provides (ie, the same Web services that drive your apps internally can also be used to make business partners happy).

One good architecture is to expose the service classes (not Web services, it can get confusing quickly! Services in this context means the classes that are serving low-level business process) to your local apps directly in process--exploiting the ability to talk to this services binarily. But then, for business partners and other services uses, put a thin Web services layer over these already-tested service classes to offer the same services layer available as Web services.

blocks|key|3678769|text|好的，那么让我们先定义一下“可伸缩性”。几乎所有的东西都可以扩展:如果你需要更多的容量，你可以简单地投入更多的硬件。但有些架构“更具伸缩性”--这是什么意思？它与成本有关:如果单位新增容量的成本较低，则架构“更具伸缩性”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3678770|在任何架构中，可伸缩性通常有三个范围:第一部分有固定的成本，因此在一段时间内，它与斜率为0呈线性关系；超过这一点，斜率会增加，并且在某些时候，通常增加容量是非常昂贵的。|3678771|如果描述单位增加容量的成本的函数在很大范围内大致是线性的，我们说一个系统是“线性可扩展的”。显然，这个斜率越小越好。|3678772|所以，现在，当有人问到SOA、SOAP或REST或其他任何东西的“可伸缩性”时，这就是他们在谈论的问题。|3678773|面向服务的体系结构被称为“更可伸缩的”，因为添加更多的容量相对便宜，即使如您所说，可能会有一些开销使您需要更多的容量来为单个用户提供服务。这是因为管理大型系统的很大一部分成本和复杂性来自于维护会话状态的需求，即跟踪调用之间发生的事情。面向服务的体系结构通过使每个调用与下一个调用相对独立来避免这种情况，RESTful体系结构是限制情况--所有会话状态都编码在表示中，因此系统的其余部分不需要知道它。当您想要添加容量时，所需做的就是添加另一台服务器；简单的负载平衡将足以将消息路由到新的服务器。|3678774|(请注意，这本质上也具有更强的容错性:如果一台服务器死机，另一台服务器或多或少会自动获得请求，并且不会丢失任何会话。)|3678775|需要大量会话状态的体系结构，如一些J2EE系统，往往伸缩性较差，因为您需要大量额外的复杂性来管理会话状态。|3678776|您在基于CGI的旧体系结构中看到的那种限制情况是，每个用户会话都需要一个完整的重量级进程；我见过这样的系统，其中fork/exec占负载的40-50%25，需要有一个复杂的软件负载平衡装置来确保请求始终到达持有会话的计算机，并且进程槽耗尽是一个主要问题。其中一个这样的系统需要购买一个全新的高端Starfire服务器来增加容量。|3678777|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

Okay, so let's define "scaleability" first. Most anything will scale: if you need more capacity, to a first approximation, you can simply throw more hardware at it. But some architectures are "more scaleable" — what does that mean? It has to do with cost: an architecture is "more scaleable" if the cost per unit of added capacity is less. 

Scaleability in general has three ranges in any architecture: there's a fixed cost for the first part, so over an interval it's linear with a slope of 0; past that point the slope increases, and at some point usually adding capacity is very expensive.

We say a system is "linearly scaleable" if the function describing cost per unit of added capacity is roughly linear over a large range. Obviously, it's desirable for that slope to be less.

So, now, when someone asks about the "scaleability" of an SOA, SOAP or REST or whatever, that's what they're talking about.

Service-oriented architectures are said to be "more scaleable" because adding more capacity is relatively inexpensive, even though, as you say, there may be overhead that makes you need more capacity to service a single user. This is because a big part of the cost and complexity of managing a big system comes from the need to maintain session state, that is, keep track of what's going on between calls. Service-oriented architectures avoid that by making each call relatively independent of the next, with RESTful architectures being the limiting case -- all the session state is encoded in the representation, so the rest of the system doesn't need to know about it. When you want to add capacity, all you need to do is add another server; simple load balancing will be sufficient to route messages to the new one.

(Notice this is also inherently more fault tolerant: if a server dies, the other more or less automagically get the requests, and there's no session to lose.)

Architectures that require lots of session state, like some J2EE systems, tend to scale less well, as you need lots of extra complexity to manage session state.

The sort of limiting case, which you saw in old CGI-based architectures, is the one where each user session requires a full heavyweight process; I've seen systems in the field where fork/exec was 40-50 percent of the load, where there needed to be a complicated software load-balancing rig to make sure that requests always got to the machine that held the session, and where simply running out of process slots was a major issue. One such system required buying a whole new high-end Starfire server to add capacity.

Whenever someone talks about a services-based architecture, they often mention scalability, often in the same breath. However, it seems that using services adds more overhead, rather than reducing it, since there is now a protocol, like SOAP or REST, involved. So, does a web services based architecture really add performance benefits as the number of users of, say, a web application, scales by perhaps an order of magnitude? Or are the scalability requirements simply offloaded onto the services, rather than the core application?

How scaleable really is a web-services based architecture?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

每当有人谈到基于服务的体系结构时，他们经常提到可伸缩性，通常是相提并论的。然而，使用服务似乎增加了更多的开销，而不是减少开销，因为现在涉及到一种协议，如SOAP或REST。那么，当web应用程序的用户数量以可能的数量级扩展时，基于web服务的体系结构真的会增加性能优势吗？或者只是将可伸缩性需求转移到服务上，而不是核心应用程序上？

问基于web服务的架构到底有多大的可伸缩性？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问基于web服务的架构到底有多大的可伸缩性？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问基于web服务的架构到底有多大的可伸缩性？
EN