在移动互联网快速推动创业浪潮的今天，绝大多数应用在构建之初都将社交元素潜意识的列入到了其产品功能清单中，即时通讯服务作为强社交的载体，又一次强势回归到应用设计者的视野中来。同时也涌现出了大量以即时通讯服务为卖点的产品，如具有代表性的用友IM。
企业级市场，即时通讯服务的产品设计与技术架构也发生了巨大的变化:1、从原本仅支持自身软件业务的场景转变为需支撑线上与线下业务的混合场景；2、服务架构更开放与透明，完全无状态化；3、配合云计算、大数据等成熟技术，支持具备接入海量数据及业务服务的能力；4、支持更多种类的客户端及协议，服务端具备接入适配功能。
从客户端设计角度出发，移动化催生了设备的多样性，保障各终端的使用统一成为了客户端设计的关键。要求即时通讯服务不限制服务接入的方式和协议，不管服务是通过移动网络还是固定网络接入，也不管协议是否支持HTTP、XMPP、MQTT、TCP等，都应可以得到所需消息的响应服务。企业级客户端通常功能比较复杂，需要应用设计者重新划分功能层次，最终可归纳为2种形式(API和SDK)。站在通讯协议角度，应根据客户端自身特点，从轻到重进行技术选型，如：推荐HTML5采用WebSocket协议实现，避免使用HTTP长短轮询及一些RIA插件实现。
客户端形态方面，桌面及移动原生APP对比WEB APP相对较重，通常采用SDK + TCP/UDP实现，应用设计者在设计客户端SDK时候应关注提升性能和扩展性上，通用SDK一般包含线程控制、编解码、锁与资源、粘包丢包、压缩与加密、内存管理等处理模块。
包含即时通讯服务的企业应用客户端也在朝着更简洁、碎片的方向发展，下面重点谈谈如何构建企业级即时通讯的核心“通讯服务”。首先先回顾一下目前即时通讯服务面临的挑战:1、海量通讯数据处理；2、高并发，高事务；3、复杂协议转换；4、大规模集群下稳定性及容灾问题；5、快速通讯消息响应；6、平滑服务扩展；以上6大问题将影响保障通讯服务能力的基础问题。
虽然通过云计算架构、容器架构、微服务架构等流行技术可以解决即时通讯服务中弹性、容灾、自动化及异地网络问题，但是其自身特性决定了其技术的细致程度，类似钟表行业的瑞士，需要追求极致。很难像其他应用一样去适应通用云平台，其中一个简单的例子，即时通讯服务的负载均衡器很少通过软负载去实现，如果采用软负载去实现，负载均衡本身将成为瓶颈点，尤其是在仅维持连接状态的长连场景下。云平台的设计势必要向即时通讯服务倾斜，成为专有云。
针对企业级即时通讯服务本身，企业在构建服务之初，应合理规划接入连接规模的阶段，避免资源浪费和设计的不合理，例如：处理C10K架构和C100K的架构将截然不同。在协议选择上可以划分为多层，客户端接入层选择自定义协议或轻量级的协议，减少数据包体积，网关后几层由于构建在内网或者一个数据中心中，应选择一些扩展性强并且健壮的协议，如：XMPP等。协议加密方面可以设计成插件方式，选择性支持二层、三层、四层加密、过滤等机制，也可使用签名证书。当通讯服务构建完成需要进行2步核心测试，分别是单机0思考压力测试及集群调度测试。
企业级即时“通讯服务”存在一个重要的特点，要求服务具备极高的稳定性，保障消息的可靠不丢失，尤其在移动场景下，例如:2G切换3G又切换4G后到没信号的极端场景下，消息始终不能丢失。这需要服务端在拥有极大并发的情况，保障通讯业务事务的健壮性，不管是通过消息回执的方式，还是消息锁机制保障，目的是一样的。从数据层面考虑，也将面临新的问题“数据持久化”，单纯谈数据持久化可能不是问题，但如果转换成海量消息数据的场景，这又将是一个服务端设计的挑战，消息与消息之间是存在多级关系的，例如：消息A属于用户B，消息A属于群组B中用户A发送给用户B的图片类型消息等。单纯使用关系型数据库和NoSQL数据库是很难解决这个问题，通常需要应用设计者自行设计一套数据散列算法进行消息对象分区，同时服务端还应实现一套查询引擎或数据调度中心。数据存储设计方面应遵循一个原则：“先规划一期规模数据，同时设计升级方案”。当这些都搞定后，数据层面还应考虑提升数据服务的稳定性和安全性，通常云平台是无法实现这些需求，服务可以弹性，但数据无法弹性，这里就需要应用开发者根据稳定性和安全级别设定数据库容灾及弹性方案。
资源存储层面，建议单独部署文件服务器(大、小文件服务器分开)、流媒体服务器。如果规模有限，可以采用开源文件服务器，如FastDFS、MogileFS、MooseFS，或租用第三方存储服务资源。当即时通讯服务中以资源服务为核心时，应考虑自行构建分布式文件系统，通常采用集中式方式实现。
构建企业级“即时通讯”服务已不仅仅是满足一些：单聊、群聊、语音、附件等基础功能，而是要从客户端及服务端两个层面分开考虑，每一个层面侧重点都不同。构建服务之初的规划与设计非常重要，不同的阶段化规模都将影响最终服务的架构。
