客户端，服务端概念
每个服务进程，都是有且只有一个Application核心类。这里类继承于BaseNotify。作用可以理解成把所有初始化，消息通知，内部对象管理汇总类
在tars的概念中，有两套网络及实现管理部分。
一部分称之为服务端，实现了 提供功能给别的服务或者pc,web,h5等等各种客户端调用的。我们一般写的业务逻辑代码，严格来说是撸服务端代码。
另一部分称之为客户端，此客户端不是一般意义上理解的pc,web这种。而是指我们服务调用其他服务时候，我们服务的角色。作为一个客户端RPC请求别的服务。
简单的理解 对于一个服务而言，客户端是 调用别人时候的 这套网络及逻辑管理代码；服务端是 被别人调用时候的 这套网络及逻辑管理代码
这两部分的实现流程，参考《服务端流程》，《客户端流程》下相关内容。
tc_mysql 关于db操作部分的记录
1、框架的所有db操作 都用try catch包起来，操作失败都会抛异常，并打出对应log
2、所有对db相关的逻辑操作。都是先写db。写db成功后再更改内存逻辑数据
3、tc_mysql的mysql api都是阻塞式的??
4、另外 tc_mysql的queryRecord传出的参数都是TC_Mysql::MysqlData类型 实际数据存放全部都是key:value 一对string。这对于部分极度要求性能的查询来说就有点浪费cpu了，此时还是自己调用mysql api定制对应的查询实现
5、tc_mysql的所有字符串都是用ostringstream 来生成。这种比string操作起来要简单少了很多类型转换和+号 值得学习下
文件配置相关介绍
配置分两种 一种是config。一种是property
业务相关配置为config 一般是在发布平台配置push推送的那种配置。这种比较简单，只要是个xml，自己想怎么定就怎么定，在此不做介绍
服务器相关配置为property。就是代码目录中，tars.tarsconfig.config.conf这类配置文件。在服务器bin相关路径下会有文件，服务启动后就去读取,一般格式如下:
<tars>
<application>
enableset=n
setdivision=NULL
<server>
app=tars
server=tarsAdminRegistry
...
</server>
</application>
</tars>
这两种文件都是通过tc_config去解析读取.
在Application类中的对应处理函数是:
cmdLoadConfig和cmdLoadProperty
tars的Notify流程中 Servant部分的实现
NotifyObserver是进程内的全局命令管理者
Application继承于BaseNotify，每TARS_ADD_ADMIN_CMD_PREFIX和TARS_ADD_ADMIN_CMD_NORMAL都会绑定一个string与一个函数 放在NotifyObserver的map<string, set<BaseNotify*> >对象中.
> * TARS_ADD_ADMIN_CMD_PREFIX：添加前置的命令处理方法，在所有Normal方法之前执行，多个前置方法之间顺序不确定
> * TARS_ADD_ADMIN_CMD_NORMAL：添加Normal命令处理方法，在所有前置方法最后执行，多个Normal方法之间顺序不确定
这两个宏 在使用的时候会将一个string做key 与一个函数映射起来.当有NotifyObserver中的Notify(key)被执行时，会根据此key找到对应的BaseNotify再调用BaseNotify->notify(key)。找到对应函数去执行。
比如平台发更新文件通知过来，此命令是在Application启动时候 绑定好的.
#define TARS_CMD_LOAD_CONFIG "tars.loadconfig" //从配置中心, 拉取配置下来: tars.loadconfig filename
TARS_ADD_ADMIN_CMD_PREFIX(TARS_CMD_LOAD_CONFIG, Application::cmdLoadConfig)
那么一收到 tars.loadconfig消息 就会直接去执行Application::cmdLoadConfig函数.
如果你代码中要绑定命令与处理函数。照例直接调用上面两个宏即可