Go语言能否支持面向切面编程（AOP）的实现？
- 内容介绍
- 文章标签
- 相关推荐
本文共计2193个文字，预计阅读时间需要9分钟。
您好，大家庭，我是小桥。今天分享的话题是：Go是否能够实现AOP？
背景：有Java同学来写Go，特别喜爱将两者进行对比，经常在技术群里讨论，比如Go能否实现类似Java的AOP。
常见讨论：Go能否实现Java那样的AOP？
结论：Go可以实现事件机制，类似于AOP的功能。
hello~大家好，我是小楼，今天分享的话题是Go是否能实现AOP?
写Java的同学来写Go就特别喜欢将两者进行对比，就经常看到技术群里讨论，比如Go能不能实现Java那样的AOP啊？Go写个事务好麻烦啊，有没有Spring那样的@Transactional注解啊？
遇到这样的问题我通常会回复：没有、实现不了、再见。
直到看了《Go语言底层原理剖析》这本书，开始了一轮认真地探索。
Java是如何实现AOP的AOP概念第一次是在若干年前学Java时看的一本书《Spring实战》中看到的，它指的是一种面向切面编程的思想。注意它只是一种思想，具体怎么实现，你看着办。
AOP能在你代码的前后织入代码，这就能做很多有意思的事情了，比如统一的日志打印、监控埋点，事务的开关，缓存等等。
可以分享一个我当年学习AOP时的笔记片段：
在Java中的实现方式可以是JDK动态代理和字节码增强技术。
JDK动态代理是在运行时动态地生成了一个代理类，JVM通过加载这个代理类再实例化来实现AOP的能力。
字节码增强技术可以多唠叨两句，当年学Java时第一章就说Java的特点是「一次编译，到处运行」。
但当我们真正在工作中这个特性用处大吗？好像并不大，生产中都使用了同一种服务器，只编译了一次，也都只在这个系统运行。做到一次编译，到处运行的技术底座是JVM，JVM可以加载字节码并运行，这个字节码是平台无关的一种二进制中间码。
似乎这个设定带来了一些其他的好处。在JVM加载字节码时，字节码有一次被修改的机会，但这个字节码的修改比较复杂，好在有现成的库可用，如ASM、Javassist等。
至于像ASM这样的库是如何修改字节码的，我还真就去问了Alibaba Dragonwell的一位朋友，他回答ASM是基于Java字节码规范所做的「硬改」，但做了一些抽象，总体来说还是比较枯燥的。
由于这不是本文重点，所以只是提一下，如果想更详细地了解可自行网上搜索。
Go能否实现AOP？之前用「扁鹊三连」的方式回复Go不能实现AOP的基础其实就是我对Java实现AOP的思考，因为Go没有虚拟机一说，也没有中间码，直接源码编译为可执行文件，可执行文件基本没法修改，所以做不了。
但真就如此吗？我搜索了一番。
运行时拦截还真就在Github找到了一个能实现类似AOP功能的库gohook（当然也有类似的其他库）：
github.com/brahma-adshonor/gohook
看这个项目的介绍：
运行时动态地hook Go的方法，也就是可以在方法前插入一些逻辑。它是怎么做到的？
通过反射找到方法的地址（指针），然后插入一段代码，执行完后再执行原方法。听起来很牛X，但它下面有个Notes：
使用有一些限制，更重要的是没有完全测试，不建议生产使用。这种不可靠的方式也就不尝试了。
AST修改源码这种方式就是我在看《Go语言底层原理剖析》第一章看到的，其实我之前的文章也有写过关于AST的，《Cobar源码分析之AST》。
AST即抽象语法树，可以认为所有的高级编程语言都可以抽象为一种语法树，即对代码进行结构化的抽象，这种抽象可以让我们更加简单地分析甚至操作源码。
Go在编译时大概分为词法与语法分析、类型检查、通用 SSA 生成和最后的机器代码生成这几个阶段。
其中词法与语法分析之后，生成一个AST树，在Go中我们能调用Go提供的API很轻易地生成AST：
fset := token.NewFileSet()
// 这里file就是一个AST对象
file, err := parser.ParseFile(fset, "aop.go", nil, parser.ParseComments)
比如这里我的aop.go文件是这样的：
package main
import "fmt"
func main() {
fmt.Println(execute("roshi"))
}
func execute(name string) string {
return name
}
想看生成的AST长什么样，可调用下面的方法：
ast.Print(fset, file)
由于篇幅太长，我截个图感受下即可：
当然也有一些开源的可视化工具，但我觉得大可不必，想看的话Debug看下file的结构。
至于Go AST结构的介绍，也不是本文的重点，而且AST中的类型很多很多，我建议如果你想看的话直接Debug来看，对照源码比较清晰。
我们这里就实现一个简单的，在execute方法执行之前添加一条打印before的语句，接上述代码：
const before = "fmt.Println(\"before\")"
...
exprInsert, err := parser.ParseExpr(before)
if err != nil {
panic(err)
}
decls := make([]ast.Decl, 0, len(file.Decls))
for _, decl := range file.Decls {
fd, ok := decl.(*ast.FuncDecl)
if ok {
if fd.Name.Name == "execute" {
stats := make([]ast.Stmt, 0, len(fd.Body.List)+1)
stats = append(stats, &ast.ExprStmt{
X: exprInsert,
})
stats = append(stats, fd.Body.List...)
fd.Body.List = stats
decls = append(decls, fd)
continue
} else {
decls = append(decls, decl)
}
} else {
decls = append(decls, decl)
}
}
file.Decls = decls
这里AST就被我们修改了，虽然我们是写死了针对execute方法，但总归是迈出了第一步。
再把AST转换为源码输出，Go也提供了API：
var cfg printer.Config
var buf bytes.Buffer
cfg.Fprint(&buf, fset, file)
fmt.Printf(buf.String())
输出效果如下：
看到这里，我猜你应该有和我相同的想法，这玩意是不是可以用来格式化代码？
没错，Go自带的格式化代码工具gofmt的原理就是如此。
当我们写完代码时，可以执行gofmt对代码进行格式化：
gofmt test.go
这相比于其他语言方便很多，终于有个官方的代码格式了，甚至你可以在IDEA中安装一个file watchers插件，监听文件变更，当文件有变化时自动执行 gofmt 来格式化代码。
看到这里你可能觉得太简单了，我查了下资料，AST中还能拿到注释，这就厉害了，我们可以把注释当注解来玩，比如我加了 // before: 的注释，自动把这个注释后的代码添加到方法之前去。
// before:fmt.Println("before...")
func executeComment(name string) string {
return name
}
修改AST代码如下，为了篇幅，省略了打印代码：
cmap := ast.NewCommentMap(fset, file, file.Comments)
for _, decl := range file.Decls {
fd, ok := decl.(*ast.FuncDecl)
if ok {
if cs, ok := cmap[fd]; ok {
for _, cg := range cs {
for _, c := range cg.List {
if strings.HasPrefix(c.Text, "// before:") {
txt := strings.TrimPrefix(c.Text, "// before:")
ei, err := parser.ParseExpr(txt)
if err == nil {
stats := make([]ast.Stmt, 0, len(fd.Body.List)+1)
stats = append(stats, &ast.ExprStmt{
X: ei,
})
stats = append(stats, fd.Body.List...)
fd.Body.List = stats
decls = append(decls, fd)
continue
}
}
}
}
} else {
decls = append(decls, decl)
}
} else {
decls = append(decls, decl)
}
}
file.Decls = decls
跑一下看看：
虽然又是硬编码，但这不重要，又不是不能用~
但你发现，这样实现AOP有个缺点，必须在编译期对代码进行一次重新生成，理论上来说，所有高级编程语言都可以这么操作。
但这不是说毫无用处，比如这篇文章《每个 gopher 都需要了解的 Go AST》就给了我们一个实际的案例：
最后写到最后，我又在思考另一个问题，为什么Go的使用者没有AOP的需求呢？反倒是写Java的同学会想到AOP。
我觉得可能还是Go太年轻了，Java之所以要用AOP，很大的原因是代码已经堆积如山，没法修改，历史包袱沉重，最小代价实现需求是首选，所以会选择AOP这种技术。
反观Go还年轻，大多数项目属于造轮子期间，需要AOP的地方早就在代码中提前埋伏好了。我相信随着发展，一定也会出现一个生产可用Go AOP框架。
至于现在问我，Go能否实现AOP，我还是回答：没有、实现不了、再见。
对了，本文的完整测试代码这里可以看到：
github.com/lkxiaolou/all-in-one/tree/master/go-in-one/samples/tree
感谢大家，如果有点收获，点个在看、赞、关注吧，我们下期再见。
搜索关注微信公众号"捉虫大师"，后端技术分享，架构设计、性能优化、源码阅读、问题排查、踩坑实践。
本文共计2193个文字，预计阅读时间需要9分钟。
您好，大家庭，我是小桥。今天分享的话题是：Go是否能够实现AOP？
背景：有Java同学来写Go，特别喜爱将两者进行对比，经常在技术群里讨论，比如Go能否实现类似Java的AOP。
常见讨论：Go能否实现Java那样的AOP？
结论：Go可以实现事件机制，类似于AOP的功能。
hello~大家好，我是小楼，今天分享的话题是Go是否能实现AOP?
写Java的同学来写Go就特别喜欢将两者进行对比，就经常看到技术群里讨论，比如Go能不能实现Java那样的AOP啊？Go写个事务好麻烦啊，有没有Spring那样的@Transactional注解啊？
遇到这样的问题我通常会回复：没有、实现不了、再见。
直到看了《Go语言底层原理剖析》这本书，开始了一轮认真地探索。
Java是如何实现AOP的AOP概念第一次是在若干年前学Java时看的一本书《Spring实战》中看到的，它指的是一种面向切面编程的思想。注意它只是一种思想，具体怎么实现，你看着办。
AOP能在你代码的前后织入代码，这就能做很多有意思的事情了，比如统一的日志打印、监控埋点，事务的开关，缓存等等。
可以分享一个我当年学习AOP时的笔记片段：
在Java中的实现方式可以是JDK动态代理和字节码增强技术。
JDK动态代理是在运行时动态地生成了一个代理类，JVM通过加载这个代理类再实例化来实现AOP的能力。
字节码增强技术可以多唠叨两句，当年学Java时第一章就说Java的特点是「一次编译，到处运行」。
但当我们真正在工作中这个特性用处大吗？好像并不大，生产中都使用了同一种服务器，只编译了一次，也都只在这个系统运行。做到一次编译，到处运行的技术底座是JVM，JVM可以加载字节码并运行，这个字节码是平台无关的一种二进制中间码。
似乎这个设定带来了一些其他的好处。在JVM加载字节码时，字节码有一次被修改的机会，但这个字节码的修改比较复杂，好在有现成的库可用，如ASM、Javassist等。
至于像ASM这样的库是如何修改字节码的，我还真就去问了Alibaba Dragonwell的一位朋友，他回答ASM是基于Java字节码规范所做的「硬改」，但做了一些抽象，总体来说还是比较枯燥的。
由于这不是本文重点，所以只是提一下，如果想更详细地了解可自行网上搜索。
Go能否实现AOP？之前用「扁鹊三连」的方式回复Go不能实现AOP的基础其实就是我对Java实现AOP的思考，因为Go没有虚拟机一说，也没有中间码，直接源码编译为可执行文件，可执行文件基本没法修改，所以做不了。
但真就如此吗？我搜索了一番。
运行时拦截还真就在Github找到了一个能实现类似AOP功能的库gohook（当然也有类似的其他库）：
github.com/brahma-adshonor/gohook
看这个项目的介绍：
运行时动态地hook Go的方法，也就是可以在方法前插入一些逻辑。它是怎么做到的？
通过反射找到方法的地址（指针），然后插入一段代码，执行完后再执行原方法。听起来很牛X，但它下面有个Notes：
使用有一些限制，更重要的是没有完全测试，不建议生产使用。这种不可靠的方式也就不尝试了。
AST修改源码这种方式就是我在看《Go语言底层原理剖析》第一章看到的，其实我之前的文章也有写过关于AST的，《Cobar源码分析之AST》。
AST即抽象语法树，可以认为所有的高级编程语言都可以抽象为一种语法树，即对代码进行结构化的抽象，这种抽象可以让我们更加简单地分析甚至操作源码。
Go在编译时大概分为词法与语法分析、类型检查、通用 SSA 生成和最后的机器代码生成这几个阶段。
其中词法与语法分析之后，生成一个AST树，在Go中我们能调用Go提供的API很轻易地生成AST：
fset := token.NewFileSet()
// 这里file就是一个AST对象
file, err := parser.ParseFile(fset, "aop.go", nil, parser.ParseComments)
比如这里我的aop.go文件是这样的：
package main
import "fmt"
func main() {
fmt.Println(execute("roshi"))
}
func execute(name string) string {
return name
}
想看生成的AST长什么样，可调用下面的方法：
ast.Print(fset, file)
由于篇幅太长，我截个图感受下即可：
当然也有一些开源的可视化工具，但我觉得大可不必，想看的话Debug看下file的结构。
至于Go AST结构的介绍，也不是本文的重点，而且AST中的类型很多很多，我建议如果你想看的话直接Debug来看，对照源码比较清晰。
我们这里就实现一个简单的，在execute方法执行之前添加一条打印before的语句，接上述代码：
const before = "fmt.Println(\"before\")"
...
exprInsert, err := parser.ParseExpr(before)
if err != nil {
panic(err)
}
decls := make([]ast.Decl, 0, len(file.Decls))
for _, decl := range file.Decls {
fd, ok := decl.(*ast.FuncDecl)
if ok {
if fd.Name.Name == "execute" {
stats := make([]ast.Stmt, 0, len(fd.Body.List)+1)
stats = append(stats, &ast.ExprStmt{
X: exprInsert,
})
stats = append(stats, fd.Body.List...)
fd.Body.List = stats
decls = append(decls, fd)
continue
} else {
decls = append(decls, decl)
}
} else {
decls = append(decls, decl)
}
}
file.Decls = decls
这里AST就被我们修改了，虽然我们是写死了针对execute方法，但总归是迈出了第一步。
再把AST转换为源码输出，Go也提供了API：
var cfg printer.Config
var buf bytes.Buffer
cfg.Fprint(&buf, fset, file)
fmt.Printf(buf.String())
输出效果如下：
看到这里，我猜你应该有和我相同的想法，这玩意是不是可以用来格式化代码？
没错，Go自带的格式化代码工具gofmt的原理就是如此。
当我们写完代码时，可以执行gofmt对代码进行格式化：
gofmt test.go
这相比于其他语言方便很多，终于有个官方的代码格式了，甚至你可以在IDEA中安装一个file watchers插件，监听文件变更，当文件有变化时自动执行 gofmt 来格式化代码。
看到这里你可能觉得太简单了，我查了下资料，AST中还能拿到注释，这就厉害了，我们可以把注释当注解来玩，比如我加了 // before: 的注释，自动把这个注释后的代码添加到方法之前去。
// before:fmt.Println("before...")
func executeComment(name string) string {
return name
}
修改AST代码如下，为了篇幅，省略了打印代码：
cmap := ast.NewCommentMap(fset, file, file.Comments)
for _, decl := range file.Decls {
fd, ok := decl.(*ast.FuncDecl)
if ok {
if cs, ok := cmap[fd]; ok {
for _, cg := range cs {
for _, c := range cg.List {
if strings.HasPrefix(c.Text, "// before:") {
txt := strings.TrimPrefix(c.Text, "// before:")
ei, err := parser.ParseExpr(txt)
if err == nil {
stats := make([]ast.Stmt, 0, len(fd.Body.List)+1)
stats = append(stats, &ast.ExprStmt{
X: ei,
})
stats = append(stats, fd.Body.List...)
fd.Body.List = stats
decls = append(decls, fd)
continue
}
}
}
}
} else {
decls = append(decls, decl)
}
} else {
decls = append(decls, decl)
}
}
file.Decls = decls
跑一下看看：
虽然又是硬编码，但这不重要，又不是不能用~
但你发现，这样实现AOP有个缺点，必须在编译期对代码进行一次重新生成，理论上来说，所有高级编程语言都可以这么操作。
但这不是说毫无用处，比如这篇文章《每个 gopher 都需要了解的 Go AST》就给了我们一个实际的案例：
最后写到最后，我又在思考另一个问题，为什么Go的使用者没有AOP的需求呢？反倒是写Java的同学会想到AOP。
我觉得可能还是Go太年轻了，Java之所以要用AOP，很大的原因是代码已经堆积如山，没法修改，历史包袱沉重，最小代价实现需求是首选，所以会选择AOP这种技术。
反观Go还年轻，大多数项目属于造轮子期间，需要AOP的地方早就在代码中提前埋伏好了。我相信随着发展，一定也会出现一个生产可用Go AOP框架。
至于现在问我，Go能否实现AOP，我还是回答：没有、实现不了、再见。
对了，本文的完整测试代码这里可以看到：
github.com/lkxiaolou/all-in-one/tree/master/go-in-one/samples/tree
感谢大家，如果有点收获，点个在看、赞、关注吧，我们下期再见。
搜索关注微信公众号"捉虫大师"，后端技术分享，架构设计、性能优化、源码阅读、问题排查、踩坑实践。