M3Game 是一个采用 Golang 构建游戏后端的尝试，期望能探索出一套 Golang 游戏后台的开发方案。M3分为单实例开发方案和集群化部署方案两部分。单实例开发方案已完成，主要包括单进程的代码框架。集群化部署方案正在进行，主要包括容灾恢复，动态伸缩，数据一致性方案等。
单实例开发框架分为GameLogic，Frame-Runtime，Custom-Plugin三层。
Frame-Runtime。框架驱动层，负责消息驱动，服务网格，插件管理等核心驱动工作。
Custom-Plugin。自定义插件层，框架层将第三方服务抽象为多种插件接口，插件层根据实际的基础设施来进行实现。
GameLogic。游戏逻辑层，用于承载实际的业务逻辑。框架使用protobuf来生成脚手架，可以通过在pb中添加Option的方式将业务层接口自动注入到框架层。
优势：
1，更加贴近实际业务。M3要解决的问题大都是作者在实际业务环境中遇到的问题，更加贴近实际的游戏开发。
2、自动化的逻辑注入。借助pb的自定义选项，业务逻辑只需要很少的代码，就可以自动的注入到框架层
3、更通用的技术和更低的门槛。M3基于golang主流的protobuf和grpc进行构建，没有繁琐的代码生成工具，上手门槛低。
Mutil，Async，Actor Server: 游戏后台常见的业务模式，分别对应并发，单线程异步，Actor模式
App: 用于承载业务逻辑的服务实体，是服务网格中的独立个体，由“环境ID.区服ID.功能ID.实例ID”唯一标识。一个App可以承载一个或多个Server
Client：RPC客户端，由服务提供方编写，包含一些参数校验，和路由规则
ResourceLoader: 可线上热更新的资源加载器，一般用于GameLogic Config的管理
Runtime: 框架驱动器
Transport: 提供服务之间Reply式RPC调用能力，采用GrpcSer实现一对一调用
BroekerSer：提供服务之间单向Ntify式RPC调用能力，采用Broker-plugin实现一对多调用
Mesh：服务网格，内含一组路由规则，以及规则对应的选路逻辑。采用Router-Plugin实现服务发现和服务注册
PluginMgr：插件管理器
Router-Plugin： 路由组件，提供服务注册和服务发现的能力。当前有一个Consul实现
DB-Plugin: 存储组件，提供数据存储能力，当前有一个内存数据库实现
Broker-Plugin：消息队列组件，提供针对主题的发布和订阅功能，当前有一个Nats实现
Log-Plugin: 日志组件，当前有一个Zap实现。
Trace-Plugin: 链路追踪组件，当前接入opentelemetry标准。
Metric-Plugin: 监控组件，当前有一个prometheus实现
Shape-Plugin：流量治理组件，当前有一个sentinel实现
Gate-Plugin：服务网关组件，当前有一个grpc-stream实现
M3内部依赖
HelloWorld
以example/simpleapp为例
Step1、定义服务 proto，生成pb文件
Step2、编写App代码
Step3、编写服务实体simpleser
step4 制作配置文件
Step5 编译运行
M3Game：单实例开发方案 - 南盼的文章 - 知乎 https://zhuanlan.zhihu.com/p/613863845
M3Game：集群化部署方案 - 南盼的文章 - 知乎 https://zhuanlan.zhihu.com/p/614877626