Java实现即时聊天：聊天服务器＋聊天客户端＋Web管理控制台

一、前言

说实话&＃xff0c;写这个玩意儿是我上周刚刚产生的想法&＃xff0c;本想写完后把代码挂上来赚点积分也不错。写完后发现这东西值得写一篇文章&＃xff0c;授人予鱼不如授人以渔嘛&＃xff08;这句话是这么说的吧&＃xff09;&＃xff0c;顺便赚点应届学生MM的膜拜那就更妙了。然后再挂一个收款二维码&＃xff0c;一个人1块钱&＃xff0c;一天10000个人付款&＃xff0c;一个月30万&＃xff0c;一年360万。。。可了不得了&＃xff0c;离一个亿的小目标就差几十年了。

好了&＃xff0c;不说梦话了&＃xff0c;现在我们回到现实中&＃xff0c;这篇博文如果能有>2个评论&＃xff0c;我后续会再出一个Netty相关的专栏。否则&＃xff0c;就不出了。有人会好奇&＃xff0c;为什么把阈值定义成>2呢&＃xff1f;不为什么&＃xff0c;因为我肯定会先用我媳妇儿的号留个言&＃xff0c;然后用自己的号留个言。

好了&＃xff0c;废话不多说了&＃xff0c;后面还有好多事儿呢&＃xff0c;洗菜、做饭、刷碗、跪搓衣。。。好了&＃xff0c;言归正传吧。

二、最终效果

为什么先看最终效果&＃xff1f;因为此刻代码已经撸完了。更重要的是我们带着感官的目标去进行后续的分析&＃xff0c;可以更好地理解。标题中提到了&＃xff0c;整个工程包含三个部分&＃xff1a;

1、聊天服务器

聊天服务器的职责一句话解释&＃xff1a;负责接收所有用户发送的消息&＃xff0c;并将消息转发给目标用户。

聊天服务器没有任何界面&＃xff0c;但是却是IM中最重要的角色&＃xff0c;为表达敬意&＃xff0c;必须要给它放个效果图&＃xff1a;

从效果图我们看到了一些内容&＃xff1a;收到心跳包、收到消息&＃xff0c;转发消息&＃xff0c;这些内容后面会详细讲解。

2、聊天客户端

聊天客户端的职责一句话解释&＃xff1a;登陆&＃xff0c;给别人发聊天内容&＃xff0c;收其它人发给自己的聊天内容。

下面为方便演示&＃xff0c;我会打开两个客户端&＃xff0c;用两个不同用户登陆&＃xff0c;然后发消息。

3、Web管理控制台

目前只做了一个账户管理&＃xff0c;具体看图吧&＃xff1a;

三、需求分析

无&＃xff08;见第二章节&＃xff09;。

四、概要设计

1、技术选型

1&＃xff09;聊天服务端

聊天服务器与客户端通过TCP协议进行通信&＃xff0c;使用长连接、全双工通信模式&＃xff0c;基于经典通信框架Netty实现。

那么什么是长连接&＃xff1f;顾名思义&＃xff0c;客户端和服务器连上后&＃xff0c;会在这条连接上面反复收发消息&＃xff0c;连接不会断开。与长连接对应的当然就是短连接了&＃xff0c;短连接每次发消息之前都需要先建立连接&＃xff0c;然后发消息&＃xff0c;最后断开连接。显然&＃xff0c;即时聊天适合使用长连接。

那么什么又是全双工&＃xff1f;当长连接建立起来后&＃xff0c;在这条连接上既有上行的数据&＃xff0c;又有下行的数据&＃xff0c;这就叫全双工。那么对应的半双工、单工&＃xff0c;大家自行百度吧。

2&＃xff09;Web管理控制台

Web管理端使用SpringBoot脚手架&＃xff0c;前端使用Layuimini&＃xff08;一个基于Layui前端框架封装的前端框架&＃xff09;&＃xff0c;后端使用SpringMVC&＃43;Jpa&＃43;Shiro。

3&＃xff09;聊天客户端

使用SpringBoot&＃43;JavaFX&＃xff0c;做了一个极其简陋的客户端&＃xff0c;JavaFX是一个开发Java桌面程序的框架&＃xff0c;本人也是第一次使用&＃xff0c;代码中的写法都是网上查的&＃xff0c;这并不是本文的重点&＃xff0c;有兴趣的仔细百度吧。

4&＃xff09;SpringBoot

以上三个组件&＃xff0c;全部以SpringBoot做为脚手架开发。

5&＃xff09;代码构建

Maven。

2、数据库设计

我们只简单用到一张用户表&＃xff0c;比较简单直接贴脚本&＃xff1a;

这张表都在什么时候用到&＃xff1f;

1&＃xff09;Web管理端登陆的时候&＃xff1b;

2&＃xff09;聊天客户端将登陆请求发送到聊天服务端时&＃xff0c;聊天服务端进行用户认证&＃xff1b;

3&＃xff09;聊天客户端的好友列表加载。

3、通信设计

本节将会是本文的核心内容之一&＃xff0c;主要描述通信报文协议格式、以及通信报文的交互场景。

1&＃xff09;报文协议格式

下面这张图应该能说明99%了&＃xff1a;

剩下的1%在这里说&＃xff1a;

a&＃xff09;粘包问题&＃xff0c;TCP长连接中&＃xff0c;粘包是第一个需要解决的问题。通俗的讲&＃xff0c;粘包的意思是消息接收方往往收到的不是“整个”报文&＃xff0c;有时候比“整个”多一点&＃xff0c;有时候比“整个”少一点&＃xff0c;这样就导致接收方无法解析这个报文。那么上图中的头8个字节就为了解决这个问题&＃xff0c;接收方根据头8个字节标识的长度来获取到“整个”报文&＃xff0c;从而进行正常的业务处理&＃xff1b;

b&＃xff09;2字节报文类型&＃xff0c;为了方便解析报文而设计。根据这两个字节将后面的json转成相应的实体以便进行后续处理&＃xff1b;

c&＃xff09;变长报文体实际上就是json格式的串&＃xff0c;当然&＃xff0c;你可以自己设计报文格式&＃xff0c;我这里为了方便处理就直接放json了&＃xff1b;

d&＃xff09;当然&＃xff0c;你可以把报文设计的更复杂、更专业&＃xff0c;比如加密、加签名等。

2&＃xff09;报文交互场景

a&＃xff09;登陆

b&＃xff09;发送消息-成功

c&＃xff09;发送消息-目标客户端不在线

d&＃xff09;发送消息-目标客户端在线&＃xff0c;但消息转发失败

五、编码实现

前面说了那么多&＃xff0c;现在总得说点有用的。

1、先说说Netty

Netty是一个相当优秀的通信框架&＃xff0c;大多数的顶级开源框架中都有Netty的身影。具体它有多么优秀&＃xff0c;建议大家自行百度&＃xff0c;我不如百度说的好。我只从应用方面说说Netty。应用过程中&＃xff0c;它最核心的东西叫handler&＃xff0c;我们可以简单理解它为消息处理器。收到的消息和出去的消息都会经过一系列的handler加工处理。收到的消息我们叫它入站消息&＃xff0c;发出去的消息我们叫它出站消息&＃xff0c;因此handler又分为出站handler和入站handler。收到的消息只会被入站handler处理&＃xff0c;发出去的消息只会被出站handler处理。
举个例子&＃xff0c;我们从网络上收到的消息是二进制的字节码&＃xff0c;我们的目标是将消息转换成java bean&＃xff0c;这样方便我们程序处理&＃xff0c;针对这个场景我设计这么几个入站handler&＃xff1a;

1&＃xff09;将字节转换成String的handler&＃xff1b;

2&＃xff09;将String转成java bean的handler&＃xff1b;

3&＃xff09;对java bean进行业务处理的handler。

发出去的消息呢&＃xff0c;我设计这么几个出站handler&＃xff1a;

1&＃xff09;java bean 转成String的handler&＃xff1b;

2&＃xff09;String转成byte的handler。

以上是关于handler的说明。

接下来再说一下Netty的异步。异步的意思是当你做完一个操作后&＃xff0c;不会立马得到操作结果&＃xff0c;而是有结果后Netty会通知你。通过下面的一段代码来说明&＃xff1a;

上面的writeAndFlush操作无法立即返回结果&＃xff0c;如果你关注结果&＃xff0c;那么为他添加一个listener&＃xff0c;有结果后会在listener中响应。

到这里&＃xff0c;百度上搜到的Netty相关的代码你基本就能看懂了。

2、聊天服务端

首先看主入口的代码

代码中除了initChannel方法中的代码&＃xff0c;其他代码都是固定写法。那么什么叫固定写法呢&＃xff1f;通俗来讲就是可以Ctrl&＃43;c、Ctrl&＃43;v。

下面我们着重看initChannel方法里面的代码。这里面就是上面讲到的各种handler&＃xff0c;我们下面挨个讲这些handler都是干啥的。

1&＃xff09;IdleStateHandler。这个是Netty内置的一个handler&＃xff0c;既是出站handler又是入站handler。它的作用一般是用来实现心跳监测。所谓心跳&＃xff0c;就是客户端和服务端建立连接后&＃xff0c;服务端要实时监控客户端的健康状态&＃xff0c;如果客户端挂了或者hung住了&＃xff0c;服务端及时释放相应的资源&＃xff0c;以及做出其他处理比如通知运维。所以在我们的场景中&＃xff0c;客户端需要定时上报自己的心跳&＃xff0c;如果服务端检测到一段时间内没收到客户端上报的心跳&＃xff0c;那么及时做出处理&＃xff0c;我们这里就是简单的将其连接断开&＃xff0c;并修改数据库中相应账户的在线状态。

现在开始说IdleStateHandler&＃xff0c;第一个参数叫读超时时间&＃xff0c;第二个参数叫写超时时间&＃xff0c;第三个参数叫读写超时时间&＃xff0c;第四个参数时时间单位秒。这个handler表达的意思是当25秒内没读到客户端的消息&＃xff0c;或者20秒内没往客户端发消息&＃xff0c;就会产生一个超时事件。那么这个超时事件我们该对他做什么处理呢&＃xff0c;请看下一条。

2&＃xff09;HeartBeatHandler。结合a&＃xff09;一起看&＃xff0c;当发生超时事件时&＃xff0c;HeartBeatHandler会收到这个事件&＃xff0c;并对它做出处理&＃xff1a;第一将链接断开&＃xff1b;第二讲数据库中相应的账户更新为不在线状态。

3&＃xff09;StringLengthFieldDecoder。这是个入站handler&＃xff0c;他的作用就是解决上面提到的粘包问题&＃xff1a;

只需要集成Netty提供的LengthFieldBasedFrameDecoder 类&＃xff0c;并重写getUnadjustedFrameLength方法即可。

首先看构造方法中的5个参数。第一个表示能处理的包的最大长度&＃xff1b;第二三个参数应该结合起来理解&＃xff0c;表示长度字段从第几位开始&＃xff0c;长度的长度是多少&＃xff0c;也就是上面报文格式协议中的头8个字节&＃xff1b;第四个参数表示长度是否需要校正&＃xff0c;举例理解&＃xff0c;比如头8个字节解析出来的长度&＃61;包体长度&＃43;头8个字节的长度&＃xff0c;那么这里就需要校正8个字节&＃xff0c;我们的协议中长度只包含报文体&＃xff0c;因此这个参数填0&＃xff1b;最后一个参数&＃xff0c;表示接收到的报文是否要跳过一些字节&＃xff0c;本例中设置为8&＃xff0c;表示跳过头8个字节&＃xff0c;因此经过这个handler后&＃xff0c;我们收到的数据就只有报文本身了&＃xff0c;不再包含8个长度字节了。

再看getUnadjustedFrameLength方法&＃xff0c;其实就是将头8个字符串型的长度为转换成long型。重写完这个方法后&＃xff0c;Netty就知道如何收一个“完整”的数据包了。

4&＃xff09;StringDecoder。这个是Netty自带的入站handler&＃xff0c;会将字节流以指定的编码解析成String。

5&＃xff09;JsonDecoder。是我们自定义的一个入站handler&＃xff0c;目的是将json String转换成java bean&＃xff0c;以方便后续处理&＃xff1a;

这里会调用我们自定义的一个编解码帮助类进行转换&＃xff1a;

6&＃xff09;BussMessageHandler。先看这个入站handler&＃xff0c;是我们的一个业务处理主入口&＃xff0c;他的主要工作就是将消息分发给线程池去处理&＃xff0c;另外还负载一个小场景&＃xff0c;当客户端主动断开时&＃xff0c;需要将相应的账户数据库中状态更新为不在线。

接下来还差线程池的处理逻辑&＃xff0c;也非常简单&＃xff0c;就是将任务封装成executor然后交给线程池处理&＃xff1a;

接下来看一下消息转发executor是怎么做的&＃xff1a;

整体逻辑&＃xff1a;一获取要把消息发给那个账号&＃xff1b;二获取该账号对应的连接&＃xff1b;三在此连接上发送消息&＃xff1b;四获取消息发送结果&＃xff0c;将结果发给消息“发起者”。

下面是登录处理的executor&＃xff1a;

登陆逻辑也不复杂&＃xff0c;登陆成功则更新用户在线状态&＃xff0c;并且无论登陆成功还是失败&＃xff0c;都会返一个登陆应答。同时&＃xff0c;如果登陆校验失败&＃xff0c;在返回应答成功后&＃xff0c;需要将链接断开。

7&＃xff09;JsonEncoder。最后看这个唯一的出站handler&＃xff0c;服务端发出去的消息都会被出站handler处理&＃xff0c;他的职责就是将java bean转成我们之前定义的报文协议格式&＃xff1a;

8&＃xff09;SessionManager。剩下最后一个东西没说&＃xff0c;这个是用来保存每个登陆成功账户的链接的&＃xff0c;底层是个map&＃xff0c;key为用户账户&＃xff0c;value为链接&＃xff1a;

到这里&＃xff0c;整个服务端的逻辑就走完了&＃xff0c;是不是&＃xff0c;很简单呢&＃xff01;

3、聊天客户端

客户端中界面相关的东西是基于JavaFX框架做的&＃xff0c;这个我是第一次用&＃xff0c;所以不打算讲这块&＃xff0c;怕误导大家。主要还是讲Netty作为客户端是如何跟服务端通信的。

按照惯例&＃xff0c;还是先贴出主入口&＃xff1a;

对这段代码&＃xff0c;我们主要关注这几点&＃xff1a;一所有handler的初始化&＃xff1b;二connect服务端。

所有handler中&＃xff0c;除了bussMessageHandler是客户端特有的外&＃xff0c;其他的handler在服务端章节已经讲过了&＃xff0c;不再赘述。

1&＃xff09;先看连接服务端的操作。首先发起连接&＃xff0c;连接成功后发送登陆报文。发起连接需要对成功和失败进行处理。发送登陆报文也需要对成功和失败进行处理。注意&＃xff0c;这里的成功失败只是代表当前操作的网络层面的成功失败&＃xff0c;这时候并不能获取服务端返回的应答中的业务层面的成功失败&＃xff0c;如果不理解这句话&＃xff0c;可以翻看前面讲过的“异步”相关内容。

2&＃xff09;BussMessageHandler。整体流程还是跟服务端一样&＃xff0c;将受到的消息扔给线程池处理&＃xff0c;我们直接看处理消息的各个executor。

先看客户端发出登陆请求后&＃xff0c;收到登陆应答消息后是怎么处理的&＃xff08;这段代码可以结合1&＃xff09;的内容一起理解&＃xff09;&＃xff1a;

接下来看客户端是怎么发聊天信息的&＃xff1a;

实际上&＃xff0c;到这里通信相关的代码已经贴完了。剩下的都是界面处理相关的代码&＃xff0c;不再贴了。

客户端&＃xff0c;是不是&＃xff0c;非常简单&＃xff01;

4、Web管理端

Web管理端可以说是更没任何技术含量&＃xff0c;就是Shiro登陆认证、列表增删改查。增删改没什么好说的&＃xff0c;下面重点说一下Shiro登陆和列表查询。

1&＃xff09;Shiro登陆

首先定义一个Realm&＃xff0c;至于这是什么概念&＃xff0c;自行百度吧&＃xff0c;这里并不是本文重点&＃xff1a;

接下来把这个Realm注册成Spring Bean&＃xff0c;同时定义过滤链&＃xff1a;

到现在为止&＃xff0c;Shiro配置好了&＃xff0c;下面看如何调起登陆&＃xff1a;

登陆代码就这么愉快的完成了。

2&＃xff09;列表查询

查是个很简单的操作&＃xff0c;但是却是所有web系统中使用最频繁的操作。因此&＃xff0c;做一个通用性的封装&＃xff0c;非常有必要。以下代码不做过多讲解&＃xff0c;初级工程师到高级工程师&＃xff0c;就差这段代码了&＃xff08;手动捂脸&＃xff09;&＃xff1a;

a&＃xff09;Controller

b&＃xff09;Service

c&＃xff09;Dao

五、结语

本文确实都是实实在在的干货&＃xff0c;希望本文能对大家有一些帮助&＃xff0c;源代码工程不打算贴了&＃xff0c;希望你能跟着文章自己手敲一遍。

最新BAT java经典必考面试题链接&＃xff1a;https://pan.baidu.com/s/1B_Lc1tluda0fbdrFnexOMQ
提取码&＃xff1a;gw8d