对于业务服务而言。
业务服务在框架中是被管理角色，它必须满足两点，才能框架被框架认为运行中的服务：
1、可被框架找到，所以要在NodeServer的ServerFactory中必须有正确的ServerObject相关信息，可以通过application+serverName找到对应信息，并且该信息被标记成 Activity中。
2、在db的t_server_conf中，其必须被置为Activity，并且有pid。
要保证这2点，那么最主要是保证服务的state正确。
在db中 stage有两个字段setting_state表示设置想要的启动状态(操作平台可用activity和inactivity去更改服务状态)，present_state表示当前服务进程的状态。
在启动操作时：
1]AdminReg先将db中的setting_state状态设置成tars::Acitive
2]调用NodeServer->startServer启动，在NodeServer中，先将ServerObject中的服务状态设置成Activating （此时不通知regisrty写db。checkpid成功后再通知）
3]在执行完启动命令，进程起来之后再通知registry将t_server_conf中的present_state字段置为Activating 。
注意，Activating表示在启动中，Active表示在运行中。那么服务的present_state在何时变成Active呢？
NodeServer有个KeepAliveThread线程，此线程会不停的与registry发送心跳。当服务还是在Activating,如果有monitorScript，并执行此monitorScript检测pid成功的话，ServerObject会调用keepAlive()，将服务状态改成Active并通过registry同步到db字段中；在每次发送心跳成功之后，都会将ServerObject中的服务状态更改成Active .并通过registry异步通知主控更新对应db字段中的值.
完全没看懂。。monitorScript看起来是在tarsnode/util/monitor.sh？？但看这个脚本的内容又不像
从代码设计层面怎样保证代码的高鲁棒性.
每个环节都用try-catch包起来；出错流程立刻中断；在目标逻辑完成之后，再做更新标记，写db这些操作；对于关键流程，db中的标记状态，需要通过定时操作 保证可以将正确的标记同步到db 即使在之前关键步骤突然core,也不会影响主体流程