一篇文章帶你了解運維重器 Tencent Hub

演講者：鄒輝 騰訊雲 PaaS 產品總監

背景：5月23-24日，以「煥啟」為主題的騰訊「雲+未來」峰會在廣州召開，廣東省各級政府機構領導、海內外業內學術專家、行業大咖及技術大牛等在現場共議雲計算與數字化產業創新發展。

騰訊雲 PaaS 產品總監鄒輝在騰訊「雲+未來」峰會的「開發者專場」做了主題為「新時代運維重器 Tencent Hub 最佳實踐」的技術內容分享，針對DevOps產品的一些設計理念和思考。

以下內容整理自演講：

鄒輝：因為工作關係，我會在日常工作中跟很多企業和運維人員打交道，協作他們做容器化和DevOps化的一些工作。在過程中，我們發現大家對於DevOps的價值，以及如何實現DevOps還有一些疑問。所以今天先簡單介紹我們為什麼要去做DevOps，以及怎麼樣去做DevOps。

從技術的角度來看，隨著業務的發展，業務的場景越來越多，越來越複雜，我們的系統架構也會越來越龐大，開發人員也會越來越多，同時對系統的穩定性要求也會越來越高。所以這些場景催生了我們的技術架構的變革，由此會帶來微服務架構設計理念的產生。

微服務架構設計理念的產生能夠解決這些問題，但是微服務也帶來很多的問題，微服務導致我們的系統模塊越來越多，而這些模塊運維管理複雜度也會增加，同時微服務會讓我們的開發速度得到增加，我們的開發人員對我們發布的效率會有一個明顯的訴求。所以在運維人員對系統的質量把控，以及開發人員對系統效率的追求上有矛盾，這就是我們DevOps需要解決的一些問題，由此催生了DevOps。

所以DevOps實際上就是我們需要通過DevOps來保證質量的同時，平衡開發效率，本質上來說DevOps實際上就是一個流程化和工具化的過程，通過工具來固化流程，通過流程來保證運維發布和研發質量，同時降低人工進行操作時候的一些誤操作引發的故障，也提高了整個研發效率。所以基於這一點，如何去實現我們的DevOps，實際上非常清晰，因為DevOps就是一個流程規範制定和工具自動化的過程，所以作為DevOps，我覺得關鍵在於兩步：

1、把我們的流程梳理清楚，把我們的軟體開發過程中的一些步驟，我們有有哪些步驟，比如我們有代碼提交、發布測試化，靜態掃描，把我們研發過程梳理清楚。我們也需要把我們團隊的關係梳理清楚，這個軟體開發過程中有開發，有測試，有運維，還有一些管理者，需要哪些步驟需要哪些人審核，在哪些步驟需要通知哪些人。接下來我們就需要進步第二步；

2、通過工具化把所梳理的流程實現自動化的過程。如何去選擇一個合適的DevOps工具體系，把流程規範給自動化起來，接下來就是我今天分享的一個重點，給大家分享一下，我們騰訊雲在DevOps工具體系這方面的實踐。

整個騰訊雲在DevOps這裡實際上推出了一款工具，叫Tencent Hub。Tencent Hub是第一款涵蓋了DevOps整個體系的工具體系，主要分成三部分，從代碼的開發階段到代碼的構建階段，一直到代碼的發布階段。在代碼開發階段，我們可以提供TAPD的開發平台，我們也推出了一個Tgait的代碼倉庫，基於這個構建組件，我們很方便的可以把整個DevOps流程給串起來，同時也提供了一個全面的倉庫，在這個倉庫裡面，我們可以存儲任何的代碼，DevOps任何的一個存儲，最終我們也會跟運行環境裡面的一些服務打通，來支持各種發布，提供各種各樣的查檢。這就是整個騰訊雲在tencent hub整體的一個體系圖。

在CD環節，我們有一個核心組件，叫Work Flow，大家可以簡單理解為它就是一個工廠的流水線，通過這個流水線，我們可以把DevOps環節開發、測試、發布、代碼自動測試，這所有的環節很簡單的串聯起來。因為不同的公司研發流程不一樣，並且隨著業務的發展，流程可能也會在不斷的變更，所以我們再去設計Work Flow這款組件的時候，一個核心考量就是能否快速的去適應多樣化的流程體系，以及快速的適應流程的變更。

基於這一點，我們在用Work Flow的時候，把Work Flow分成了三塊，一個是Engine環境，一個是插件層，還有一個是Work Flow插件庫，主要是管理調度功能，真正實現任務實行是在下面Work Flow的插件去實現這個功能。

在Work Flow Engine這一層我們可以看到也是分成多個階段，我們將一個DevOps完整階段拆分成多個不同的，這些串列執行，也可以並行執行，我們可以定義任何DevOps的流程，同時在執行過程中，我們也可以暫停這個stage，也可以啟動這個stage，在完成以後，我們也可以根據反饋結果來定義這個流程是該繼續走下去，還是該終止。當我們把代碼構建完成之後發布到自動化測試系統中做測試，發現某個自動化測試用力跑不過，這個時候我們可以設計一個終止的環節，然後把這個系統結果到開發運維人員，或者測試人員。同時Work Flow Engine，同時也寫好亞碼文件，把完整的流程導入到Engine裡面執行。這就是在Engine方面我們的一些設計和思考。

在這一層，我們能夠做的一個調度方式，大家可以看這張圖，第一種調度方式是Engine可以通過AP調動任務，Engine層可以執行指定的一個任務，實際上以容器績效的方式定義和運行這個插件，也是我們在Work Flow做的一個比較大的革新。為什麼這樣說？因為我們發現把容器引入到DevOps裡面去做會帶來很多的好處，首先我的DevOps流程裡面會有執行各種各樣的任務，如果把這個任務通過容器化固化下來，通過容器績效我們可以很方便的傳播，這個時候大家看的可能不是跟Engine相關的插件，而就是一個容器績效。一旦把插件分裝到容器裡面之後，我們公司裡面可以根據大家的喜好和專業程度，根據自己的一個喜好去開發容器。這就是我們在Work Flow插件這一塊實現的機制。

另外，如果說是用戶想要自定義自己的插件，完成一些功能，也只是需要定義好簡單的輸入和輸出即可，輸入值可以從前面任何流程獲取，制定本質的輸出參數，輸出參數也可以反饋回來，供後面的流程使用。用戶也可以很簡單的去遵守這個輸入和輸出的規範，開發自己的績效插件。

另外，除了Work Flow之外，剛才也提到了Registry，我們發現在Work Flow會產生很多中間產物，比如說我構建一個Zaar程序，或者發布一些配置文件，這些配置文件發布在哪些地方，包括發布機制，它這個存在的地方或者最終績效存在的地方等等，我們發現在DevOps環節中會產生各種各樣的中間產物，而這些中間產物往往會存儲到不同的地方，使用不同的協議去獲取。

我們也針對一些常見的語言庫和流程提供一些通用的插件庫，比如說裡面的代碼檢查、構建，這些績效可以統統在這一層獲取到。這就是我們在Work Flow這裡面的一些設計理念。

基於這一點，我們開發了一個叫Registry的一個通用倉庫，可以實現通用存儲，使用這個通用存儲可以很方便的把DevOps裡面中間產物，各種中間產物給管理起來。

Registry也提供了多層管理機制，從組織到用戶團隊，到個人，這樣一個分級管理機制，通過許可權的方式去統計，也提供各種各樣的日記，靜態掃描的功能，讓用戶能夠更方便的使用這些Registry功能。這就是Registry這邊的一些設計。

除此之外，其實我們還把騰訊內部的一些研發實踐，通過服務的方式分裝起來給開發者，讓開發者不光可以使用Work Flow，使用既定插件，同時還可以使用騰訊內部一些比較好的經驗，更好的去支撐他們的DevOps，比如我們自動化運維、代碼託管、自動化測試，以及我們最近推出的一個OTFA這樣的安卓平台，後面是我們基於APP而開發的測試平台。

今天我這邊的演講就到這裡結束了謝謝大家。

-END-

騰訊雲助手，移動管理輕鬆上雲

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！