@winglight2016 哈哈，团队里好几个前 dubbo contributor ，很多业务代码也参照了 dubbo 的设计，使用 微内核+插件化+SPI 扩展，就是过度设计

@midsolo 得看看你们在做时间什么事情，业务代码肯定不能过度设计，但是核心模块可以

这里两个写法看不出什么，如果是我的话，会将这个 Task 的逻辑，写到具体的 Service 然后 TaskRunner 作为一个中间组件 到这个程度的话： 1. new Thread(() -> XXXService.DoSomething).start(); // 原生线程池，没有特殊处理 2. TaskRunner.Run("doSomething", () -> XXXService.DoSomething); // 中间件封装 为什么中间件封装： 1. 统计，监控，日志 2. 线程数量控制（即便是协程） 3. 以后 TaskRunner 控制复杂调度（优先级，丢弃，限流...） 如果你们是一个成熟的团队，本来就需要这些中间件，在这个基础上，都只是一个简单的方法调用而已

#32 上面的 1/2 区别很小，对于团队的人来说接受度没什么区别，所以你们的问题是： 复杂场景下，需要丰富中间件，而不是“按需开发中间件”，这样会增加其他团队成员的理解程度

说个常见的，IService/ServerImpl ，我写了多年代码也没遇上几回需要多实现的场景，我重来都是直接一个 Service

不好意思 我们是按代码量算钱的

@midsolo #13 确实如此。有时候你写的扩展，对接手的人来讲只是累赘。

啰里八唆的 JAVA 味道是这样的

最好加上 pool 去调度，任务开始前，创建上下文注入 thread local 去隔离变量就够了

平白无故添加了认知负荷，人的精力是有限的