文章目录
- 1. 写在最前面
- 2. 依赖注入
- 2.1 使用场景
- 2.2 框架对比
- 3. fx 框架使用场景示例
- 3.1 示例
- 3.2 golang 原生的库
- 3.3 fx 库
- 3.4 对比
- 3.4.1 如上两种实现方式对比
- 3.4.2 关于过度设计
- 3.4.3 感悟
- 4. 碎碎念
- 5. 参考资料
1. 写在最前面
同事在技术分享的时候用了 golang 的 fx 框架,突然想起之前有一次帮别人 review 代码的时候也看到过这个框架。只是大概知道是「依赖注入」的框架,并没有深入分析理解过,包括这个框架的优势、劣势以及适合的场景一概不清楚。知识这个东西,摆在那里就是人家的,学到了才是自己的。所以顺便整理一波,方便后面自己要用的时候,可以很快的上手。
注: 有再一再二,没有再三再四。第一次和第二次看到的时候可以说不理解,但是都第三次和第四次了,这可说不过去了。
2. 依赖注入
2.1 使用场景
维基百科官方话术:「依赖注入是种实现控制反转用于解决依赖性设计模式。一个依赖关系指的是可被利用的一种对象(即服务提供端)。依赖注入是将所依赖的传递给将使用的从属对象(即客户端)。该服务是将会变成客户端的状态一部分。传递服务给客户端,而非允许客户端来建立或寻找服务,是本设计模式的基本要求。」
注:维基百科的这个概念我读了三遍能理解,但是很难深入的分辨出什么场景适合用依赖注入。
这个概念让我陷入了沉思,然后我又不死心的,问了问 chatgpt
chatgpt 的回答如下:
总结:chatgpt 的回答整体上比维基百科理解起来要更简单一点。(ps:遇到不懂的概念可以试试 chatgpt
2.2 框架对比
以下是几个常用的 golang 依赖注入框架:
-
google 的 wire : 一个用于管理依赖注入的代码生成工具,它提供了一种简单的方式来定义依赖关系,并生成相应的代码。wire 可以检查和解析依赖关系、生成可重用、高效的代码。官方文档,GitHub - google/wire: Compile-time Dependency Injection for Go
-
uber 的 fx:一个基于 wire 构建的更高级的依赖注入框架,它提供了更多的特性和功能,如生命周期的管理、插件系统、服务注册等。fx 旨在提供一种更易于使用和维护的依赖注入模式。官方文档:GitHub - uber-go/fx: A dependency injection based application framework for Go.
注:两者的差别,在于 wire 是使用 Code Gen 的方式,而 fx 则是使用的 reflection.
3. fx 框架使用场景示例
在使用框架之前,一定要先想清楚,业务的复杂程度真的到了必需框架不可的程度了吗?
个人观点:
- 引入库会一定程度上减少了业务开发的复杂性,但是也会导致理解代码的成本变高(ps: 通用的常见库除外,比如日志库
3.1 示例
实现一个 http server ,支持如下两个 POST 方法
-
/echo :将请求的内容,直接作为响应的 body
-
/hello:请求的内容拼接 hello 字符,将其作为响应的 body
形如:
3.2 golang 原生的库
代码:
package main
import (
"fmt"
"io"
"log"
"net/http"
)
var handleMap = map[string]func(w http.ResponseWriter, r *http.Request){
"/echo": handleEcho,
"/hello": handleHello,
}
func main() {
http.HandleFunc("/", handleRequest)
log.Fatal(http.ListenAndServe(":8080", nil))
}
func handleRequest(w http.ResponseWriter, r *http.Request) {
f := handleMap[r.URL.Path]
if f != nil {
f(w, r)
return
}
http.NotFound(w, r)
}
func handleEcho(w http.ResponseWriter, r *http.Request) {
body, err := io.ReadAll(r.Body)
if err != nil {
http.Error(w, "Error reading request body", http.StatusInternalServerError)
return
}
fmt.Fprintf(w, "%s", body)
}
func handleHello(w http.ResponseWriter, r *http.Request) {
body, err := io.ReadAll(r.Body)
if err != nil {
http.Error(w, "Error reading request body", http.StatusInternalServerError)
return
}
msg := fmt.Sprintf("%s hello", body)
fmt.Fprint(w, msg)
}
3.3 fx 库
代码:
package main
import (
"context"
"fmt"
"io"
"net"
"net/http"
"go.uber.org/fx"
"go.uber.org/zap"
)
// 定义的接口
type Route interface {
http.Handler
Pattern() string
}
func AsRoute(f any) any {
return fx.Annotate(
f,
fx.As(new(Route)),
fx.ResultTags(`group:"routes"`),
)
}
// 实现 Route 接口的数据结构, echo 接口
type EchoHandler struct {
log *zap.Logger
}
func NewEchoHandler(log *zap.Logger) *EchoHandler {
return &EchoHandler{
log: log,
}
}
func (*EchoHandler) Pattern() string {
return "/echo"
}
func (h *EchoHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
if _, err := io.Copy(w, r.Body); err != nil {
h.log.Warn("Failed to handle request", zap.Error(err))
}
}
// 实现 Route 接口的数据结构, hello 接口
type HelloHandler struct {
log *zap.Logger
}
func NewHelloHandler(log *zap.Logger) *HelloHandler {
return &HelloHandler{log: log}
}
func (*HelloHandler) Pattern() string {
return "/hello"
}
func (h *HelloHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
body, err := io.ReadAll(r.Body)
if err != nil {
h.log.Error("Failed to read request", zap.Error(err))
http.Error(w, "Internal server error", http.StatusInternalServerError)
return
}
if _, err := fmt.Fprintf(w, "Hello, %s\n", body); err != nil {
h.log.Error("Failed to write response", zap.Error(err))
http.Error(w, "Internal server error", http.StatusInternalServerError)
return
}
}
func NewServeMux(route []Route) *http.ServeMux {
mux := http.NewServeMux()
for _, r := range route {
mux.Handle(r.Pattern(), r)
}
return mux
}
func NewHTTPServer(lc fx.Lifecycle, mux *http.ServeMux, log *zap.Logger) *http.Server {
srv := &http.Server{Addr: ":8081", Handler: mux}
lc.Append(fx.Hook{
OnStart: func(ctx context.Context) error {
ln, err := net.Listen("tcp", srv.Addr)
if err != nil {
return err
}
log.Info("Starting HTTP Server", zap.String("addr", srv.Addr))
go srv.Serve(ln)
return nil
},
OnStop: func(ctx context.Context) error {
return srv.Shutdown(ctx)
},
})
return srv
}
func UseHttpServer(*http.Server) {}
func main() {
fx.New(
fx.Provide(
NewHTTPServer,
fx.Annotate(
NewServeMux,
fx.ParamTags(`group:"routes"`),
),
AsRoute(NewEchoHandler),
AsRoute(NewHelloHandler),
zap.NewExample,
),
fx.Invoke(UseHttpServer),
).Run()
}
3.4 对比
fx 库的官方介绍如下:
- Eliminate globals: Fx helps you remove global state from your application. No more
init()
or global variables. Use Fx-managed singletons. - Code reuse: Fx lets teams within your organization build loosely-coupled and well-integrated shareable components.
- Battle tested: Fx is the backbone of nearly all Go services at Uber.
总结:
-
消除了 init() 和 全局变量的使用
-
解耦程度更好以及更方便的共享组件
-
在 Uber 内部成熟度很高,几乎所有的 go 服务的底层支柱。
但是:
-
使用了 init() 和 全局变量 真的有什么坏处吗?
-
你的程序真的需要那么高的解耦程度吗?
-
「backbone」代表 100% 可靠吗?
最近开发心得,代码凡是依赖别人的,交付时间完全依赖别人排期。但是代码全部控制在自己手里,那里方便修复改哪里!
「你的修复方式,不会影响到客户。但是你为了追求完美的代码,延误了交付时间,一定会招来客户投诉」(ps:不要问我怎么知道的,成长血泪史
3.4.1 如上两种实现方式对比
golang 原生库 | fx 库 | |
---|---|---|
开发复杂度 | 中 | 高 |
解耦程度 | 中 | 高 |
运维成本 | 中 | 高 |
注:代码首先是需要人理解和维护的,其次都是其次。如果理解的成本变高,那相应的维护成本可想而知。
以上等级划分:均为高中低三档 按照笔者的比较:golang 原始库完胜 fx 库
注意:不能大而全的总结为 fx 库不好,而是总结为在代码的规模较少、又要保证交付节奏时,不引入复杂或者自己不熟悉的库,不失为一种很好的选择。
注:凡是自己控制的,都是可靠的,凡是有依赖的,皆需要多问问「真的是这样吗?」
3.4.2 关于过度设计
上面的对比让笔者脑子中产生了一个之前看过的关键词「过度设计」。
维基百科给出的定义:
「过度设计」指的是一种过于复杂的方式设计产品或提供问题的解决方案的行为,而在这种情况下,可以证明存在一种更简单的解决方案,其效率和效果与原设计相同。
注:参考 Paweł Głogowski 的这个定义,可以总计为「解决你所有没有的问题的代码和设计」
原因: 我们试图预测未来,对未知的问题做准备。(ps:你认为的未来的问题,可能根本没有出现的机会,所以减少焦虑,不要过度,因为未来的事情担心和设计
解决方法:
-
让工程师成为真正的产品工程师
-
正确定义问题来减少模糊性
-
多问:这对解决当前用户的问题有什么帮助?要是现在不解决会怎么?
3.4.3 感悟
-
开发者应该视自己的方案来选择技术实践,框架提供的是「选择」,而不是限制开发者的自由。
-
框架的目的是协助工程师,如果不知道需要什么协助,用框架也帮不上忙,说不定还会束手束脚。
4. 碎碎念
上海的天气真的是瞬息万变,昨天还可以穿小裙子,今天就要穿呢子大衣,惹不起!
-
时间扑面而来,我们终将释怀。健康的活着,平静的过着,开心的笑着,适当的忙着,就很好。
-
第一是做让自己开心的事情,第二是「绝对不做让自己不开心的事情」。
-
就算失败,我也想知道,自己倒在距离终点多远的地方。
5. 参考资料
-
用 fx 来替 Go 依赖注入吧
-
golang 依赖注入 wire 和 dig 体验对比
-
Golang 依赖注入经典解决方案uber/fx理论解析)
-
依赖注入是什么?如何使用它?
-
过度设计会扼杀你的产品_文化 & 方法_Simón Muñoz_InfoQ精选文章
-
Overengineering in software development | Solidstudio