初始化流程

初始化做了什么

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)

啟動 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)
}