單體 or 微服務?Service Weaver:我全都要!
TL;DR
怎么理解 Service Weaver,就是一個應用中有很多的接口,這些接口間會互相調用。如果將操作系統進程(應用)比做一塊電路板,接口比做元器件??梢赃x擇將哪些元器件放入該電路板中,哪些元器件放入其他的電路板中。
同一塊電路板中的元器件間通過板上的導線連接(進程內的本地方法調用);不同電路板中的元器件間通過排線來連接(遠程方法調用)。
總結幾個關鍵詞:
- 一個編程框架
- 用于編寫、部署、管理分布式應用
- 支持的語言 Go
- 在本地以單進程、多進程運行
- 在云端由框架拆分成微服務,并于云供應商集成
- 單體方式開發,微服務方式部署
體驗了一圈下來,給我的感覺有點類似 Notion、Obsidian 這類筆記軟件。傳統的筆記軟件只能引用其他的筆記,而這類筆記可以細粒度到 heading 內容。
放到微服務下就是管理的維度不在是服務本身,而且更小的接口,并且對某些接口進行擴展,即使所有接口都位于同一個二進制文件中。
背景
架構的演進,總是在解決問題的過程中引入新的問題,然后再解決問題,循環往復。
從單體到微服務
軟件架構從單體演進到微服務架構已經十多年了,尤其是近幾年云原生風生水起,微服務架構已有深入人心的架勢。
單體架構由于在規模擴大時,單體面臨性能瓶頸和硬件限制、無法支撐業務的快讀迭代、開發效率下降協同難度增加等原因,頹勢日漸明顯。然后就有了微服務架構的提出,來解決單體架構的各種問題。
上云
由于云平臺提供顯著的成本效益,減少初始投資并實現按需付費、提供極大的靈活性和可擴展性、提供的穩定性和可靠性確保業務連續性、專業的安全保障和合規性支持減輕企業的運營負擔,企業將其業務和數據遷移至云計算平臺。
問題
拆分成微服務,由此帶來了不少好處:更高效的應用擴展、更小的錯誤傳播半徑、獨立的安全域以及完善的模塊邊界。
反過來,如何正確地找到邊界進行拆分并非易事。拆分的依據是什么?two pizza team?依據資源使用、組織架構、數據結構?亦或是考慮未來的增長?
微服務的拆分執行下來毫無章法,最終的結果是微服務越來越多、更多的故障點、更長的鏈路、更大的延遲。這實際上增加了應用的開發、部署和管理成本。
- 原本單個二進制文件,拆分后有多個;原本一次部署完成,拆分后需要多個 CI/CD 流水線來部署;原本一個配置文件,拆分后需要維護多個。
- 微服務彼此獨立部署,無法忽略多版本的情況。需要調整部署策略來降低風險,同樣還有本地開發和測試的難度增加。
- 學習成本高,需要學習如何將應用二進制文件包裝成容器,并了解云的各種工具和部署方式,即使對經驗豐富的程序員來說也難以理解。
- 同時還要解決分布式帶來的各種問題,如服務發現、安全、負載均衡,以及服務間的調用。
- 延遲增加,時間消耗在數據的序列化以及網絡傳輸上。
為什么用 Service Weaver?
今年 3 月 Google 開源了 Service Weaver[1],希望能解決微服務架構的各種問題。
有了 Servier Weaver,你可以專注在業務邏輯的開發上,其他的工作交給 Service Weaver 來完成。
無需要糾結微服務的拆分規則,可以拆分為任意數量的組件??梢栽诓渴鸬臅r候輕松指定哪些組件作為一個微服務來運行,哪些在不同的微服務上運行。
使用 Service 可以部署和管理單一二進制文件。
Service Weaver 使用自定義的序列化和傳輸協議,成本效益比行業最佳的解決方案(gRPC+protobuf)高出三倍。
如何使用 Service Weaver 開發應用?
Service Weaver 的核心是組件(component),一個類似 actor 的計算單元。
組件是個常見的 Go 接口,組件間的交互通過調用接口定義的方法來完成。
下面的示例中定義了一個 Reverser 組件,用于反轉字符串。
// The interface of the Reverser component.
type Reverser interface {
Reverse(context.Context, string) (string, error)
}
// The implementation of the Reverser component.
type reverser struct{
weaver.Implements[Reverser]
}
func (r reverser) Reverse(_ context.Context, s string) (string, error) {
runes := []rune(s)
n := len(runes)
for i := 0; i < n/2; i++ {
runes[i], runes[n-i-1] = runes[n-i-1], runes[i]
}
return string(runes), nil
}
其他組件可以調用 Reverser 組件的方法:
reversed, err := reverser.Reverse(ctx, "Hello, World!")
組件的最大優點是不依賴于系統進程。上面的例子中,盡管沒有編寫任何網絡和序列化相關的代碼,這些組件可以運行在不同的進程中甚至是不同的機器上。
圖片
如上圖所示,如果組件位于同一個進程中,方法的調用就是傳統的 Go 方法調用;如果位于不同的進程中,方法的調用就是 RPC。
將應用拆分為不同組件的過程,有點類似微服務的拆分。組件也同樣有著清晰的邊界,以及很好的擴展性。但又沒有微服務的缺陷:
- 所有組件都運行同一個版本,無需考慮版本的兼容性。
- 可以很容易地通過 go run 和 go test 運行和測試應用。
- 微服務的拆分和合并是非常痛苦的。
如何管理 Service Weaver 應用?
部署
在云上運行就跟本地運行一樣簡單:
$ go run . # Run locally, in the same OS process.
$ weaver multi deploy weaver.toml # Run locally, in multiple OS processes.
$ weaver gke deploy weaver.toml # Run in the cloud.
配置
Service Weaver 需要的配置非常少。一個 在線商城[2] 的演示中可能需要超過 1500 行配置,而 Service Weaver 編寫的同樣應用所需的配置不超過 10 行:
[weaver]
binary = "./online_boutique"
rollout = "6h"
[gke]
regions = ["us-west1", "us-east2"]
listeners.boutique = {public_hostname = "online-boutique.net"}
只需指定二進制文件、部署的持續時間、部署的區域以及公開訪問的地址。就這么簡單。
發布新版本
傳統的微服務,在發布新版本時,舊版本的示例可以會與其他新版本的示例進行通信。
Service Weaver 使用不同的方式升級,確??蛻舳说恼埱笸耆谙嗤陌姹鞠绿幚恚翰煌姹镜慕M件不會發生通信。
這就避免了大多數的系統故障:研究表明的:多大三分之二的故障是由系統多個版本之間的交互引起的[3]。
有了 Service Weaver,僅需更新代碼、構建、運行即可,其他的交給 Service Weaver。
可觀測性
Service Weaver 提供了用于日志、指標和鏈路跟蹤的庫,并自動與應用的部署環境集成。
下面的示例演示了如何為 Reverser 組件添加計數指標:
var reverseCount = metrics.NewCounter(
"reverse_count",
"The number of times Reverser.Reverse has been called",
)
func (reverser) Reverse(_ context.Context, s string) (string, error) {
reverseCount.Add(1.0)
// ...
}
測試
傳統的微服務,應用開發周期非常慢。在迭代中,需要安裝笨重的云依賴、復雜的測試框架,或者部署到云上。這些都極大影響了開發進度。
有了 Service Weaver 可以想運行 Go 程序一樣完成構建、運行、測試。提供的 weavertest包可用來編寫端到端測試,就像寫單元測試一樣簡單。
演示
安裝 Service Weaver
參考 安裝文檔[4],注意要求 Go 的版本不低于 1.21。在 macOS 上直接用 Homebrew 安裝:
brew install service-weaver
weaver version
weaver v0.21.2 darwin/arm64
go version
go version go1.21.3 darwin/arm64
初始化工程
mkdir hello-sample
cd hello-sample
go mod init hello-sample
使用上面 Reverser 組件的例子。
編寫 Reverser 組件
創建 reverser.go 文件,內容如下:
package main
import (
"context"
"github.com/ServiceWeaver/weaver"
)
// Reverser component.
type Reverser interface {
Reverse(context.Context, string) (string, error)
}
// Implementation of the Reverser component.
type reverser struct{
weaver.Implements[Reverser]
}
func (r *reverser) Reverse(_ context.Context, s string) (string, error) {
runes := []rune(s)
n := len(runes)
for i := 0; i < n/2; i++ {
runes[i], runes[n-i-1] = runes[n-i-1], runes[i]
}
return string(runes), nil
}
Reverser 組件通過定義創建接口 Reverser 定義,該接口定義了用于反轉字符串的方法 Reverse;結構體類型 reverser 通過 weaver.Implements[Reverser] 定義為組件 Reverser 的實現。
接下來是調用組件的代碼。
編寫 Main 組件
創建 main.go 文件,內容如下,也就是 main 組件:
package main
import (
"context"
"fmt"
"log"
"github.com/ServiceWeaver/weaver"
)
func main() {
if err := weaver.Run(context.Background(), serve); err != nil {
log.Fatal(err)
}
}
type app struct{
weaver.Implements[weaver.Main]
reverser weaver.Ref[Reverser]
}
func serve(ctx context.Context, app *app) error {
// Call the Reverse method.
var r Reverser = app.reverser.Get()
reversed, err := r.Reverse(ctx, "!dlroW ,olleH")
if err != nil {
return err
}
fmt.Println(reversed)
return nil
}
weaver.Run(...) 初始化并運行 Service Weaver 應用,每個應用都有一組組件組成。運行時會自動創建 weaver.Main 并將其交給應用。
查看其源碼可以看到使用了泛型:
func Run[T any, P PointerToMain[T]](ctx context.Context, app func(context.Context, *T "T any, P PointerToMain[T]") error) error {
...
}
Run 執行時會先找到 Main 組件的定義,在上面的代碼中結構體類型 app 被定義為 weaver.Main 組件,然后創建該組件并將其交給代碼中的 serve 來使用,然后調用 serve 函數。
在 Main 組件 app 中我們還可以看到 reverser weaver.Ref[Reverser]。在 Service Weaver 中,如果一個組件 X 要調用組件 Y,就會再 X 的定義中加入 y weaver.Ref[Y],因此這里 Main 組件將會調用 Reverser 組件。
在創建 Main 組件時,會從“注冊表”中找到組件 Reverser 的“真正”實現,并將其交給 Main 組件。
這里的真正實現,可能是本地的調用,也可能是遠程的調用。怎么實現的?還有很重要的一步:生成代碼。
生成代碼
然后執行下面的命令生成代碼 weaver_gen.go:
weaver generate
簡單看下文件的內容(里面用了大量的反射),首先有個 init() 方法進行組件的注冊,注冊信息包括
- 組件名
- 接口
- 接口的實現
- 本地調用 stub
- 遠程調用的客戶端 stub
- 供遠程調用的服務端 stub
- 通過反射進行方法調用的 stub
其中幾個 stub 也都在 weaver_gen.go 文件中,由上面的命令自動生成。
因此,假如不執行 weaver generate 命令就沒有 weaver_gen.go 文件,在運行時也就找不到任何組件的注冊信息的。
運行
現在可以運行應用:
go run .
╭───────────────────────────────────────────────────╮
│ app : hello-sample │
│ deployment : 09caf84b-822c-44d3-a149-a5b2e733a136 │
╰───────────────────────────────────────────────────╯
Hello, World!
對服務來說用這種方式來觸發調用肯定不合理,而是應該讓其接收 HTTP 的流量。
進階 - 單進程部署部署
接下來,使用下面的代碼替換 main.go:
package main
import (
"context"
"fmt"
"log"
"net/http"
"github.com/ServiceWeaver/weaver"
)
func main() {
if err := weaver.Run(context.Background(), serve); err != nil {
log.Fatal(err)
}
}
type app struct {
weaver.Implements[weaver.Main]
reverser weaver.Ref[Reverser]
hello weaver.Listener
}
func serve(ctx context.Context, app *app) error {
// The hello listener will listen on a random port chosen by the operating
// system. This behavior can be changed in the config file.
fmt.Printf("hello listener available on %v\n", app.hello)
// Serve the /hello endpoint.
http.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
name := r.URL.Query().Get("name")
if name == "" {
name = "World"
}
reversed, err := app.reverser.Get().Reverse(ctx, name)
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
fmt.Fprintf(w, "Hello, %s!\n", reversed)
})
return http.Serve(app.hello, nil)
}
在定義 Main 組件時加入了 hello weaver.Listener,Service Weaver 會自動初始化一個 HTTP 監聽器,并接收網絡流量。
在 serve 中定義了 HTTP 路徑 /hello:在接收到流量后從請求中讀取參數 name 的值,然后調用 Reverser 組件;同時 serve 返回的 http.Server 運行在 Main 組件的 HTTP 監聽器上。
生成代碼
由于修改了 Main 組件的定義,需要執行 weaver generate 重新生成代碼。在更新后的 weaver_gen.go中可以看到 Main 組件的注冊信息多了一個 Listeners,值是個字符串數組 []string{"hello"},對應著代碼中監聽器的名字 hello。
配置文件
此時如果運行應用,會隨機給應用分配一個端口。如果要自定義端口的話,就需要增加配置文件了。
創建一個名為 weaver.toml 的文件,內容如下:
[single]
listeners.hello = {address = "localhost:12345"}
在配置文件中設置監聽器 hello 的監聽地址。
運行
在運行時需要將配置文件的路徑提供給應用。
SERVICEWEAVER_CONFIG=weaver.toml go run .
╭───────────────────────────────────────────────────╮
│ app : hello-sample │
│ deployment : 68e82ba2-a5ba-49c0-8b56-4edb775dba4b │
╰───────────────────────────────────────────────────╯
hello listener available on 127.0.0.1:12345
發送請求,可以收到反轉后的字符串。
curl "localhost:12345/hello?name=world"
Hello, dlrow!
[!INFO] 可以通過 /debug/weaver/healthz 端點查看應用的健康狀態。 curl -i "localhost:12345/debug/weaver/healthz" HTTP/1.1 200 OK Date: Wed, 11 Oct 2023 00:20:01 GMT Content-Length: 2 Content-Type: text/plain; charset=utf-8 OK
進階 - 多進程
配置文件
接下來修改配置文件,用下面的內容替換:
[serviceweaver]
binary = "./hello-sample"
[multi]
listeners.hello = {address = "localhost:12345"}
在配置文件中,這次我們加入了二進制文件地址,以及多進程部署的地址。
運行
因為是多進程運行無法使用 go run 命令了,此時要用到 weaver multi 命令了(通過 weaver multi -h查看使用方式):
weaver multi deploy weaver.toml
╭───────────────────────────────────────────────────╮
│ app : hello-sample │
│ deployment : 9956d5c9-e88b-4d0f-a808-d4f7f475ed36 │
╰───────────────────────────────────────────────────╯
S1011 08:36:28.419836 stdout 5df75365 │ hello listener available on 127.0.0.1:12345
S1011 08:36:28.419922 stdout 74d79043 │ hello listener available on 127.0.0.1:12345
weaver multi 為每個組件各創建了兩個副本,因此可以看到打印了兩行日志。如果再次發送請求,也會得到同樣的應答。
這次我們通過 Weaver Dashboard 來查看應用情況,通過下面的命令啟用 dashboard(為其隨機分配監聽接口):
weaver multi dashboard
Dashboard available at: http://127.0.0.1:56108
在瀏覽器中可以打開其 dashboard。
圖片
點擊鏈接后可以獲取其詳細信息,其中就可以看到每個組件都有兩個進程:
圖片
Dashboard 展示的信息相比命令行的內容會更加詳細:
weaver multi status
╭────────────────────────────────────────────────────────────────╮
│ DEPLOYMENTS │
├──────────────┬──────────────────────────────────────┬──────────┤
│ APP │ DEPLOYMENT │ AGE │
├──────────────┼──────────────────────────────────────┼──────────┤
│ hello-sample │ 9956d5c9-e88b-4d0f-a808-d4f7f475ed36 │ 1h46m17s │
╰──────────────┴──────────────────────────────────────┴──────────╯
╭──────────────────────────────────────────────────────────────────╮
│ COMPONENTS │
├──────────────┬────────────┬───────────────────────┬──────────────┤
│ APP │ DEPLOYMENT │ COMPONENT │ REPLICA PIDS │
├──────────────┼────────────┼───────────────────────┼──────────────┤
│ hello-sample │ 9956d5c9 │ weaver.Main │ 28079, 28082 │
│ hello-sample │ 9956d5c9 │ hello-sample.Reverser │ 28083, 28084 │
╰──────────────┴────────────┴───────────────────────┴──────────────╯
╭────────────────────────────────────────────────────────╮
│ LISTENERS │
├──────────────┬────────────┬──────────┬─────────────────┤
│ APP │ DEPLOYMENT │ LISTENER │ ADDRESS │
├──────────────┼────────────┼──────────┼─────────────────┤
│ hello-sample │ 9956d5c9 │ hello │ 127.0.0.1:12345 │
╰──────────────┴────────────┴──────────┴─────────────────╯
進階 - 云端部署
[!IMPORTANT] 注意! 接下來的操作是在 X86 的平臺上完成的。
安裝 weaver-kube
使用 weaver-kube[5] 可以將應用部署到普通的 Kubernetes 上。
go install github.com/ServiceWeaver/weaver-kube/cmd/weaver-kube@latest
weaver-kube version
weaver kube v0.21.2 darwin/arm64
配置文件
使用下面的內容替換 weaver.toml 文件:
[serviceweaver]
binary = "./hello-sample"
[kube]
repo = "docker.io/addozhang"
listeners.hello = {public = true}
這次使用 kube 配置,對應 weaver kube deploy 操作。其中 repo 是執行操作時構建鏡像所推送的倉庫地址,設置監聽器為 {public = true} 將會為其創建 Kubernetes LoadBalancer Service。
weaver kube deploy weaver.toml
...
Generating kube deployment info ...
Generated roles and bindings
Replica sets generated successfully [hello-sample/Reverser github.com/ServiceWeaver/weaver/Main]
Generated kube deployment for replica set github.com/ServiceWeaver/weaver/Main
Generated kube autoscaler for replica set github.com/ServiceWeaver/weaver/Main
Generated kube listener service for listener hello
Generated kube deployment for replica set hello-sample/Reverser
Generated kube autoscaler for replica set hello-sample/Reverser
Generated Jaeger deployment
Generated Jaeger service
Generated kube deployment for config map hello-sample-prometheus-config-4beb9a0b
Generated kube deployment for Prometheus hello-sample-prometheus-21ee5ea1
Generated kube service for Prometheus hello-sample-prometheus-21ee5ea1
Generated kube deployment for config map hello-sample-loki-config-e2c46e76
Generated kube deployment for config map hello-sample-promtail-b648e7f2
Generated kube deployment for Loki hello-sample-loki-e8d90de6
Generated kube service for Loki hello-sample-loki-e8d90de6
Generated kube daemonset for Promtail hello-sample-promtail-b648e7f2
Generated kube deployment for config map hello-sample-grafana-config-a873d265
Generated Grafana deployment
Generated Grafana service
kube deployment information successfully generated
/tmp/kube_1cfbd355-10a4-47b6-aaec-efd9bbd17a06.yaml
鏡像推送到倉庫后,還會生成部署所需的 manifest 文件,執行命令進行部署:
kubectl apply -f /tmp/kube_1cfbd355-10a4-47b6-aaec-efd9bbd17a06.yaml
集群我用的是 k3s 創建的:
export INSTALL_K3S_VERSION=v1.27.1+k3s1 curl -sfL https://get.k3s.io | sh -s - --disable traefik --disable local-storage --disable metrics-server --write-kubeconfig-mode 644 --write-kubeconfig ~/.kube/config
測試
查看 Pod 和 LoadBalancer 的端口,可以看到為兩個組件各創建了一個 Pod。
kubectl get po,svc -l appName=hello-sample
NAME READY STATUS RESTARTS AGE
pod/hello-sample-github-com-serviceweaver-weaver-main-a0713fddsfgb2 1/1 Running 0 6h16m
pod/hello-sample-hello-sample-reverser-ad954898-01bf315f-86df6pvchc 1/1 Running 0 6h16m
kubectl get svc -l lisName=hello default ?
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-sample-lis-hello-4701ccf4 LoadBalancer 10.43.195.210 10.0.2.4 80:31340/TCP 6h17m
在宿主機上執行命令,執行成功。
curl "localhost/hello?name=world"
Hello, dlrow!
總結
Service Weaver 的思路很好,針對目前微服務架構的問題做了優化和提升,再加上有 Google 的背書,希望繼續演進下去。尤其當前只支持 Go 語言,雖說 Go 在云原生中風生水起,當時業務開發大部分仍是 Java 技術棧。在業務開發中,Go 的受眾還是相當小。
當前的版本是 v0.21.2,仍處于很早期的階段,請謹慎對待(源碼里搜了下 TODO 關鍵詞有 100 多處)。
沒有完美的架構,沒有銀彈!
參考資料
[1] Google 開源了 Service Weaver: https://opensource.googleblog.com/2023/03/introducing-service-weaver-framework-for-writing-distributed-applications.html
[2] 在線商城: https://github.com/ServiceWeaver/onlineboutique
[3] 研究表明的:多大三分之二的故障是由系統多個版本之間的交互引起的: https://scholar.google.com/scholar?cluster=4116586908204898847
[4] 安裝文檔: https://serviceweaver.dev/docs.html#installation
[5] weaver-kube: https://github.com/ServiceWeaver/weaver-kube