构建包含服务的网页的标准做法是什么
我听说过很多关于 SOA、服务等的好处。但我没有看到如何以良好的性能来实现它。
我有一个带有社交网络功能和广告的网页。我的大部分代码都纠缠在一起，但我认为广告和“推荐朋友”功能是相当独立的，非常适合类似 SOA 的方法。
我可以为这两个服务创建一个 REST HTTP 级别的 API，然后为我的主站点的每个页面请求调用。
我不希望用户等待太长时间来加载页面，如果我在请求中收到一堆数据（例如推荐的用户ID），我必须处理或搜索相关数据等，我觉得我会让事情变得更慢真正的好处。 一个相对较慢的 HTTP 调用来获取我刚刚在本地处理的内容。我刚刚将处理转移到慢速 HTTP 请求的另一端。
我能看到的唯一其他选项是在我的 html 模板上放置 iframe，其 src 指向这些外部服务。这些服务将直接返回 HTML。从而并行加载。
据说一个典型的亚马逊页面是由 150 个服务构建的，我在那里没有看到 150 个 iframe，那么他们是如何做到这一点并获得低延迟的呢？
I have heard a lot about the benefits of SOA, services, etc. But I fail to see is how it can be done with good performance.
I have a webpage with social network functionalities and advertisements. Most of my code is entangled together but I think the advertisements and the "recommended friends" functionities are pretty independent, perfect for a SOA like approach.
I can make a REST HTTP level API for these two services and call then for every page request of my main site.
I dont want users to wait too long for the page to load, if I get a bunch of data in my request (for instance recommended user id) that I have to process or search related data, etc I feel I make things slower for no real benefit.
A relatively slow HTTP call to get something I would have just processed locally. I've just moved my processing to the other side of a slow HTTP request.
The only other option I can see is toput iframes on my html templates with their src pointing to these external services. These services would return directly HTML. Thus loading in parallel.
It is said that a typical amazon page is build from 150 services, I dont see 150 iframes there so how they do that and get low latencies?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题中似乎存在一些术语的混合。首先，SOA 不仅仅是创建服务（在本例中看起来像 Web 服务）以提供数据的行为。这是一个相当复杂的架构概念（类似于 DDD、MVC 等），涉及将应用程序开发为一系列基于服务的层，在这些层中发出请求并提供服务。因此，与支持一套业务流程的大型对象图相反，您最终会得到一组相对原子的命令，从而与整个模型进行相当直接的交互。这种架构的一大好处是它的可扩展性相当好。您可以构建新的服务集，而不必不断地重新设计模型并引入新的命令/工作流程。
话虽如此，服务电话相当便宜。考虑进行服务调用的成本（1k？2k？更少？）与完整回发或网页请求（70k？100+k？）的成本。如果您需要对页面上的每个命令进行完整的发布和重定向，那么您在带宽和性能方面的成本将相当高如果您预计会有大量流量。由公司构建的系统雅虎和谷歌等公司通过将任务划分为一系列在页面加载后异步执行的命令来减少预期的等待时间和整体网络流量，从而受益匪浅。
这里的关键是这些服务调用是异步进行的。因此，从用户的角度来看，等待页面加载的时间非常少。因此，就像您在 StackOverflow 上看到的那样，您可以在后台处理您的赞成票时继续扫描问题的文本。
这是正确的方法吗？这取决于你。如果你现有的方法有效，请坚持下去。如果由于当前架构导致性能明显下降而值得花时间和精力来实施更复杂的解决方案，那么也许您应该考虑进行更改。
There seems to be a bit of mixing of terms in the question. First-off, SOA is not simply the act of creating services (web services, it looks like in this case) for providing data. It is a fairly complex architectural concept (along the lines of DDD, MVC, etc) that involves developing your application into a series of service-based tiers in which requests are made and served. So, as opposed to having large object graphs supporting a suite of business processes, you end up with a set of relatively-atomic commands that result in fairly straight-forward interactions with your overall model. One of the big benefits of this architecture is that it scales fairly well. Rather than constantly having to re-work your model and massage new commands/workflows in, you can build new sets of services.
All that having been said, service calls are fairly cheap. Consider the cost of making a service call (1k? 2k? less?) versus a full post-back or request of a web page (70k? 100+k?). If you are requiring a full post and redirect for each command on the page, you are looking at a fairly high cost in terms of bandwidth and performance if you are expecting a lot of traffic. Systems built by companies such as Yahoo and Google benefit immensely by partitioning tasks into a series of commands that are executed asynchronously after the page is loaded to reduce preceived waiting time and overall network traffic.
The big key here is that these service calls are made asynchronously. As such, from the user's perspective, there is very little time spent waiting for a page to load. So, just like you see here on StackOverflow, you can continue scanning the text of the question while your upvote is being processed in the background.
Is this the right way to go? That's up to you. If what you have works, stick with it. If it's worth the time and the ramp-up to implement a more complex solution because there is an active and perceptible degradation in performance caused by your current architecture, then maybe you should consider a change.