即时通讯软件需要什么开发技术?

作为企业级的即时通讯和融合信息系统，UM联信融合信息平台将通讯技术与计算机软件技术相融合，集成了视频、语音、数据业务，将不同网络中的数据相互转化，为企业和政府用户提供了一套工作协同、信息融合的专业平台。

平台集成了包括文本会话、文件传输、短信收发、网络电话、网络传真、网络会议、视频会等多种沟通方式以及最全面的通讯手段，使用户无论何时、何地，均可使用多种设备随时处理不同系统中的消息，可以有效地保证用户促进工作协同，提升沟通效率，降低通讯费用，响应速度大大提升。

在企业的应用中，UM联信体现了以下几大特点：

◆即时通讯：强加内部沟通，提升管理软件的即时性，提高办公效率

◆统一消息：多系统的统一消息提醒，革命性的将“人找事”转化为“事找人”

◆桌面办公：多门户系统多页面的快速通道，单点登录，一站式验证

◆更安全更可靠的协议，多方式的多形式的数据加密

◆统一通信：带来更多的协作方便性，网络通讯迅速降低沟通成本

◆统一管理：可管可控的统一管理计费控制平台

◆指挥催办：快速智能的消息分发，数据结果分析统计

◆组织结构的统一：方便快速的定位和查找人员，并与之联系协作

◆会议沟通：提供多种形式的会议模式，满足不同会议的需求

◆网络服务人员随时咨询，解决软件问题，提高顾客的满意度

UM联信是企业信息化的最优选择。

UM联信——即时通讯带来的优势

即时通讯：加强内部沟通，提升管理软件的即时性，提高办公效率

现状分析：目前，企业与政府为了提高办公效率，纷纷上了管理软件（比如：OA）。此类软件一般都是基于工作流来实现办公的，基于B\S结构的，属于分时业务系统。该类系统中的消息，需要工作人员时刻关注，需要时刻开着IE页面并且还需要即时刷新，很是麻烦。如果不在系统相关的页面上，一些重要事情往往无法通知相关人士，而得不到到及时的审批而造成事务越积越多，影响了办公效率。那如何解决这种分时业务，实现即时的提醒，是目前的一大困惑；同时，在工作中往往会遇到要发送一些超大的附件（几十兆）给同事，但内部的邮件系统不能支持超大的文件发送，往往要用U盘传递或者文件局域网共享等办法，较繁锁；而在工作中常常要找同事（不在同一间办公室），问问一些相关的紧急事务，电话沟通但往往占线，无法即时沟通，往往要亲自跑一趟，而这，费力又费时，效率也不高。那如何解决同事之间的即时沟通问题，如何传递超大的文件，这也是摆在我们面前的一大困惑。

解决之道：UM联信的即时通讯平台是面向企业级应用的，基于C\S结构的。在面向工作人员的客户端上可以统一呈现单位所有的人员组织信息，这样就可以快速的找到你要找那个同事，并能迅速发起与他的对话，直接拖拽你想发送的超大文件，对方就能立刻看到你发送的消息，立刻就能提示对方接收你的文件。如果对方不在客户端上，没有关系，对于文本消息，UM联信不仅支持离线留言，还提供短信的直接发送；对于文件传输，UM联信也支持离线文件传输，等接收方上线之后，就能马上收到，保证消息的即时性。

而且UM联信还兼容飞鸽传输，同时兼容外网和局域网两部分，基于XMPP（IETF国际标准组织IM通讯标准）、DNS 集群通讯解析，实现S2S（服务器与服务器之间）的通讯服务器集群应用。解决目前企业即时通讯系统不能互联互通的难题，开拓分众即时通讯互联互通的先河，并提供软件插件库扩展增值应用机制，建立最普及的电子商务即时通讯群。

使用UM联信，需安装联信服务器端，客户端通过登录服务器端来进行通讯，服务器端可进行统一管理。（客户端可与软件“飞鸽传书”兼容）适合于各种集团公司、中小企业、分支机构、经济联盟体，政府机关及关联机构，行政事业等实体组织的协同商务工作和组织间的电子商务通讯。同时可用于各种垂直门户、行业网站、电子商务网站、SNS论坛、网吧等网络经营机构的会员沟通。

CIM(CROSS-IM) 一款面向开发者的 IM(即时通讯)系统；同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM 。

借助 CIM 你可以实现以下需求：

下面来看看具体的架构设计。

整体主要由以下模块组成：

cim-server

IM 服务端；用于接收 client 连接、消息透传、消息推送等功能。

支持集群部署。

cim-forward-route

消息路由服务器；用于处理消息路由、消息转发、用户登录、用户下线以及一些运营工具（获取在线用户数等）。

cim-client

IM 客户端；给用户使用的消息终端，一个命令即可启动并向其他人发起通讯（群聊、私聊）；同时内置了一些常用命令方便使用。

整体的流程也比较简单，流程图如下：

所以当我们自己部署时需要以下步骤：

接下来重点看看具体的实现，比如群聊、私聊消息如何流转；IM 服务端负载均衡；服务如何注册发现等等。

IM 服务端

先来看看服务端；主要是实现客户端上下线、消息下发等功能。

首先是服务启动：

由于是在 SpringBoot 中搭建的，所以在应用启动时需要启动 Netty 服务。

从 pipline 中可以看出使用了 Protobuf 的编解码（具体报文在客户端中分析）。

注册发现

需要满足 IM 服务端的水平扩展需求，所以 cim-server 是需要将自身数据发布到注册中心的。

所以在应用启动成功后需要将自身数据注册到 Zookeeper 中。

最主要的目的就是将当前应用的 ip + cim-server-port+ http-port 注册上去。

上图是我在演示环境中注册的两个 cim-server 实例（由于在一台服务器，所以只是端口不同）。

这样在客户端（监听这个 Zookeeper 节点）就能实时的知道目前可用的服务信息。

登录

当客户端请求 cim-forward-route 中的登录接口（详见下文）做完业务验证（就相当于日常登录其他网站一样）之后，客户端会向服务端发起一个长连接，如之前的流程所示：

这时客户端会发送一个特殊报文，表明当前是登录信息。

服务端收到后就需要将该客户端的 userID 和当前 Channel 通道关系保存起来。

同时也缓存了用户的信息，也就是 userID 和 用户名。

离线

当客户端断线后也需要将刚才缓存的信息清除掉。

同时也需要调用 route 接口清除相关信息（具体接口看下文）。

IM 路由

从架构图中可以看出，路由层是非常重要的一环；它提供了一系列的 HTTP 服务承接了客户端和服务端。

目前主要是以下几个接口。

注册接口

由于每一个客户端都是需要登录才能使用的，所以第一步自然是注册。

这里就设计的比较简单，直接利用 Redis 来存储用户信息；用户信息也只有 ID 和 userName 而已。

只是为了方便查询在 Redis 中的 KV 又反过来存储了一份 VK，这样 ID 和 userName 都必须唯一。

登录接口

这里的登录和 cim-server 中的登录不一样，具有业务性质，

为了实现只能一个用户登录，使用了 Redis 中的 set 来保存登录信息；利用 userID 作为 key ，重复的登录就会写入失败。

获取一台可用的路由实例也比较简单：

当然要获取 Zookeeper 中的服务实例前自然是需要监听 cim-server 之前注册上去的那个节点。

具体代码如下：

也是在应用启动之后监听 Zookeeper 中的路由节点，一旦发生变化就会更新内部缓存。

群聊接口

这是一个真正发消息的接口，实现的效果就是其中一个客户端发消息，其余所有客户端都能收到！

流程肯定是客户端发送一条消息到服务端，服务端收到后在上文介绍的 SessionSocketHolder 中遍历所有 Channel（通道）然后下发消息即可。

服务端是单机倒也可以，但现在是集群设计。所以所有的客户端会根据之前的轮询算法分配到不同的 cim-server 实例中。

因此就需要路由层来发挥作用了。

路由接口收到消息后首先遍历出所有的客户端和服务实例的关系。

路由关系在 Redis 中的存放如下：

由于 Redis 单线程的特质，当数据量大时；一旦使用 keys 匹配所有 cim-route: 数据，会导致 Redis 不能处理其他请求。

所以这里改为使用 scan 命令来遍历所有的 cim-route:。

接着会挨个调用每个客户端所在的服务端的 HTTP 接口用于推送消息。

在 cim-server 中的实现如下：

cim-server 收到消息后会在内部缓存中查询该 userID 的通道，接着只需要发消息即可。

在线用户接口

这是一个辅助接口，可以查询出当前在线用户信息。

实现也很简单，也就是查询之前保存 ”用户登录状态的那个去重 set “即可。

私聊接口

之所以说获取在线用户是一个辅助接口，其实就是用于辅助私聊使用的。

一般我们使用私聊的前提肯定得知道当前哪些用户在线，接着你才会知道你要和谁进行私聊。

类似于这样：

在我们这个场景中，私聊的前提就是需要获得在线用户的 userID。

所以私聊接口在收到消息后需要查询到接收者所在的 cim-server 实例信息，后续的步骤就和群聊一致了。调用接收者所在实例的 HTTP 接口下发信息。

只是群聊是遍历所有的在线用户，私聊只发送一个的区别。

下线接口

一旦客户端下线，我们就需要将之前存放在 Redis 中的一些信息删除掉（路由信息、登录状态）。

IM 客户端

客户端中的一些逻辑其实在上文已经谈到一些了。

登录

第一步也就是登录，需要在启动时调用 route 的登录接口，获得 cim-server 信息再创建连接。

登录过程中 route 接口会判断是否为重复登录，重复登录则会直接退出程序。

接下来是利用 route 接口返回的 cim-server 实例信息（ip+port）创建连接。

最后一步就是发送一个登录标志的信息到服务端，让它保持客户端和 Channel 的关系。

自定义协议

上文提到的一些登录报文、真正的消息报文这些其实都是在我们自定义协议中可以区别出来的。

由于是使用 Google Protocol Buffer 编解码，所以先看看原始格式。

其实这个协议中目前一共就三个字段：

目前主要是三种类型，分别对应不同的业务：

心跳

为了保持客户端和服务端的连接，每隔一段时间没有发送消息都需要自动的发送心跳。

目前的策略是每隔一分钟就是发送一个心跳包到服务端：

这样服务端每隔一分钟没有收到业务消息时就会收到 ping 的心跳包：

内置命令

客户端也内置了一些基本命令来方便使用。

比如输入 :q 就会退出客户端，同时会关闭一些系统资源。

当输入 :olu(onlineUser 的简写)就会去调用 route 的获取所有在线用户接口。

群聊

群聊的使用非常简单，只需要在控制台输入消息回车即可。

这时会去调用 route 的群聊接口。

私聊

私聊也是同理，但前提是需要触发关键字；使用 userId;;消息内容 这样的格式才会给某个用户发送消息，所以一般都需要先使用 :olu 命令获取所以在线用户才方便使用。

消息回调

为了满足一些定制需求，比如消息需要保存之类的。

所以在客户端收到消息之后会回调一个接口，在这个接口中可以自定义实现。

因此先创建了一个 caller 的 bean，这个 bean 中包含了一个 CustomMsgHandleListener 接口，需要自行处理只需要实现此接口即可。

自定义界面

由于我自己不怎么会写界面，但保不准有其他大牛会写。所以客户端中的群聊、私聊、获取在线用户、消息回调等业务(以及之后的业务)都是以接口形式提供。

也方便后面做页面集成，只需要调这些接口就行了；具体实现不用怎么关心。

cim 目前只是第一版，BUG 多，功能少（只拉了几个群友做了测试）；不过后续还会接着完善，至少这一版会给那些没有相关经验的朋友带来一些思路。

欢迎工作一到五年的Java工程师朋友们加入Java程序员开发： 721575865

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

在一对一直播交友源码的开发过程中，即时通讯是最关键的功能之一。那一对一直播源码系统是如何实现即时通讯的呢？

即时通讯就是实时语音文字视频等交流，实现即时通讯目前有四种方式：短轮询、长轮询、SSE、websocket，接下来我们来按顺序简单了解一下。

（1）短轮询

即每隔一小段时间就发送一个请求到服务器，服务器返回最新数据然后客户端根据获得的数据来更新界面，这样就间接地实现了即时通信。这一方式的优点是简单，缺点是对服务器的压力较大，浪费带宽的流量，但通常情况下数据都是没有发生改变的。

（2）长轮询

即客户端发送一个请求到服务器，然后服务器查看客户端请求的数据（就是服务器中的数据）是否发生变化，如果发生变化，就会立即响应返回，否则保持这个链接并定期检查最新数据，直到发生了数据更新或者连接超时。因此，客户端连接一旦断开，就会再次发出请求，这样一来，在相同的时间内大大减少了客户端请求服务器的次数。这一方式有一个弊端：服务器长时间的连接会消耗资源，返回数据的顺序无法保证，管理和维护困难。

（3）SSE

即服务器推送事件，为了解决浏览器只能够单向传输数据到服务端，HTML5提供了一种新的技术叫做服务器推送事件SSE。SSE技术提供的是从服务器单向推送数据给浏览器的功能，但是配合浏览器主动请求，实际上就是实现客户端与服务器之间的双向通信。

（4）Websocket

在HTML5中，为了加强web的功能，提供了websocket技术，它不仅是一种web通信方式，也是一种应用层协议。它提供了浏览器和服务器之间原生的全双工跨域通信。通过浏览器和服务器之间所建立的websocket连接，在同一时刻能够实现客户端到服务器和服务器到客户端的数据发送。

网络应用程序设计也叫网络编程。通过使用套接字来达到进程间通信目的编程就是网络编程。代码、开发工具、数据库、服务器架设和网页设计这5部分都要接触。代码分静态代码和动态代码。