Go 原生外掛使用問題全解析

SOFAStack 發表於 2022-07-14
Go

圖片

文|丁飛(花名:路德 )

螞蟻集團高階工程師

圖片

深耕於 SOFAMesh 產品的商業化落地 主要方向為基於服務網格技術的系統架構升級方案設計與落地

本文 4394 字 閱讀 10 分鐘

|前言|

MOSN 作為螞蟻集團在 ServiceMesh 解決方案中的資料面元件,從設計之初就考慮到了第三方的擴充套件開發需求。目前,MOSN 支援通過 gRPC、WASM、以及 Go 原生外掛三種機制對其進行擴充套件。

我在主導設計和落地基於 Go 原生外掛機制的擴充套件能力時遇到了很多問題,鑑於這方面的相關資料很少,因而就有了這個想法來做一個非常粗淺的總結,希望能對大家有所幫助。

注:本文只說問題和解決方案,不讀程式碼,文章最後會給出核心原始碼的 checklist。

PART. 1--文章技術背景

一、執行時

通常而言,在計算機程式語言領域,“執行時”的概念和一些需要使用到 VM 的語言相關。程式的執行由兩個部分組成:目的碼和“虛擬機器”。比如最為典型的 JAVA,即 Java Class + JRE。

對於一些看似不需要“虛擬機器”的程式語言,就不太會有“執行時”的概念,程式的執行只需要一個部分,即目的碼。但事實上,即使是 C/C++,也有“執行時”,即它所執行平臺的 OS/Lib。

Go 也是一樣,因為執行 Go 程式不需要前置部署類似於 JRE 的“執行時”,所以它看起來似乎跟“虛擬機器”或者“執行時”沒啥關係。但事實上,Go 語言的“執行時”被編譯器編譯成了二進位制目的碼的一部分。

圖片

圖 1-1. Java 程式、runtime 和 OS 關係

圖片

圖 1-2. C/C++ 程式、runtime 和 OS 關係

圖片

圖 1-3. Go 程式、runtime 和 OS 關係

二、Go 原生外掛機制

作為一個看起來更貼近 C/C++ 技術棧的 Go 語言來說,支援類似動態連結庫的擴充套件一直是社群中較為強烈的訴求。

如圖 1-5,Go 在標準庫中專門提供了一個 plugin 包,作為外掛的語言級程式設計介面,src/plugin 包的本質是使用 cgo 機制呼叫 unix 的標準介面:dlopen() 和 dlsym() 。因此,它給 C/C++ 背景的程式設計師一種“這題我會”的錯覺。

圖片

圖 1-4. C/C++ 程式載入動態連結庫

圖片

圖 1-5. Go 程式載入動態連結庫

PART. 2--典型問題解決

很遺憾,與 C/C++ 技術棧相比,Go 的外掛的產出物雖然也是一個動態連結庫檔案,但它對於外掛的開發、使用有一系列很複雜的內建約束。更令人頭大的是,Go 語言不但沒有對這些約束進行系統性的介紹,甚至寫了一些比較差的設計和實現,導致外掛相關問題的排錯非常反人類。

本章節重點跟大家一起看下,在開發、使用 Go 外掛,主要是編譯、載入外掛的時候,最常見、但必須定位到 Go 標準庫 (主要包括編譯器、連結器、打包器和執行時部分) 原始碼才能完全弄明白的幾個問題,及對應的解決方法。

簡而言之,Go 的主程式在載入 plugin 時,會在“runtime”裡對兩者進行一堆約束檢查,包括但不限於:

- go version 一致

- go path 一致

- go dependency 的交集一致

  • 程式碼一致
  • path 一致

- go build 某些 flag 一致

一、不一致的標準庫版本

主程式載入外掛時報錯:

plugin was built with a different version of package runtime/internal/sys

從這個報錯的文字可以得知,具體有問題的庫是 runtime/internal/sys ,很顯然這是一個 go 的內建標準庫。看到這裡,你可能會有很大的疑惑:我明明用的是同一個本地環境編譯主程式和外掛,為什麼報標準庫不是一個版本?

答案是,Go 的 error 日誌描述不準確。而這個報錯出現的根本原因可以歸結為:主程式和外掛的某些關鍵編譯 flag 不一致,跟“版本”沒啥關係。

比如,你使用下面的命令編譯外掛:

GO111MODULE=on go build --buildmode=plugin -mod readonly -o ./codec.so ./codec.go

但是你使用 goland 的 debug 模式除錯主程式,此時,goland 會幫你把 go build 命令按下面的例子組裝好:

圖片

注意,goland 組裝的編譯命令裡包含關鍵的 

-gcflags all=-N -l 引數,但是外掛編譯的命令裡沒有。此時,你在嘗試拉起外掛時就會得到一個有關 runtime/internal/sys 的報錯。

圖片

圖 2-1. 編譯 flag 不一致導致的載入失敗

解決這一類標準庫版本不一致問題的方案比較簡單:儘可能對齊主程式和外掛編譯的 flag。事實上,有一些 flag 是不影響外掛載入的,你可以在具體的實踐中慢慢摸索。

二、不一致的第三方庫版本

如果使用 vendor 來管理 Go 的依賴庫,那麼當解決上一節的問題之後,你 100% 會立即遇到以下這個報錯:

plugin was built with a different version of package xxxxxxxx

其中,xxxxxxxx 指的是某一個具體的三方庫,比如 github.com/stretchr/testify。這個報錯有幾個非常典型的原因,如果沒有相關的排查經驗,其中幾個可能會燒掉開發人員不少時間。

Case 1. 版本不一致

如報錯所示,似乎原因很明確,即主程式和外掛所共同依賴的某個第三方庫版本不一致,報錯中會明確告訴你哪一個庫有問題。此時,你可以對比排查主程式和外掛的 go.mod 檔案,分別找到問題庫的版本,看看他們是否一致。如果這時候你發現主程和外掛確實有 commitid 或 tag 的不一致問題,那解決的方法也很簡單:對齊它們

但是在很多場景下,你只會用到三方庫的一部分:如一個 package,或者只是引了某些 interface。這一部分的程式碼在不同的版本里可能根本就沒有變更,但其他沒用到的程式碼的變更,同樣會導致整個三方庫版本的變更,進而導致你成為那個“版本不一致”的無辜受害者。

而且,此時你可能立即會遇到另一個問題:以誰為基準對齊?主程式?還是外掛?

從常理上來說,以主程式為基線進行對齊是一個比較好的策略,畢竟外掛是新新增的“附屬品”,且主程式與外掛通常是“一對多”的關係。但是,如果外掛的三方庫依賴因為任何原因就是不能和主程式對齊怎麼辦?在嘗試了很久以後,我暫時沒有找到一個完美解決這個問題的辦法。

如果版本無法對齊,就只能從根本上放棄走外掛這條路。

Go 語言的這種對三方庫的、幾乎無腦的強一致性約束,從一方面來說,避免了執行時因為版本不一致帶來的潛在問題;從另一方面來說,這種刻意不給程式設計師靈活度的設計,對外掛化、定製化、擴充套件化開發非常的不友好。

圖片

圖 2-2. 共同依賴的三方庫版本不一致導致的載入失敗

Case 2. 版本號一致,程式碼不一致

當你按照 case 1 的思路排查 go.mod 檔案,但是驚訝的發現報錯的庫版本是一致的時候,事情就會變得複雜起來。你可能會拿出世界上最先進的文字查驗工具,並花掉一個上午去 diff 三方庫的 commitid,但它們就是一模一樣,似乎陷入了薛定諤的版本。

出現這個問題可能的一個不是原因的原因是:有人直接修改了 vendor 目錄下的程式碼,Go 外掛機制會對程式碼內容的一致性進行校驗。

這真的是一個非常令人頭大,並難以排查的原因。除了修改程式碼的那個人,和已經在其他 case 中被“坑”過的那些人,沒人會知道這件事情。如果修改的 vendor 程式碼出現在主程式裡,你就幾乎沒有任何靠譜的辦法讓它們正常工作起來。

不要直接在 vendor 裡改程式碼!!!

不要直接在 vendor 裡改程式碼!!!

不要直接在 vendor 裡改程式碼!!!

回饋開源社群,或者 fork-replace!!!

好訊息是,你不需要解決這個問題。因為即使解決了,也還會有更大的問題等著你。

圖片

圖 2-3. 共同依賴的三方庫程式碼被就地修改導致的載入失敗

Case 3. 路徑不一致

當按照 case 1 和 case 2 的思路都把問題排查、解決完,但它還是報 different version of package 的時候,可能你就會開始對 Go 的外掛機制失去耐心了:版本真的“一毛一樣”,程式碼真的一行沒動,為什麼還報不同版本???

原因是:外掛機制會校驗依賴庫原始碼的「路徑」,因此不能使用 vendor 管理依賴。

舉個例子:你的主程式原始碼放在 /path/to/main 目錄下,因此,你的某個三方庫依賴的目錄應該是:/path/to/main/vendor/some/thrid/part/lib;

同理,你的外掛原始碼放在 /path/to/plugin 目錄下,因此,同一個三方庫依賴的目錄應該是:/path/to/plugin/vendor/some/thrid/part/lib。

這些「檔案路徑」資料會被打包到二進位制可執行檔案裡並用於校驗,當主程式載入外掛時,Go 的“執行時”“聰明的”通過「檔案路徑」的差異認定它和外掛用的不是同一份程式碼,然後報了個 different version of package。

圖片

圖 2-4. 使用 vendor 機制管理第三方庫導致的載入失敗

同樣的問題也可能會出現在使用不同機器/使用者,分別編譯主程式、外掛的場景下:使用者名稱不同,go 程式碼的路徑應該也會不一樣。

解決這類問題的方法很暴力直接:刪掉主程式和外掛的 vendor 目錄,或者使用 -mod=readonly 編譯 flag

到這裡,如果你是使用同一臺機器進行主程式和外掛的編譯,那麼常見的問題應該都基本解決了,外掛機制理應能夠正常工作。另一方面,由於不再使用 vendor 管理依賴,因此 case 2 的問題也會在這裡被強制解決:要麼提 PR 給社群,要麼 fork-replace。

圖片

圖 2-5. 成功載入

三、不一致的 Go 版本

fatal error: runtime: no plugin module data

除了上面的那些問題以外,還有一個在多機器分別編譯主程/外掛場景下的常見報錯。這個報錯的一個可能原因是 Go 版本不一致,對齊它們即可。(如果從機器層面就是不能對齊怎麼辦?……)

圖片

圖 2-6. Go 版本不一致導致的載入失敗

PART. 3--統一解決方案

從第二 Part 中,我們看了一些既很難排查,也不是很好處理的問題。除此之外,其實還有一些問題沒有被重點介紹進來。作為一個程式語言官方支援的擴充套件機制,做的如此使用者不友好確實出人意料。

由於「專有云 MOSN」重點依賴 Go 的外掛機制做定開,因此必須拿出一個系統化的方案把這些問題統統解決掉。在嘗試直接修改 Go 原始碼無果以後 (吐槽:Go 外掛機制原始碼寫的令人略感遺憾) ,我們重點從“產品層”及外圍基礎設施入手開展了相關工作:

- 統一編譯環境:

  • 提供一個標準的 docker image 用來編譯主程式和外掛,規避任何 go 版本、gopath 路徑、使用者名稱等不一致所帶來的問題;
  • 預製 go/pkg/mod,儘可能減少因為沒有使用 vendor 模式導致每次編譯都要重新下載依賴的問題。

- 統一 Makefile:

  • 提供一套主程式和外掛的編譯 Makefile,規避任何因為 go build 命令帶來的問題。

- 統一外掛開發腳手架:

  • 由腳手架,而不是開發者拉齊外掛與主程式的依賴版本。並由腳手架解決其他相關問題。

- 流水線化:

  • 將編譯部署流水線化,進一步避免出現錯誤。

圖片

圖 3-1. 統一解決方案

PART. 4--關鍵原始碼位置

如果真的想從根本上搞清楚外掛校驗的機制,那這裡為你提供一些快速進入原始碼閱讀狀態的入口。我使用的 Go 原始碼為 1.15.2 版本。相關 Go 原始碼位置:

- compiler:go/src/cmd/compile/*

- linker:go/src/cmd/link/internal/ld/*

- pkg loader:go/src/cmd/go/internal/load/*

- runtime:go/src/runtime/*

一、go build 到底在做啥

你可以在 go build 命令裡新增 -x 引數,以顯式的列印出 Go 程式編譯、連結、打包的全流程,例如:

go build -x -buildmode=plugin -o ../calc_plugin.so calc_plugin.go

二、目的碼生成

go/src/cmd/compile/internal/gc/obj.go:55 :注意第 67 和第 72 行,這裡是兩個入口;

go/src/cmd/compile/internal/gc/iexport.go:244 :注意 280 行,這裡會記錄 path 相關資料。

三、庫雜湊生成演算法

go/src/cmd/link/internal/ld/lib.go:967:注意第 995-1025 行,這裡計算 pkg 的 hash。

四、庫雜湊校驗

go/src/runtime/symtab.go:392 :關鍵資料結構;

go/src/runtime/plugin.go:52 :連結期 hash 與執行時 hash 值校驗點;

go/src/cmd/link/internal/ld/symtab.go:621 :連結期 hash 賦值點;

go/src/cmd/link/internal/ld/symtab.go:521 :執行時 hash 賦值點。

PART. 5--總結

可以看到,即使 Go 的原生外掛機制有各種各樣令人頭痛的問題,SOFAStack 團隊依舊秉持“開源、開放、可擴充套件”的初衷,通過各種手段解決問題,並最終將此能力做到生產可用。

目前,專有云 MOSN 的協議編解碼器和 logger 的定製化開發已經實現全面的外掛化。接下來,我們將持續對 MOSN 架構進行升級,目標對包括路由邏輯、LB 邏輯、註冊中心/配置中心對接等在內的多方面能力進行外掛化支援。

瞭解更多……

MOSN Star 一下✨: https://github.com/mosn/mosn

點選閱讀原文,和我們一起共建吧🧸

本週推薦閱讀

MOSN 構建 Subset 優化思路分享

圖片

MOSN 文件使用指南

圖片

MOSN 1.0 釋出,開啟新架構演進

圖片

MOSN Contributor 採訪|開源可以是做力所能及的事

圖片

歡迎關注:

圖片