阿里技術人的第一節課，都上些什麼？
來自專欄我是程序員
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(階段)不同頻率。
結語
以上，概要地介紹了從源代碼到上線的基本的構建部署過程，講解了各種質量保證方法及其工具支持，講解了流水線把流程作業連接起來自動運轉。這些能力合在一起，就實現了對持續交付的一整套工具支持方案。當然，如果你問DevOps的工具支持方案，我也會說，以上幾部分，構成了DevOps的工具支持方案…… 名字是次要的，關鍵是幫上廣大研發同學的忙，高效且穩妥的開發和發布。
這節課只是概要介紹。有需要的童鞋可以使用Aone的對外版本雲效，體驗一位阿里技術人工作的一天。
本文作者：董越
原文鏈接
更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎
本文來自雲棲社區合作夥伴「阿里技術」，如需轉載請聯繫原作者。
推薦閱讀：