面向切面编程?Go能实现AOP吗?

背景

写Java的同学来写Go就特别喜欢将两者进行对比,经常看到技术群里讨论,比如Go能不能实现Java那样的AOP啊?Go写个事务好麻烦啊,有没有Spring那样的@Transactional注解啊?

遇到这样的问题我通常会回复:没有、实现不了、再见。

3772f2e121ede8e95d14f4d8c704e2dd.png

直到看了《Go语言底层原理剖析》这本书,我开始了一轮认真地探索。

Java是如何实现AOP的

AOP概念第一次是在若干年前学Java时看的一本书《Spring实战》中看到的,它指的是一种面向切面编程的思想。注意它只是一种思想,具体怎么实现,你看着办。

AOP能在你代码的前后织入代码,这就能做很多有意思的事情了,比如统一的日志打印、监控埋点,事务的开关,缓存等等。

可以分享一个我当年学习AOP时的笔记片段:

e2c63a5b6f73e2c37592ed694349bfeb.png

在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(当然也有类似的其他库):

https://github.com/brahma-adshonor/gohook

看这个项目的介绍:

5ba7744770aeff73bc67b817d770006b.png

运行时动态地hook Go的方法,也就是可以在方法前插入一些逻辑。它是怎么做到的?

8d6b18cfe33b102392e6ffbe3b4a7034.png

通过反射找到方法的地址(指针),然后插入一段代码,执行完后再执行原方法。听起来很牛X,但它下面有个Notes:

457a680c33849fec86f7a45dd02dc9dc.png

使用有一些限制,更重要的是没有完全测试,不建议生产使用。这种不可靠的方式也就不尝试了。

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)

由于篇幅太长,我截个图感受下即可:

1e695454d531a1d4b1ddab32e840d074.png

当然也有一些开源的可视化工具,但我觉得大可不必,想看的话Debug看下file的结构即可。

至于Go AST结构的介绍,也不是本文的重点,而且AST中的类型很多很多,叙述起来比较枯燥。

我们这里就实现一个简单的,在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())

输出效果如下:

42c035de027cb6053b4017c281c7e1cb.png

看到这里,我猜你应该有和我相同的想法,这玩意是不是可以用来格式化代码?

没错,Go自带的格式化代码工具gofmt的原理就是如此。

当我们写完代码时,可以执行gofmt对代码进行格式化:

gofmt test.go

这相比于其他语言方便很多,终于有个官方的代码格式了,甚至你可以在IDEA中安装一个file watchers插件,监听文件变更,当文件有变化时自动执行 gofmt 来格式化代码。

bf8dab1f2ac4c9276b30ab32a5f12281.png

看到这里你可能觉得太简单了,我查了下资料,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

跑一下看看:

3348dbc8ab44000db8dc20a72a151844.png

虽然代码很丑,但这不重要,又不是不能用~

b88803561a5a0220eb4b6bd7a4b1a3c5.png

但你发现,这样实现AOP有个缺点,必须在编译期对代码进行一次重新生成,理论上来说,所有高级编程语言都可以这么操作。

但这不是说毫无用处,比如这篇文章《每个 gopher 都需要了解的 Go AST》就给了我们一个实际的案例:

a9d8a2979be473133b9209eb7075ef83.png

最后

写到最后,我又在思考另一个问题,为什么Go的使用者没有AOP的需求呢?反倒是写Java的同学会想到AOP。

我觉得可能还是Go太年轻了,Java之所以要用AOP,很大的原因是代码已经堆积如山,没法修改,历史包袱沉重,最小代价实现需求是首选,所以会选择AOP这种技术。

反观Go还年轻,大多数项目属于造轮子期间,需要AOP的地方早就在代码中提前埋伏好了。我相信随着发展,一定也会出现一个生产可用Go AOP框架。

至于现在问我,Go能否实现AOP,我还是回答:没有、实现不了、再见。

43d8e612874ed3b373ef5d2292ebb321.png

- END -

扫码关注公众号「网管叨bi叨」

给网管个星标,第一时间吸我的知识 👆

网管为大家整理了一本超实用的《Go 开发参考书》收集了70多条开发实践。去公众号回复【gocookbook】即刻领取!

觉得有用就点个在看  👇👇👇

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值