Go編程：圖解反射

原文發佈在個人站點:GitDiG.com, 原文鏈接：Go 編程：圖解反射

反射三原則太難理解，看一張圖你就懂了。完美解釋兩個關鍵詞 interface value 與 reflection object 是什麼。

1. 圖解反射

在使用反射之前，此文The Laws of Reflection必讀。網上中文翻譯版本不少，可以搜索閱讀。

開始具體篇幅之前，先看一下反射三原則：

• 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.

在三原則中，有兩個關鍵詞 interface value 與 reflection object。有點難理解，畫張圖可能你就懂了。

先看一下什麼是反射對象 reflection object？ 反射對象有很多，但是其中最關鍵的兩個反射對象reflection object是：reflect.Type與reflect.Value.直白一點，就是對變量類型與值的抽象定義類，也可以說是變量的元信息的類定義.

再來，爲什麼是接口變量值 interface value, 不是變量值 variable value 或是對象值 object value 呢？因爲後兩者均不具備廣泛性。在 Go 語言中，空接口 interface{}是可以作爲一切類型值的通用類型使用。所以這裏的接口值 interface value 可以理解爲空接口變量值 interface{} value。

結合圖示，將反射三原則歸納成一句話：

通過反射可以實現反射對象 reflection object與接口變量值 interface value之間的相互推導與轉化, 如果通過反射修改對象變量的值，前提是對象變量本身是可修改的。

2. 反射的應用

在程序開發中是否需要使用反射功能，判斷標準很簡單，即是否需要用到變量的類型信息。這點不難判斷，如何合理的使用反射纔是難點。因爲，反射不同於普通的功能函數，它對程序的性能是有損耗的，需要儘量避免在高頻操作中使用反射。

舉幾個反射應用的場景例子:

2.1 判斷未知對象是否實現具體接口

通常情況下，判斷未知對象是否實現具體接口很簡單，直接通過 變量名.(接口名) 類型驗證的方式就可以判斷。但是有例外，即框架代碼實現中檢查調用代碼的情況。因爲框架代碼先實現，調用代碼後實現，也就無法在框架代碼中通過簡單額類型驗證的方式進行驗證。

看看 grpc 的服務端註冊接口就明白了。

grpcServer := grpc.NewServer()
// 服務端實現註冊
pb.RegisterRouteGuideServer(grpcServer, &routeGuideServer{})

當註冊的實現沒有實現所有的服務接口時，程序就會報錯。它是如何做的，可以直接查看pb.RegisterRouteGuideServer的實現代碼。這裏簡單的寫一段代碼，原理相同：

//目標接口定義
type Foo interface {
    Bar(int)
}
  
dst := (*Foo)(nil)
dstType := reflect.TypeOf(dst).Elem()

//驗證未知變量 src 是否實現 Foo 目標接口
srcType := reflect.TypeOf(src)
if !srcType.Implements(dstType) {
        log.Fatalf("type %v that does not satisfy %v", srcType, dstType)
}

這也是grpc框架的基礎實現，因爲這段代碼通常會是在程序的啓動階段所以對於程序的性能而言沒有任何影響。

2.2 結構體字段屬性標籤

通常定義一個待JSON解析的結構體時，會對結構體中具體的字段屬性進行tag標籤設置，通過tag的輔助信息對應具體JSON字符串對應的字段名。JSON解析就不提供例子了，而且通常JSON解析代碼會作用於請求響應階段，並非反射的最佳場景，但是業務上又不得不這麼做。

這裏我要引用另外一個利用結構體字段屬性標籤做反射的例子，也是我認爲最完美詮釋反射的例子，真的非常值得推薦。這個例子出現在開源項目github.com/jaegertracing/jaeger-lib中。

用過 prometheus的同學都知道，metric探測標量是需要通過以下過程定義並註冊的：

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函數。項目一旦複雜，可讀性就很差。再看看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"`
    }
}

在應用中首先直接定義匿名結構metrics， 將針對該應用的metric探測標量定義到具體的結構體字段中，並通過其字段標籤tag的方式設置名稱。這樣在代碼的可讀性大大增強了。

再看看初始化代碼:

import "github.com/jaegertracing/jaeger-lib/metrics/prometheus"

//初始化
metrics.Init(&app.metrics, prometheus.New(), nil)

不服不行，完美。這段樣例代碼實現在我的這個項目中: x-mod/thriftudp，完全是參考該庫的實現寫的。

2.3 函數適配

原來做練習的時候，寫過一段函數適配的代碼，用到反射。貼一下：

//Executor 適配目標接口，增加 context.Context 參數
type Executor func(ctx context.Context, args ...interface{})

//Adapter 適配器適配任意函數
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")
    }
}

僅僅爲了練習，生產環境還是不推薦使用，感覺太重了。

最近看了一下Go 1.14的提案，關於try關鍵字的引入, try參考。按其所展示的功能，如果自己實現的話，應該會用到反射功能。那麼對於現在如此依賴 error 檢查的函數實現來說，是否合適,挺懷疑的，等Go 1.14出了，驗證一下。

3 小結

反射的最佳應用場景是程序的啓動階段，實現一些類型檢查、註冊等前置工作，既不影響程序性能同時又增加了代碼的可讀性。最近迷上新褲子，所以別再問我什麼是反射了：）

參考資源:

• The Laws of Reflection
• Go Data Structures: Interfaces