[#99] 增加 msgId 特性，默认只在 request/response 通讯方式下生效

[#102] 业务框架 BarSkeleton 类增加动态属性，方便扩展.

[#111] 新增文档解析、文档生成的控制选项

public class DemoLogicServer extends AbstractBrokerClientStartup {
    ... ... 省略部分代码
    @Override
    public BarSkeleton createBarSkeleton() {

        // 业务框架构建器
        BarSkeletonBuilder builder = ...;

        BarSkeletonSetting setting = builder.getSetting();
        // 不生成文档
        setting.setGenerateDoc(false);
        // 不解析文档
        setting.setParseDoc(false);

       ...

        return builder.build();
    }

}

[#103] 业务框架新增 Runner 机制，增强扩展性、规范性

详细的使用文档：Runner 机制 - 文档

[#104] 新增实验性特性-脉冲通讯方式

详细的使用文档：脉冲通讯方式-文档

脉冲通讯简图

脉冲与发布订阅类似，但与其不同的是，脉冲具备接收消息响应动作的功能。当脉冲生产者发送【脉冲信号请求】时，脉冲消费者接收该请求并执行相应方法后，会向脉冲生产者发送【脉冲信号响应】。这使得脉冲在功能上与发布订阅有所区别。

• 脉冲生产者的职责：1.生成脉冲信号请求、2.设置周期间隔、3.接收【脉冲消费者】的脉冲信号响应
• 脉冲消费者的职责：1.接收【脉冲生产者】的脉冲信号请求、2.生成脉冲信号响应

1. 【脉冲生产者】发送脉冲信号请求。
2. 【脉冲消费者】接收【脉冲生产者】的脉冲信号请求，并生成脉冲信号响应。
3. 【脉冲生产者】接收【脉冲消费者】的脉冲信号响应。

如果用一句话来描述脉冲通讯，那么就是：比发布订阅多了响应消息。

脉冲使用场景

在上面用了图文的方式来描述脉冲通讯这个术语，相信你对这个术语有一定的了解了。下面让我们进入一个业务场景，来说明脉冲通讯是如何解决的。

业务需求描述

假设我们有这么一种业务场景，每隔一段时间需要将当前每个游戏对外服在线的玩家数量的数据给到数据收集服务器。

对于这种需求，我们可以用不同的方式来实现，这里介绍这么几种方式，分别是：

• http
• 发布订阅
• 脉冲通讯

http 的实现方式

在游戏对外服增加一个定时器，周期性的将当前最新数据上传到指定的 URL 。（这个 URL 是数据收集服务器提供的一个 http 服务）。

redis 发布订阅的实现方式

在游戏对外服增加一个定时器，周期性的将当前最新数据用事件发布；游戏服务器作为发布者，数据收集服务器作为订阅者。这种实现方式还需要安装一个中间件来支持。

引发的问题

我们先来两种假设，分别是：

• 数据收集服务器宕机了。
• 业务不需要了。

让我们来看一下，这两个实现方式是如何应对这两个假设的。

我们可以发现，当数据收集服务器宕机时，无论是采用 HTTP 传输还是使用 Redis 进行传输，都会触发数据上报操作，而不关心对方是否还活着。当业务不需要时，这两种方式都需要移除相关的代码，否则会一直执行相关业务，且一旦业务代码有变动，就会出现风险。

这两种方式将会一直占用机器资源，会不断地上报数据，而不考虑对方是否存活、存在或能否消费。

为了解决这些问题，我们可以使用脉冲通讯。脉冲通讯可以解决上述问题，可以避免不必要的数据上报操作，从而减少资源消耗。

脉冲通讯的实现方式

数据收集服务器作为【脉冲生产者】发送一个脉冲信号请求，而游戏对外服作为一个【脉冲消费者】接收到脉冲信号请求后，开始收集在线玩家的数据，并将这些收集的数据响应给脉冲请求者（也就是脉冲生产者）。

使用脉冲的优势在于：

• 由于是数据收集服务器发起的脉冲信号请求，游戏对外服务不需要编写定时器相关代码。
• 当数据收集服务器宕机时，不再向脉冲消费者发送脉冲信号请求，因此按需请求的方式可以被实现。游戏对外服务不再需要关心数据收集服务器的存在和生存状态，因为请求是由数据收集服务器主动发起的。
• 当业务不再需要时，游戏逻辑服也无需修改相关代码逻辑，从而保证了系统的稳定性，同时无需担心资源被占用。
• 脉冲具有周期性的特点，我们可以自由地在数据收集服务器上更改周期频率（如每秒、每分钟、每十分钟、每小时、每天），以触发数据的收集。

注意事项

开源协议更改为 GPL2.0

BrokerClient 添加 AwareInject

<netty.version>4.1.92.Final</netty.version>

<jctools-core.version>4.0.1</jctools-core.version>

<qdox.version>2.0.3</qdox.version>

<protobuf-java.version>3.22.4</protobuf-java.version>

ioGame 使用趋势数据统计

关注 ioGame 的游戏服务器开发者持续增多，2022-09 ~ 2023-05 月统计数据；

这里的统计信息是关于开发者关注 ioGame 框架相关的，从统计数据中可以看出，由于 ioGame 上手简单，功能强大等优点，得到了众多开发者的关注。如果你想知道 ioGame 有没有人在使用，可以先到这里看下统计数据、开发者的评价与讨论。

https://www.yuque.com/iohao/game/gpxk93#TwVa8

这里展示了每月的统计数据，统计数据来源于语雀后台，这些数据都是真实的、客观存在的、活的。

因为成本的原因，某宝某多还没有出现能提供这种服务的商家，所以这样的统计数据也更具真实性。

通过统计数据，我们可以看到每天会有很多开发者在访问 ioGame 的在线文档，并且这些统计数据不是来源于口嗨的，也不是主观创造的。

所以，还在犹豫要不要使用 ioGame 的开发者们，更应该讨论的是 “为什么这些开发者会选择使用 ioGame”，而不是 ioGame 有没有人在使用的问题。

maven pom

ioGame 是一个 java 网络游戏服务器框架，有以下特点：

• 无锁异步化、事件驱动的架构设计
• 支持 websocket 和 socket 两种通信协议
• 支持 protobuf、json 等不同的通信协议
• 集群无中心节点、集群自动化、分布式的设计
• 轻量级，不依赖第三方中间件或数据库就能支持集群、分布式
• 提供多种通讯方式，且逻辑服之间可以相互跨机器通信
• 与 spring 和其他框架融合方便
• 学习成本低，开发体验好
• 支持多服单进程、多服多进程的启动和部署方式
• 提供游戏文档生成的辅助功能
• 包体小、启动快、内存占用少
• 提供优雅的路由访问权限控
• 提供了灵活的线程扩展与设置

• 网络通信框架：职责是各服务器之间的网络通信
• 业务框架：职责是业务逻辑的处理方式和编写方式

网络通信框架 

SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。

• 为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。
• 为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。

Bolt 名字取自迪士尼动画 - 闪电狗，是一个基于 Netty 最佳实践的轻量、易用、高性能、易扩展的通信框架。

业务框架

如果说 sofa-bolt 是为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上。而业务框架正是解决业务逻辑如何方便实现这一问题上。业务框架是游戏框架的一部分，职责是简化程序员的业务逻辑实现，业务框架使程序员能够快速的开始编写游戏业务。

业务框架对于每个 action （即业务的处理方法） 都是通过 asm 与 Singleton、Flyweight 、Command 等设计模式结合，对 action 的获取上通过 array 来得到，是一种近原生的方式。

架构简图

/** 请求 */
@ProtobufClass
@FieldDefaults(level = AccessLevel.PUBLIC)
public class HelloReq {
    String name;
}

@ActionController(1)
public class DemoAction {
    @ActionMethod(0)
    public HelloReq here(HelloReq helloReq) {
        HelloReq newHelloReq = new HelloReq();
        newHelloReq.name = helloReq.name + ", I'm here ";
        return newHelloReq;
    }
}

┏━━━━━ Debug. [(DemoAction.java:4).here] ━━━ [cmd:1 - subCmd:0 - cmdMerge:65536]
┣ userId : 888
┣ 参数: helloReq : HelloReq(name=塔姆)
┣ 响应: HelloReq(name=塔姆, I'm here )
┣ 时间: 0 ms (业务方法总耗时)
┗━━━━━ Debug [DemoAction.java] ━━━━━━━━━━━━━━[当前线程:RequestMessage-8-1]

Debug. [(DemoAction.java:4).here]：
    表示执行业务的是 DemoAction 类下的 here 方法，4 表示业务方法所在的代码行数。
    在工具中点击控制台的 DemoAction.java:4 这条信息，就可以跳转到对应的代码中（快速导航到对应的代码），这是一个开发良好体验的开始！
userId :  
    当前发起请求的 用户 id。
参数 :  
    通常是游戏前端传入的值。
响应：
    通常是业务方法返回的值 ，业务框架会把这个返回值推送到游戏前端。
时间：
    执行业务方法总耗时，我们可根据业务方法总耗时的时长来优化业务。
路由信息：[cmd - subCmd]
    路由是唯一的访问地址。