Skip to content

基于netty的异步非阻塞实时聊天(IM)服务器。

Notifications You must be signed in to change notification settings

a2888409/face2face

Folders and files

NameName
Last commit message
Last commit date

Latest commit

b3ef5a2 · May 25, 2017
Jan 6, 2017
Jan 6, 2017
Jan 6, 2017
Jan 6, 2017
Jan 6, 2017
Jan 6, 2017
Jan 6, 2017
Apr 22, 2017
Apr 28, 2016
Jan 6, 2017
Jan 29, 2016
Mar 4, 2016

Repository files navigation

face2face

image
auth服务:负责登录认证。
gate服务:负责客户端接入,也是服务器和客户端通信的媒介。
logic服务:负责处理各种业务逻辑。

为以后将服务设计为水平可扩展的服务准备,将整个服务拆分为3个进程。
实现基本功能后的目标是将每个服务设计为可水平扩展的集群,并且重点放在架构上的优化而不是逻辑功能上。

一、QuicksStart:

(a)启动服务器:

  1. 使用intellij maven方式导入该工程,执行mvn clean compile
  2. 在对应模块的resources目录下配置auth、logic服redis数据库地址
  3. 启动redis服务:thirdparty中附带了一个windows cmd命令行可以直接启动的redis进程。只需用cmd进入该目录,执行:redis-server.exe redis.windows.conf
  4. 打开intellij的debug/Run configuration根据工程路径重新配置auth logic gate服务启动项program argument-cfg选项:(比如工程clone在了E盘code目录,那么就把logic的启动项改为-cfg E:\code\face2face\logic\src\main\resources\logic.xml),auth、gate同理。
  5. 按顺序启动logicauthgate服务(因服务间断线重连暂时未加入)

(b)启动客户端
测试注册和登录功能,以及单聊功能(建议跟踪断点):

  • 按照quickstart流程依次启动服务器后,再启动client模块的下的客户端(Client类),服务便会自动执行注册,登录的流程,并每隔100ms给自己发送聊天信息。

二、添加业务逻辑

  • 协议流动方式介绍:客户端先连接gate,gate服务根据客户端发送的协议类型转发到auth服或者logic,到达auth或者logic之后,IO线程将消息dispatch到后端worker线程处理。
  • 定制业务逻辑
    • 只需在三个地方注册协议:protobuf模块的ParseRegistryMap,gate模块的TransferHandlerMap,最后是根据协议类型在auth模块或者logic模块的HandlerManager注册即可。注意:HandlerManager注册的是协议最终处理的业务逻辑。
    • 在protobuf模块对应**.proto文件添加你自己定义的协议,执行proto.bat**即可生成对应pb文件。

三、压力测试

  1. client模块中的client.Client类提供了进行压力测试的方法,可以修改启动客户端连接的数量Client.clientNum,以及每秒向服务器发送的协议的频率Client.frequency进行压力测试。
  2. CPU 8核E3-1231v3, 每个服务分配1G的堆内存,启动5000个客户端后(需要一定时间),不停给自己发送单聊协议,发现auth、logic、gate服务占用的cpu非常低,客户端能够立即收到响应。对应的TPS统计将在后续加入。

四、水平扩展思路(processing)

实际上最简单的做法,就是利用消息中间件对服务之间的调用进行解耦,这里以消息中间件RocketMQ为例子:

    client(Producer) ->  gate(Consumer)

所有用户我们都可以看做是生产者,用户操作对应生产者产生消息,gate网关服此时看做是消费者订阅用户产生的消息。我们使用RocketMQ的顺序消息特性,保证同个用户的消息都转发到同一个消息队列,这样就保证了同个用户操作的先后。

    gate(Producer)   ->  auth(Consumer)
    gate(Producer)   ->  logic(Consumer)

网关服同时又可以看做是生产者,他接收到用户请求后产生逻辑操作消息,这些逻辑操作消息根据不同的类型,又可以被auth服,logic服订阅。auth,logic收到订阅的消息,此时才进行真正的消费。
使用集群模式,消费者是可以任意水平扩展的,rocketmq天生的优势保证了只要生产者消息不丢,即使某个消费者挂了,消息也能够被集群中其他consumer正确消费,但是消费的幂等性要自己保证。