前言
工作中，随着部门组织架构调整或者业务变更，我们都会接触到一些“新业务”，这些“新业务”有个特点：运行年限长、业务复杂 、代码复杂，想想是不是头大。更让人头疼的点是还要在其需求上开发且需要保证现有接口的性能，这时是不是想脱口一句“CNM”，纯属扯淡，但现实还是得默默低头去设计评审和开发 😂。
讨论
回归正题，现实中当我们需要在历史代码基础上开发时，可能都会遇到一个问题：接口重复调用问题。那该问题如何解决了，可能大家都会想到 封装重构 。在工作中这个真的有用吗？ 这个问题其实值得我们思考的， 关于该话题不再继续在文章继续讨论（ps：可以问答区交流）。
案例
描述： 工作中都会遇到下面一种情况，一块老业务代码当你需要在里面添加功能时 发现依赖的接口在其逻辑中已经被调用过，但该代码段中的方法 比如 FuncB 和 FuncC 在其他业务逻辑上有被引用，此时如果不复用的话感觉会增加链路中的耗时 ，如果想服用就需要进行重构，此时间接引入很大的时间、人力成本和不确定因素。
示例代码：
package main
import "context"
func FuncA(ctx context.Context) {
FuncB(ctx)
FuncD(ctx)
// todo 待开发
FunE(ctx)
}
func FuncB(ctx context.Context) {
FuncC(ctx)
}
func FuncC(ctx context.Context) {
// *****
RpcFunc(ctx)
// ******
}
func FuncD(ctx context.Context) {
// ****
RpcFunc(ctx)
// *****
}
func RpcFunc(ctx context.Context) {
}
解决方案：
核心思想：将rpc返回的结果在链路上进行传递，每个功能节点按需获取。
方式一：FuncB 增加返回值 ，FuncC 和 FuncE 增加入参；其结果 导致函数意义不明确，非核心参数过多，增加理解成本。
方式二： 利用go语言的特性 context.Context,将值塞入到ctx中，再在func中去取，如果取不到再进行rpc调用，最后再将值回写到ctx中 （推荐）
结尾
欢迎大家给出宝贵的意见。
