catkatpowered/kat-server

🕊 一个软件 到处聊天 聚合 IM 服务端

🕊 Kat Server

🎉 你好！

这是一个聊天软件的后端，或者说好几个聊天软件的后端

我们正在寻找一种数据表达方式处理在通常的 IM 中可表达的内容，并尝试消息的存储与进行数据处理

通俗来讲，我们正在探索如何将多个第三方即时通讯软件中消息表达成一组适合的数据的方法

👷 构建状态

项目	状态	说明
Verify Build Github Actions		验证当前 commit 是否通过编译
Tests for Database		测试数据库模块
Tests for Config		测试配置文件模块
Tests for Utils		测试工具类
Tests for TokenPool		测试 Token 池
Tests for EventBus		测试事件总线
Tests for Network		测试网络模块
FOSSA License Scan		扫描项目以及依赖开源证书

🍉 条款与声明

本项目具有 隐私政策、使用条款 和 开源声明

✨ Quick Start

千里之行，始于 Quick Start 将描述如何快速启动和调试 Kat Server

📝 文档

在 这里 开始阅读完整文档，文档包含各个模块的设计思路、如何编写扩展等内容

⚖ 开源协议

AGPLv3 -- 这意味着基于本项目开发或者二次开发本项目以及与本项目通过网络接触的项目都需要通过 AGPLv3 开源，由于项目开发以及使用的过程中有可能会接触到个人账号密码等敏感信息，使用 AGPLv3 开源可以保证这些信息的处理流程是透明的

kat-server's Issues

一些架构上的建议

纯路人,看到hanbings开坑来看看

声明：本人不是什么专业架构师，只是发表一下自己的看法

1. KatMessageType 应该使用 enum

为什么要使用 constant 的做法呢？这样没法享受到 enum 的序列化以及他自带的一系列方法，还有编译期检查。
另外我注意到 KMT 本身的注释是消息类型管理器，我认为至少语义上应该把 Manager 和 MessageType 分离开来，一个类不应该有太多职责。（单一职责原则）

2. 尽量减少没有必要的静态代码

kat-server 内部大量使用了静态，甚至 KatExtensionManager 这样的封装几乎都是由静态方法构成的外观，并且有尝试用静态来模拟单例模式的倾向。但实际上我们应该尽量使用依赖注入的做法而不是tons of static and singletons，因为那样的耦合度更高，更不利于单元测试，而且想引入新的实现，或者进行更多封装也较为困难。

此外,使用静态来模拟单例会导致类字段中初始化顺序的微妙差异产生的 bug。

针对「过多的使用静态」这一点，我认为应该对所有完全用静态实现的功能重新考虑，因为这很不面向对象编程

3. 请抽象

上文提到了将 Manager 抽象，但不只是 Manager 需要抽象。KatServer 中存在很多有共性的地方，他们都可以抽象来享受多态带来的好处，比如 Storage，DatabaseConnector。

4. 非必要请不要使用包装类型

非必要的装箱拆箱会大幅度影响效率。

kat-server/src/main/java/com/catkatpowered/katserver/storage/KatMediaStorage.java

Line 10 in 9f0e35d

public static Boolean putMedia(InputStream inputStream) {

5. Manager 的职责太多了

初始化工作就不应该 manager 做，至少不应该是个 static void Main
完全可以在主类里完成所有组件的装配再统一暴露一个封装啊

6. 有时候暴露的事情太多了

举个例子,KatServer
虽然说很多都是 Repeat-Your-Self，但是其中也不缺乏一些像是 loadExtensions 这种只应该在初始化的时候调用一次的东西...... 甚至还有意义不明的 https://github.com/CatkatPowered/kat-server/blob/9f0e35dd47c80b6d14b510352ccc7df8c6f63a68/src/main/java/com/catkatpowered/katserver/KatServer.java#L70-72

---

就先写这些吧...

🤔 Question: Should `KatResource` and `KatUniMessage` be combined?

KatUniMessage与KatResource中的hash,uri等部分有功能重叠, 目前进行一部分网络模块更改后已不再需要KatResource等对文件的针对性设计。
我初步设计的文件传输流程详见网络部分
现询问其他模块是否会因此次重构受到影响，同时征集更好的方案

🤔Question: 是否应将配置文件从YAML转变为TOML

我认为从YAML转变为TOML有如下优点

• TOML语法相较YAML更易理解
• TOML相较于YAML更易排查错误
• kat-boot使用C++编写，目前未能发现C++有完善安全的YAML解析器，同时为了配置文件统一，建议改为TOML

🤔 Question: Should self-generated certificates be removed?

KatServer 不应当提供过多的自动化功能，个人认为自生成证书不应当 KatServer 完成，更倾向让用户自行生成。

KatServer 不应当提供过于保姆的功能，同时应当尽可能的容易维护，因此个人认为应当移除 KatServer 中的自生成证书功能，这项功能交由用户自行完成或者其他生成方式较为合理。

🥇 Feat: Hello! Extension System!

你好！拓展世界

从设计上看 KatServer 对外放开了很多可操作部分，同时我们也在努力让 KatServer 拥有强大的拓展系统 。

从最初的目标上看我们的初衷也面向拓展 。

随着小目标不断的完成，我们是时候需要集成并且抽象出拓展系统了！

什么是拓展？

拓展是一系列能为 KatServer 提供额外功能的子模块，他们能部分替换 KatServer 内部的模块与功能，提供更加强大的功能并且宏观上提升可自定义性，这些子模块由 Java 或者其他语言编写，总而言之他们能集成到 KatServer 当中，提供不同的功能！

现在的完成度与可自定义模块？

拓展能实现的部分内容依赖于 KatServer 自身的可替换能力，因此我们在下面列出来我们的模块列表及其可替换性。

Module	Replaceable	Stats
📁 Storage	✔	🏗
🍜 Database	✔	🏗
🖧 Network	❌	🏗
🎹 KatMessageType	✔	✔
🎉 Tokenpool	❌	✔
⚙ Config	❌	✔
🚀 EventBus	❌	✔

拓展应当如何使用 KatServer 提供的函数与功能？

我们所有对拓展开放的功能都会写在 KatServer.java 当中，因此直接访问 KatServer 类便可知道我们所有已经抽象出来的功能。

由于部分功能还在开发，因此这些部分将不会被抽象到 KatServer 类当中。可以通过访问 KatXXXManager 直接获取这部分功能。

🤔 Feat: Is it necessary to write our own download utility？

如题所示，当前面临着一个问题：是否需要编写我们自己的下载工具类像是 DownloadUtils.java ?

LocalProvider.java 作为内置的资源文件储存提供者，需要用到一些下载功能，因此当前面临以下问题

若是使用外部依赖：

• 额外庞大的依赖
• 对于文档不熟悉导致整体功能错误
• 可能和此项目集成较差，难以管理

若是此项目自己编写诸如 DownloadUtils.java 的下载工具类

• 可能会增加维护负担。
• 部分下载功能实现困难

从总体上看当前只有 LocalProvider.java 需要使用下载功能，是否有必要因为小部分需求引入额外的依赖，亦或者编写实用工具类？