我们如何在两个不同的服务之间共享数据
我目前正在开发一项定期轮询的网络服务。它不存储其状态，并且每次查询时都会实例化。本质上，它检索其他外部实体（例如数据库）的状态并将其传递回请求者。
最近，出现了存储状态的需求，因为
- 需要从特定源持续收集数据并存储重要/相关的位，
- 需要收集特定数据源在一段时间内的聚合
我想出了以下想法：
我在这里主要关心的是我正在使用静态类（本质上是一个全局）来在两个服务之间共享数据。有更好的方法吗？
编辑：感谢您到目前为止的回复。对于这个问题的模糊性表示歉意：只是想找出跨不同服务共享数据的最佳方式是什么，并且不确定具体细节（即需要什么）。我正在开发的平台是 .NET 框架，这两个服务只是作为 Windows 服务托管的 WCF 服务。
数据库路线听起来像是最传统的方法 - 但是我现在不愿意走这条路（主要是为了部署/设置问题；除了简单地安装软件之外，它还需要创建新表等）此时传输的数据量相对较少。当然，这种情况将来可能会发生变化，此时走数据库路线可能是正确的选择。
除了添加数据库持久层还有其他办法吗？
I am currently working on a web service which is periodically polled. It does not store its state and is instantiated everytime it is queried. Essentially, it retrieves the state of other external entities e.g. databases and delivers it back to the requester.
Recently, the need to store state as arisen in that
- There is the need to continously collect data from a particular source and store the bits that are important/relevant
- There is the need to collect the aggregate of a particular data source over a period of time
I came up with the following idea:
My main concern here is the fact that I am using a static class (essentially a global) to share data between the two services. Is there a better way to doing this?
edit: Thanks for the responses thus far. Apologies for the vaguesness of this question: just trying to work out what is the best way to share data across different services and am unsure as to the specifics (i.e. what is required). The platform that I am developing on is the .NET framework and both services are simply WCF services hosted as a Windows service.
The database route sounds like the most conventional way to go - however I am reluctant to go down that path for now (mainly for deployment/setup issues; it introduces the need to create new tables, etc in addition to simply installing the software) for at this point the transfer of relatively small amounts of data. This may of course change in the future and going the database route might be the way to go at that point.
Is there any other way besides adding a database persistance layer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您需要收集和聚合数据，您可能需要考虑在两层之间使用数据库。或者我误解了什么？
您应该考虑用更多要求来增强您的问题：几乎所有选项都在这里开放。
If you need to collect and aggregate data, you might want to consider using a database between the two layers. Or have I misunderstood something?
You should consider enhancing your question with more requirements: pretty much all options are open here.
当然 - 数据绑定怎么样？我在这里没有太多关于您的平台的信息，但最先进的系统以某种形式提供它。
Sure - how about data binding? I don't have a lot of information to go on here - about your platform but most sufficiently advanced systems offer it in some form.
您可以将静态共享数据替换为某种数据库表示形式，并在数据库和 Web 服务之间使用缓存层（如 memcached），以便大多数时候可以从缓存中快速获取数据，但可以从数据库中检索数据根据需要。
You could replace your static shared data with some database representation, with a caching layer (like memcached) between the database and the webservice, so that most of the time the data is available very quickly from the cache, but can be retrieved from the database as needed.
我很欣赏您希望保持架构简单。根据您必须查找的项目的数量和持久性，您可能只考虑利用文件系统或消息队列。听起来您想要一个文件系统，因为这听起来对您的设计影响最小。
如果您开始处理数以万计的小文件，您的目录可能会变得难以导航并且文件查找速度变慢。我通常为每个目录拍摄大约 1000 - 10000 个文件，并编写一个例程，可以根据文件名模式生成文件的路径。保持子目录的数量均匀很重要，某些文件系统对子目录的数量有限制 在父目录中。
I appreciate that you want to keep the architecture simple. Depending on the magnitude of items you have to look up and there permanency, you might just consider leveraging your file system or a message queue. It sounds like you want a file system, because that sounds the least amount of impact to your design.
If you start dealing with tens of thousands of small files, your directories could get hard to navigate and slow to do file lookups on. I typically shoot for about 1000 - 10000 files per directory, and concoct a routine that can generate a path to the file depending on the file name pattern. Keeping the number of subdirectories even is important, some file systems have a limit on the number of subdirectories in a parent directory.