来自零点智能社区
一、前言
TAF，一个后台逻辑层的高性能RPC框架，目前支持C++,Java, node 三种语言， 往后可能会考虑提供更多主流语言的支持如 go等，自定义协议JCE，同时也支持HTTP。 它集可扩展协议编解码、高性能RPC通信框架、名字路由与发现、发布监控、日志统计、配置管理等于一体，通过它可以快速用微服务的方式构建自己的稳定可靠的分布式应用，并实现完整有效的服务治理。
当前已开源，易名为“TARS”，赶紧上github去star一下吧。
此系列文章选用Java语言进行描述，先对TAF部署开发环境、相关概念和整体架构做介绍，后面分taf-server、taf-client两部分展开，相关文档不多，主要从代码上进行理解。
二、部署开发环境
1. 部署
TAF的部署有管理平台的支持，如果是147或213测试环境，申请服务节点和部署都不需要管理人员的审批，已经接入docker环境，按需申请，上线成功后支持动态扩容，非常方便，使用完关闭下线即可。
2. 开发
需要使用maven进行项目管理，引入如下依赖：
<dependencies> <dependency> <groupId>qq-central</groupId> <artifactId>taf-server</artifactId> <version>3.0.0-SNAPSHOT</version> </dependency> <dependency> <groupId>qq-central</groupId> <artifactId>taf-proxy</artifactId> <version>3.0.0-SNAPSHOT</version> </dependency> </dependencies>
然后需要在code平台上创建一个svn代码仓库，将创建好对应的位置填写到管理平台的编译选项中，这样平台就可以直接从你填写的位置去拉取代码到编译机上进行编译了。注意：代码仓库需要添加一个用户svn_taf 的读权限；当然也可以采用其他的编译方式，如申请编译机和开发机，可km上查找并理解区分一下taf 测试机，编译机，开发机。
最后需要有一个mnet 跳板机，这个需要leader审批，申请之后安装go工具用来远程登录taf节点看日志，这样准备工作就基本完成了。
在开发中只需要关注业务逻辑实现即可，但如果想进一步了解清楚框架底层的机制和实现，后面的文章将进行相关探讨。
部署开发过程如下图所示：
三、整体交互流程
官方文档的这张图再清晰不过了
其中registry为主控服务，提供路由查询； 另外这里的patch为发布服务请求，传达到patch服务后由node服务在各个节点上拉起；
petsvr服务会定期上报心跳到node服务，由node服务统一将心跳上报registry，我觉得这样是要比单独一个个上报更加高效的，同时可以向petsvn发送管理admin命令；
下面的各个服务节点就是TAF提供的运营支持，定期上报统计信息到stat，打印远程日志到log，定期上报属性信息到property、上报异常信息到notify、从config拉取服务配置信息 ；
最后需要注意，Java部分代码没有主控的实现，仅包括Server和Client端，但在使用上只要将registry，node和各个运营服务部署运行成功，服务之间都是可以通过走JCE协议进行交互的。
四、配置管理
TAF有配置管理服务，此外管理平台上也有许多配置项，代码中有很多地方都会从配置文件中读取配置项的，容易搞混，这里先简单做个介绍。
服务上线后，跳板机登录进入到目录 /usr/local/app/taf，展开目录结构如下：
├── app_log -> /dockerdata └── app.service ├── bin │ ├── apps │ ├── conf │ ├── lib │ └── log ├── conf │ └── app.service.config.conf └── data └── tafnodes.dat
其中：app.service为你上线服务对应的应用名和服务名；
apps目录下的ROOT即为项目代码资源所在位置；
管理平台的服务配置项上添加的配置文件，可push或拉取到本地 bin/conf 目录；
另外，有三个重要的默认目录提一下，
应用根目录：basepath=/user/local/app/taf/app.service/bin 日志目录：logpath=/user/local/app/taf/app_log 数据目录：datapath=/user/local/app/taf/app.service/data
当然以上这些配置你也在配置文件中看到，管理平台上的操作为：
服务管理页中，点击私有模版可对模版进行更改；
点击Servant管理页可对单个服务的最大连接数，线程数，线程池大小，是否灰度等选项进行更改，如下图：
五、RPC
RPC（Remote Procedure Call），即远程过程调用，可理解为一种通信协议，该协议允许运行于一台计算机的程序调用另一台计算机的子程序。使用RPC框架的好处就是不需要额外编写网络交互这部分代码了，这部分代码编写上也极容易出错，因此框架相当于在Socket层之上做了一层可靠的应用层封装。另外，远程调用涉及数据包的编解码，框架通常会定义接口描述语言（Interface Description Language，IDL），方便跨平台的远程过程调用。
TAF框架正是提供了以上问题的完整方案，服务端采用异步NIO通信模式，客户端可支持同步或异步调用； 数据编码提供了JCE协议支持，同时支持编写IDL运行脚本实现代码自动生成。从某种意义来说，我觉得可以简化跨语言混合编程，
在服务端处理客户端的并发请求中，TAF实现上采用了Reactor多线程模式，这里贴两张网上看到觉得比较好的NIO时序图，有利于理解。
服务端：
客户端：
下节单独对TAF线程模型做介绍。
感谢阅读，有错误之处还请不吝赐教。
上周答辩结束，终于有时间把之前整理的整理一下
这段时间的实习还是收获良多，除了技术上的，还有思维逻辑和方法论上的吧，有许多的致谢，留待以后慢慢言谢吧
0827 update：
不知不觉已完成了预期的总结，该系列文章汇总如下，欢迎阅读指教，交流学习：
TAF-必修课（一）：整体架构理解
TAF-必修课（二）：Reactor多线程模型
TAF-必修课（三）：Server启动全过程
TAF-必修课（四）：过载保护
TAF-必修课（五）：Client端调用
TAF-必修课（六）：容错
TAF-必修课（七）：负载均衡
当然，TAF相关的内容远不止这些，比如这里暂时没有具体探讨的还有：协议、IDC分组、Set部署、就近接入、日志相关、消息染色、配置中心、运营监控服务等；
计划往后继续深入学习慢慢补充，或许还可以搞成一个系列，再升级到选修课 …..（先给自己定个小目标，比如 * * *是吧）
由于水平有限，文章难免有错误或纰漏之处，请各位看官不吝赐教
