從開發到上線 實戰持續交付 -李道兵

在產品的開發過程當中，對數據量要求較高的網站進行架構設計時如何部署是個很複雜的問題，涉及到多個層面的不一樣要求，七牛首席架構師李道兵在部署工具和測試以及持續集成方面給出了本身的思考。在七牛的開發者實踐日中與你們分享《從開發到上線 實戰持續交付》。

李道兵首先從不一樣的層面來分析目前的網站的架構的設計，從數據庫、緩衝層的方面引出部署的概念。而後開始介紹部署工具的進化史，從最初的安裝文檔、FTP/SFTP、War包、系統安裝包到一鍵部署工具，一直到最近興起的docker，逐個分析了每種部署工具的優缺點。針對capistrano+puppet，進行了重點的講解和說明。最後結合七牛的實例分析瞭如何從代碼到上線的整個部署、測試、持續集成過程和其中可能會遇到的問題。下面是完整的現場記錄：

此次想和你們分享的是從開發到上線，特別是咱們七牛在這方面關於一些持續交付的事情。在演講以前我推薦兩本書，一本是《精益創業》，更多講的是從想法變成實現的。其實從想法變成一個代碼，再到運營的階段，經過運營階段反饋修整你的想法，造成這樣一個循環，達到用戶的快速增加或者快速試錯調整你的產品。我今天講的是從想法到代碼，從代碼再到運營階段。第二本書是《持續交付》發佈可靠軟件的系統方法，講的是你須要作哪些事情，包括持續集成和一鍵部署，你們有興趣的能夠看一下。

咱們回到總體，簡單的想法無論是作什麼，如今大部分的形式要否則是APP，要否則是網站。咱們從網站開始講，從前日後最前面是提供靜態文件或者是分發動態請求。再後來是業務邏輯層，咱們儘可能作到無狀態設計，它的好處是一天的量從一百萬上升到一千萬，你從十臺變成一百臺就能夠了，這種伸縮不用改代碼，只須要後面有多少個後端而已。一個用戶來訪問，確定要有相關業務邏輯，通常是用什麼作呢？數據庫，裏面要注意兩個事情，一個是容災，一個是容錯。容災更多的是高可靠的架構處理你的需求，容錯是作一些近期備份的工做。剩下的就是一個需求了，如今咱們對媒體的應用很是多，用戶有音頻、視頻等等的需求。用戶上傳的時候，用一些小的軟件或者更直接一點上公有云存儲都有很好的解決方案。剩下一些不是可選的，可是建議儘早上的就是緩衝層，目的是讓數據無壓力。就是你怎麼保證你的數據庫的數據一致性，緩存也有使用的問題。好比說機器宕了，怎麼解決一會兒就把數據庫壓跨的事情。做爲一個開發人員，已經把你的想法變成了產品，接下來的問題是在一個反饋循環以後須要改代碼，至關於這些東西從新上線。考慮到這些事情的時候，咱們又應該作哪些事情呢？

這個過程咱們稱之爲部署，這麼多年咱們一直是這麼作的。第一個是安裝文檔，好比wordpress，按照安裝文檔作這個事情，最大的問題是若是你要對它裏面的東西作一些改動怎麼作呢？要否則在線上修改，若是是大的改動的話，就須要從新安裝一遍。至關於對你整個時間的消耗會很大，成本會高不少。第二個常見的是FTP/SFTP，好比PHP這種，其實上傳了以後你的整個服務就直接可用了。這裏面比較麻煩一點是適用面很窄，本地要作版本管理。若是不作版本管理的話，極可能原文件都找不到了，很是尷尬。第三個常見的是Java裏面的一些war文件，是你把服務端有一個Java的文件，須要手動拷貝，多機狀況下仍然要搭配一些合適部署系統作這個事情。第四個是系統安裝包，比較累一點，可是對大規模部署壓力很小。好比說你有幾百臺、上千臺的機器，之前yahoo是這樣部署的，不知道如今是否是。最大的麻煩是系統安裝這一部分比較費時間。

最後一個是能夠作到一鍵部署，配置文件比較簡單案件，好比說現場有一些小錯誤，你能夠五分鐘以內把這個錯誤修復掉，不用等到漫長的部署流程。puppet和salt能夠用來解決配置問題。在這樣的狀況下，基本上就把這個東西解決了。如今有一些比較新興的部署方面的技術方向是docker，如今有必定程度上能夠取代一些虛擬機的東西，也可能成爲一種新的軟件分發方式。可是如今來說，在咱們看來有一些地方不太成熟，有一些嚴重的錯誤繞不過去，咱們正在作研究，可是尚未完成採用。

咱們多介紹一點capistrano，右邊是整個部署的目錄圖，下面分三個子目錄，一個是軟件機，再一個是目錄的部署結構。再下來是一個共享的東西，好比說配置是共享的，每次部署的時候用的是同一份配置。好比說你的一些文件都是共享的，在它部署的過程當中，一鍵部署具體怎麼作呢？第一個步驟很簡單，下載新的代碼到releases目錄，裏面就有五個了，在當前的時間造成新的目錄名，再把對應的一些代碼拷貝過去。第二步是把全部的配置文件、日誌目錄所有連接過去。第三步是連接到最新的目錄裏，第四步是重啓程序，至關於程序裏面的定義目錄都以這個爲主的，你整個的程序就一會兒到了新版本。你這邊實際上是一鍵作了四件事情，很是簡單。第一個切換capistrano連接到上一個版本，測試之後立刻能夠回滾了，很是有用。

這種方法有一個小問題，你的機器在線上的代碼修改能很好的解決，若是你的系統盤毀掉了就有一個問題，你須要重裝系統。重裝系統須要多少時間呢？有可能記得以前你安裝完系統的時候，你打了哪些補丁、調了那些配置？配置了哪些目錄和日誌滾動？可是你有沒有作文檔化，若是作了的話，順着文檔重裝一遍須要多久？若是說這段時間內作的很差，服務就下線了，作的好也許就是在一個階段裏面。你須要多久可以恢復服務，這是面臨很麻煩的問題。第二個問題是業務的大量增加，你須要把你得有些服務器擴容，好比說一臺擴展到十臺，十臺擴展到一百臺。擴展帶來兩個問題，第一個問題是怎麼把這個事情作的很是快，不用浪費不少人力。第二件事情是怎麼把事情作的很對，其實擴容的機器當中有很微妙的差別，好比說原來的機器上面已經調過了，可是這個沒有。怎麼經過一些方法把事故消除掉？若是有這些方法你們會很高興。新來的機器是否是監控配齊了？原來的機器一步一步積攢過了監控，可是新機器有沒有呢？是咱們關心的問題。

puppet/salt這兩套系統是來幫助你解決這個問題的，首先第一個全部的配置入庫，你的全部機器上無論是要預裝哪些軟件或者怎麼樣，均可以在版本庫裏看到信息。第二個是胸模板簡化配置，十臺或者一百臺不須要把全部文件拷貝，只須要指定一下就能夠了，對應的哪些功能有哪些天然就知道了。並且也不用一臺一臺的應用這個配置，並且會按期作一些安全更新，或者其餘的一些配置調整的東西，哪些須要重啓，它能夠引入一些依賴或者消息，經過這些指令使你不用想配置哪些配置了，相似的也會有一些其餘的需求，這些需求均可以經過它來知足。

對於咱們來說cap+puppet的問題是咱們要考慮的，咱們回滾的時候只能回滾程序，若是程序和配置偶合的很緊的時候，新版本程序須要一個新配置，你能夠用編程來解決，這樣程序員就有很大負擔了。第三個有中心架構，可是優化的不夠好。當數量達到一千臺往上的水平，它有一點支撐不住了，這是咱們另外從新開發的理由。咱們作雲存儲對數據安全很是關心，咱們去線上裁判數據。開發人有很強的需求瞭解你的日誌，你線上的一些狀況。好比說網絡流量，一些鏈接數等等都是咱們開發人員想去了解的。這樣的狀況下，你就須要不少的腳本幫助你的開發人員瞭解這些狀況，這些也是以前不夠用的，須要咱們另外開發一套新的部署系統的理由。這個新的系統咱們如今已經逐步在採用了，也許未來有機會能夠對外發布一下。

前面講了從代碼到上線的整個流程，儘管回滾很方便，可是你確定不但願把錯誤的版本放上去。更況且有時候回滾並不能解決問題，由於有的錯誤已經發生了。好比說轉帳轉錯了，錢損失了，也挽回不了。你要保證代碼的質量就是要測試，咱們推崇的是自動測試和持續集成。首先來說你的開發人員要寫你的單元測試和一些集成測試。第二個是你每次作一些合併請求的時候，全部單元測試和集成測試都會跑一遍，保證你全部的提交不會干擾你原有的業務邏輯。負責這個代碼的人員會特別注意，針對你寫的新功能或者錯誤修復是否補充了測試？若是沒有補充，直接就被拒絕了。最後發佈的時候咱們會有一個更加好的測試，咱們這個軟件能夠決定跑一個大規模的測試，來決定咱們這個是否是最好的版本。可是一些代碼質量的可視化工做是它作不了的，好比說單元測試的總數量是否隨着時間緩慢上升，你的測試覆蓋率是否穩定在可接受的水平，這些都是很方便量化的。量化的可視化可以幫助主管或者其餘人也好，很方便的知道這個團隊或者說代碼質量是否有裂化的問題，也方便你們介入。

從頭串一下工具鏈，咱們怎麼作一個小事情的呢？第一個是提交issue，全部的工做跟它關聯起來。第二個是修改代碼提交你的PR(Pull Request)，若是持續集成經過了，這個PR就合併掉了。持續集成經過，經過以後進行部署，部署上線以後再次檢驗issue，而後就能夠關閉了。咱們把這個流程作的個很短，十幾二十分鐘就會完成，使得咱們的試錯週期更短一些。這裏面有一些咱們的經驗教訓，第一個是所謂的正規化。

正規化是幾個點，第一個是全部的原碼須要入庫，特別是第三方軟件，你早晚有一天對它修改。你儘早把它入庫，針對入庫的代碼作一份發佈系統的話，即便是第三方軟件也歸入到部署流程裏面來，這對你之後是一個好事。第二個是你線上的配置永遠不要入代碼庫，由於涉及一些隱私，特別是安全問題。若是說開發人員拿到線上數據庫密碼的話，咱們認爲是一個風險。第三個是你線上的配置要入庫，不是入代碼，是入一個部署庫。最關鍵的密碼和私鑰的部分不要作到庫裏面，好比說你把模板配置作到裏面，讓咱們的整個過程很安全。整個程序也不須要上級領導蓋章和批准，所有能夠自動化，又比較安全

剛纔提到從測試到上線流程，有一個咱們提的是測試環境。集成測試能夠避免一些問題，可是仍然不放心。或者說咱們真的是對它不放心，咱們就搭一個測試環境。好比說你能夠有測試環境和線上環境乃至更多的環境，首先部署到測試環境，經過手動檢驗完成以後再決定是否在線上部署。測試環境作到，兩點一個是跟你的線上系統不要有任何關聯，無論是數據庫仍是怎麼樣的。大家之間不要共享一些共同的密鑰之類的東西，這樣會致使權限問題，若是別人拿到你測試系統的帳號，有可能在線上系統能夠用的話，這種狀況下是一個安全流動，這個就是須要注意的事情。

咱們另外作的是小入口，測試環境和線上環境不同。因而特別小型的東西，如今小作一個部署，而後才大規模的放量作一些部署，挺好的。第二個是你在小入口上面，個人整個請求量和訪問量很是小。很是小的時候，不少線上測試工具就能夠用了。若是你有一個小入口，無論是經過什麼操做作的請求，均可以達到相似的效果。在這兩個狀況下，都是很好的，不只是測試手段，也是一個部署的手段。看上去也很簡單，像一個一個的日誌。

咱們有一個遺留問題，第一個是Go語言的問題，是一個編譯性語言，咱們不但願它到服務器去作，由於對咱們服務器擾動很大，咱們經過可執行程序作分發。第二個問題是可執行程序分發的時候，內網達到必定程度的話，會使你的服務器扛不住。咱們本身是作存儲、分發的，最簡單的方法是文件加一步推送到內網的分發節點，這樣就能夠支撐你內網上千臺服務器。第三個是不少依賴外網的東西，咱們不少機器是徹底跟外網不能鏈接的。不只外網訪問不了它，它也訪問不了外網。好比說像安全中心，或者說安裝部署的配置腳本，就須要它去外網作一些東西，咱們能夠作一些圖片包安裝的，剩下的問題咱們能夠經過它繞過來。
謝謝！

該分享來自七牛首席架構師李道兵在這次的沙龍活動中帶來了題爲《從開發到上線 實戰持續交付》的分享。

順便通知一下你們：開發者最佳實踐日·第7期－互聯網產品從設計到上線 上海站將於12月13日在上海創業者公共實訓基地5號樓1層，EFG一樓舉行，歡迎Segmentfault社區的各路猿們來相聚！
報名地址：
http://qiniu-7.eventdove.com

「開發者最佳實踐日」是由七牛雲存儲發起並聯合各方小夥伴爲開發者舉辦的系列技術沙龍，關注開發者在實際應用中可能遇到的技術問題。致力於爲敢於創新的開發者們提供行業內最前沿最熱門的技術乾貨，以技術驅動應用創新，讓更多的開發者享受技術帶來的生活樂趣。