事故现场之依赖了不该依赖的 host ip
昨天,组里服务遇到了一个诡异的问题,跟着看了下原因,记录在此。
先介绍背景:我们维护了两个服务,一个对外服务,承接流量,称之为主服务,主服务会调用各种第三方 RPC 服务,获取各种字段,拼在一个大的 model 上。其中有一个 RPC 服务,称之为 E 服务,是我们自己维护的,它返回一部分字段。
昨天,组里服务遇到了一个诡异的问题,跟着看了下原因,记录在此。
先介绍背景:我们维护了两个服务,一个对外服务,承接流量,称之为主服务,主服务会调用各种第三方 RPC 服务,获取各种字段,拼在一个大的 model 上。其中有一个 RPC 服务,称之为 E 服务,是我们自己维护的,它返回一部分字段。
最近接手了一个“公共”服务,负责维护它的稳定性。代码库有很多人参与“维护”,其实就是各种业务方使劲往上堆逻辑。虽然入库前我会进行 CR,但多了之后,也看不过来,还有一些人自己偷摸就把代码合到 master 上去了。总之,代码质量无法得到很好的保证。
当然了,如果把合代码的权限收敛到我一个人,理论上是可行的。但是,一方面,业务迭代的速度很可能就 block 在我这了;另一方面,业务方的迭代逻辑涉及很多具体的业务,我也不太熟。所以,CR 的时候也只能看一些诸如 go 出去的 func 有没有加 recover、有没有异常使用空指针等等,对于业务相关的代码提不出什么有用的意见。
某天晚上看到曹大在群里指点江山,折服。感叹为何曹大如此渊博,遂决定从头到尾研读完他所有的博文。
前后共花了一个月的时间,今天终于读完了(2020-11-24~2020-12-26),总共 118 篇。从 15 年 10 月 31 日开始的第一篇,到今天,总共写了 5 年多的时间。基本上每半个月产出一篇,非常稳定。