基于Tars高并发IM系统的设计与实现-实战篇1

通过前文基础篇，进阶篇的介绍，相信大家已经对IM的基础能力实现，难点及其如何解决有了一个全面的了解与认识。
相信大家都迫不及待想看看一个高性能的IM系统到底怎么设计与实现，从本篇开始主要讲述如何实现一个完整的IM系统。

消息流转整体方案我们采用服务器中转方案：A通过服务器S将信息发给B
在这里插入图片描述

在目前互联网时代，已经有一些大公司提供了不错的开源基础平台供大家使用，站在巨人肩上可以省不少力。

Tars平台作为腾讯近几年推出的一款基础框架，在腾讯内部也适用广泛，以是C++方面开源少有且稳定的技术平台。

笔者通过几年在IM领域对Tars的使用，对该框架也比较熟悉，是目前市场上C++语言IM领域比较适合的开发平台，其本身就是来源于QQ服务平台，对IM领域可以说是有天然的适应性，完全能够满足高可靠，高并发，低延时的基本性能需求。

采用Tars平台总体设计方案，前文已经描述，具体见下图；
在这里插入图片描述

基于Tars框架实现的IM系统设计与实现，我们从下面三章内容着手介绍：

Tars框架
IM服务端实现
IM客户端实现

Tars框架

本章节内容主要来自Tars在线文档：https://doc.tarsyun.com/

基础介绍

Tars是基于名字服务使用Tars协议的高性能RPC开发框架，同时配套一体化的服务治理平台，帮助个人或者企业快速的以微服务的方式构建自己稳定可靠的分布式应用。
Tars是将腾讯内部使用的微服务架构TAF（Total Application Framework）多年的实践成果总结而成的开源项目。Tars这个名字来自《星际穿越》电影中机器人Tars，电影中Tars有着非常友好的交互方式，任何初次接触它的人都可以轻松的和它进行交流，同时能在外太空、外星等复杂地形上，超预期的高效率的完成托付的所有任务。拥有着类似设计理念的Tars也是一个兼顾易用性、高性能、服务治理的框架，目的是让开发更简单，聚焦业务逻辑，让运营更高效，一切尽在掌握。
目前该框架在腾讯内部，有100多个业务、10多万台服务器上运行使用。

设计思想

Tars的设计思路是采用微服务的思想对服务进行治理，同时对整个系统的各个模块进行抽象分层，将各个层次之间相互解耦或者松耦合，如下图：
在这里插入图片描述

最底的协议层，设计思路是将业务网络通信的协议进行统一，以IDL(接口定义语言)的方式，开发支持多平台、可扩展、协议代码自动生成的统一协议。在开发过程中，开发人员只需要关注通讯的协议字段的内容，不需要关注其实现的细节，大大减轻了开发服务时需要考虑的协议是否能跨平台使用、是否可能需要兼容、扩展等问题。
中间的公共库、通讯框架、平台层，设计思路是让业务开发更加聚焦业务逻辑的本身。因此，从使用者的角度出发，封装了大量日常开发过程中经常使用的公共库代码和远程过程调用，让开发使用更简单方便；从框架本身的角度出发，做到高稳定性、高可用性、高性能，这样才能让业务服务运营更加放心；从分布式平台的角度出发，解决服务运营过程中，遇到的容错、负载均衡、容量管理、就近接入、灰度发布等问题，让平台更加强大。
最上面的运营层，设计思路是让运维只需要关注日常的服务部署、发布、配置、监控、调度管理等操作。

整体架构

架构拓扑

整体架构的拓扑图主要分为2个部分：

服务节点
公共框架节点。

服务节点

服务节点可以认为是服务所实际运行的一个具体的操作系统实例，可以是物理主机或者虚拟主机、云主机。随着服务的种类扩展和规模扩大，服务节点可能成千上万甚至数以十万计。每台服务节点上均有一个Node服务节点和N(N>=0)个业务服务节点，Node服务节点会对业务服务节点进行统一管理，提供启停、发布、监控等功能，同时接收业务服务节点上报过来的心跳。

公共框架节点

除了服务节点以外的服务，其他服务节点均归为一类。
公共框架节点，数量不定，为了自身的容错容灾，一般也要求在在多个机房的多个服务器上进行部署，具体的节点数量，与服务节点的规模有关，比如，如果某些服务需要打较多的日志，就需要部署更多的日志服务节点。

又可细分为如下几个部分：

Web管理系统：在Web上可以看到服务运行的各种实时数据情况，以及对服务进行发布、启停、部署等操作；
Registry（路由+管理服务）：提供服务节点的地址查询、发布、启停、管理等操作，以及对服务上报心跳的管理，通过它实现服务的注册与发现；
Patch（发布管理）：提供服务的发布功能；
Config（配置中心）：提供服务配置文件的统一管理功能；
Log（远程日志）：提供服务打日志到远程的功能；
Stat（调用统计）：统计业务服务上报的各种调用信息，比如总流量、平均耗时、超时率等，以便对服务出现异常时进行告警；
Property（业务属性）：统计业务自定义上报的属性信息，比如内存使用大小、队列大小、cache命中率等，以便对服务出现异常时进行告警；
Notify（异常信息）：统计业务上报的各种异常信息，比如服务状态变更信息、访问db失败信息等，以便对服务出现异常时进行告警；

原则上要求全部的节点之间网络互通，至少每台机器的node能够与公共框架节点之间都是可以连通的。

服务交互流程

框架服务在整个系统中运行时，服务之间的交互分：业务服务之间的交互、业务服务与框架基础服务之间的交互。

服务发布流程：在Web系统上传server的发布包到patch，上传成功后，在web上提交发布server请求，由registry服务传达到node，然后node拉取server的发布包到本地，拉起server服务。
管理命令流程：Web系统上的可以提交管理server服务命令请求，由registry服务传达到node服务，然后由node向server发送管理命令。
心跳上报流程：server服务运行后，会定期上报心跳到node，node然后把服务心跳信息上报到registry服务，由registry进行统一管理。
信息上报流程：server服务运行后，会定期上报统计信息到stat，打印远程日志到log，定期上报属性信息到property、上报异常信息到notify、从config拉取服务配置信息。
Client访问Server流程：client可以通过server的对象名Obj间接访问server，Client会从registry上拉取server的路由信息（如ip、port信息），然后根据具体的业务特性（同步或者异步，tcp或者udp方式）访问server(当然client也可以通过ip/port直接访问server)。

web管理系统

在这里插入图片描述

web管理系统主要包含以下功能：

业务管理：包括已部署的服务，以及服务管理、发布管理、服务配置、服务监控、特性监控等；
运维管理：包括服务部署、扩容、模版管理等；

服务结构

框架核心的服务端与客户端实现结构图如下:
在这里插入图片描述

服务端：
- NetThread：收发包，连接管理，多线程(可配置），采用epoll ET触发实现，支持tcp/udp；
- BindAdapter：绑定端口类，用于管理Servant对应的绑定端口的信息操作；
- ServantHandle：业务线程类，根据对象名分派Servant的对象和接口调用；
- AdminServant：管理端口的对象；
- ServantImp：继承Servant的业务处理基类（Servant：服务端接口对象的基类）；
客户端：
- NetThread：收发包，连接管理，多线程(可配置），采用epoll ET触发实现，支持tcp/udp；
- AdapterProxy：具体服务器某个节点的本地代理，管理到服务器的连接，以及请求超时处理；
- ObjectProxy：远程对象代理，负责路由分发、负载均衡、容错，支持轮询/hash/权重；
- ServantProxy：远程对象调用的本地代理，支持同步/异步/单向，Tars协议和非Tars协议；
- AsyncThread：异步请求的回应包处理线程；
- Callback：具体业务Callback的处理基类对象。