[#159] 同进程同时支持多种连接方式方式的技巧

public class MyApplication {
    ... ... 省略部分代码
    static int externalCorePort = 10100;

    public static void main(String[] args) {
        // 游戏对外服列表
        List<ExternalServer> externalServerList = listExternalServer();
        new NettyRunOne()
                .setExternalServerList(externalServerList)
                .startup();
    }

    static List<ExternalServer> listExternalServer() {
        return List.of(
                // 连接方式；WEBSOCKET
                createExternalServer(ExternalJoinEnum.WEBSOCKET)
                // 连接方式；TCP
                , createExternalServer(ExternalJoinEnum.TCP)
                // 连接方式；UDP
                , createExternalServer(ExternalJoinEnum.UDP)
        );
    }

    static ExternalServer createExternalServer(ExternalJoinEnum join) {
        int port = externalCorePort;
        port = join.cocPort(port);
        DefaultExternalServerBuilder builder = DefaultExternalServer
                .newBuilder(port)
                // 连接方式
                .externalJoinEnum(join)
                // 与 Broker （游戏网关）的连接地址
                .brokerAddress(new BrokerAddress("127.0.0.1", IoGameGlobalConfig.brokerPort));

        return builder.build();
    }
}

[#157] fix 默认心跳钩子问题

[#122] 同进程亲和性

简介

同进程内不同 Netty 实例通信时，是通过内存进行传输的，不需要经过网络传输，数据传输速度极快。也就是说，如果我们将游戏对外服、Broker（游戏网关）、游戏逻辑服部署在同一个进程中（也就是单体应用），那么各服务器之间是在内存中通信的。甚至可以简单的理解为在同一 JVM 中的 a 方法调用了 b 方法，b 方法调用了 c 方法。

同进程亲和性是 ioGame 的特性之一，可以让同一进程内的 Netty 实例拥有相互访问优先权。说人话就是，如果你在同一进程内启动了游戏对外服、Broker（游戏网关）、游戏逻辑服，当有请求需要处理时：

• 即使你启动了多个 Broker（游戏网关），游戏对外服会优先将请求交给同进程内的 Broker（游戏网关）来处理。
• 即使你启动了多个相同的游戏逻辑服，Broker（游戏网关）会优先将请求交给同进程的游戏逻辑服来处理。
• 同样的，游戏逻辑服处理完请求后，会优先将响应交给同进程内的 Broker（游戏网关）。

部署简图

图中有这么几个部分，分别是：

• 玩家，这些玩家可能连接到【1111】或【2222】进程中。
• 【进程 3333】启动了多个公共的游戏逻辑服。
• 【进程 1111】启动了游戏对外服、Broker（游戏网关）、游戏逻辑服[A-1、B-1]。
• 【进程 2222】启动了游戏对外服、Broker（游戏网关）、游戏逻辑服[A-2、B-2]。

同进程亲和性指的是，优先访问同进程内的游戏逻辑服，当同进程内没有能处理请求的游戏逻辑服时，才会去其他进程或机器中查找能处理请求的游戏逻辑服；

处理流程

下面用一个场景来说明，游戏逻辑服对应的 action 数据如下：

游戏逻辑服-A 提供了路由：1-1。

游戏逻辑服-C 提供了路由：2-1。

从图中我们知道了，相同类型的【游戏逻辑服-A】启动了两台，分别在【进程 1111】和【进程 2222】中。

现在我们有一个玩家与【进程 1111】的游戏对外服建立了连接，并发起 1-1 请求；请求会被【游戏逻辑服-A-1】来处理，因为【游戏逻辑服-A-1】与玩家所在的【游戏对外服】是同一个进程内的，所以该请求会优先被【游戏逻辑服-A-1】消费；

通过同进程亲和性我们可以看出，虽然启动了两台相同类型的【游戏逻辑服-A】，但玩家的请求只会由【进程 1111】内的【游戏逻辑服-A-1】来消费，因为玩家连接的是【进程 1111】的游戏对外服。

当玩家发起 2-1 请求时，在【进程 1111】内找不到对应的游戏逻辑服来处理这个请求时，框架会将请求交给【游戏逻辑服-C-1】来处理。

使用场景

开发者可以利用同进程亲和性的特点，按照上图中的部署方式，可以让各服务器之间通过进程来做微隔离。此外，又能提供一些游戏逻辑服来处理公共业务；如一些跨服活动、跨服战...等，各种跨服业务。

使用该部署方式，可做参考的游戏类型如下：

• 滚服类型的游戏
• RTS（Real Time Strategy）实时战略游戏，例如星际争霸、红色警戒。
• MOBA（Multiplayer Online Battle Arena）多人在线竞技场游戏，例如英雄联盟、DOTA2。
• ARPG（Action Role-playing Game）动作角色扮演游戏，例如暗黑破坏神、无尽之剑。
• FPS（First-person Shooter）一人称射击游戏，例如使命召唤、绝地求生。
• TPS（Third-person Shooter）第三人称射击游戏，例如疾速前进、战地。
• 待补充...

小结

同进程亲和性是优先访问同进程内的游戏逻辑服，并不是说不能访问其他进程的游戏逻辑服。

特点

• 同进程亲和性换句话说就是，除了可以优先让同进程内的逻辑服相互访问外，还能访问其他进程的逻辑服。
• 各逻辑服在同进程内的通信，是通过内存进行传输的，不需要经过网络传输，数据传输速度极快。
• 合理利用同进程亲和性，可以让各服务器之间通过进程来做微隔离。

最后

ioGame 的架构由三部分组成：1.游戏对外服、2.Broker（游戏网关）、3.游戏逻辑服；三者既可相互独立，又可相互融合。所以，使用 ioGame 几乎可以满足任意的部署方式，可以根据你的需求来适应不同类型的游戏，并且在 ioGame 中做这些工作是简单的。

这里为什么要特意介绍一下三者之间的组合关系呢？目的是想告诉开发者，ioGame 的架构是灵活的。同进程亲和性在以下组合会生效。

为了更简单的说明三者之间的灵活性，现在把三者用字母代替，A.游戏对外服、B.Broker（游戏网关）、C.游戏逻辑服；我们可以得出如下组合

通过上面的组合，我们可以看出，ioGame 架构是支持类似传统架构那样只做一次跳转，甚至可以做到零跳转，这完全取决于你们的部署方式。

上面三种组合方式，都具备同进程亲和性。同进程亲和性生效的要点只有一个，至少保证有两部分在一个进程内。

其他更新

<netty.version>4.1.94.Final</netty.version>

ioGame 使用趋势数据统计

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

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

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

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

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

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

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

点击我，到语雀后台查看 ioGame 的数据

maven pom

<dependency>
    <groupId>com.iohao.game</groupId>
    <artifactId>run-one-netty</artifactId>
    <version>${ioGame.version}</version>
</dependency>

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]
    路由是唯一的访问地址。