2.ObjectSystem跟Event不再需要加标记，因为基类已经加了
3.拆分显示层跟逻辑层，显示层的组件放到View里面
4.publish改成支持异步的

StartMachineConfig 该表表示物理机配置，每台物理机一条数据
StartProcessConfig 该表表示进程配置，每个进程一条配置
StartZoneConfig    该表表示游戏区配置，每个区一条
StartSceneConfig   该表表示游戏场景配置，场景属于哪个区，放在哪个进程上面
可以从表看出，游戏所有区都可以配置在一个进程上，方便开发，正式发布再配置到不同的进程即可，非常方便！

* Log输出到Console

* 使用Config前添加ConfigComponent
使用OuterAddress拼接好的外网地址
修改TimerComponent关于TimeOut相关代码

主要原因是为了避免类似using语句因为取消协程导致无法调用到Dispose方法的问题，所以协程即使取消也一定要往下执行
因此增加bool值来判断是否已经取消

1.Model 逻辑层数据结构定义
2.Hotfix 逻辑层的逻辑方法
3.ModelView 显示层的数据结构定义
4.HotfixView 显示层的逻辑方法
5.ThirdParty 第三方库
为什么要分出ModelView跟HotfixView呢？主要原因是要分离显示层跟逻辑层，逻辑层的代码其实可以用来做压测机器人。如果一开始就定好这样的结构，压测机器人完全可以利用客户端逻辑层的代码，节省大量时间

2.ActorMessageHandlerAttribute不需要指定AppType

协程锁原理很简单，同一个key只有一个协程能执行，其它同一个key的协程将队列，这个协程执行完会唤醒下一个协程。
协程锁是个非常方便的组件，比如服务端在处理登录或者下线过程中，每个异步操作都可能同一个账号会再次登录上来，
逻辑十分复杂，我们会希望登录某部分异步操作是原子操作，账号再次登录要等这个原子操作完成才能执行，
这样登录或者下线过程逻辑复杂度将会简化十倍以上。协程锁是ET解决这类异步重入问题的大杀器。

服务端消息优化后的bug残留

消息处理代码更加简洁