重构，完善事件总线和中间件设计， 完善模型设计

.gitignore

@@ -30,3 +30,4 @@ sig.bin
 qrcode.png
 signature.bin
 *.toml
+*.db

README.md

@@ -11,19 +11,7 @@
 
 ## 开发进度
 
-目前距离第一个Release版本的发布还有很多需要进行的工作：
-- [x] 基础的事件总线系统
-- [x] 内置LagrangeGo适配器的部分事件发送
-- [x] 类Satori的消息解析
-- [x] 配置读取/生成/补全
-- [ ] 数据库连接，统一数据库接口设计
-- [ ] 消息发送/统一Client设计
-- [ ] 插件系统设计和实现
-- [ ] 完善内置LagrangeGo适配器的事件接收和处理
-- [ ] 集群模式设计和实现（集群的动态和静态总控模式）
-- [ ] 排障和性能优化
-- [ ] 自动化测试
-- [ ] 确定各项基础程序设计，编写使用文档
+Refact分支正在进行重构，目前进度还在推进，过几天再来探索吧~
 
 ## 特性
 

REFACT.md

@@ -0,0 +1,43 @@
+这个分支是对Iceinu现有设计的重构
+
+因为写的实在是有点太混乱并且写的过程中又有了一些新的想法，需要对代码进行一遍重构来改善质量。
+
+在之后完成度超过主分支之后会进行合并并替代主分支
+
+## 重构目标
+
+之前对于Iceinu的组网设计比较抽象，虽然设想了集群但是完全没有做出相应的设计。
+
+Iceinu会在启动时为实例分配一个ID，作为对每个实例的操作基础，机器人的实例组网有多种方式。
+
+首先是单节点模式，也就是默认的Bot运行模式，不进行集群，实例的事件总线完全本地运行。
+
+静态集群模式，需要一个可以被访问的主实例，这个模式下每个实例的事件总线仍然是本地运行的，但是节点会向主实例推送
+自己的用户树，主节点会和所有子节点维护一个长连接网络，用于互相推送事件，在接收到用户树推送/更新后动态计算分配
+各个节点的用户可用性，实现各个bot之间消息处理的去重
+
+动态集群模式，基本和静态集群模式一致，但是需要各个节点之间都可以相互访问，当主节点出现任何问题导致无法访问时，其
+他任何一个节点都可以重新成为主实例。
+
+分布式模式，这个模式下的事件总线只在主实例上运行，主实例会通过长连接网络接受每一个节点的消息事件推送，并将消息处
+理事件对所有节点进行广播，子节点自动匹配对应的消息处理事件。
+
+集群模式下各个节点各自具备完整的信息处理能力，有自己的消息缓存，适合有多台性能比较高的机器的情况，且动态集群模式
+如果可以实现应该是可用性总体来讲最优秀的状态。分布式实际上是将子节点变成了传统意义上的协议端，对低性能设备更友好
+，非常适合分散部署大量实例。
+
+同时还要引入一个新的设计，模型（Model），用来定义一个或多个平台的消息事件，默认模型应该是基于Satori的，但是如果
+出现了自己定制私有的消息事件模型和适配器的情况，可以直接通过更换模型来实现，模型无需实现接口，它本身就不是通用的
+，而是在特殊情况下的一个解决方案，可以让适配器的设计更加灵活，用来设计一些不考虑全平台兼容的适配器，只需要实现适
+配单个平台的消息事件。
+
+消息缓存，这个也是之前的设计基本没有考虑的一个东西，适配器可以自由实现对应平台的消息模型，Iceinu自动将消息模型实
+现为缓存数据库中的一个表，这个缓存数据表具有固定的缓存数量，用来缓存对应平台的消息，供适配器进行取用。
+
+目前消息缓存基本上会使用一个额外的DuckDB来实现，因为消息可能需要一定程度上的持久化，加上嵌入式数据库部署更方便，
+所以也就暂时不考虑Redis之类的缓存数据库。
+
+在Iceinu的设计里，main.go实际上更接近于一个启动脚本，如果直接将Iceinu作为开发框架引入那么修改这个启动脚本就可以
+实现大部分对框架本身的配置，我希望如果其他开发者使用Iceinu进行二次开发的话那么他们在开发过程中能集中精力主要实
+现自己的想法和功能，框架能把绝大多数大家需要的功能都封装好，能够让大家都用最轻松的方式进行开发；同时如果将Iceinu
+作为库来导入自由利用其中的部分设计来实现自己的功能也可以比较方便的进行调用。