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

捉蟲大師發表於2021-11-09
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

責任鏈模式

什麼是責任鏈模式

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

image

責任鏈模式為每次請求建立了一個鏈，鏈上有 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 的限流熔斷等的核心設計與實現。

搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。
image

相關文章