管理多个 OData/WCF 服务
从架构上来说，如何在不牺牲性能的情况下整合来自多个 OData / WCF 服务的数据？我正在通过服务公开 EF 上下文，并希望能够灵活地查询要查询的对象。
假设用户发起一个查询，需要联系 x 个在分布于世界各地的单独服务器上运行的单独 OData 服务。随着 x 的增加，我认为收到结果所需的时间也会增加。
有谁知道通过缓存或临时中央数据库等提高性能的方法？
目前，我正在通过按计划的时间间隔联系所有 OData 服务并启动针对该中央数据库的查询，将数据整合到一个 SQL 数据库中。如果可能的话，我正在寻找更好、更轻量级的解决方案。
提前致谢。
Architecturally speaking how could you consolidate data coming from multiple OData / WCF services without sacrificing performance? I am exposing an EF context over the service and want flexibility in what object(s) to query.
Say a user initiates a query that requires contacting x number of seperate OData services running on seperate servers distributed across the world. As x increases, I think the time it takes to receive the results will increase, too.
Does anyone know of ways to either improve performance through caching or some temporary central database, etc?
Currently I am consolidating data in one SQL database by contacting all the OData services on scheduled intervals, and initiating queries against this central database. I'm looking for a better and more lightweight solution, if possible.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是否可以公开一种特定于运行的查询类型的分层 Web 服务？不确定您在这里谈论的是应用程序。
为了减少延迟时间，您可以异步地从这些不同的服务请求数据（这样您就可以同时执行多个调用）。这将有助于解决您对服务数量增加的担忧。为了避免客户端代码的复杂性，请使用这个新的分层服务。
如果性能成为问题，请删除此分层服务，但保留对客户端服务的并发调用。
如果由于服务之间存在数据发送的逻辑链或其他原因而无法同时执行这些操作，那么恐怕有很多方法可以帮助您整合它们 - 除了自己更改这些服务或按照您的建议进行操作 - 收集并自己缓存数据。
更新：只是为了澄清，是的，这只是另一项服务，为您与所有独立的服务进行对话，您的客户端/应用程序将简单地使用这个服务。该服务本身可以根据您的要求封装并发调用和结果缓存。因为它是用于报告，如果数据的年龄或稍微过时的可能性不是问题，或者如果数据本质上基本上是静态的，我会同意缓存大数据块的想法。
Is it possible to expose a sort of layering web service specific to the types of queries run? Not sure if you are talking about an application here.
To reduce latency times you could ask for data from these disparate services asynchronously (so you can do multiple calls concurrently). This will help handle your concern over the number of services increasing. To avoid this code complexity at the client side, use this new layering service.
If performance becomes an issue, remove this layering service, but keep the concurrent calls to the services on the client side.
If you cannot perform the actions concurrently because there is a logical chain of data being sent between the services or whatever, then I'm afraid there is much to help you consolidate them - other than changes those services yourself or do as you suggest - collect and cache the data yourself.
Update: just to clarify, yes it would simply be another service that talks to all the separated services for you, your client / application will simply then use this one service. The service itself can encapsulate concurrent calls and result caching as per your requirements. Because it is for reporting I would agree with the caching idea for big chunks of data if the age of the data or the possibility of being slightly out of date is not an issue, or if the data is largely static by nature anyway.