Go chassis雲原生微服務開發框架應用程式設計實戰

2022-08-24 18:03:57

什麼是Go chassis

go chassis是一個go語言微服務開發框架，專注於雲原生應用的開發主要的使用場景是雲服務開發。go chassis將雲服務開發過程中沉澱的能力融入到了開發框架中，以幫助開發團隊快速編寫雲原生應用。

文章目標

本文介紹我們的設計理念和目標，為何go chassis會誕生。後面的系列文章會著重介紹使用方法，專案實戰。對於微服務架構模式，雲原生要素，為什麼選擇go語言等將不再贅述。

誕生背景

公司開發雲服務，要構建健壯，韌性，安全，高可靠的雲服務，必然有大量基礎能力需要編寫，為了加速開發，我們將這些能力便沉澱在了該框架中。為什麼呢？

我們希望加速每一個元件也就是微服務的開發速度。有的人看到的只是冰山一角，真的要達成微服務架構模式的願景，其實需要繁重的工作量。就像冰山那樣，我們要將通用能力沉澱下去，能夠複用。如果讓各個業務團隊同時照顧冰山上下，各自開發各自的，那結果將是災難性的，企業用人成本極高。

在業務交付的過程中，各個雲團隊有大量的管理服務需要對接，每個團隊都在寫重複的程式碼，通過框架能力，將交付職責分離，減少開發成本：

如何快速開發一個微服務

可以跟隨這個檔案體驗。

github.com/go-chassis/…

統一治理和協定模型

我們使用Invocation概念來統一協定描述，當協定請求到來後，go chassis會把request轉換為Invocation進行治理（如負載均衡，限流，熔斷，重試，金絲雀釋出等），這樣就可以允許任意的協定接入到go chassis，並無縫使用go chassis提供的核心功能，當前預設提供原生grpc和http兩種協定的接入。

為什麼會有這樣的設計呢？

每個協定層的優化空間非常大，使用者態到核心態的呼叫速度本來就相對內部程式碼來說是很慢的，優化這一層程式碼很重要，RPC怎麼也比http來得好。
不同部門可能有私有協定訴求，那麼服務治理就交給核心框架完成。協定由業務部門決定自主研發或是整合現有協定。當你發現公司內部不同部門都在開發自己的協定做自己的服務治理時，再向將業務統一一個架構，一個工具鏈上，將非常困難。

可延伸的處理鏈條：handler chain as middleware

我們以Java為例，大家在寫一個攔截器或者過濾器的時候可以對請求進行處理，處理完，這個攔截器的的執行過程就結束了，那麼如何達成以下目標？

1.跟蹤業務執行結果指標，比如http狀態碼，並匯出他們讓prometheus收集。

2.跟蹤關鍵的業務執行結果，審計這些資訊。比如請求返回的一些結果資訊

3.分散式呼叫鏈追蹤，end span必須等到請求返回才能拿到。

使用者端呼叫遠端服務時，也需要進行中間處理，比如使用者端負載均衡，請求重試，這些不能夠耦合在業務程式碼中

Java的答案很簡單，註解。那麼go呢？

我們引入了handler chain程式設計模型，chain中每個handler都可以拿到後面的handler的執行結果，包括業務程式碼的執行結果。

看下介面定義

type Handler interface {
	Handle(*Chain, *invocation.Invocation, invocation.ResponseCallBack)
	Name() string
}

// ResponseCallBack process invocation response
type ResponseCallBack func(*Response)

ResponseCallBack用於接受後置handler返回的結果，所以每一個handler處理時都可以按需定義自己的ResponseCallBack來獲取後面handler甚至是業務邏輯程式碼的執行結果。幫助通用邏輯（即中介軟體）和業務邏輯徹底解耦。可以看下現在已經支援的中介軟體，無論限流，熔斷，負載均衡，認證鑑權，審計，我們都用此機制實現：

go-chassis.readthedocs.io/en/latest/m…

將公司全部的工具鏈，服務治理手段，安全合規等都落入到處理鏈中，可快速加快研發速度，並統一規範，減少管理負擔。

不只是API，通過設定簡化開發過程

只舉2個例子

監控

減少讓開發者自己呼叫API的過程，將他們簡化為設定項

例如可觀察：

引入一行程式碼

import _ github.com/go-chassis/go-chassis/v2/middleware/monitoring

加上設定

handler:
  chain:
    Provider:
      default: monitoring

就可以在伺服器端進行監控，匯出請求數，延遲等指標，大大加速開發人員效率

# HELP request_count 
# TYPE request_count counter
request_count{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0"} 14
# HELP request_process_duration 
# TYPE request_process_duration summary
request_process_duration{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0",quantile="0.5"} 3
request_process_duration{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0",quantile="0.9"} 80
request_process_duration{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0",quantile="0.99"} 80
request_process_duration_sum{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0"} 315
request_process_duration_count{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0"} 14

需要自定義指標：

err := metrics.CreateCounter(metrics.CounterOpts{
		Name:   「user_login」,
		Labels: labelsSlice,
	})
metrics.CounterAdd(「user_login」, 1, labelMap)

可信軟體

公司對軟體質量的高要求，需要我們編寫大量的基礎程式碼。我們也將通用的部分都落地到了框架中，通過簡單的組態檔啟用，不再需要不同團隊重複編寫程式碼

servicecomb:
  transport:
    failure:
      rest: http_500,http_502 #統計錯誤率時，例如只把500和502作為錯誤
    maxIdleCon:
      rest: 1024
    maxBodyBytes:
      rest: 20 #只需要指定我的服務能接受的body體大小，存取的超時時間即可不再需要各個團隊維護程式碼。
    maxHeaderBytes:
      rest: 1 #限制http header大小
    timeout: #限制使用者端超時
      rest: 30s

外掛化

為了應對不同業務訴求，我們總是要考慮“可替換性”。而這個的優先順序總是大於“可複用性”。這就是go chassis的外掛理念。基本所有的重要元件都是外掛化的，框架已經定義好標準介面，只需要開發者實現好，註冊到框架中，就可以在組態檔中設定並生效了，業務開發者是完全不感知的。可以參考我們對quota元件的擴充套件過程，他負責資源的配額管理

go-chassis.readthedocs.io/en/latest/d…

後續將詳細剖析go chassis的內部設計和特性使用。

在下一篇文章中，我將講述go chassis如何快速開發出一個微服務。由於是系列文章，隨著文章不斷更新，如果有期望瞭解的話題，內容可以留言反饋，我會加入到後續文章中。

專案地址：

github.com/go-chassis/…

目前的使用者：