阿里技術人的第一節課,都上些什麼?

阿里技術人的第一節課,都上些什麼?

來自專欄我是程序員14 人贊了文章

從源碼到上線

事情可不簡單

什麼叫程序?或者說,什麼叫軟體?這裡面好像有歧義。有時候指的是源代碼,有時候指的是安裝包或者安裝光碟,比如「我下載了一個軟體」 。有時指的是已經安裝好隨時可以運行的程序,比如「手機上新裝了一個應用」 。還有的時候指的是正在運行中的,正在提供服務的程序,比如一個網站。

這些不同的含義反映了一件事:單純的源代碼,還不能提供服務,不能為用戶帶來價值。只有源代碼被構建打包,並且被部署運行起來,才能為用戶帶來價值。

那麼,如何才能部署運行起來,為用戶提供服務呢?這很麻煩嗎?——是的,這很麻煩。

想像一下,如果你是一個初創企業的CTO。天上忽然掉餡兒餅,掉下來五個Git庫,源代碼已經寫好,而且一點兒毛病都沒有。每個Git庫能編譯成一個war包。你需要把每個war包部署到100台伺服器上,總共需要500台伺服器。另外,隨著用戶的使用,會不斷追加新功能,產生新版本,需要更新伺服器上的軟體版本。

假定你不是在阿里巴巴,假定也沒有阿里雲,假定你只是有很多錢可以僱到合適的人,你想想一共有多少事情要做?

先要買或者租機房,再買伺服器,風火水電都要搞穩妥。更要接好網路,每台機器要裝好操作系統的合適版本。不止是操作系統,還有相關基礎軟體、路由、資料庫、監控系統、日誌收集系統以及中間件等都是必須的。哦,域名還忘了申請了……

這些搞定之後,才能安裝那些war包。這麼多台,肯定不能一台一台操作,累死了,得有個批量操作的方法。可這方法怎麼弄呢?另外,考慮到將來要更新軟體版本,所以這還不是一次能搞定的事情,那更是得批量操作了。更新版本的時候,還有個麻煩事,不能一下子都停機啊,那不就要出事故了。所以得分批來。比如,先更新20%的機器,再更新20%,如此一共五批弄完。

往細節看,其中更新某一台機器,其實都是個挺複雜的過程。首先下載新的war包到這台機器,然後開始替換過程。先得把流量切走,切流量前,還得先把監控報警關上。流量切走了,就可以停止當前war包的運行。然後用新的war包代替舊的war包,啟動試試看。如果通過了一些基本的自動檢測,說明新war包大體上能運行,於是就開始切流量回來,最後把監控報警恢復。

忒麻煩!!

還好有工具幫忙

怎麼辦?——用趁手的工具啊!正是為了提高大家的工作效率,讓大家能夠集中精力在具體業務本身的研發上,阿里巴巴集團多年以來建設了一整套基礎設施。

在交付層和運維層,都有大量的基礎設施。但這些,大家可能感受不深。對於一個應用來講,它最關心的事情,基本都是通過Aone暴露出來的。Aone也就是最上層研發層的主要工具。

註:本文提及的阿里內部產品叫Aone,Aone於2017年正式對外開放,更名為雲效。

回到前面討論的場景,把完美的源代碼發布上線這個過程,那麼大體步驟應該是:

第一步,把運行環境初始化好。這一步目前同學們基本可以在Aone上一站式完成了,就是在Aone上註冊一個新應用,然後根據嚮導指引,把上線任務一項一項配下來。當然還有些內容比如資料庫還需要訪問其他系統申請配置,將來我們努力做成一站式配置好。

第二步,根據源碼構建出壓縮包(基本就是把war包壓縮一下),然後把壓縮包部署到各目標伺服器上。這一步,可以在Aone上一鍵完成。將來更新版本也一樣。點一下按鈕,所有事情都做完。這就是用Aone的好處。

阿里巴巴相關術語

為了使用Aone,我們得了解一些Aone的關鍵概念。其實是在阿里巴巴開發時,大家一開始約定俗成的概念,後來固化在Aone上。我們一個一個來看:

應用:Git庫里裝的是源代碼,這是程序的一種形態。那麼運行中的程序叫什麼呢?在阿里巴巴,我們管它叫「應用」。一般來說,一個Git庫,構建生成一個包,產生一個應用,在若干台伺服器/虛擬機/容器中運行,在測試、線上環境中運行。一般應用跟Git庫是一比一的關係,不過也有各種特殊情況,比如一個Git庫里有多個應用。所以,我們確實需要應用這個概念。另外,應用不僅包括了應用主包(通常是war包打成tgz包),也包括了運行所需環境的配置,比如tomcat版本等。

二方包:三方包,指的是來自阿里巴巴外部的,開源或商業的包,比如jar包、rpm包等。而二方包,則是指來自阿里巴巴內部的,通常是其他團隊的包。也就是說,一個團隊研發出這個二方包,公布出來,供各團隊使用。當然,也可能就是供團隊自己使用。反正,只要是來自阿里內部的,上傳到Nexus或Yum這樣的包的倉庫的,就都算二方包。

產品/產品線/產品樹:應用是從部署運維的角度看運行中的程序。產品是從使用者的角度看運行中的程序。通常產品由一到多個應用組成。產品進而構成產品線,這樣一級一級地上去,形成了一棵樹,叫產品樹。產品樹的根節點,就是阿里巴巴。產品樹的第一級展開,是各個BU。

變更:在外面的世界,現在變更通常是指線上運行環境的變化,比如更新了軟體版本,比如擴容、縮容等運維操作。在阿里巴巴,變更也有這個含義。但是在阿里巴巴,變更還有一個含義,軟體研發過程中的含義。通常我們把一條feature分支就對應到一個變更。於是也常管這條feature分支叫變更分支。從這個角度看集成,就是把若干變更攢到一起,通過各種質量檢測後,部署上線。

發布:發布,release,這個詞常常是指軟體版本公布出來供使用。但在阿里巴巴,這個詞不僅對應於部署到線上環境,即使是部署到測試環境,也叫發布。換句話說,發布基本上就是部署的代名詞。比如每個變更覺得自己OK了,就點一下變更詳情頁面上的「提交待發布」這個鈕,標記一下。然後,在集成測試環境(也就是日常環境)對應的流程階段的詳情頁面,就能看見這個變更。再選中它,然後點擊「提交發布」這個鈕,就與其他變更分支一起合併到發布分支,並部署到測試環境啦。

技術發展趨勢

發布部署方面,在阿里巴巴,時下最重要的變革當然是Docker化。

那麼這一波浪潮之後,下一波浪潮會是什麼呢?有可能是Serverless架構。這方面的文章也很多,大家可以翻翻看。

提高質量的多種方法

剛才我們給的是一個天上掉餡兒餅的例子,忽然間得到了完美的源代碼,然後考慮構建並部署上線。現實世界中哪兒有這樣的好事兒啊。代碼裡面肯定有bug。那麼,怎麼能夠有效率地把問題找出來,繼而修復好?具體有哪些方法?

按四個象限梳理

為方便梳理,我們劃一個橫軸,一個縱軸,然後按照得到的四個象限,梳理各種質量保證方法。這裡所說的橫軸,在最左邊,是源代碼。在最右邊,是運行中的程序。這裡所說的縱軸,在最上邊,是自動化,在最下邊,是人工。

先看左半部分。左下角,人工的對源代碼的檢測。這主要對應的是代碼評審。我們在代碼服務這門課上介紹的。此外,安全評審有時也有人工介入。

左上角,自動對源代碼的檢測。代碼規約的自動檢查工具,就落在這裡。事實上,還有不少工具也落在這裡,論品牌,有Sonar、PMD等。論方法,有圈複雜度等。所有這些自動檢測,被稱之為Staticprogram analysis 或 Static code analysis,靜態程序分析/靜態代碼分析。

這方面,在阿里巴巴有工具支持,對應的是Aone的實驗室這個功能。可以通過實驗室,接入各種靜態程序分析工具和方法。實驗室的前身是CISE。現在CISE也仍然是實驗室背後的引擎。所以有時候聽別人說CISE的時候,你就知道其實指的就是實驗室啦。

再來看右半部分。右上角,是自動的對運行中的程序的檢測。這也就是常說的自動測試啦。在阿里巴巴,也是主要由Aone的實驗室來向大家提供相應服務。這包括單元測試/集成測試;介面測試/Web UI測試;功能測試/性能測試,等等。

右下角,是人工測試。雖說是人工測試,工具也同樣可以提供支持,主要是管理測試用例。相應的工具是Aone中的測試用例管理。

測試環境隔離技術

不論是自動測試還是人工測試,只要是需要先把應用部署到測試環境,那就跟測試環境的管理有關係了。測試環境的管理,我們專門講一講測試環境隔離技術。

想像一下,你開發了一個feature,也就是一個變更。為了讓它比較靠譜再送去集成,你需要對它進行測試。單元測試當然好,但這是不夠的。需要儘可能模擬真實環境進行測試。那麼問題來了,如何儘可能模擬真實環境?比如,為每個淘系的工程師另搭一個淘寶測試用?這費用咱真花不起……

怎麼解決這個問題?阿里巴巴用了一個聰明的方法,測試環境隔離。讓大家共享一個測試環境,但又彷彿每個人都是獨佔它的,互相不干擾。

具體說來,假定搭起一套測試環境,需要1000台機器,分別運行應用ABCDE……。這個環境我們稱作日常測試環境。每個應用的版本,我們姑且稱之為A0、B0、C0、D0、E0……

現在假定甲這名同學在開發A這個應用的一個變更,在開發過程中,現在產生的應用版本是A1。於是把A1部署到單獨一台機器上,並用一些神奇的技術(通過中間件等)與剛才說的日常測試環境連通。於是,在甲這名同學看來,他所面對的系統是A1、B0、C0、D0、E0…… 而且彷彿他獨佔了這個系統。

類似地,如果乙這名同學為了一個feature,在開發A和B分別拉出變更分支,產生A2、B2。那麼A2、B2將分別被部署到單獨的機器上,然後它們一起與日常測試環境連通。於是,在乙這名同學看來,他所面對的系統是A2、B2、C0、D0、E0…… 從乙的角度看,他彷彿獨佔了整個測試系統。甲和乙在測試時,不會互相干擾。

有了這樣的解決方案,就同時達到了兩個目標:盡量模擬真實的環境;用不高的代價。

關於測試環境隔離技術,這裡只是簡單介紹下原理。

阿里巴巴相關術語

項目環境:就是前面說的,測試一個feature所需的測試環境。可能對應一個應用上的一個變更,也有可能對應多個應用。項目環境使用了上面講的測試環境隔離技術,背後接的一整套測試環境,是日常環境。

日常環境:就是集成測試環境。把各個變更攢在一起,然後部署到這裡,看是不是能work。

預發環境:這個環境比日常環境更接近真實環境。事實上,從網路隔離的角度,它不是在測試網,而是在生產網。它所連接的資料庫,也通常就是線上運行使用的資料庫。一般來說,是先在日常環境測試,通過了再到預發環境測一下。

正式環境:正式環境就是生產運行的真實環境,向廣大用戶提供服務。

流水線

所謂流水線,通俗地講就是把不同的工作按一定順序串起來。為什麼要串起來呢?

首先,有些工作天生就是有先後順序的。如果想部署,總得先構建吧。所以構建-部署,就是天然的工作順序。如果每次都是先點個按鈕做構建,等構建結束後再點個按鈕做部署,好像有點兒笨,不如點一個按鈕,把這兩件事按順序都做了。

其次,為保證質量,我們想往流程裡面加規則和卡點。比如,必須通過代碼評審和安全評審,才允許合併代碼。這些質量保證性的工作,還有可能有不同的順序和頻率。典型的單元測試和靜態程序分析應該早做,頻繁地做。而整個鏈路的測試,比較費勁,頻率可以相對低些。因此,這些工作也是流水線中的環節,並且可能以不同頻率執行。不同頻率這個事兒,就是持續交付這個流行詞兒中所說的不同stage(階段)不同頻率。

Aone提供了把不同的工作串接的能力,也就是流水線的能力。在分支模式下,每個環境,比如日常、預發、正式,分別對應一條流水線。在Git Flow和自由模式下,你甚至可以把所有工作內容,從代碼提交到最後正式發布,做到一個流水線里。看著代碼過一道道「關口」,然後發布上線,還是很爽的。

結語

以上,概要地介紹了從源代碼到上線的基本的構建部署過程,講解了各種質量保證方法及其工具支持,講解了流水線把流程作業連接起來自動運轉。這些能力合在一起,就實現了對持續交付的一整套工具支持方案。當然,如果你問DevOps的工具支持方案,我也會說,以上幾部分,構成了DevOps的工具支持方案…… 名字是次要的,關鍵是幫上廣大研發同學的忙,高效且穩妥的開發和發布。

這節課只是概要介紹。有需要的童鞋可以使用Aone的對外版本雲效,體驗一位阿里技術人工作的一天。

本文作者:董越

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號:阿里云云棲社區 - 知乎

本文來自雲棲社區合作夥伴「阿里技術」,如需轉載請聯繫原作者。

推薦閱讀:

TAG:伺服器 | 測試 | 單元測試 |