Closed HollisMeynell closed 1 week ago
ForteScarlet
commented
2 weeks ago 看上去，也许你的需求类似 #72 中提到的 反向 WS 连接。
在你说的 几个问题 中，大多数都是可以通过业务逻辑自行实现的，它本质上跟onebot并没有什么实际关系，比如负载均衡，故障转移或者拉黑qq等。
如果simbot端作为一个 服务端 ，或者说反向连接的服务器端，通过以 ws 连接为媒介动态构建bot实例，本质上的确是可行的，毕竟这些在ob11协议中都有一定程度的约定。
这是看上去的确是一个可行的方案，或者设计，适合一些成规模的、或作为某种服务商的情况。 但同时它内容量庞大，且不适用于大多数普通开发者。这很纠结，这很难判断出是否有价值去花费大量精力（对于一个社畜来讲）设计实现它。
也许我们可以逐步拆解它的可实现内容，比如从外部主动直接输入任意事件结构开始，反向WS API，或基于任意ID的动态bot等。
或者你有什么更好的方案与建议（ 如果能直接贡献pr一步到位就更好了哈哈 ）
HollisMeynell
commented
2 weeks ago 确实, 前面提到的很多是可以交给框架使用者来实现, 只是在框架层面实现更方便一些(比如在event监听需要主动关闭bot连接以及获取连接请求Header这些就需要额外增加扩展), 负载均衡跟故障转移这个, 似乎可以抽象出来, 可能应用在其他协议的bot
适合一些成规模的、或作为某种服务商的情况
这个需求已经远超一般人写个bot玩玩的范围, 所以这个issue仅仅是想知道, 是不是在'不要做'的范围之内, 有很多开发者信奉"Make each program do one thing well", 认为多余的功能只会使程序变得臃肿, 提出的问题是在实现中可能遇上的(其实就是开发遇到的, 我目前在维护一个游戏数据查询的bot, 自己qq三天两头被举报, 无奈只能是开放服务, qq维护交给其他人)
由于是刚开始接触(还不是使用), 所以要彻底了解这个项目才能尝试提交pr, 我会尽可能的支持 只要不怕我写的垃圾代码提pr引起高血压
ForteScarlet
commented
2 weeks ago 完整的支持肯定是不太现实的，那更像是一个具体的应用而不是框架。 不过，让它变得可以实现这个目的是有可能的，这其中主要可以拆解为：通过外部ws接收事件，和通过ws（或者说外部的ws）进行API交互。 第一点的话理论上是可以实现的，bot可以接受任意外部的事件json字符串，也就是可以接受来自外部的事件，不论来自ws还是http。 第二点的话尚待考虑，目前只有通过内部实现的HTTP请求方式。 按理说，这两点支持的情况下，使得bot成为动态构建的，就基本可以支撑所述场景。
ForteScarlet
commented
2 weeks ago 一个游戏数据查询的bot, 自己qq三天两头被举报
顺带一提，如果只是问答形式的查询bot，不如试试官方的botAPI，组件也是有的（
是否会提供贡献？
否
版本信息
No response
涉及的编程语言
Java
项目构建工具
Maven
内容描述
希望增加作为service来运行, 使用场景为将bot部署在公网, qq分布式连接服务后端, 将压力分流
可能需要考虑下面几个问题
需要使用 token来验证合法的onebot qq端, 同时支持未经验证的onebot qq端可以使用部分功能(onebot 消息可以随意伪造, 对于一些管理员专用功能可以伪造发送者来越权调用)
负载均衡, 多个onebot qq端在同一个群里需要事件去重或者说响应去重(防止一呼百应, 一个消息重复处理多次)
故障转移, 在A与B都在群X, 收到群X的消息时, 在处理一段时间后响应或者连续响应, 响应消息时A离线了, 将其转移至B响应
可以定义端口以及端点,
ws://ip:[port]/[endpoints], 以及支持拉黑qq个人的思路是
在收到 ws 连接请求后解析 header 中的
Authorization并将token信息记录, 并允许通过事件获取token, 由使用者来决定如何处理, 或者在listen/ 注解 中增加参数, 可以指定仅处理对应 token 的 qq 端下发的事件onebot qq 端连接后获取群聊列表, 并将群聊与 onebot qq 端做表, 收到事件时有两种方案:
发送消息前判断 ws session 是否关闭, 如果关闭了, 则从上面的群聊与实例表取一个相同群聊的实例发送, 取不到可以抛错
这个就看 service 的实现了, ktor 以及 spring boot 都可以实现, 拉黑 qq 可以通过 header 的
X-Self-ID