文｜丁飛（花名：路德 )
螞蟻集團高階工程師
深耕於 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 採訪｜開源可以是做力所能及的事
歡迎關注：
