原文發(fā)布在個(gè)人站點(diǎn): GitDiG.com, 原文鏈接：https://www.gitdig.com/go-reflect/
1. 圖解反射
在使用反射之前，此文The Laws of Reflection必讀。網(wǎng)上中文翻譯版本不少，可以搜索閱讀。
開始具體篇幅之前，先看一下反射三原則：
- Reflection goes from interface value to reflection object.
- Reflection goes from reflection object to interface value.
- To modify a reflection object, the value must be settable.
在三原則中，有兩個(gè)關(guān)鍵詞 interface value 與 reflection object。有點(diǎn)難理解，畫張圖可能你就懂了。
先看一下什么是反射對象 reflection object？ 反射對象有很多，但是其中最關(guān)鍵的兩個(gè)反射對象reflection object是：reflect.Type與reflect.Value.直白一點(diǎn)，就是對變量類型與值的抽象定義類，也可以說是變量的元信息的類定義.
再來，為什么是接口變量值 interface value, 不是變量值 variable value 或是對象值 object value 呢？因?yàn)楹髢烧呔痪邆鋸V泛性。在 Go 語言中，空接口 interface{}是可以作為一切類型值的通用類型使用。所以這里的接口值 interface value 可以理解為空接口變量值 interface{} value。
結(jié)合圖示，將反射三原則歸納成一句話：
通過反射可以實(shí)現(xiàn)反射對象
reflection object與接口變量值interface value之間的相互推導(dǎo)與轉(zhuǎn)化, 如果通過反射修改對象變量的值，前提是對象變量本身是可修改的。
2. 反射的應(yīng)用
在程序開發(fā)中是否需要使用反射功能，判斷標(biāo)準(zhǔn)很簡單，即是否需要用到變量的類型信息。這點(diǎn)不難判斷，如何合理的使用反射才是難點(diǎn)。因?yàn)椋瓷洳煌谄胀ǖ墓δ芎瘮?shù)，它對程序的性能是有損耗的，需要盡量避免在高頻操作中使用反射。
舉幾個(gè)反射應(yīng)用的場景例子:
2.1 判斷未知對象是否實(shí)現(xiàn)具體接口
通常情況下，判斷未知對象是否實(shí)現(xiàn)具體接口很簡單，直接通過 變量名.(接口名) 類型驗(yàn)證的方式就可以判斷。但是有例外，即框架代碼實(shí)現(xiàn)中檢查調(diào)用代碼的情況。因?yàn)榭蚣艽a先實(shí)現(xiàn)，調(diào)用代碼后實(shí)現(xiàn)，也就無法在框架代碼中通過簡單額類型驗(yàn)證的方式進(jìn)行驗(yàn)證。
看看 grpc 的服務(wù)端注冊接口就明白了。
grpcServer := grpc.NewServer()
// 服務(wù)端實(shí)現(xiàn)注冊
pb.RegisterRouteGuideServer(grpcServer, &routeGuideServer{})
當(dāng)注冊的實(shí)現(xiàn)沒有實(shí)現(xiàn)所有的服務(wù)接口時(shí)，程序就會報(bào)錯(cuò)。它是如何做的，可以直接查看pb.RegisterRouteGuideServer的實(shí)現(xiàn)代碼。這里簡單的寫一段代碼，原理相同：
//目標(biāo)接口定義
type Foo interface {
Bar(int)
}
dst := (*Foo)(nil)
dstType := reflect.TypeOf(dst).Elem()
//驗(yàn)證未知變量 src 是否實(shí)現(xiàn) Foo 目標(biāo)接口
srcType := reflect.TypeOf(src)
if !srcType.Implements(dstType) {
log.Fatalf("type %v that does not satisfy %v", srcType, dstType)
}
這也是grpc框架的基礎(chǔ)實(shí)現(xiàn)，因?yàn)檫@段代碼通常會是在程序的啟動階段所以對于程序的性能而言沒有任何影響。
2.2 結(jié)構(gòu)體字段屬性標(biāo)簽
通常定義一個(gè)待JSON解析的結(jié)構(gòu)體時(shí)，會對結(jié)構(gòu)體中具體的字段屬性進(jìn)行tag標(biāo)簽設(shè)置，通過tag的輔助信息對應(yīng)具體JSON字符串對應(yīng)的字段名。JSON解析就不提供例子了，而且通常JSON解析代碼會作用于請求響應(yīng)階段，并非反射的最佳場景，但是業(yè)務(wù)上又不得不這么做。
這里我要引用另外一個(gè)利用結(jié)構(gòu)體字段屬性標(biāo)簽做反射的例子，也是我認(rèn)為最完美詮釋反射的例子，真的非常值得推薦。這個(gè)例子出現(xiàn)在開源項(xiàng)目github.com/jaegertracing/jaeger-lib中。
用過 prometheus的同學(xué)都知道，metric探測標(biāo)量是需要通過以下過程定義并注冊的：
var (
// Create a summary to track fictional interservice RPC latencies for three
// distinct services with different latency distributions. These services are
// differentiated via a "service" label.
rpcDurations = prometheus.NewSummaryVec(
prometheus.SummaryOpts{
Name: "rpc_durations_seconds",
Help: "RPC latency distributions.",
Objectives: map[float64]float64{0.5: 0.05, 0.9: 0.01, 0.99: 0.001},
},
[]string{"service"},
)
// The same as above, but now as a histogram, and only for the normal
// distribution. The buckets are targeted to the parameters of the
// normal distribution, with 20 buckets centered on the mean, each
// half-sigma wide.
rpcDurationsHistogram = prometheus.NewHistogram(prometheus.HistogramOpts{
Name: "rpc_durations_histogram_seconds",
Help: "RPC latency distributions.",
Buckets: prometheus.LinearBuckets(*normMean-5**normDomain, .5**normDomain, 20),
})
)
func init() {
// Register the summary and the histogram with Prometheus's default registry.
prometheus.MustRegister(rpcDurations)
prometheus.MustRegister(rpcDurationsHistogram)
// Add Go module build info.
prometheus.MustRegister(prometheus.NewBuildInfoCollector())
}
這是 prometheus/client_golang 提供的例子，代碼量多，而且需要使用init函數(shù)。項(xiàng)目一旦復(fù)雜，可讀性就很差。再看看github.com/jaegertracing/jaeger-lib/metrics提供的方式：
type App struct{
//attributes ...
//metrics ...
metrics struct{
// Size of the current server queue
QueueSize metrics.Gauge `metric:"thrift.udp.server.queue_size"`
// Size (in bytes) of packets received by server
PacketSize metrics.Gauge `metric:"thrift.udp.server.packet_size"`
// Number of packets dropped by server
PacketsDropped metrics.Counter `metric:"thrift.udp.server.packets.dropped"`
// Number of packets processed by server
PacketsProcessed metrics.Counter `metric:"thrift.udp.server.packets.processed"`
// Number of malformed packets the server received
ReadError metrics.Counter `metric:"thrift.udp.server.read.errors"`
}
}
在應(yīng)用中首先直接定義匿名結(jié)構(gòu)metrics， 將針對該應(yīng)用的metric探測標(biāo)量定義到具體的結(jié)構(gòu)體字段中，并通過其字段標(biāo)簽tag的方式設(shè)置名稱。這樣在代碼的可讀性大大增強(qiáng)了。
再看看初始化代碼:
import "github.com/jaegertracing/jaeger-lib/metrics/prometheus"
//初始化
metrics.Init(&app.metrics, prometheus.New(), nil)
不服不行，完美。這段樣例代碼實(shí)現(xiàn)在我的這個(gè)項(xiàng)目中: x-mod/thriftudp，完全是參考該庫的實(shí)現(xiàn)寫的。
2.3 函數(shù)適配
原來做練習(xí)的時(shí)候，寫過一段函數(shù)適配的代碼，用到反射。貼一下：
//Executor 適配目標(biāo)接口，增加 context.Context 參數(shù)
type Executor func(ctx context.Context, args ...interface{})
//Adapter 適配器適配任意函數(shù)
func Adapter(fn interface{}) Executor {
if fn != nil && reflect.TypeOf(fn).Kind() == reflect.Func {
return func(ctx context.Context, args ...interface{}) {
fv := reflect.ValueOf(fn)
params := make([]reflect.Value, 0, len(args)+1)
params = append(params, reflect.ValueOf(ctx))
for _, arg := range args {
params = append(params, reflect.ValueOf(arg))
}
fv.Call(params)
}
}
return func(ctx context.Context, args ...interface{}) {
log.Warn("null executor implemention")
}
}
僅僅為了練習(xí)，生產(chǎn)環(huán)境還是不推薦使用，感覺太重了。
最近看了一下Go 1.14的提案，關(guān)于try關(guān)鍵字的引入, try參考。按其所展示的功能，如果自己實(shí)現(xiàn)的話，應(yīng)該會用到反射功能。那么對于現(xiàn)在如此依賴 error 檢查的函數(shù)實(shí)現(xiàn)來說，是否合適,挺懷疑的，等Go 1.14出了，驗(yàn)證一下。
3 小結(jié)
反射的最佳應(yīng)用場景是程序的啟動階段，實(shí)現(xiàn)一些類型檢查、注冊等前置工作，既不影響程序性能同時(shí)又增加了代碼的可讀性。最近迷上新褲子，所以別再問我什么是反射了：）
