Tars源码分析----Application

前言

Application是相对于EpollServer来说更靠近上层的类。它是所有服务的基类。Tars的核心功能是可以方便地构建各种类型的服务，因此Application类作用是非常核心的。每一个以Tars为基础构建的服务都需要从Application继承而来。从更底层的角度来看的话，Application是对EpollServer的一次封装，一定程度上可以说它连接了上层的服务实现者和下层的EpollServer组件。它为服务实现者提供了很多操作EpollServer的接口，使得服务实现者不需要过多关注EpollServer中的细节。

服务进程

从用户的角度来说，Tars是一个服务集合。用户可见的所有tars系统的关键组件，包括Patch，Log，Registry，Config，Notify等等(可参考Tars架构图)都是一个个的服务进程，这些是系统自身提供的元服务，为系统提供对用户服务的管理功能。当然Tars用户需要做的也是在Tars添加自己的服务，供客户端使用。

这里关注的是为用户提供的RPC服务。如上图所示，可以看到一个RPC调用过程需要涉及到三个寻址：

1. 服务寻址，这个是进程层面，一般根据ip地址和端口完成；
2. servant寻址，由具体的服务来完成；
3. RPC method，由实现该method的servant来完成。

1比较简单，在配置服务时进行系统设置即可，与服务代码关系不大。2和3则需要服务的实现者编码实现。当然，由于这些算法都存在一定的共性，因此可以针对性的提供一些标准的实现。比如对于包含servant的服务，Tars为服务提供了ServantHandle来进行servant寻址处理，这得益与EpollServer为adapter提供的可插入Handle接口。同时Tars利用自动代码生成