依赖注入的正确打开方式 bilibili/kratos × google/wire

一、前言

依赖注入相信大家都不陌生也不是什么新鲜的概念了，笔者初次深切体会依赖注入这种设计模式是在16年笔者在学习phalapi框架时使用的DI()函数，简单来说就是将所有的资源初始化集中在一起，通过统一的容器对外提供，而不是通过全局变量或到处New的方式。最近在学习kratos又看到一个团队的历史项目都使用wier，一个是正面教材一个是反面教材也有一些自己的思考，希望能够分享出来和大家交流交流。

资料如下：

wier官方文档：https://github.com/google/wire
kratos依赖注入：https://go-kratos.dev/docs/guide/wire
phalapi依赖注入：http://www.phalapi.net/wikis/2-11.html

二、依赖注入解决什么问题？

其实笔者开始写Goalng包括团队内部自己研发的小框架go-core主要使用的是资源容器的方式，框架帮助你将资源统一的容器管理起来（也是一种间接的全局变量的方式，只是不能直接进行修改），但对于业务分层如果是微服务的话足够简单就直接 packagename.funcname 进行调用，如果是稍微复杂一些的项目用一个空的status的全局变量来提供func的隔离。

但这样的设计会存在一下几个问题：

依赖不清晰：
- 虽然限定了调用层级，但无法直观了解当前模块依赖那些下层模块
资源获取僵化不灵活：
- 资源获取在最底层虽然可以也实现多态，但影响范围只能是全局，无法控制作用域
避免犯错：
- 无论是容器资源管理还是全局status变量都存在被误操作的可能性

三、一个糟糕的依赖注入的设计

如果你使用成熟框架无论是go-zero或kratos都应该按照他们的最佳实践来执行，如果是框架层没有约束还是要更具自己的实际情况来进行选择，有限选择最简单的方式顺应研发人员的直觉，设计模式如果用不对那将是场灾难，就和最近接触到了一个项目虽然使用了wier作为依赖注入，但是用的一塌糊涂：

它存在的问题：

貌似依赖注入了又貌似没有
- 一个大对象实例化了保管了所有资源
- 获取资源还是在使用New的方式
- 应为需要New所以下次实例化需要的资源也变成了当前这一层的依赖，需要一层一层将资源传递下去
- 所有入口资源都依赖了一个全局的大资源

一个设计模式如果没有用对，虽然解决了上面资源共享的问题，但是又带来了一堆奇怪的问题，真的是得不偿失。所以架构也好业务也好都是逐步演进过来的，不要将设计模式当做万能药，第一性原则还是保持简单和高内聚低耦合，遇到文件引入对应的方案然后需要做好落地的最佳实践。

四、怎样是一个好的依赖注入？

当笔者接触到上面的项目之后就非常的迷茫，在思考怎么样才是一个好的依赖注入设计模式的落地呢？当接触到 kratos 之后给了我一些启发：

一个好的依赖注入需要具备哪些特性

编码过程中所有的依赖都只能从自身对象实例中获取，不允许New或使用全局变量
依赖注入过程要贯穿全流程，从grpc服务或http服务初始化开始而不是从业务才开始使用

bilibili/kratos × google/wire 标准样例：

// 定义依赖关系，从头到尾
func wireApp(*conf.Server, *conf.Data, log.Logger) (*kratos.App, func(), error) {panic(wire.Build(server.ProviderSet,data.ProviderSet,biz.ProviderSet,service.ProviderSet,newApp))
}// 初始化方法也要参与依赖注入
func newApp(logger log.Logger, gs *grpc.Server, hs *http.Server) *kratos.App {return kratos.New(kratos.ID(id),kratos.Name(Name),kratos.Version(Version),kratos.Metadata(map[string]string{}),kratos.Logger(logger),kratos.Server(gs,hs,),)
}// 程序启动直接从wier生成的方法中获取app, cleanup, err := wireApp(bc.Server, bc.Data, logger)if err != nil {panic(err)}defer cleanup()// start and wait for stop signalif err := app.Run(); err != nil {panic(err)}

依赖的资源都是局部的，并且只关注自己所依赖的范围，依赖的依赖怎么注入不应该被关注

// GreeterService is a greeter service.
type GreeterService struct {v1.UnimplementedGreeterServeruc *biz.GreeterUsecase
}// NewGreeterService new a greeter service.
func NewGreeterService(uc *biz.GreeterUsecase) *GreeterService {return &GreeterService{uc: uc}
}...
// GreeterUsecase is a Greeter usecase.
type GreeterUsecase struct {repo GreeterRepolog  *log.Helper
}// NewGreeterUsecase new a Greeter usecase.
func NewGreeterUsecase(repo GreeterRepo, logger log.Logger) *GreeterUsecase {return &GreeterUsecase{repo: repo, log: log.NewHelper(logger)}
}