Service chain背景：
带在请求的header上的信息，用来标记当前请求所属环境。支持Dubbo，消息队列，Rest。
比如A调用B，如果A，B都在环境1中，那么走环境1中的A，B实例。如果环境1中没有B实例，走基础环境的B实例，以此来做环境隔离。
prj环境：
相互隔离的项目环境。
StockCenter、trade-core：应用名称。
etcd：注册中心，类似Zookeeper。
sc-context：存储Service chain上下文。
初步现象：ZanProxy配置prj环境，prj环境StockCenter部署成功，扣减一直走到StockCenter的基础环境。
初步诊断：
1. StockCenter扣减的请求走到了基础环境。
2. 怀疑是Service Chain标识中途丢失，查看StockCenter扣减日志，确实没有prj的标。其他环境过来的请求是有prj的标的。
3. 通过调用链排查，在扣减之前的调用链是完整的，到trade-core调用StockCenter调用链丢失。调用链丢失的问题是另外一个问题。
4. debug prj环境的trade-core，可以走到，说明到trade-code是正常的，问题出现trade-code调用StockCenter。
5. 查看etcd接口注册信息，发现StockCenter扣减接口注册正常，排除接口注册问题。
进阶诊断：
1. 找框组同学排查，走远程debug trade-core排查.
2. 远程debug效率较低，先通过调用链找线索。
3. trade-core链路中没有异步逻辑，排除异步造成的sc-context丢失。
3. trade-core在调用StockCenter之前有一系列的调用，在进行了有赞云调用之后，sc-context信息丢失，怀疑这一步出现问题。
4. 使用抓包工具到prj环境的trade-core中进行抓包，定位到修改sc-context的代码位置。
5. 打开有赞云相应类源码，发现确实有读取sc-context进行修改的操作，并且丢失了部分信息。
解决：
1. 找到有赞云同学，修改代码，重新打包并发布了trade-core，问题解决。
总结:
1. 一开始就应该怀疑是Service Chain问题，定位sc-context丢失的地方。
2. 抓包工具要学好，看框架组排查问题效率很高。
网友评论