我目前正在致力于社交网络的实施。
该架构是：
- 分布式 C++/Qt 客户端
- Neo4j 服务器数据库
我可以直接查询数据库，因为它有来自我的 Qt 应用程序的 REST 接口。
我对这种方法不太满意，因为它不安全，并且无法进行优化（缓存请求）。
我应该使用什么服务器/架构来管理来自客户端的请求？
我更喜欢 Python，而不是 Java，但这里速度很重要。
您认为 REST 足够快还是应该使用 RPC？
在最后一个场景中，这意味着我应该为数据库开发自己的服务器实现。
I'm currently working on the implementation of a social network.
The architecture is:
- Distributed C++/Qt clients
- Neo4j server database
I could directly query the database since it has a REST interface from my Qt apps.
I'm not quite comfortable with this approach because it is not secured, and no optimizations (caching requests) are possible.
What server/architecture should I use for managing requests from the clients?
I am more Python than Java but here speed matters.
And do you think REST is fast enough or should I use RPC?
In the last scenario, it means I should develop my own server implementation for the database.
发布评论
评论（1）
REST 会足够快。使用它，直到您可以测量并获得一些真实数据来告诉您这是一个问题。
但我不会使用 REST API 直接处理数据库。
我会在两者之间添加管理安全性、验证和绑定、用例和错误处理、日志记录、事务等的层。
如果您在 Spring 中执行此操作，控制器将担心前两个，而服务将担心处理最后两个。
是的，客户端/服务器直接连接到数据库更复杂，但是您正在以更多层和更多代码为代价购买您想要的东西（安全性等）。决定它对你的价值。
当然，速度很重要，但限制更可能是由网络延迟决定的。如果客户端通过 Internet 访问，则意味着平均需要 12 个路由器跃点才能到达您的应用程序。我发现公司 Intranet 上的往返延迟为 70 毫秒。让它成为速度的衡量标准。
至于重要的是什么，我认为社交网站应该考虑扩展到大量访问者。我所知道的架构是线程池和请求队列，每个传入请求有一个线程，或者像 Netty 这样的非阻塞 I/O。我认为相当于 Netty 的 Python 是 扭曲。
REST will be fast enough. Use it until you can measure and have some real data that tells you it's a problem.
But I wouldn't use the REST API to deal directly with the database.
I'd add layers between the two that manages security, validation and binding, use cases and error handling, logging, transactions, etc.
If you were doing this in Spring it would be controllers that would worry about the first two and services that would deal with the last two.
Yes, it's more complicated that client/server directly to the database, but you're buying something you want (security, etc.) at the cost of more layers and more code. Decide what it's worth to you.
Speed matters, of course, but the limit is more likely to be set by network latency than anything else. If clients are coming over the Internet, that means an average of 12 router hops to get to your app. I see 70 ms roundtrip for latency on my corporate intranet. Let that be a gauge for speed.
As for what's important, I think a social networking site should worry about scaling to lots of visitors. The architectures I'm aware of are thread pools and request queues, with one thread per incoming request, or non-blocking I/O like Netty. I think the Python equivalent to Netty is Twisted.