基于go1.18的workspace和泛型编写，项目使用了多个go module.
由于1.18还不推荐大量使用泛型，所以仅有一些集合功能使用了泛型编写。随着时间的推移，标准库中会自己增加对应C++ STL的功能，这时就不再需要使用自建的数据结构和算法了。
由于go语言不太方便做依赖倒置，也没有类似spring的框架，所以这里封装的都是一些比较简单常用的功能。
├── apm # 分布式链路追踪基础库(openTelemetry)
├── base # 基础库，常用数据结构和utils，log模块
├── db # sqlx + sqlbuiler的封装
├── ginutil # gin封装
├── kgoutil # kgo(kafka lib)封装
├── module # 模块封装，将所有功能统一抽象为模块，提供启动器和模块间类似rpc的相互通信机制
├── nacos # 集成nacos和viper，配置管理和服务注册
├── network # tcp/udp对应module的封装，提供抽象解析器，提供json的一个范例实现
├── pb # protobuf对应于network中抽象解析器的一种实现
├── prom # 普罗米修斯的集成
├── redisutil # redis通信，常用功能，以及分布式锁封装
├── sdp # sdp格式，兼容国标
├── sip # sip通信协议，tcp/udp的transport
└── ws # websocket对应于network/module的封装根据go语言的规定，当多个模块写在同一个repo里时，tag需要按<module>/<version>的格式进行打tag，如base/v1.0.0，所以各个模块拥有不同的版本号。
平时开发可以直接commit然后push，在依赖库里直接使用go get -u升级到最新的master即可。最好不要在master分支直接开发。
在发布时，需要将各个库的依赖改成latest的稳定版本。
由于使用了workspace，所以本地编写代码时，即使go.mod中的依赖版本未更新，也会优先使用本地source. 如果最终push的时候忘了更新go.mod中依赖的版本，
会出现本地能编译但是使用者无法编译的问题。因此在每次push之前，都要检查依赖基础库的版本问题。如果是java使用snapshot的方式，由于每次都自动更新到最新，就没这个顾虑。
所以go mod的管理还是有一些问题的，需要谨慎push. 理论上这些模块使用单独的repo更好，但是由于很多模块里面的代码非常少，这样切来切去也很麻烦，所以目前采用类似java common的集中管理模式。
为了方便发布版本，在根目录有一个release.py的Python脚本，可以用来发布版本并自动更新依赖该版本的其他模块，然后这些模块也会发布一个新版本。
建议不要频繁发布版本，用@master直接拉取最新代码调试的差不多了再更新。或者也可以在本地go.mod里面使用replace到本地进行调试，确认没问题之后再推送到仓库。