前言：

Finops Crane集訓(xùn)營主要面向廣大開發(fā)者，旨在提升開發(fā)者在容器部署、K8s層面的動手實踐能力，同時吸納Crane開源項目貢獻者，鼓勵開發(fā)者提交issue、bug反饋等，并搭載線上直播、動手實驗組隊、有獎?wù)魑牡认盗屑夹g(shù)活動。既能讓開發(fā)者通過活動對 Finops Crane 開源項目有深入了解，同時也能幫助廣大開發(fā)者在云原生技能上有實質(zhì)性收獲。

活動介紹鏈接
Crane項目開源鏈接，可以star一下

一、 背景：

CNCF 云原生計算基金會 2021 年《FinOps Kubernetes Report》顯示，遷移至 Kubernetes 平臺后， 68% 的受訪者表示所在企業(yè)計算資源成本有所增加，36% 的受訪者表示成本飆升超過 20%。

附：相關(guān)數(shù)據(jù)參考《云原生.降本增效電子書》

1.云支出浪費成為企業(yè)用云普遍現(xiàn)象：

2.企業(yè)云上成本管理面臨諸多挑戰(zhàn)：

從以上數(shù)據(jù)可以看出，企業(yè)云原生應(yīng)用帶來好處的同時，也會造成云資源巨大的投入成本和浪費，大家對《如何提升資源利用率，實現(xiàn)降本增效》的需求愈發(fā)迫切。

為了應(yīng)對在后云原生時代，成本管理面臨的諸多挑戰(zhàn)，F(xiàn)inOps理念應(yīng)運而生。

二、FinOps：

FinOps 定義了一系列云財務(wù)管理規(guī)則和最佳實踐，通過助力工程和財務(wù)團隊、技術(shù)和業(yè)務(wù)團隊彼此合作， 進行數(shù)據(jù)驅(qū)動的成本決策，使組織能夠獲得最大收益。其原則、角色、成熟度、階段、能力如下圖所示。

騰訊的云原生降本增效最佳實踐是基于 FinOps 框架開展的。

Crane是一個基于 FinOps 的云資源分析與成本優(yōu)化平臺。它的愿景是在保證客戶應(yīng)用運行質(zhì)量的前提下實現(xiàn)極致的降本。

三、 Crane：

1.開源地址：

• GitHub - gocrane/crane: Crane (FinOps Crane) is an opensource project which manages cloud resource on Kubernetes stack, it is inspired by FinOps concepts.（Crane Github鏈接）
• Crane 官網(wǎng)：Introduction - Crane - Cloud Resource Analytics and Economics（中文官網(wǎng)鏈接）
• Crane 核心模塊：（中文官網(wǎng)鏈接）

2. Crane成本優(yōu)化方向與核心功能：

3. Crane 的整體架構(gòu)：

4. Crane 不斷迭代和優(yōu)化大盤數(shù)據(jù)分析系統(tǒng)，滿足各式運營數(shù)據(jù)需求：
   

5. 更多的了解參考視屏回播：

Finops Crane 開源項目經(jīng)驗分享鏈接

四、 公司技術(shù)架構(gòu)演變：

公司在最開始的單體架構(gòu)，為了應(yīng)付各種公司商業(yè)模式快速上線，采用了全棧PHP開發(fā)模式，相對于公司的成本考慮，可以快速的滿足業(yè)務(wù)的需求外，還能在一定程度上控制成本的增長。

隨著公司的業(yè)務(wù)發(fā)展，單體架構(gòu)暴露的問題越來越多，公司內(nèi)部逐漸向微服務(wù)云化進行過渡，可以看出，公司隨著業(yè)務(wù)體量的增長，對應(yīng)的技術(shù)研發(fā)費用越來越龐大了，幾乎是暴增式正比。

技術(shù)團隊也是在配合公司的CostDown原則，也是做出一些降本提效的措施，比如通用性業(yè)務(wù)的SaaS化，抽離公共基礎(chǔ)服務(wù)，減少重復(fù)開發(fā)。以下也可以看出技術(shù)部也僅僅是在建設(shè)工程化能力的方向上進行努力產(chǎn)出量化的成果。

如何將目標從如何使用云，轉(zhuǎn)變?yōu)槿绾斡煤迷疲?/p>

希望結(jié)合Finops的方案給創(chuàng)造核心價值賦能：

五、公司云服務(wù)面臨的困境：

在k8s集群方案的優(yōu)化上，目前也只是停留在探索期，目前在工作中發(fā)現(xiàn)的一些業(yè)務(wù)瓶頸：

1. 為了確保項目集群的穩(wěn)定，可以看到以下資源分配：

• 后管服務(wù)一般是1臺主機
• web服務(wù)按業(yè)務(wù)訪問量，在業(yè)務(wù)前端會負載到2-6臺服務(wù)器上，后續(xù)分析使用量再適當?shù)慕档?/li>

2. 第三方合作公司服務(wù)器預(yù)算超限：

• 軟件列表：包含數(shù)據(jù)庫、中間件、開發(fā)語言及版本、nginx、httpd等相關(guān)軟件
• 服務(wù)列表：包含有自開發(fā)或基于開源等開發(fā)應(yīng)用服務(wù)
• 硬件列表：包含需要的硬件列表，如ECS、rds、polardb、NAS等基礎(chǔ)設(shè)置

為了保證服務(wù)的穩(wěn)定性，一般都是讓第三方按最大配置進行開啟，再部署相關(guān)服務(wù)。

3. 目前自動擴容服務(wù)器比較原始：

經(jīng)常是手動調(diào)配服務(wù)器的資源不足，不能動態(tài)的擴展，如果遇到雙11這種大型活動，基本上要線上待命，保證系統(tǒng)的穩(wěn)定性。

上圖可以看到，xx-job的計劃任務(wù)，失敗率占了1/3，而且還會引起慢SQL占用資源，雖然做了MySQL主從。

是否可以使用Crane的混部方案？

上圖展示為生產(chǎn)系統(tǒng)的CPU資源等其它各種現(xiàn)狀，從圖中分析浪費的幾個原因：

綜合上面場景分析，可以看到在很多時候，其實云資源利用率不夠靈活，大多數(shù)資源利用率不高。資源配置策略都是按最大預(yù)估量設(shè)置可能會導(dǎo)致資源浪費。

在參加由騰訊云聯(lián)合 CSDN 推出的《云原生.降本增效電子書》、《騰訊云 Finops Crane 開發(fā)者集訓(xùn)營》線上培訓(xùn)后，了解一些通過云原生技術(shù)進行成本優(yōu)化的方案，同時也學(xué)習(xí)了很多優(yōu)秀實踐方法論、資源與彈性、架構(gòu)設(shè)計。

六、 測試環(huán)境實踐Crane：

推薦測試的機器最好內(nèi)存大于8G，否則會比較吃力，推薦linux/mac環(huán)境。測服已經(jīng)有kubectl、docker軟件

騰訊云 Finops Crane開發(fā)者集訓(xùn)營實驗回播鏈接

測服機器配置：

1. 安裝Helm：

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

2. 安裝Crane：

先將腳本下載下來：

https://raw.githubusercontent.com/gocrane/crane/main/hack/local-env-setup.sh

修改相關(guān)代碼：

# 將以下名稱修改為測服實際的集群名稱
CRANE_CLUSTER_NAME="crane"

# 將以下代碼注釋
echo "Step1: Create local cluster: " ${CRANE_KUBECONFIG}
kind delete cluster --name="${CRANE_CLUSTER_NAME}" 2>&1
kind create cluster --kubeconfig "${CRANE_KUBECONFIG}" --name "${CRANE_CLUSTER_NAME}" --image kindest/node:v1.21.1
export KUBECONFIG="${CRANE_KUBECONFIG}"
echo "Step1: Create local cluster finished."

執(zhí)行代碼：

./ local-env-setup.sh

3. 啟動并確保所有 Pod 都正常運行：

export KUBECONFIG=${HOME}/.kube/config_crane    # 建議寫到環(huán)境變量文件，否則每開一個窗口就要初始化
kubectl get pod -n crane-system

4. 訪問 Crane Dashboard：

kubectl -n crane-system port-forward service/craned --address 0.0.0.0 9090:9090

開啟測服9090端口：

偶爾會出現(xiàn)失敗的情況

5. Crane頁面：

Crane Dashboard 提供了各式各樣的圖表展示了集群的成本和資源用量

集群總覽可以按照維度成本、集群成本和利用率指標以及命名空間成本來展示成本的分布情況：

該圖中是運行 CPU 等資源持續(xù)一周的真實用量情況，評估資源利用率可以通過以下的緯度進行統(tǒng)計：

• 業(yè)務(wù)周峰值：每周最高的資源用量
• 日均峰值：每日峰值用量的均值
• 平均利用率：所有采樣點的平均值

根據(jù)這些值的變化率，方便進行提升資源利用率，常見的手段包括：

• 業(yè)務(wù)優(yōu)化：優(yōu)化業(yè)務(wù)資源申請規(guī)格以及彈性擴縮容提升以縮減已申請但未使用的資源
• 調(diào)度優(yōu)化：通過調(diào)度優(yōu)化提升裝箱率
• 混部：回收節(jié)點的閑時資源

Crane 會自動分析集群的各種資源的運行情況并給出優(yōu)化建議，會定期檢測發(fā)現(xiàn)集群資源配置的問題，并給出優(yōu)化建議。不過，推薦應(yīng)用在監(jiān)控系統(tǒng)（比如 Prometheus）中的歷史數(shù)據(jù)越久，推薦結(jié)果就越準確。

資源推薦頁面也能查看到優(yōu)化建議Recommendation 對象列表，根據(jù)配置定期運行推薦任務(wù)，給出優(yōu)化建議來供系統(tǒng)調(diào)整資源配置：

查看閑置節(jié)點：

查看集群成本：

6. Effective HPA基于社區(qū) HPA 做底層的彈性控制：

Effective HPA（簡稱 EHPA）是開源項目 Crane 中的彈性伸縮產(chǎn)品，它基于社區(qū) HPA 做底層的彈性控制，支持更豐富的彈性觸發(fā)策略（預(yù)測，監(jiān)控，周期），讓彈性更加高效，并保障了服務(wù)的質(zhì)量。

紅色曲線是實際使用量，綠色曲線是算法預(yù)測出的使用量，可以看到算法可以很好的預(yù)測出使用量的趨勢，并且根據(jù)參數(shù)實現(xiàn)一定的偏好（比如偏高）。

紅色曲線是通過原生的 HPA 自動調(diào)整的副本數(shù)，而綠色曲線是通過 EHPA 自動調(diào)整的副本數(shù)，可以看到 EHPA 的彈性策略更加合理：提前彈和減少無效彈性。

七、參考實際優(yōu)化成果：

將 Crane 的各項能力落地到騰訊內(nèi)部自研業(yè)務(wù)部門，管理數(shù)百個集群，十數(shù)萬 Workload，數(shù)百萬 Pod，充分的也體現(xiàn)了技術(shù)的可行性。

以騰訊內(nèi)部部門集群優(yōu)化為例，通過使用FinOps Crane，該部門在保障業(yè)務(wù)穩(wěn)定的情況下,資源利用率提升了3倍；騰訊另一自研業(yè)務(wù)落地FinOps后，在一個月內(nèi)實現(xiàn)了總CPU規(guī)模40萬核的節(jié)省量，相當于每月成本節(jié)約超千萬元。

其它知名的大公司也在生產(chǎn)系統(tǒng)中部署使用，有豐富的落地經(jīng)驗。

八、對公司落地的提案改善方案思考：

1.優(yōu)化方案實現(xiàn)前的思考準備：

2.對公司落地的提案改善方案思考

九、對標其它云的產(chǎn)品：

1.查看提供的“運維管理”工具：

2.“成本分析”中，在費用趨勢板塊，可查看多類維度下的費用變化趨勢：

3.“成本分析”中，查看預(yù)測趨勢：開啟后可查看最大未來12個月的預(yù)測趨勢數(shù)據(jù)：

個人感覺云成本這塊，Crane這塊做的還是比較好，可以結(jié)合上面的描述自行進行對比，僅代表個人觀點。

十、源碼分析：

1. 技術(shù)棧體系：

go、react、typesrcipt

3. 大體目錄結(jié)構(gòu)：

├─cmd
│  ├─craned
│  └─main.go   # 入口文件，對應(yīng)實際的pkg有許多功能代碼，這里的思想有點類似于vue源碼，比如web端、weex端
│
├─deploy       # 部署相關(guān)yaml文件
│
├─doc          # 文檔相當
│
├─examples     # 示例
│
├─pkg          # 示例
│  ├─web       # 前端相關(guān)代碼
│  |  agent
│  │  autoscaling
│  │  ...
│  └─webhooks  # go代碼

3. 本地搭建并開發(fā)：

如果后端開發(fā)，需要一些前置條件，如docker、go環(huán)境、shell、make命令，推薦使用linux或mac

$ make Makefile

4. 本地后端項目開發(fā)：

后端是使用了gin + grpc

• go代碼中定義了大量了的interface接口，再去實現(xiàn)接口
• 代碼中也含有不少單元測試的代碼，提高項目的穩(wěn)定性

4.1 入口文件：

crane/cmd/craned/main.go：

import (
	"github.com/gocrane/crane/cmd/craned/app"
)
func main() {
	...
	# NewManagerCommand創(chuàng)建一個具有默認參數(shù)的*cobra.Command對象，再去執(zhí)行一個Execute方法
	# app是對應(yīng)目錄下的craned/app/manager.go文件
	if err := app.NewManagerCommand(ctx).Execute(); err != nil {
		fmt.Fprintf(os.Stderr, "%v\n", err)
		os.Exit(1)
	}
}

注：
1. 項目中使用了 cobra 庫，"github.com/spf13/cobra"這個包來進行 cmd 的標準輸入輸出解析。
2. 個人在項目中比較常用的是 viper 包，"github.com/spf13/viper"
3. 入口文件比較簡潔，一個日志初始化，一個獲取 ctx 標準輸入輸出的上下文，一個是初始化應(yīng)用

crane/cmd/craned/app/manager.go：

import {
    # 這里引了很多pkg下面的go功能代碼，可以在這里全部加載進來
    "github.com/gocrane/crane/pkg/features"
	"github.com/gocrane/crane/pkg/known"
	"github.com/gocrane/crane/pkg/metrics"
	...
}
func NewManagerCommand(ctx context.Context) *cobra.Command {
    # 初始化options，對應(yīng)文件`craned/app/options/options.go`
	opts := options.NewOptions()
	# 負責管理所有的controllers業(yè)務(wù)功能代碼
	cmd := &cobra.Command{
		Use:  "craned",
		Long: `The crane manager is responsible for manage controllers in crane`,
		Run: func(cmd *cobra.Command, args []string) {
			...
			# 解析cmd標準輸入輸出，并進行一些初始化工作，啟動應(yīng)用（主要邏輯塊）
			if err := Run(ctx, opts); err != nil {
				klog.Exit(err)
			}
		},
	}
	
	cmd.Flags().AddGoFlagSet(flag.CommandLine)
	# 添加一些默認參數(shù)，比如沒有傳的參數(shù)，會在這里做一些初始化操作
	opts.AddFlags(cmd.Flags())
	utilfeature.DefaultMutableFeatureGate.AddFlag(cmd.Flags())

	return cmd
}

4.2 業(yè)務(wù)主函數(shù)邏輯：

func Run(ctx context.Context, opts *options.Options) error {
	config := ctrl.GetConfigOrDie()
	config.QPS = float32(opts.ApiQps)
	config.Burst = opts.ApiBurst
	
	# 1. 將傳參和自定義初始化的默認參數(shù)進行合成為一個ctrlOptions
	ctrlOptions := ctrl.Options{
		Scheme:                  scheme,
		MetricsBindAddress:      opts.MetricsAddr,
		Port:                    9443,
		HealthProbeBindAddress:  opts.BindAddr,
		LeaderElection:          opts.LeaderElection.LeaderElect,
		LeaderElectionID:        "craned",
		LeaderElectionNamespace: known.CraneSystemNamespace,
	}
	if opts.CacheUnstructured {
		ctrlOptions.NewClient = NewCacheUnstructuredClient
	}

	mgr, err := ctrl.NewManager(config, ctrlOptions)
	if err != nil {
		klog.ErrorS(err, "unable to start crane manager")
		return err
	}
	# 2. 設(shè)置健康檢查
	if err := mgr.AddHealthzCheck("healthz", healthz.Ping); err != nil {
		klog.ErrorS(err, "failed to add health check endpoint")
		return err
	}
	# 設(shè)置就緒檢查
	if err := mgr.AddReadyzCheck("readyz", healthz.Ping); err != nil {
		klog.ErrorS(err, "failed to add health check endpoint")
		return err
	}
	
	# 3. 將一些metricserver、grpc、mock、prometheus、prom信息放到map切片中
	# 并返回3個值realtimeDataSources, historyDataSources, hybridDataSources
	realtimeDataSources, historyDataSources, dataSourceProviders := initDataSources(mgr, opts)
	# 時間序列預(yù)測的 Controller 的對象，與 EHPA 有關(guān)，下面會分析
	predictorMgr := initPredictorManager(opts, realtimeDataSources, historyDataSources)
	
	# 4. 啟動features配置項，可以定義是否開啟
	# 比如：Autoscaling、Analysis、NodeResource、NodeResourceTopology、PodResource、ClusterNodePrediction、CraneCPUManager等。
	# 對應(yīng)文件：`crane/pkg/features/features.go`
	initScheme()
	# 注冊nodeName indexer
	initFieldIndexer(mgr)
	# 初始化webhook服務(wù)
	# 對應(yīng)`crane/pkg/webhooks`下面文件
	initWebhooks(mgr, opts)

	# 5. 內(nèi)存配置過低，配置并管理 pod oom event 相關(guān)邏輯
	# 對應(yīng)文件`crane/pkg/oom/recorder.go`
	podOOMRecorder := &oom.PodOOMRecorder{
		Client:             mgr.GetClient(),
		OOMRecordMaxNumber: opts.OOMRecordMaxNumber,
	}
	if err := podOOMRecorder.SetupWithManager(mgr); err != nil {
		klog.Exit(err, "Unable to create controller", "PodOOMRecorder")
	}
	go func() {
		if err := podOOMRecorder.Run(ctx.Done()); err != nil {
			klog.Warningf("Run oom recorder failed: %v", err)
		}
	}()
	
	# 6. 多種 Recommender 來實現(xiàn)面向不同資源的優(yōu)化推薦，下面會分析
	recommenderMgr := initRecommenderManager(opts)
	initControllers(podOOMRecorder, mgr, opts, predictorMgr, recommenderMgr, historyDataSources[providers.PrometheusDataSource])
	// initialize custom collector metrics
	initMetricCollector(mgr)
	runAll(ctx, mgr, predictorMgr, dataSourceProviders[providers.PrometheusDataSource], opts)

	return nil
}

注：
1. kubectl -n crane-system port-forward service/craned 9090:9090初始化項目時的傳參解析
2. 大多數(shù)pkg中的業(yè)務(wù)代碼在Run函數(shù)中都有使用

4.3 Recommender：

crane/pkg/recommendation/recommender/interfaces.go：

type Recommender interface {
	Name() string
	framework.Filter
	framework.PrePrepare
	framework.Prepare
	framework.PostPrepare
	framework.PreRecommend
	framework.Recommend
	framework.PostRecommend
	framework.Observe
}

比如資源推薦就實現(xiàn)了 Recommender 接口，主要做了下面 3 個階段的處理：

• Filter 階段：過濾沒有 Pod 的工作負載
• Recommend 推薦：采用 VPA 的滑動窗口算法分別計算每個容器的 CPU 和內(nèi)存并給出對應(yīng)的推薦值
• Observe 推薦：將推薦資源配置記錄到 crane_analytics_replicas_recommendation指標

crane/pkg/recommendation/manager.go：

func NewRecommenderManager(recommendationConfiguration string) RecommenderManager {
	m := &manager{
		recommendationConfiguration: recommendationConfiguration,
	}

	m.loadConfigFile() // nolint:errcheck

	go m.watchConfigFile()

	return m
}

# 對應(yīng)上面圖 Filter、Prepare、Recommend、Observe 幾個階段
func Run(ctx *framework.RecommendationContext, recommender recommender.Recommender) error {
	klog.Infof("%s: start to run recommender %q.", ctx.String(), recommender.Name())

	// 1. Filter phase
	err := recommender.Filter(ctx)
	if err != nil {
		klog.Errorf("%s: recommender %q failed at filter phase: %v", ctx.String(), recommender.Name(), err)
		return err
	}

	// 2. PrePrepare phase
	err = recommender.CheckDataProviders(ctx)
	if err != nil {
		klog.Errorf("%s: recommender %q failed at prepare check data provider phase: %v", ctx.String(), recommender.Name(), err)
		return err
	}

	// 3. Prepare phase
	err = recommender.CollectData(ctx)
	if err != nil {
		klog.Errorf("%s: recommender %q failed at prepare collect data phase: %v", ctx.String(), recommender.Name(), err)
		return err
	}

	// 4. PostPrepare phase
	err = recommender.PostProcessing(ctx)
	if err != nil {
		klog.Errorf("%s: recommender %q failed at prepare data post processing phase: %v", ctx.String(), recommender.Name(), err)
		return err
	}

	// 5. PreRecommend phase
	err = recommender.PreRecommend(ctx)
	if err != nil {
		klog.Errorf("%s: recommender %q failed at pre commend phase: %v", ctx.String(), recommender.Name(), err)
		return err
	}

	// 6. Recommend phase
	err = recommender.Recommend(ctx)
	if err != nil {
		klog.Errorf("%s: recommender %q failed at recommend phase: %v", ctx.String(), recommender.Name(), err)
		return err
	}

	// 7. PostRecommend phase, add policy
	err = recommender.Policy(ctx)
	if err != nil {
		klog.Errorf("%s: recommender %q failed at recommend policy phase: %v", ctx.String(), recommender.Name(), err)
		return err
	}

	// 8. Observe phase
	err = recommender.Observe(ctx)
	if err != nil {
		klog.Errorf("%s: recommender %q failed at observe phase: %v", ctx.String(), recommender.Name(), err)
		return err
	}

	klog.Infof("%s: finish to run recommender %q.", ctx.String(), recommender.Name())
	return nil
}

4.3 結(jié)合源碼與圖進行EHPA分析：

1. 用戶創(chuàng)建 Effective HPA 的對象后會生成兩個資源對象，其中一個是一個是 TimeSeries Prediction。

2. TimeSeries Prediction 是時間序列預(yù)測的 Controller 的對象：
   （1）. 創(chuàng)建后有一個組件叫 Predictor 開始(對應(yīng)函數(shù) initPredictorManager)從 Prometheus 中拿取應(yīng)用歷史數(shù)據(jù)。
   （2）. 并且通過預(yù)測算法得到未來持續(xù)預(yù)測，把預(yù)測結(jié)果更新到 TimeSeriesPredicton 中。

3. get history metice 對應(yīng)到 initDataSources 函數(shù)中

4. 從 Prometheus 獲取歷史 metric 通過預(yù)測算法計算，將結(jié)果記錄到 TimeSeriesPrediction。

5. HPA Contoller 調(diào)用 scale API 對目標應(yīng)用擴/縮容，對應(yīng)在 initMetricCollector 函數(shù)。

6. 在文件 crane/pkg/metrics 中，包含以下邏輯：
   （1）. HPAController 通過 metric client 從 KubeApiServer 讀取 metric 數(shù)據(jù)
    (2). KubeApiServer 將請求路由到 Crane 的 Metric-Adapter。
    (3). HPAController 計算所有的 Metric 返回的結(jié)果得到最終的彈性副本推薦。

5. 本地前端項目開發(fā)：

前端是使用的是vite + react + react-redux + typescript + less + axios + tdesign-react + echarts + react-i18等技術(shù)開發(fā)的

以下為主要的技術(shù)棧版本：

$ git clone https://github.com/gocrane/crane.git
$ cd pkg/web
$ yarn install
$ yarn dev:mock

6. 本地調(diào)試proxy代理：

• 在vite.config.js文件中設(shè)置proxy代理

• 在crane/pkg/web/nginx/default.conf文件中也可以看到nginx反向代理的配置信息。如果想要配置https，可以在這里自定義進行擴展?？梢允褂脀eb/Dockerfile文件直接docker build。

7.前端源碼分析：

1. react是用hook寫法，并非react Class寫法。

2. 項目中自定義的hooks：crane/pkg/web/src/hooks。

3. crane/pkg/web/src/pages 下面是主要的業(yè)務(wù)邏輯代碼。

4. crane/pkg/web/src/components 下面是組件代碼，其中看了 BoardChart、PieChart、SeriesLineChart 等圖表組件寫的不錯，通用性比較強。

7.1自定義hook，crane/pkg/web/src/hooks/useIsNeedSelectNamespace.ts：

import { grafanaApi } from 'services/grafanaApi';

export const useIsNeedSelectNamespace = ({ selectedDashboard }: { selectedDashboard?: any } = {}) => {
  const dashboardDetail = grafanaApi.useFetchDashboardDetailQuery(
    { dashboardUid: selectedDashboard?.uid },
    { skip: !selectedDashboard?.uid },
  );

  return (dashboardDetail?.data?.dashboard?.templating?.list ?? []).find(
    (item: { name: string }) => item.name === 'namespace' || item.name === 'Namespace',
  );
};

注：
1. 還可以將一個請求封裝為一個hook，讓我對萬物皆可hook，有了新的思路的理解。
2. 按以前想法是將這個封裝為一個函數(shù)使用。
3. 最后一行代碼 find 函數(shù)中，是否可以使用['namespace', 'Namespce'].includes(item.name)更為簡潔呢？

8.前端相關(guān)項目的問題點：

8.1 目錄結(jié)構(gòu)，建議使用alias別名管理，否則層級混亂時，極不方便維護：

8.2 建議使用一些按需引入的類庫，比如lodash可以換成lodash-es：

8.3 當echarts沒有數(shù)據(jù)時，可以建議用div渲染一個空白塊，而不是echarts去畫圖，相較性能來說，還是有點浪費：

8.4 文中typescript部分，使用了不少any數(shù)據(jù)類型：

8.5 在數(shù)據(jù)量比較大的頁面，多個request同時請求，導(dǎo)致頁面渲染比較慢，可以推薦一些兼容性比較好的數(shù)據(jù)壓縮工具，之前做可視化大屏也遇到過類似問題。

8.6 建議有一個登陸頁面，否則暴露出去，服務(wù)器的資源就可能會泄露信息。

8.7 在crane/pkg/web/src/router/index.ts文件中，可以使用路由自動加載方式動態(tài)引入：

8.8 建議安裝一個stylelint進行格式化css代碼，用自己開發(fā)的公共腳手架工具掃了一下，發(fā)現(xiàn)還是有不少錯誤：

8.9 接口返回值總是感覺怪怪的，最好可以加業(yè)務(wù)狀態(tài)碼

8.10 是否可以增加一些預(yù)警的機制，發(fā)送短信、機器人等

8.11 services中的API請求，個人感覺封裝的不是太好，可能也是由于自身水平?jīng)]能理解。

8.12 命名覺得統(tǒng)一一點好點：

8.13 crane/pkg/web/src/configs/host.ts 文件，最好是寫在.env文件這些，可以做.gitignore忽略提交，不然合作中，沖突較為頻繁。

export default {
  mock: {
    // 本地mock數(shù)據(jù)
    API: '',
  },
  development: {
    // 開發(fā)環(huán)境接口請求
    API: '',
  },
  ...
};

十一、總結(jié)：

• 為推進云原生用戶在確保業(yè)務(wù)穩(wěn)定性的基礎(chǔ)上做到真正的極致降本，騰訊云率先在國內(nèi)推出了第一個基于云原生技術(shù)的成本優(yōu)化開源項目 Crane。

• Crane 遵循 FinOps 標準，旨在為云原生用戶提供云成本優(yōu)化一站式解決方案，旨在助力企業(yè)和生態(tài)更良性發(fā)展和應(yīng)用先進技術(shù)，達成降本增效。

• Crane 依托于云原生技術(shù)，結(jié)合監(jiān)控預(yù)測、調(diào)度增強、業(yè)務(wù)混部等多項硬核科技，將優(yōu)化措施應(yīng)用到了云成本優(yōu)化的多個關(guān)鍵環(huán)節(jié)，從而輔助用戶決策、簡化運維效率、提升系統(tǒng)穩(wěn)態(tài)、全面降本增效。

總體來說，在騰訊云大規(guī)模的實踐案列下，我們也可以自己在 K8s 集群中安裝 crane 來獲取這些相關(guān)功能，用于幫助企業(yè)像管理 Workload 一樣聲明式管理 Node 節(jié)點，高效解決節(jié)點維護、資源規(guī)劃等各種各樣的運維問題。

在降本增效方面上，騰訊的云原生降本增效最佳實踐是基于 FinOps 框架開展的。可以幫助更多企業(yè)通過云原生全面釋放生產(chǎn)力，加速實現(xiàn)數(shù)字化和綠色化雙轉(zhuǎn)型。

號外：

通過對幾次的CSDN的培訓(xùn)發(fā)現(xiàn)，對騰訊云有很大的改觀，也是一個非常不錯的選擇，有些方面甚至做的更好。在后續(xù)的工作中，也會大量給公司推薦騰訊云的一些有效的方案，用于公司降本增效。

經(jīng)過二期的培訓(xùn)，講師胡老師也是會細心的給我們講解，舉出很多案列結(jié)合場景，深入易懂，答疑環(huán)節(jié)也是會認真的給我們解答問題，給出具體的實案，CSDN的老師們也是很耐心的回答我們的提問，比如網(wǎng)絡(luò)超時，等的比較慢，也是會比較耐心的跟我們講解。非常感謝騰訊云聯(lián)合CSDN的活動，也希望國內(nèi)云計算相關(guān)行業(yè)第一個開源的項目能夠普及到更多公司，幫助企業(yè)降本增效。

另外，也推薦官方可以出一些其它云的對接教程，如阿里云、華為云、微軟云，這樣可以做更多、更好的推廣。文章來源地址http://www.zghlxwxcb.cn/news/detail-475503.html

到了這里，關(guān)于騰訊云 Finops Crane 開發(fā)者集訓(xùn)營 - 讓云不再“錢”途無量的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！