一个令人吐血的问题

背景：

并行计算时，本机TR服务会调用其它服务器TR服务，进行计算，得到结果，最后本机汇总结果，返回给调用方。

现在有四台服务器，sd,sd1,sd2,sd3。现在把sd配置成软负载，而sd1,sd2,sd3配置成硬负载。

关注点：

本机调用，20个线程，运行10000次，执行两次，直接调用sd的服务，不调用sd1,sd2,sd3，来测试分发功能是否OK。此时只关注分发量是否平均，不关注是并行计算处理内容是否正确。

问题：

进行分发测试后，统计结果，进入到logs/sofa目录下，查看sofa-sal-digest.log文件

grep '10.253.69.103'sofa-sal-digest.log|grep callDataPoint -c 进行统计

发现10.253.69.103这个105109次，而10.253.69.104为0次，而10.253.69.105为106767次，根据平均分配原则，此次104的机器肯定有问题。（数据不完全一致因为有其它调用的原因）

排查：

1. 怀疑服务器未启动，查看java进程及8080/services服务，进程OK，服务OK。

2. 怀疑代码未更新，更新流，重新部署，运行后结果仍不正确。

3. 怀疑服务发布失败，进入sofa-boot.log日志进行查看，发现果然未启动成功。

4. 怀疑TR服务问题，其它TR服务OK。

5. 怀疑配置中心挂掉，服务注册失败，发现配置中心OK，其它TR服务发布成功，且未有出错日志。

6. 怀疑流的信息被改，果然，吐血！

感想：

上述问题是与开发共同排查的，在排查的过程中，发现自己的思路不清晰，而开发比较清楚，原因在于我们对系统的启动流程、SOFA框架不熟悉导致的。因此还要加强框架及部署系统整个流程的关注。我们现在排查系统层面的问题现在还很弱，原因是对这块不了解，所以还是要加强了解，了解的够多，明白调用关系和加载顺序，深入懂得原理，才会手到病除。