ioGame
ioGame copied to clipboard
iohao
ioGame21 功能收集
收集一些功能需求，用于下个大版本中；欢迎讨论！
ioGame 的版本规则 https://www.yuque.com/iohao/game/wsgmba#zagb5
ioGame 版本规则 x.y.z
- x 表示当前使用的 JDK 版本
- y 表示 ioGame API 变更版本 （但基本上不会变动，常规下是变动 x 才会变动 API）
- z 表示 ioGame 新特性、新功能、新模块、bugfix 相关
ioGame 的 x 会跟着最新的 JDK LTS 版本来走的，目的是确保 ioGame 的 API 不会发生很大的变化。
为了保持新活力与接受新鲜事物， ioGame 基本会用上最新的 JDK LTS; 也就是说，下一个 x 将会是 21;
x 一般延后 1~2 个季度，给开发者一个缓冲。
即下一个 JDK LTS 出来后，那么 ioGame 的 x 会在 1~2 个季度后跟上。
- 建议简化逻辑服之间的相互通讯方式，可参考Dubbo类似的方式，可简化很多开发工作；
可以举个示例吗，简化后是什么样的
- 对外服增加对客户端链接数的限制，并能提供自定义实现的方式；
这个可以通过 业务编排钩子接口 实现自定义
- 建议简化逻辑服之间的相互通讯方式，可参考Dubbo类似的方式，可简化很多开发工作；
可以举个示例吗，简化后是什么样的
A 逻辑服Service暴露对外的接口并自己实现，B逻辑服Service通过Bean注入的方式直接可以调用A逻辑服Service的接口实现方法
- 建议简化逻辑服之间的相互通讯方式，可参考Dubbo类似的方式，可简化很多开发工作；
可以举个示例吗，简化后是什么样的
A 逻辑服Service暴露对外的接口并自己实现，B逻辑服Service通过Bean注入的方式直接可以调用A逻辑服Service的接口实现方法
可以阅读 action 接口化的使用方式，或许与是你要想要的，而且更简单 https://github.com/iohao/ioGame/discussions/123
- 建议简化逻辑服之间的相互通讯方式，可参考Dubbo类似的方式，可简化很多开发工作；
可以举个示例吗，简化后是什么样的
A 逻辑服Service暴露对外的接口并自己实现，B逻辑服Service通过Bean注入的方式直接可以调用A逻辑服Service的接口实现方法
可以阅读 action 接口化的使用方式，或许与是你要想要的，而且更简单 #123
action 必须要走路由配置，而且还需要PB协议定义，内部调用更简单一点好，可以考虑类似Dubbo微服务端的远程调用方式，非常方便。
- 建议简化逻辑服之间的相互通讯方式，可参考Dubbo类似的方式，可简化很多开发工作；
可以举个示例吗，简化后是什么样的
A 逻辑服Service暴露对外的接口并自己实现，B逻辑服Service通过Bean注入的方式直接可以调用A逻辑服Service的接口实现方法
可以阅读 action 接口化的使用方式，或许与是你要想要的，而且更简单 #123
action 必须要走路由配置，而且还需要PB协议定义，内部调用更简单一点好，可以考虑类似Dubbo微服务端的远程调用方式，非常方便。
都差不多的， rpc 路由通过类+方法名来确定，当使用参数时也需要自定义结构。 action 接口化在使用上足够简单了。 但会将这个纳入考虑。
jdk21 出来了，准备支持 虚拟线程， 到时候会出压测报告吗
ioGame 由 [网络通信框架] 和 [业务框架] 组成.
网络部分使用的 bolt , 如有需要请直接压测 bolt；
参考 https://github.com/sofastack/sofa-bolt/issues/38 https://github.com/sofastack/sofa-bolt/issues/264
业务框架不会成为性能瓶颈，因为在个人电脑上做压测，在单线程中业务框架平均每秒可以执行 1152 万次业务逻辑。
gossip需要指定种子节点,这种方式还是没有去中心化,能不能搞个不需要指定种子节点的,而是随着服务启动数量的多少自动选举出种子节点,并且随着服务下线减少数量后重新选举出种子节点,这样开发者就可以随意下线机器不用在乎锁下线的机器是否种子节点了
