七牛雲宮靜：基於容器和大數據平臺的持續交付平臺

7 月 6 日上午，在 ArchSummit 2018 深圳站 | 全球架構師峯會上，七牛雲工程效率部技術專家宮靜分享了《基於容器和大數據平臺的持續交付平臺》爲題的演講。本文是對演講內容的整理。





本次分享的主要內容是基於容器和大數據平臺去構建的持續交付系統，是七牛雲工程效率部在持續交付、容器化方面去作的技術實踐。將從如下兩個方向展開：一個是容器化方向，一個是持續交付的平臺。主要會結合在七牛雲的實踐來介紹這個持續集成、持續部署在容器化方向的探索和思考，以及將來方向的考慮。


01 業務場景的介紹

七牛雲業務場景：

上圖的數字實際上是七牛雲的業務場景的縮影，七牛雲如今有六大產品線，圍繞這六大核心業務，咱們有 500 多個組件和服務，這個數字可能還在持續地變化，不斷地上升，不斷地發展。咱們外部的業務需求是這樣的，由於市場在快速變化，它對咱們業務需求要求是有一個快速迭代的能力，快速發佈的能力。工程效率部的目標是在保證質量的前提下來作到一個快速的驗證和有效的發佈的能力。而產品研發人員和工程效率這邊是這樣的一我的員比，在這樣的一我的員比下，咱們會遇到哪些問題呢？

02 研發團隊在質量、工程效率所面臨的問題總結

如下是咱們研發團隊面臨的一個真實的問題的總結。當一個團隊中的開發人員面對的是怎麼樣一個開發場景，開發人員要面對的是多樣化的編譯運行環境，要保證從代碼開發到編譯到運行到調試自測這樣一個完整的路徑覆蓋，當他完成這個路徑過長的時候，就會影響他的開發效率。覆蓋這樣一個完整的路徑目前有一個什麼樣的挑戰呢？

第一部分是咱們的服務比較多的，產品結構是比較複雜的，在各類狀況下調試自測的難度是增長的。首先咱們開發人員並非去獨立開發，一般狀況下是一個很大的團隊，須要一個團隊合做，這個團隊中可能有多我的在並行進行開發，而後如何去有效把這些並行的開發高效的集成在一塊兒，作到一個快速的迭代，同時合併不會對主幹代碼的穩定性和質量形成一個不穩定的風險。

第二部分是質量方面的問題。質量的同窗面對的是複雜的測試場景，對業務產品在不一樣的測試環境下作多樣的驗證，保證咱們的產品能在各類各樣的複雜場景下都能正確穩定的運行。第二點，一般狀況下測試資源是有限的，咱們要合理地作一個規劃，用有限的資源應對集成測試、性能測試等各類狀況的驗證需求。第三點是在面對這麼複雜的場景，這麼多樣的業務，而後咱們又怎麼去把咱們驗證效率作提高，來知足咱們快速迭代，快速發佈的需求。第四點是咱們如今常常提到的一點，咱們如何在產品研發的整個流程，對代碼狀態作有效追蹤，這是咱們要回答的問題，也是咱們平常的工做一個重要組成部分。

第三部分是微服務帶來的新挑戰。咱們也觀察到說，好比說像剛剛的服務數量的量級是由於微服務模式的實施，微服務架構給咱們帶來一些好處，但任何事情都是有兩面性的，不能先看到它全部帶來的好處，而要看到另一面。

首先是服務拆分以後帶來的架構複雜度，服務拆分之後，開發人員可能只須要去關注拆分後的服務，這部分服務它的部署運行，它的功能。可是這個服務它是服務於整個產品的，咱們產品的總體因爲服務拆分，它的架構變得更復雜了。咱們是否是須要有一個架構人員或者是技術人員作總體的把控？當產品在作微服務模式實施的時候，個人架構複雜度不能有一個線性的或者指數性的提高。

第二點就是說，當服務拆分之後，給開發人員帶來了一些便利，可是微服務模式它是不是面對整個運維部署的流程的？咱們的產品雖然服務拆分了，但仍然要做爲一個總體去部署運維。對於測試人員來講，咱們要面對的是這樣的一個總體的方面，因此咱們要考慮的是產品去總體部署運維的難度。

接下來是七牛雲工程效率部，在解決這些問題方面，提出的一些方向和思路。

第一個是比較容易考慮到的一點，就是要去保證咱們的工具鏈是完備的，當開發人員從第一行代碼開始，就有一個完備的工具鏈去支持他完成開發，完成整個的調試自測。而研發團隊的一些其它角色，好比說測試人員或者運維人員，會遇到其餘各類各樣的需求，這都須要工具鏈的支持。

第二個是容器化方向，由於在這樣的主題下，容器化方向是你們都在考慮的，它能給咱們帶來什麼好處，首先咱們的資源能夠大幅提高它的有效利用率。第二點能夠作到環境的隔離，而後保證從代碼開始就在一致的環境上編譯運行，它的可移植性是加強的。

第三點是主要在質量效率上要保證有持續演進的 CICD 系統，這個系統保證咱們作快速的迭代，有效的驗證。

第4、第五點實際上是咱們如今一直考慮的問題，如何把一個產品從代碼開始，到最終上線去作一個有效的追蹤和分析，在不一樣的開發流程環節中，都須要去追蹤，這個功能在開發的時候，它的總體實現是什麼樣的、它的代碼質量什麼樣的，不一樣的人有不一樣的代碼實現質量，有的人作了有效的單測覆蓋、有的人可能沒有單測。對整個研發流程都須要去作打點、追蹤、分析，全流程去保證做爲一個團隊的研發階段到最終交付的內容是符合咱們效率上、質量上的要求。

03 持續交付平臺 SPOCK 介紹

下面是對前三點的實踐作主要的介紹，也就是持續交付系統 SPOCK 平臺。

SPOCK 平臺的定位是基於容器和大數據平臺的持續交付系統。

第一點是容器化方向的實施，SPOCK 平臺能夠作到什麼。它能夠作到的咱們容器化測試環境的管理，當用戶對測試環境有任何需求的時候能夠一鍵部署，這個一鍵部署聽起來是比較容易的，可是實際上咱們有不少的開發維護的細節。

第二點是把容器化服務作到了模板化，它能夠自由編排，當我面對的是複雜產品的結構的時候，自由編排會保證建立產品環境的靈活性。   

第三點是工做流模塊化，不一樣角色對集成的需求是不同的，應對這樣不一樣的需求，把工做流各個環節作到了模塊化，也就是說研發人員和測試人員，他能夠根據他的需求來定製他的工做流，擴展他的工做流，用戶能夠經過配置來按照須要對這個工做流路徑作擴展。

第四點是持續交付及系統的基本，也就是說咱們須要跟研發流程中所涉及到的各個系統，好比 jira 系統、github 系統發佈系統集成起來，達到代碼的持續集成持續發佈的目的。

第五點是統一日誌服務，它是基於大數據平臺構建的。

最後一點就是在持續交付流程的各個環節，咱們作數據的打點和收集。這樣作是爲了去構建持續交付流程上的質量效率體系，數據是能夠收集，能夠度量的，這些收集和度量能夠幫助去優化和改進研發流程，去對質量效率提出下一步的發展空間。

上圖如今的持續交付流程示意圖，在這個裏面能夠看到，咱們的研發團隊的不一樣角色，均可以去使用 SPOCK 平臺，去進行它的持續集成。開發人員可能的使用流程是這樣的，當開發完成一部分功能的開發，能夠去手動地觸發的工做流，這個工做流是在 SPOCK 平臺中管理的，它能夠作到基於容器化的統一構建，SPOCK 平臺能夠把構建鏡像自動部署到容器雲環境中，提供給開發同窗進行調試和自測。當代碼開發調試自測完成迭代以後，代碼提交到代碼倉庫中去進行管理。在這個提交以後，咱們會進入測試環節，測試人員是怎麼用這個環境的呢？首先是咱們的自動持續集成能力，也就是說咱們這個平臺集成各類系統，作到代碼的自動集成和部署。

測試人員須要對整個產品或者是幾個服務作一個集成的測試或者是聯調的測試的時候，能夠根據本身的需求，對他所維護的集成環境進行一鍵部署，而後經過工做流來進行集成測試的自動迴歸驗證。在驗證經過以後，就能夠走到一個持續發佈的流程，發佈到咱們的預上線系統環境。

這是 SPOCK 架構的示意圖，SPOCK 平臺的兩個特性，第一個是容器環境的管理，第二個是在容器環境之上，作到的持續交付的實現，從右邊來說，是容器化方向的實現。SPOCK 平臺中把產品抽象成產品模板進行管理，基於這些模板，能夠去部署產品實例。這些部署和模板是經過咱們的 K8S CTL 模塊去實施的，從而在容器集羣中去生效，底層就是七牛的容器雲服務平臺 Kirk Cluster。

上文提到，基於模塊化的工做流配置作到了可定製化的交付流程，Reaper 模塊執行統一的容器化構建，Warpdrive 對工做流各模塊作實際的任務執行。底層還有 SPOCK 涉及到的一些其它服務，好比咱們的鏡像倉庫和對象存儲，基於這些基礎服務對整個持續交付過程都作到了的軟件管理，因此對整個過程都是可追蹤的，任何構建的交付對象都在咱們的對象存儲中去進行跟蹤、存儲和管理。中間的 Pandora 服務是七牛大數據平臺，基於大數據平臺對咱們整個持續交付流程和測試環境集羣作數據的統一收集和分析，最終能夠在 Pandora 大數據平臺上進行數據分析。

04 產品實施

下面介紹測試環境容器化具體的實施，換句話就是怎麼對測試環境作到一鍵部署。

當我去問一個技術人員說，你怎麼把你的服務容器化的時候，技術人員可能他的回答是比較簡單的：寫一個 Dockerfile 爲服務編譯容器鏡像，底層是 kubernetes 容器編排系統，寫一個 yml 文件，描述這個容器怎麼在個人集羣裏面去部署、如何啓動運行、服務的伸縮、服務的更新、服務的維護、它的策略是什麼樣的。而且我去聲明服務在這個容器集羣裏面須要的資源，它的網絡和存儲。而後經過工具腳原本自動建立，自動更新維護。

當一個服務，或者是幾個服務的時候，事情好像就是這麼簡單，可是當要面臨的是幾十個服務、上百個服務的時候，事情就變得不那麼簡單了。我要面對的不只是服務量級上的變化，個人服務在不一樣的環境下，不一樣的場景下，它的配置多是不同的，它的運行環境多是不同的，它所須要的資源也不同，好比說個人存儲聲明在測試環境和在生產環境下是不同的，同時不一樣的研發人員須要部署產品結構也是不同的。要怎麼把這些差別在咱們平臺中去有效地管理和維護起來呢？這個就是 SPOCK 在容器化方向作的一些探索。

首先能夠看到的是這個場景，這些小的圓圈圈多是一個容器服務，或者是咱們比較熟悉 K8S 的，認爲它是一個服務的最小單元 POD，單個服務就是一個容器鏡像加一個部署描述 yml 文件，再加一些配置文件。咱們怎麼把這些零散的服務把它給組織起來，作到根據需求的差別化部署，提供給開發人員呢？不一樣的開發人員對環境的要求差別很大，開發只須要關注他負責開發的那一塊就夠了。它可能有共同的依賴或者是相似的服務需求，又要部署本身正在開發調試的服務。

第二個場景，咱們可能看到的是產品結構層級上更復雜一點，要部署的服務之間，有前後啓動順序關係，有服務的依賴，最終做爲一個總體的產品去運維和部署。這個主要是在調研的時候，發現的是測試人員的集成測試環境，它對這樣的需求會比較多一些。

應對這樣的不一樣環境，咱們是怎麼去實施的呢？

首先咱們把這些單個的服務，給抽取出來，定義一個服務的模板。一個服務的模板包括的是描述這個服務的模板文件，以及這個服務它自身所須要的一些配置文件。簡單來講就是一個 YAML 文件，加一些 Config 文件，服務能夠按照業務邏輯進行組織成服務組，一個服務組裏面的服務，它是沒有前後啓動順序的，它是並行的，只是把一個服務放到了一個服務組單元，咱們能夠對同一個單元下的服務作統一管理。可是當我有層級關係，依賴關係的時候，有前後啓動順序的時候，在服務組織上又有個總體的產品結構概念，這個產品結構把不一樣的服務組作一個層級的管理。好比說我先起第一級別的服務組，再起第二級別的服務組，再起第三層級的服務組，服務組之間是按照順序去前後啓動，它是有一個依賴關係的。

對應到咱們真正的產品上，現實是什麼樣的呢？一個實際案例是要去部署一個帶數據庫服務的架構的時候。首先我可能要去定義這個產品結構，我把產品中的服務作一個抽象，作一個隔離，作了一個拆分。抽象出前端的服務、後端服務、數據庫服務，咱們把這些前端服務、後端服務、數據庫服務都模塊化，做爲服務模塊去管理。

編排的時候把服務按照邏輯編排到服務組，服務組內部都是平行的，同一服務組沒有前後的啓動順序。可是當我要總體的去部署這個產品的時候，我可能先去部署數據庫服務組，而後再去部署個人後端服務組，最後再去部署個人前端服務組，當個人全部服務組都部署完成以後，咱們整個產品就能夠對外提供一個可訪問域名，而後做爲一個總體去運行起來。

另外是咱們在實施中發現可能還會遇到一些實際問題，比咱們想象的更要複雜，是否是全部的服務都在容器化的環境下去運行。咱們首先要明確一點，咱們把服務作容器化的時候，前面描述的是服務怎麼去運行，怎麼去部署，可是實際咱們在作容器化方案的時候，咱們要考慮的一點就是容器化不等於把一個服務從物理級直接遷移容器上面去部署運行，由於咱們在物理級部署和容器部署這兩個不一樣的部署架構上，其實在服務場景是有差別化的。

什麼樣的服務適合在物理級上部署，什麼樣的服務適合在容器化的環境下部署，在目前的這個容器服務上或者是現有的解決方案上，一些特殊服務是否是還不能作到在容器環境中提供等同的服務支持。因此咱們在實際作這個容器化方案的時候，咱們須要去作一個總體的評估和審覈，拿到一個產品去作容器化的時候，要去進行設計，我這個容器化環境提供的是什麼樣的業務場景、提供的是什麼樣的服務能力、它是不是跟咱們物理級部署提供的同樣的目的和同樣的場景支持。同時咱們要對容器化的範圍也作一個界定，什麼樣的服務作容器化，什麼樣的服務不作容器化，這個是要根據咱們實踐和方案評估來肯定的。

在實踐中遇到了這樣的狀況，也就是說一些服務咱們判斷它在現有的方案下不適合作容器化，那麼怎麼作到說，去提供一個能夠一鍵部署的測試環境呢，這裏是 SPOCK 的解決方案，咱們把物理級部署和容器部署作一個打通，也就是說在 SPOCK 去進行一鍵部署的時候，物理機部署和容器服務部署同時支持的，服務之間可能有物理級部署和服務部署兩部分，而後它們之間能夠互相依賴，這樣的方案有一個前提，而後也有不少的技術細節。首先 SPOCK 平臺須要把已有的物理級部署方式在平臺上實現，而且對接。而後咱們須要去梳理咱們的服務依賴關係，經過統一的配置管理和統一的規劃來進行部署實施。

接下來就是咱們實施中遇到的一個日誌方面的實際問題，好比說當個人容器服務去重啓伸縮的時候，它的日誌，究竟是怎麼管理去收集的，這個咱們如今的實施是基於大數據平臺作一個統一的日誌收集和分析的服務，也就是說我跑在這個容器集羣上面的全部測試環境，我都基於這個大數據平臺它的數據源收集的組件去進行數據收集，數據收集以後，咱們的日誌數據其實不是存儲在容器集羣的存儲當中的，咱們如今把它統一放在數據平臺上作日誌管理，經過這個日誌管理咱們也發現能夠有一些新的創新點，當日志統一收集起來以後，它能夠作到的是，它能夠作更高效的分析，能夠定製化的搜索，業務報警，這是咱們如今發現，經過這個解決方案給咱們帶來的一些好處。

這個大數據平臺也不僅是去收集咱們的統一日誌服務，前面能夠看到咱們的系統定位是一個持續交付的系統，持續交付也就是在代碼的初始階段就進入了這個系統，可是在這個流程持續運行的時候，各個環節它的代碼質量究竟是什麼樣的，咱們須要去觀察、去收集、去度量，也就是說在代碼進入到持續交付系統以後，就對每一個環節作一個數據收集，在代碼的構建階段、單測階段、部署階段、集成測試、分發階段，都去收集各類有效數據，去把它給放到咱們數據平臺。

這個數據作什麼用呢？這個數據做爲咱們一個質量效率體系的數據基礎，這個數據基礎能夠去有效度量代碼在進入持續交付、持續迭代的流程中，它究竟是處於一個什麼狀態的，是否在某一個環節，或者是某幾個環節，有一個比較好的可改進的空間。

這裏給了一個圖，是咱們持續交付流程中收集的系統測試的覆蓋率。咱們能評估到每一次開發提交代碼，系統測試是否有效覆蓋到了代碼，它有一個總體的評估。代碼提交後自動觸發這些自動進行持續集成和持續構建的流程，在這個過程當中，這些數據就自動進入咱們的質量效率體系，生成度量指標用於評估。

05 關於將來的挑戰和思考

最後介紹的是咱們將來考慮的一個方向。

這個方向比較大，就是咱們但願把測試服務化，對研發團隊進行開放。如今作到的是測試環境，做爲一個一鍵部署的服務去提供開放，以後但願把全部的這些持續交付的流程環節都把它給模塊化、服務化，做爲測試服務提供出去。這樣全部開發人員都是能夠經過服務化的方式，去使用咱們的測試體系、質量體系。

以上是今天所有的內容分享。

關注公衆號【七牛雲】，瞭解更多信息哦~