tars framework 源码解读(五) framework 部分章节。框架整体高可用方面的思考

对于业务服务而言。

业务服务在框架中是被管理角色，它必须满足两点，才能框架被框架认为运行中的服务：

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,也不会影响主体流程

标签：服务,db,framework,state,源码,tars,Active,Activating,NodeServer
来源： https://www.cnblogs.com/yylingyao/p/12198439.html