Tars源码分析----Application

最新推荐文章于 2022-07-10 23:18:49 发布

gswen

最新推荐文章于 2022-07-10 23:18:49 发布

阅读量3.3k

点赞数

分类专栏： tars 服务器端编程

本文链接：https://blog.csdn.net/Swartz2015/article/details/80710872

版权

本文主要分析了Tars框架中的Application类，它是所有服务的基类，封装了EpollServer并提供服务配置接口。Application负责启动EpollServer，根据配置文件配置Adapter，并提供了服务初始化、析构的控制接口。此外，文章探讨了Tars服务的分层寻址机制，包括服务寻址、servant寻址和RPC method寻址，并解释了为什么servant和adapter需要一一对应。最后，总结了Application的关键接口及其作用，强调了其在服务架构中的核心地位。

摘要由CSDN通过智能技术生成

前言

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

服务进程

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

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

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

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