相比于使用HTTP协议的常规方案，TARS首先提供的特性就是异步长连接的RPC调用方式：
发起一个异步调用之后，当前线程并不会被阻塞而是继续执行，当收到服务端响应之后在回调线程池中通过回掉函数来执行结果的处理。这样所有的处理线程都一直处于工作的状态中，而不会挂起导致线程资源的浪费。整体上提升了服务的处理能力。
TARS的异步能力主要是通过两个部分的异步来实现的，首先是网络首发包的异步，TARS的网络层实现采用了Reactor模型，通过nio提供的事件IO实现基于事件的异步网络IO。第二是线程模型的异步，我们从线程模型上来看TARS如何是做到异步调用的：
TARS的主要通过上图的过程来完成异步调用，首先主调线程发起异步调用，主调线程将请求内容加入网络线程池的发送队列中，之后该线程继续执行。网络线程池使用Reactor模型实现，通过nio提供的Selecter实现事件IO，所以所有网络线程均是事件驱动的异步IO，当监听到对应连接的写事件后将请求发送，等待监听到读事件后读取响应并交给回调线程处理响应。这样所有的线程都避免了IO阻塞达到了更高的利用效率。
解决SpringCloud服务端基于同步线程模型的稳定性问题
TARS提供了纯异步化编程，和服务端过载保护的能力，在服务端保证收到大量的请求也能够保证服务的正常处理效率，其次因为主调方采用长连接和异步调用，避免了大量新建连接和阻塞带来的资源浪费从而提升了服务的整体稳定性。
此外，如果服务端收到过量的请求往往会导致服务端的线程竞争，让服务端的处理能力低于正常的处理水平，在TARS则通过队列来进行过载保护。我们来看TARS的线程模型：
在网络线程收到请求后，TARS会将请求先加入请求队列，工作线程从请求队列中获取请求进行处理，如果短时间内大量请求到达只会被缓存到请求队列中并不会影响工作线程池的处理能力。如果工作线程池从队列中取到请求发现其已经超时则会直接丢弃请求避免处理无效的请求。
场景．异步调用，避免阻塞，提升性能
假如我们在Spring Cloud中存在这样一个调用关系，A服务需要调用B服务，而B服务需要依赖处理耗时远大于是B服务的C服务。比如在通常的业务场景中，如果API接口需要调用一个订单生成的服务，而订单生成服务只需要生成订单ID计算量相对较小，但是他还需要依赖一个订单写入服务，应为涉及到库存修改、订单写入需要一系列的事务处理，整体耗时远远大于订单ID的生成，所以订单服务大量的线程资源浪费在了等待订单写入服务上。在这种情况下可以使用TARS改造订单服务和写入服务，从而使用异步调用写入服务来提升资源利用率，采用TARS提供的异步RPC能力来进行跟深度的改造：
