[已回复] 关于IM聊天框架升级的一些想法探讨

通过阅读"RinbowChat v11服务端开发者指南-v1.7" 文档已经了解了两项服务。
观点：这两项服务
    1.http 请求 服务。通常都是后端请求接口通过这个服务达成目的

    2.socket(通信协议)请求服务。通常都是 im聊天通过  他来完成
其中包含这个项目包含有：认证授权   聊天 商城  积分 文件 等功能。

第一个问题
   但通过app看还有视频和语音服务等服务  具体代码  我并没有我发现在他在那里

第二个问题 （可以给我更好的建议）
   如果 我上面描述没有问题。那么我想对这个进行改造升级。升级过程   spring boot —> spring cloud 达成现网关一至

最终结构如下
    rainbow-chat-cloud/
├── rainbow-gateway/              # API网关 (Spring Cloud Gateway)
├── rainbow-auth-service/        # 认证授权服务
├── rainbow-chat-service/        # 聊天服务 (GroupChatProcessor, IMAdminProcessor)
├── rainbow-shop-service/       # 商城服务 (ShopProcessor)
├── rainbow-score-service/      # 积分服务 (ScoreProcessor)
├── rainbow-file-service/          # 文件服务 (FileInfoProcessor)
├── rainbow-video-service/     #  视频,语音服务 (VideoVoice)
├── rainbow-im-chat/               # 协议通信（communiProtocol）
├── rainbow-common/              # 公共模块



| **当前技术**              | **Spring Cloud 替代方案**                     |
|---------------------------|-----------------------------------------------|
| 自定义HttpController      | Spring MVC + `@RestController`                |
| 自定义Processor接口       | Spring `@Service` + 业务逻辑层                |
| 自定义DBShell             | Spring Data JPA / MyBatis-Plus                |
| 手动序列化                | Spring Boot 自动JSON序列化                    |
| 无服务注册                | Nacos / Eureka / Consul                       |
| 无配置中心                | Spring Cloud Config / Nacos Config            |
| 无API网关                 | Spring Cloud Gateway                          |
| 无熔断降级                | Sentinel / Resilience4j                       |

如果我按以上改完是否会对性能不友好  或者说其他不兼容
我以上便是我的想法和观点

确实是个好的想法

我来逐条回复你：
---
1、关于音视频音视频服务：

这个是独立的多媒体子系统（市面上几乎所有的有音视频聊天的应用里，音视频都是走的独立子系统和独立的多媒体通道，跟Im本身的服务端是无耦合的）。

至于你说的没有看到音视频服务，你可以在RainbowChat产品交付物压缩包里，看到有“RainbowAV音视频子系统”字眼的两个压缩包，那就是了（里面有源码和独立的文档资料）。

---
2、关你拆分的服务：

1）积分、商城本身就是以前运营产品里遗留的特性，目前来说不建议保留，删除就好了，没有意义。

2）“1”中已经回复了，所以音视频服务在这里也不需要，也不存在。

---
最后：

建议架构的拆分上，有必要拆分的再去拆分，使用的架构和中间件、框架或服务越少越好，因为架构变的复杂、框架依赖变多了之后，那出问题的可能性必然只会多不会少。所以，建议架构设计上尽量克制，先解决有无，之后再考虑更进一步的演进。

补充：im这种系统，服务端的服务，本质上只有两种：即 长连接（所有有关socket实时通信的代码） 和 短连接（所有有关http协议的rest接口和文件上传下载服务等），建议你围绕这两种概念去拆分，会更合理一些，也更清晰一些（其实大厂也都同样都是围绕这两个概念在玩）。切记！