OIM微服务即时通讯服务架构

MQ

接入层

3

tcp保持长连接，推送聊天消息

群

系统接入

系统接入服务

业务服务

系统架构图

系统关系图

1

Redis

接口中心

技术管理层服务(对应oim-server-module-core-xxx)

负责均衡

5

4

聊天

关系说明（数字对应上图箭头数字）

网关

TCP/WebSocket长连接服务

接口管理服务

2

http

TCP服务管理

业务端

基础依赖

1、core-cente（注册中心）先启动；接下来启动core-action（接口中心），core-gateway（网关）；net-control（长连接服务的管理服务），net-work（客户端长连接服务，会通过注册中心发现net-control，并建立连接），然后启动work-xxxx一系列业务服务，业务服务会自动上报（core-action）当前服务的所有接口，接口中心（core-action）会自动同步所有业务服务的接口地址到网关服务（core-gateway）和长连接服务（net-work）；2、长连接服务（net-work）和管理服务建立连接（net-control），用来监控（net-work）是否存活，每个net-work服务都有一个MQ队列，当用户建立连接后，net-work与用户的路由关系保存在redis中，当net-work下线或者挂掉，net-control会及时清理用户和net-work的路由关系。3、客户端首先通过负载均衡->微服务网关，网关根据接口中心同步的接口对应服务的关系找到对应发服务->系统接入服务（work-portal），因为客服端需要服务端的地址比较多，全部写死在客户端不够灵活，所有客户端只要配置能够访问网关的地址即可，其他的服务地址配置通过接入服务返回。除了内部局域网可以自动发现相关服务地址，考虑到项目部署方案自由灵活，并且机房、云服务等网络环境复杂，需要手动配置真实可访问地址。4、当用户登录获取到token后，使用token去连接上一步获取到的长连接服务（这里net-work长连接服务为什么没有负载均衡？因为TCP的普通负载服务作为中间转发，既做服务端又做客户端，而作为客户端连接真实服务的时候，客户端发起连接数受到当前系统可用端口问题，理论也就5-6万个连接，这样反而没有意义。如果通过nat更底层的负载，尚未研究），然后进行认证，认证成功便保持连接，并且服务端（net-work）会将用户和服务的路由关系保存到redis，断开连接后服务端会清除关系。5、服务端如果要推送消息给客户端，先从redis获取路由关系，然后把消息丢进对应的MQ，MQ推送给对应的服务端（net-work），然后推送给客户端。6、如果net-work挂掉，net-control会清理挂掉服务的路由关系。

管理端

微服务网关

Nginx

支持一下，帮忙右上角点赞呀

联系人

6

数据库(支持主流多种)

用户

业务层服务(对应oim-server-module-work-xxx)

TCP长连接服务

TCP管理中心

注册中心