我们有非常复杂的 C++ 图像处理引擎，使用 Intel Compiler、OpenCV 等。目前它正在通过 C# 互操作层集成到我们的生产中，它非常薄，几乎不影响速度性能（而且我们谈论的很少每个请求的毫秒数）。现在我们正计划将我们的系统迁移到 CentOS（并且仍然支持 Windows 平台）。从历史上看，我对 Mono 不太信任，JNI 也有它的问题，所以最合乎逻辑的解决方案是转向纯 C++ 实现。
考虑到我们需要移植以下功能，您认为这是个好主意：
1) 文件系统 2) JSON 3) 线程 4) Storm / Kafka / RabbitMq 5) XML 6) Log2Cxx
顺便说一句，我认为 Qt 可能不需要 UI，但它会为我们提供文件系统、线程、XML 甚至 JSON。
非常感谢，帕维尔
您的信用卡付款很有可能是由运行 Qt 核心的系统处理的，因此您走在正确的轨道上。
Qt 是模块化的。你需要几个模块来排除 GUI 的东西，尽管 GUI 也可以在服务器中使用。例如，绘制一些图像以发送回客户端非常容易。我建议尽可能使用 Qt，并且只有在 Qt 不能提供您需要的东西并且不能以简单的方式实现时才使用 Boost。如果你在 Qt 和 boost 之间犹豫不决，你最终会得到很多胶水代码，这将使整个事情变得比必要的工作更多。
Qt 本身没有日志记录机制，它有一些用于调试输出的功能，但如果您想要真正的日志记录，它需要更多功能。它确实涵盖了文件系统、json、线程、网络、使用事件队列和/或信号槽连接的对象之间的通信。它还具有流式 XML 解析器。您可以将您的项目与 log2xx 集成。持久的消息传递基础设施也需要集成，因为 Qt 不提供。您可能会发现，就消息传递而言，实现您所需要的更容易。
询问线程的速度开销有点毫无意义，因为在几乎所有框架中，线程控制器只是在线程中启动用户代码的一种方式。一旦创建线程，它就没有运行时开销。一切都取决于您在线程中运行的代码。
因此，您想问的是，您通常会在线程中“运行”哪些代码？理想情况下，您只想运行默认实现中提供的事件循环QThread。仅当您从其他线程向其发布消息时，事件循环才会与其他线程同步。这就是任何其他线程间通信的实现无论如何都会做的事情，因此没有额外的 Qt 特定开销。然后，您将 QObjects 移动到要运行它们的线程中（或者只是在已经在该线程中运行的代码中创建）。
当您必须封装阻塞的第三方代码时，例如臭名昭著的阻塞数据库接口，那么您将被迫将每个数据库连接放在自己的线程中。无论您是否使用 Qt，情况都是如此，因此没有什么特别之处。
Qt 的 XML 和 json 实现是合理的，我不明白为什么它们会比其他任何东西更糟糕。
如果您认真对待您的项目，您将成为 Digia 的客户。我相信他们会回答您关于所提供的支持级别、稳定性等方面的问题。
将 Qt 用于您的项目的一个好处是它是跨平台的：您可以在 Linux 或 Windows 服务器上运行它。如果它是由第三方安装的系统，这可能是一个重要的考虑因素。
Qt 也可能涵盖 Log2Cxx，因为它具有日志记录机制。据我所知，您当然可以在 Qt 5.0 上解析 JSON。QJson 是另一种选择，您可以查看：
http://qjson.sourceforge.net/usage/
除了 Qt，我会推荐 Boost 库，因为它是我在必要时会在 C++ 中使用的第一个库。