边缘计算原因后台项目必须用 C++做,有没有大佬有这方面经验的,需要跟前端交互,给些技术关键词

CGI

socket || database || queue || cache...

难不成你说的是 TCP/UDP/WebSocket/轮询 /长轮询...这类东西?

http

C++没有成熟的框架,或者解决方案这种吗

cpprestsdk

使用约定协议交互

通常用 http websocket 等;

在用 Socket

你的前端是啥? cli ? gui ? web ?

c++后台一般不直接跟 web 交互

可选的方式有:

  1. 编译成动态库,暴露 C ABI 的 API ,这样 goalng 之类的后台基本可以即插即用(需要共享一个头文件和一个不需要实现具体功能,即 stub 的动态库二进制文件)
  2. 使用 unix socket ,交互 json 数据或者 protobuf 之类的(无队列)
  3. 使用消息队列中间件,随便选一个两边语言都有 binding 的

queue

假设 c++库 /程序叫 core:

  • core 在内存中保存配置或者控制位
  • core 如果需要被外部控制,可以序列化成比较通用的结构化数据比如 json/msgpack ,外部控制器(比如 golang 写的 web 后端)来负责持久化它们,存取数据库之类的,core 只解析 web 后端传过来的结构化数据
  • 转发器直接将流量转到 core ,比如 nginx module 或者集成了 libpcap 的东西,它们可以直接通过 IPC 手段与 core 存取同一个共享 buffer
  • core 执行必要的计算并且在内存中保存计算状态
  • 等待 web 后端异步地来读取这个状态,或者 RPC 通知后端状态发生变化
  • 在 RPC 里传递计算结果,这时候就还是通用结构化数据

rpc 或者 restful 写法的 web api
底层都是通过 socket 转发数据

这问题我熟悉呀,你提供一些接口,让做 web 服务器的在对应 url 路由调用你的函数,不然自己实现一个简单 HTTP

c++ --- java/go --- client

通过 rpc ,中间加一层比较好。
涉及到前后端对接和业务需求变动,中间这层变化老快了。你要是把所有和前度对接的逻辑都堆到 c++去,也不是不行,但是改动,编译,debug 这些老费劲了。

中间加一层+1

最常用的就是 websocket

中间比如说用 java/go 转一层不是合理的解决方式,相当于把 C++的算法封成 SDK 用呗,但是 C++操作控制器传感器这些更麻烦了,完了对系统资源要求也更高了

用 cpython 封装下, 直接用 py 做一个 webapi 就可以了, 省事。

oatpp 可以用这个 web 框架

rpc 或者 http

前台是 web 不就是 restful 吗,啥意思啊

grpc

github.com/sogou/workflow

site:hesudu.com/t c++ http

后端吐 CGI 出来或者 JSON 字符串出来就完事了(需遵循 HTTP 协议,如果你要用 HTTP 的话),没啥难度。

cgi QQ 邮箱现在还在用,稳定服务几亿用户

不过老实说 C++处理字符串相关的很麻烦,调试起来也要反复编译,用在 web 这种场景很费力气。
真不如用脚本语言粘一层。

protobuff

啊,为什么要在中间套一层 Java/Golang/Python , 难道 c++ 发展这么多年没有 http 库么,不应该把

stefanfrings.de/qtwebapp/
都是 c++,可以看看这个,这样的话前后端分离,只要定 api 就行

usocket 库,17 写法

正解 gRPC Cpp Quick Start 走一波 grpc.io/docs/languages/cpp/quickstart/