一、背景
背景：7.14 周一常规发版，本次发版需求中包含：查询交易账单下沉，查询交易记录调用交易中心的 Dubbo 接口。 就当一切按部就班时，在预发环境验收时：发现在国际环境下，切换语言无法展示英文。
🌰如下交易状态、交易类型，需展示英文。 
发现有这个问题，直接上12楼找交易中心对应的开发同学核实。
发现他在看其他线上问题，还得等。。。
向这个同学反馈了这个问题后，他查看了下代码：发现这块代码并没有处理国际化，只是将底层接口透出罢了，但底层方法是支持国际化的。
因为是复用底层方法，只是没有对外开语言，让他先根据站点来判断，国际区的就直接返回英文。
- 从上下文中获取当前站点信息（ThreadLocal）
- 判断当前环境，如果是国内环境则适用中文
java
SiteEnum siteEnum = Context.getSite();
if (siteEnum == SiteEnum.CN) {
Context.setLang("zh");
} else {
Context.setLang("en");
}待发布到测试环境后，再测试一把。
（1）发现问题：请求不稳定
当测试环境发布完成后，以为解决了，但请求几次发现请求不稳定，中英文在那互相切换。
根据当前请求现象，有几个排查方向：
- 测试环境中有多个 pod，可能存在旧的 pod 没有被 kill，还在提供访问
- 有人本地启动应用，直连测试环境，dubbo 服务注册上了，并提供服务
- 代码写的有问题
🧭方向一：有人本地启动应用
这个好解决：
-
问可能负责这个应用的相关人员，均没有本地启动
-
查看 dubbo provider 的 ip，都是容器内部网络
这个可以排查。
🧭方向二：多个 pod 问题
排查了多个环境，发现均已经部署到最新的分支了。
应该不会存在 旧 pod 未 killed 情况。
为以防万一，还是跟运维沟通，帮忙再 k8s 里查看是否存在旧的 pod。
🧭方向三：代码问题
跟这个开发同学，再度 review 了他所写代码，所新增的内容并没有什么问题。
（2）解决问题
针对有问题的请求，直接分析其链路，到底是请求到哪？
排查过程遇到问题：
- traceId关联不上：直接拿应用服务（HTTP）的 traceId，不能直接到交易中心服务去查询
那就取这次 dubbo 的请求返回的 traceId，只需要在加个日志： 
取得打印的日志中的 traceid：c14d60dcb09940c0aebfa1e41de28c70
直接在 sls日志平台搜索： 
Tips：不要加筛选，直接查询。
最后发现是 bill-center-task 这个服务在提供 dubbo 服务，但这个服务是用于后台任务处理的。
- 不应该对外提供服务的。
看下项目工程：一个工程（git仓库）部署为 2 应用：
bill-center是对外提供服务的。bill-center-task是用于后台任务处理，DTS 处理。
工程采用 DDD模式中的 COLA 框架：
问题显而易见了，这位开发同学将 dubbo 接口方法写在了 app 层：导致 task 模块也扫描到对应的 dubbo 服务了，从而对外提供服务。
解决：将对应的 dubbo 接口移动到对应模块的 adapter 层就可以。
二、小结
因为此次排查挺浪费时间的，所以记录下，其中原因有二：
- 测试环境部署时间长：需要等部署好再调试排查
- 代码规范：缺乏深刻的认知和经验，并且没有第二人 review code
好的框架可以减少工程复杂度，但相应的开发人员需具备相应的认知和经验。