@lvlongxiang199 你跟我说的场景根本就不一样. 我说的是业务系统, 你说的是底层组件. 底层组件本来就各模块相对独立. 业务系统逻辑往往是交织在一起, 宛如一张大网一般. 像我们公司的产品, 使用说明都可以写成一本书了. 基本上改哪块都是牵扯一大片. 所以必然是某个人负责一个功能就一杆子捅到底. 即便是抽象出接口, 也不可能分开写. 你接口实现好了, 别人没实现好呢! 一大堆 throw new NotImplementedException() 怎么搞? 调啥都是 NotImplementedException. 总不能调别人接口的地方都写成 mock 吧? 而且万一是 A 依赖 B 的功能, B 依赖 C 的功能呢? 测都没法测. 只能是等别人把功能做完了你才能动手. 要么就是全你自己搞.

至于单体架构的链路追踪, 你说的问题直接给记录入口参数, 时间, 返回内容, 调用堆栈就足够了. 你都知道调用堆栈了还看不出来问题么? 比如说有些竟态导致的 BUG, 其实模拟一下就能复现. 不行拿脚本跑. 游戏测试怎么做的你就怎么做呗. 游戏的逻辑更复杂, 你说的这种难以复现的问题更多. 你看哪个游戏还整链路追踪的? 搞复杂了兄弟. 哪怕实在不行到处埋点都比你直接上一套链路追踪好. 对于单体的链路追踪本质上就是 AOP. 多少会影响性能的.


"一个服务把其他服务串联起来算是面条代码吗 ?" 必然不是. 微服务中每一个服务都是状态无关的. 一个服务处理过程结束之后可以直接广播动作, 其他服务接收到广播就完成各自相应的动作. 中间没有调用关系, 互相不依赖. 而单体架构下往往是一个函数调另一个函数, 另一个函数再调另一个函数. 上下文一大堆. 所以为啥叫面条代码, 面条不就是挑一筷子一长溜一米多长么, 代码也是. 光调用链就几十层, 那可不跟面条一样!