Sentinel-Go 源碼系列（二）｜初始化流程和責任鏈設計模式

• 2021 年 11 月 9 日
• 筆記
• golang, Sentinel, sentinel-go

上節中我們知道了 Sentinel-Go 大概能做什麼事情，最簡單的例子如何跑起來

其實我早就寫好了本系列的第二篇，但遲遲沒有發布，感覺光初始化流程顯得有些單一，於是又補充了責任鏈模式，二合一，內容顯得豐富一些。

初始化流程

初始化做了什麼

Sentinel-Go 初始化時主要做了以下2件事情：

• 通過各種方式（文件、環境變數等）載入全局配置
• 啟動非同步的定時任務或服務，如機器 cpu、記憶體資訊收集、metric log 寫入等等

初始化流程詳解

提供的 API

上節例子中，我們使用了最簡單的初始化方式

func InitDefault() error

除此之外，它還提供了另外幾種初始化方式

// 使用給定的 parser 方法解析配置的方式來初始化
func InitWithParser(configBytes []byte, parser func([]byte) (*config.Entity, error)) (err error)

// 使用已解析好的配置對象初始化
func InitWithConfig(confEntity *config.Entity) (err error)

// 從 yaml 文件載入配置初始化 
func InitWithConfigFile(configPath string) error

從命名能看出它們只是配置的獲取方式不一樣，其中InitWithParser 有點意思，傳入的 parser 是個函數指針，對於 Java 寫慣了的我來說還是有點陌生，比如通過 json 解析可以寫出如下 parser

parser := func(configBytes []byte) (*config.Entity, error) {
	conf := &config.Entity{}
	err := json.Unmarshal(configBytes, conf)
	return conf, err
}
conf := "{\"Version\":\"v1\",\"Sentinel\":{\"App\":{\"Name\":\"roshi-app\",\"Type\":0}}}"
err := api.InitWithParser([]byte(conf), parser)

配置項

簡單看一下 Sentinel-Go 的配置項，首先配置被包裝在一個 Entity 中，包含了一個 Version 和 真正的配置資訊 SentinelConfig

type Entity struct {
	Version string
	Sentinel SentinelConfig
}

接著， SentinelConfig 是這樣：

type SentinelConfig struct {
	App struct {
		// 應用名
		Name string
		// 應用類型：普通應用，網關
		Type int32
	}
	// Exporter 配置
	Exporter ExporterConfig
	// 日誌配置
	Log LogConfig
	// 統計配置
	Stat StatConfig
	// 是否快取時間戳
	UseCacheTime bool `yaml:"useCacheTime"`
}

• App 應用資訊
  • 應用名
  • 應用類型：如普通應用、網關應用等
• ExporterConfig：prometheus exporter 暴露服務的埠和 path

type ExporterConfig struct {
	Metric MetricExporterConfig
}

type MetricExporterConfig struct {
	// http 服務地址，如 ":8080"
	HttpAddr string `yaml:"http_addr"`
	//  http 服務 path，如"/metrics".
	HttpPath string `yaml:"http_path"`
}

• LogConfig：包括使用什麼logger，日誌目錄，文件是否使用 pid（防止一台機器部署兩個應用日誌混合），以及 metric log 的單個文件大小、最多保留文件個數、刷新時間

type LogConfig struct {
	// logger，可自定義
	Logger logging.Logger
	// 日誌目錄
	Dir string
	// 是否在日誌文件後加 PID
	UsePid bool `yaml:"usePid"`
	// metric 日誌配置
	Metric MetricLogConfig
}

type MetricLogConfig struct {
  // 單個文件最大佔用空間
	SingleFileMaxSize uint64 `yaml:"singleFileMaxSize"`
	// 最多文件個數
	MaxFileCount      uint32 `yaml:"maxFileCount"`
	// 刷新間隔
	FlushIntervalSec  uint32 `yaml:"flushIntervalSec"`
}

• StatConfig：統計配置包括資源採集窗口配置，metric 統計的窗口、系統資訊收集間隔

type StatConfig struct {
	// 全局統計資源的窗口（後續文章再解釋）
	GlobalStatisticSampleCountTotal uint32 `yaml:"globalStatisticSampleCountTotal"`
	GlobalStatisticIntervalMsTotal  uint32 `yaml:"globalStatisticIntervalMsTotal"`
	// metric 統計的窗口（後續文章再解釋）
	MetricStatisticSampleCount uint32 `yaml:"metricStatisticSampleCount"`
	MetricStatisticIntervalMs  uint32 `yaml:"metricStatisticIntervalMs"`
	// 系統採集配置
	System SystemStatConfig `yaml:"system"`
}

type SystemStatConfig struct {
	// 採集默認間隔
	CollectIntervalMs uint32 `yaml:"collectIntervalMs"`
	// 採集 cpu load 間隔
	CollectLoadIntervalMs uint32 `yaml:"collectLoadIntervalMs"`
	// 採集 cpu 使用間隔
	CollectCpuIntervalMs uint32 `yaml:"collectCpuIntervalMs"`
	// 採集記憶體間隔使用
	CollectMemoryIntervalMs uint32 `yaml:"collectMemoryIntervalMs"`
}

配置覆蓋

從上文知道，參數可以通過自定義 parser / 文件 / 默認 的方式來傳入配置，但後面這個配置還可以用系統的環境變數覆蓋，覆蓋項目前只包括應用名、應用類型、日誌文件使用使用 PID 結尾、日誌目錄

func OverrideConfigFromEnvAndInitLog() error {
	// 系統環境變數可覆蓋傳入的配置
	err := overrideItemsFromSystemEnv()
	if err != nil {
		return err
	}
	...
	return nil
}

啟動後台服務

• 啟動 聚合 metric 定時任務，聚合後發送到 chan，聚合後的格式如下：

_, err := fmt.Fprintf(&b, "%d|%s|%s|%d|%d|%d|%d|%d|%d|%d|%d",
		m.Timestamp, timeStr, finalName, m.PassQps,
		m.BlockQps, m.CompleteQps, m.ErrorQps, m.AvgRt,
		m.OccupiedPassQps, m.Concurrency, m.Classification)

時間戳|時間字元串|名稱|通過QPS|阻斷QPS|完成QPS|出錯QPS|平均RT|已經通過QPS|並發|類別

• 啟動 metric 寫入日誌定時任務，可配置間隔時間（秒級），接受上個任務寫入 chan 的數據

• 啟動單獨 goroutine 收集 cpu 使用率 / load、記憶體使用，收集間隔可配置，收集到的資訊存放在 system_metric 下的私有變數

var (
	currentLoad        atomic.Value
	currentCpuUsage    atomic.Value
	currentMemoryUsage atomic.Value
)

• 若開啟，則啟動單獨 goroutine 快取時間戳，間隔是 1ms，這個主要是為了高並發下提高獲取時間戳的性能

func (t *RealClock) CurrentTimeMillis() uint64 {
  // 從快取獲取時間戳
	tickerNow := CurrentTimeMillsWithTicker()
	if tickerNow > uint64(0) {
		return tickerNow
	}
	return uint64(time.Now().UnixNano()) / UnixTimeUnitOffset
}

獲取時，如果拿到 0 則說明未開啟快取時間戳，取當前，如果拿到值說明已開啟，可直接使用

• 若配置了 metric exporter，則啟動服務，監聽埠，暴露 prometheus 的 exporter

責任鏈模式

什麼是責任鏈模式

可以用這樣一張圖形象地解釋什麼是責任鏈：

責任鏈模式為每次請求創建了一個鏈，鏈上有 N 多個處理者，處理者可在不同階段處理不同的事情，就像這幅圖上的小人，拿到一桶水（請求）後都可以完成各自的事情，比如往頭上澆，然後再傳遞給下一個。

為什麼叫責任？因為每個處理者只關心自己的責任，跟自己沒關係就遞交給鏈上的下一個處理者。

責任鏈在哪裡有用到？很多開源產品都是用了責任鏈模式，如 Dubbo、Spring MVC 等等

這麼設計有什麼好處？

• 簡化編碼難度，抽象出處理模型，只需關注關心的點即可
• 擴展性好，如果需要自定義責任鏈中的一環或者插拔某一環，非常容易實現

關於擴展性除了大家理解的軟體設計中的擴展性外，這裡還想提兩點，阿里開源的軟體其實都有高擴展性這個特性，一是因為是開源，別人使用場景未必和自己一致，留出擴展介面，不符合要求的，用戶可以自行實現，二是如果要追溯，阿里開源擴展性 Dubbo 可能算是祖師爺（未考證），Dubbo 作者（梁飛）的部落格中說過為什麼 Dubbo 要設計這麼強的擴展性，他對程式碼有一定的追求，在他維護時期，程式碼能保證高品質，但如果項目交給別人，如何才能保持現在的水準呢？於是他設計出一套很強的擴展，後面開發基於這個擴展去做，程式碼就不會差到哪裡去

• 可動態，可針對每個請求構造不同的責任鏈

Sentinel-Go 責任鏈設計

先看責任鏈的數據結構定義，Sentinel-Go 把處理者叫 Slot（插槽），將 Slot 分為了前置統計、規則校驗、統計三組，且每組是有有序的

type SlotChain struct {
	// 前置準備（有序）
	statPres []StatPrepareSlot
	// 規則校驗（有序）
	ruleChecks []RuleCheckSlot
	// 統計（有序）
	stats []StatSlot
	// 上線文對象池（復用對象）
	ctxPool *sync.Pool
}

在調用 Entry 開始進入 Sentinel 邏輯時，如果沒有手動構造 SlotChain，則使用默認。

為什麼這裡要設計成三個 Slot組呢？因為每組 Slot 的行為稍有不同，比如前置準備的 Slot 不需要返回值，規則校驗組需要返回值，如果校驗當前流量不通過，還需要返回原因、類型等資訊，統計 Slot 還會有一些入參，比如請求是否失敗等等

type BaseSlot interface {
	Order() uint32
}

type StatPrepareSlot interface {
	BaseSlot
	Prepare(ctx *EntryContext)
}

type RuleCheckSlot interface {
	BaseSlot
	Check(ctx *EntryContext) *TokenResult
}

type StatSlot interface {
	BaseSlot
	OnEntryPassed(ctx *EntryContext)
	OnEntryBlocked(ctx *EntryContext, blockError *BlockError)
	OnCompleted(ctx *EntryContext)
}

總結

本文從源碼角度分析了 Sentinel-Go 的初始化流程和責任鏈的設計，總體上來說還是比較簡單，接下來的系列文章將會分析 Sentinel-Go 的限流熔斷等的核心設計與實現。

搜索關注微信公眾號”捉蟲大師”，後端技術分享，架構設計、性能優化、源碼閱讀、問題排查、踩坑實踐。