摘要：剛才聽了謝樂冰的演講我覺得很多東西和我們的思路非常像，從我回國到現在大概有一年多的時間。在看來，一個業務應用應該是分層的，每一層都是一個所謂的服務，剛才謝樂冰講的所謂服務化和異步化，不會把這些東西從前到頭攪在一起，這樣非常難以擴展。

本文是數人云深圳技術分享課上Coding CTO 孫宇聰的演講實錄，小數帶你走近這位詼諧幽默的大牛，領略他深入的見解和豐富的實踐經驗。

非常感謝今天有這個機會，數人云的CEO是我前同事王璞，他原來是Google的，我是在Google云計算部門，我們合作非常緊密。

創業也是非常好的機會，Coding是關注于開發者、生產力、效率。數人云會關注真正從代碼到研發、落地，這一系列的事情，這簡直就是絕配。剛才聽了謝樂冰的演講我覺得很多東西和我們的思路非常像，從我回國到現在大概有一年多的時間。我一直在改造Coding原來的業務、架構，包括新業務的架構設計。對我來講他講的很多東西我們已經實踐過了，只不過采用的方法可能不太一樣，用名詞來說就是殊途同歸，條條大路通羅馬。

今天我從研發的角度講一講，把一個所謂的代碼變成無服務、無狀態、分布式，我們是怎么想的。我們很遺憾的是跟他不是一同開始，我們沒利用他們的東西，現在我們也非常想能夠把我們這些經驗和他們的經驗結合起來，給大家提供一個完整的，從開發一直到最后的體驗。

先吹吹牛，介紹一下我自己。我原來在Google，2007年加入的Google，2009年去的Google美國總部。我去了以后參加兩個大項目，一個項目是YouTube國內不存在的視頻網站，當年經歷了YouTube爆發式增長的階段，從無到有的過程，這個經歷是值得一提的。應該是2010年左右，當時YouTube每個月的上傳量已經超過1個PB，這個數字目前沒幾個人達到。我們建了CDN網絡，當時我們有一萬個節點，10000臺機器，都是部署在每個SP自己的機房里，當時的峰值流量就達到10T，一回國都是2M的小水管，當時流量是10個TbpS，可能80%的流量都是小貓視頻，大家上YouTube最多的事是看小貓視頻。

后來轉到Google cloud platform，當時做的主要是Google所有內部百萬臺服務器的運維服務，要管理機器從工廠造出來那一刻，接上電源以后，然后安裝、部署，包括運行軟件，最后都要銷毀，當時兩個團隊20人，管全球100多萬臺機器，我們不是管機器的，是讓系統管機器。

后來國內炒的很火的Borg，Omega，Google所有的任務都是集中在這兩個任務分發系統上，Borg已經很牛了，Omega又很牛，但是不幸的是Omega已經早就被cancel了。Omega這伙人寫Borg寫煩了，就想重寫一下，這幫人寫了大概兩三年，最后沒能解決什么實際問題。這個事情在Google內部結果是不太好的，就被cancel了。更搞笑的是，寫Omega這伙人一看公司不讓我寫了，我改成寫Kubernetes。原班人馬寫Kubernetes，把這個思想帶過去，重新用go又寫了一遍。市面上的容器化管理平臺又有幾個，我的看法是Kubernetes現在不是很靠譜，起碼現在不是很靠譜，大家就知道選什么好了。

回國以后，我們主要干了Coding這個事，主要是做了所謂的眾包平臺，可以讓需求方在上面找到程序員做事，程序員也可以接到私活，有點像軟件行業的房屋中介。

Coding基于終端業務是碼市，用張老板的話說讓自由人自由連接，需求方找到程序員，程序員找到需求方。我們開發針對很多程序員的生產力工具，我回國以后最大的感受，國內的程序員是太敬業了，比國外敬業多，我們早上10點多公司，下午3點多就回家了，國內的程序員什么時候干過這個事，996，10、10、7，都干過的。很多時候老板招程序員是來干活，他一是不關心你用什么工具干活，二是不關心你怎么干的，效率高不高。我們是給程序員提供好的工具，提高生產力，解放生產力，讓成程序員效率提高。

基于這個我們做了項目管理、代碼倉庫、在線開發的WebIDE、演示平臺。很多東西目前還是秘密，但是我們也秘密研發中，今年下半年很多東西要上線。

今天主題主要是講Borg和Coding的實踐。Google的Borg系統是什么東西？Google Borg系統是整個公司的任務分發系統，你在Google里面寫程序必須在Borg這個平臺上運行，怎么做到的？你買不到機器，公司不給你批錢買機器，必須從Borg買資源。當一個東西成為一個公司標準的時候就好辦了，否則你永遠是買一臺機器瞎配一下，永遠所做不到所謂的PaaS，或平臺化。

Google的數據中心，或者說它的架構層面是什么樣的？它也非常簡單，Google有幾個名詞可以解釋一下，首先是Google的機器，每一臺都是沒有外殼的機器，因為外殼對Google來說一點用沒有，因為它要求隨時可以操作。所有這些機器組成一排，很多排的機器組成所謂的集群，兩三個集群組成所謂的數據中心，數據中心放在一起就組成一個園區。

為什么說這件事？Google的一大理念是分層或分區，相當于從上到下都是一個經過頂層設計的狀態，不會是說有的公司是從前到后都攪在一起，你要說我做一個業務，業務從買機器到布線，到供電，都是連在一起的，全都是一個部門搞的，這樣搞出來的東西可能效率稍微高一點點，但是復雜度高非常難以擴展。Google分層的理念和容器化的理念一樣，容器化本身是要分層，只有分層才能降低復雜度，每一層都給每一層提供不同的接口。這個是每一排機器是連到一個供電設備上，每一個集群，每一個Cluster是一個完整的Borg Cluster，好幾個數據中心有好幾個Borg Cluster。給應用開發者提供了一個穩定、抽象的平臺，你不用擔心我具體找哪臺機器，而是把任務運行到哪個集群中，然后自動在集群中給你分配資源，這是Google的生產環境是這樣的組織過程。

當Google一個請求來的時候，Google都涉及到哪些東西，一直到最后的服務層涉及到什么條件和環節。Google有所謂的B2、B4，可以理解為一個是公有網絡，一個是私有網絡。B2是和各大運營商接的網絡，B4是數據中心的骨干網。數據包從ISP，或從用戶直接到達Google數據中心以后一定會進入Borg Cluster，所有任務都在Borg Cluster這個集群里。Borg里運行了GFE，GFE它相當于一個前端，有GSLB是負載均衡系統，告訴用戶你應該訪問哪些機器，或者是怎么樣，這個請求到達應用程序的后端，存儲層讀數據，最后反饋給用戶。

在Google看來，一個業務應用應該是分層的，每一層都是一個所謂的服務，剛才謝樂冰講的所謂服務化和異步化，不會把這些東西從前到頭攪在一起，這樣非常難以擴展。把整個的所有流程切片以后，每一層都可以橫向擴展，處理很多應用，效率也非常高。這就是Google做分布式，就是靠一層層切分，每一層都有不同的團隊負責，這層和那層有明確的接口，接口是異步的，非常清晰的，所以才能大規模擴張。

今天講的重點是Google的Borg是干什么用的，Borg內部架構是什么樣？首先里面有幾個比較大的東西，第一個東西就是所謂的Borg master，有五個方框，因為實際就是跑在5臺機器上的。Borg master是基于所謂的Paxos協議，把一個狀態可以安全地復制到5個機器上，只要5個機器有3個正常工作，這個集群就能正常工作，這就是Borg master，把集群的所謂狀態，什么東西運行在什么地方，一個任務運行幾份，運行在哪，什么狀態，都記在Borg master上。Borg Master有對應的Borglet，就是Borg slave，運行在集群的小節點上執行任務的東西， Borg master負責發指令，Borg slave負責執行。Google這個模型運行十年多，每一個集群大概有10000臺機器，這個模型是經過驗證的，每一個集群里開始是10000，后來漲到30000-50000臺機器，這個規模是非常可觀的。

還有Scheduler，選擇每個機器去運行，這個細節就不說了。和用戶的接口，Borg有個所謂的config，config就是你寫了一下我現在有一個東西要運行，這個東西有什么運行條件，通過工具推到Borg Master上，Borg Master給你安排一個機器，如果這個機器突然間掛了，就可以把任務遷到別的機器上運行。Borg Cluster的模式，給上層的應用提供了一個接口，你只要告訴我你運行什么，我不關心你具體運行在哪。大家可以看Google特別吹牛的文章，我們每個月有20億的任務在運行，實際上有很多任務是運行1秒就崩潰，然后又重新運行，里面數據有點浮高。但是這個模型是Google經過實踐得出的，因為開發者真的不關心具體的機器是哪個，只關心我需要2G內存，一個CPU，塞到機器上跑就可以了，不關心機器上還運不運行其他的東西。

Borg模型比較難，Borg Master也是Google內部工具。我回國以后遇到最大的問題，這些東西都玩不了，就得土制。因為你沒有一個完整的解決方案做這個事，我們自己得把這個東西搭起來。搭起來得需要一些東西，分為三大塊，第一大塊是所謂的Run time，這解決容器化的運行時環境。二是在Run time運行就得涉及到鏡像，或鏡像分發的機制，有一個東西要運行，可以把它運行到某一個機器上。最后是有Orchestration，就是編排系統，即有一個人，一個程序，決定這個東西運行在什么地方，然后是下載鏡像，然后去執行。在2015年初的時候發現，目前符合這個模式的東西就是Docker，我們先試試Docker什么樣。

2015年上半年，基本上大上半年的時間，我們搞了所謂的Docker化，最開始我們內部使用的都是一個所謂單機部署，每個人都要自己拷貝這樣的文件，然后執行命令。我們后來搞了一個Docker化，Docker化的結果是，所有的代碼打包成了Docker Image。Docker生產環境有自己的私有Registry，用Docker container運行代碼。最后還寫了生產環境的容器編排系統，這個做得很爛，沒有數人云做得好，但是勉強解決了我們手動執行的一些問題。搞完這個東西以后，我們發現Docker到處是坑。

然后我來講講填了哪些坑。Docker daemon，也就是運行時，當時大家覺得很厲害，一開始都說你用容器必須用Docker，后來發現Docker daemon不是唯一的一個啟動容器的途徑，跟以前搞的都是一回事。Docker daemon會遇到一個問題，任何人用Docker第一天都發現，Docker 里面沒有init，daemon也沒有reap子進程，如果程序fork很多進程，會在系統中出現很多僵尸進程，最終導致 docker daemon 出現問題，國內目前也沒有把這個問題解決。每次跑一個Docker程序的時候都要擔心，我們會擔心這個Docker有沒有處理好僵尸進程的問題。二是Docker后面的存儲系統沒有一個靠譜的，用AUFS，很多垃圾文件不清理，我從事軟件開發這么多年從來沒有過，很少見，大部分都是已經打包好的程序，不會占用很多磁盤iNode。最新版OverlayFS產生一些死鎖還有崩潰，BTRfs也是。當時我們對人生產生了懷疑，為什么我們要自找這么多事，我們原來跑得好好的，為什么搞到Docker上來，遇到了一些新問題。我們甚至把Docker daemon改成Open SSH，但Docker daemon和Open SSH其實是一回事，就是提供遠程命令執行的工具。你也可以理解為一個木馬，發一個指令就跑一個程序，而且跑的還有問題，我們不如直接SSH連接上運行這個程序，都比這個靠譜，當時很難受。后來Docker daemon本質上是一個所謂的系統工具，它不停地掃描系統中的文件路徑，進入這個狀態。它有兩個問題，一是原子性操作的問題，你Docker刪除一堆事，要刪目錄，調一堆系統API，任何一個地方出現問題都會造成垃圾，造成系統死鎖。Docker daemon一重啟，別的肯定也會要重啟，對我的個人聲譽在團隊里造成很大的影響。

Docker daemon有很多問題，Docker是當時可選的東西，給我們帶來好處，但是隨之而來的也有一些問題。Docker團隊自己也意識到有問題，后來美國的神仙打一下架，覺得我們同意搞一個所謂的OCI，它成立了一個標準，就產生了一個Runc的東西，Runc就是一個具體執行container的東西，Docker一聽說這個東西就趕緊把代碼捐出來，給了Runc，好處是他對代碼很熟悉，趕緊搞了一個containerD，是grpc warpper，通過grpc訪問的一個服務，最后用戶還保證Docker不變。對Docker來說OCI像毒藥，逼著他吃，但是吃完也對他本身造成威脅。對最終用戶是好事，如果我們發現Docker不靠譜，就直接用containerd交流，如果containerd也不靠譜，就繞過去讓他和Runc交流，你不再綁在一個Docker。跟虛擬化是一樣的，以前大家覺得虛擬化就是Vmware，必須得用Vmware的一套東西才能看得見。現在分層，先有KVM，然后有QEMU和containerD差不多，再上面有Openstack。和Google的東西一樣，把邏輯分層，不再是一團，從上到下捅到底，每一層都被替換，靈活性更高、性能也會更好。

而后我們又發現Docker Image本身也不怎么樣，最后大家的評論是非常雞肋。Docker Image就是一個壓縮包，如果你想把一個東西傳給另一個人打一個包壓縮一下發過去，是一樣的，Image又能分層，又能節省傳輸，這個東西都是扯淡，因為我們內網一秒好幾百M，省出10M的磁盤空間對我們來說是省幾毫秒。Docker Image來自于DockerFile，Dockerfile有一些表面問題，首先是不會寫，這個東西是他自己發明的，對于開發者來說，這個東西對你是有學習障礙的東西。你學習過程中蕩滌了你的靈魂，又開始懷疑人生。所以用Docker就經常懷疑人生，你覺得以前學的東西都不好使了，用了一段時間以后發現這些都是騙人的，你要干的事還是一樣。Docker的核心問題，或者是Image核心問題一是編譯代碼，二是打包成鏡像發出去。怎么編譯，怎么打包，這兩件事是完全分開的，不應該攙在一起。你下次寫Docker Image的時候，發現寫DockerFile，既做編譯，又做打包，恭喜你，你已經成功地給自己挖很多坑，運行的時候發現打包一次需要好幾小時，下載一堆東西，最后打包的鏡像好幾十G，這些事情我們都干過。我們第一個鏡像是打包完3G多，當時我們震驚了，這么辛苦寫了這么多的代碼嗎，運行程序就達到3G。

最后我們理解了，你要做好一個事情，Build和Package要分家，先Build好代碼，再把編譯的結果賽到Image運行，Build要靈活，要針對你的所有系統來做，你的代碼是什么樣就應該怎么Build，你要寫Java，最后產生一個結果是Java包，如果不是就說明你的代碼寫得有問題，你應該在這個問題上解決，最后就產生Java包，Package就是把Java和Java包放在一起運行。

Coding最后的Dockerfile就三行，第一行是from某個基礎鏡像，一個Java運行時，第二行是add某個Java包，第三是CMD運行。DockerFile基本上我們處于雞肋狀態，用它還可以利用它去推代碼，這部分功能還是有點用的。但是真正用DockerFile，我們不會用它做復雜邏輯。

把Build和Package分開，我們用的所有編程語言都已經把編譯工具搞好，所有的編譯工具都能產生一個多帶帶的包。我們嘗試用DockerFile同時解決build和package這兩個問題，真是沒事找事。你用Docker的時候發現我干了一堆事，看起來很牛，但是實際效果并不好。作為程序員得審視這個問題，就是能不能產生價值，如果不產生價值你是在給Docker打工，盲目跟從Docker，他說這么干就這么干，他如果改了你這些東西就浪費了。如果你抓住本質，Docker怎么改對你就沒有影響。

Package的構成我們還是用的Docker image的方式，寫了三行，一是Java的運行時環境，二是Java包，三是怎么運行Java，這是所謂的Package。后來發現三行太多，應該寫兩行，他讓我們寫一行就寫一行。為什么第三行不用寫，Java程序執行起來都一樣，都是Java -jar這些東西，你要加一些參數。不會寫到Image里會發現，Java調一下內存要重新打包嗎？太不合理了。最后CMD就不寫了，Docker直接執行，在配置文件里執行。基本上所有的服務，要么是三行，要么是兩行。

在使用的過程中我們發現，Docker有很多花里胡哨的東西，結果卻是什么也沒用，我們用的是非常簡單的，就把Docker當成容器。為什么呢？第一點你看到大部分文章講Docker作為公有云平臺我們應該如何使用Docker，這是國內公司的通病。搞Docker的部門大部分是公司的運維部門，國內的運維部門沒有權限改代碼，只能改自己的平臺，作為公司的平臺部門得提供各種SDN的服務，研發人員根本不需要這東西，如果你沒有SDN，就是主機，就是host網絡模式，給你分配一個端口，保證你的端口是可用的，這個就行了，以前Borg就是這樣，Google搞了十年，每個開發的人都知道，我們啟動的時候得找一下本地端口什么樣，要么可以配置，要么可以自動尋找一個可用端口。Docker來了說你不用干這個事，我給你一個IP，給你一個80，你永遠可以訪問這個。但是他沒有做到，做了很多后面的東西，SDN，各種打包，性能很差，這個事一般他不告訴你，當你上了賊船以后，為什么我們的程序性能這么差。他說困難是暫時的，面包會有的，未來兩年這個性能就提高了。我說未來兩年我們程序都不用了，早就換了，這個明顯是不合理的。

經常有人問我你們用Docker這么多，怎么解決共享存儲的問題。我說我們沒有共享存儲，以前是什么樣還是什么樣。很多程序，共享存儲一是要改代碼，或者說有一個很牛的，我們能夠申請一個文件系統，自動掛載上面。后來我們發現這個東西沒有一個有用的，對我們來說沒有區別。我們的編程模型還是針對本地服務，我們在編程的時候已經考慮到如果本地文件不存在怎么辦，遷移數據怎么辦，我們都有現成的解決方案，為什么要換，我們還是用Host模型。數據就是寫在機器上，如果你要遷移這臺機器，如果這個東西有狀態，你就應該處理這個狀態，而不是運維部門幫你解決處理狀態的問題，這是公司里效率最低的方式，它得跟運維部門協調，我們要遷移了，運維部門說我幫你把數據拷過去，這個是不行的。

Docker有一個更大的坑，我把這個東西都轉成Docker運行，你一看時區都是GMT時區，有種到了愛爾蘭的感覺，所有的log時間對不上了。Docker沒告訴你，主機里的locale，你的編碼設置、時區設置，每個用戶passwd都是用的默認的設置。這給我們造成很大困擾。每一個打包的人得關心到底是什么樣，到底怎么正確設置時區，密碼這些東西。后來我們直接就mount，跟主機一樣，如果今天這個程序運行在中國的一臺主機上，他就應該用這臺主機的模式。我們用容器，很多時候變成我們真的只關心，第一是運行時的版本，第二是代碼的版本，只有這兩個東西是會變的，其他東西都是跟著主機一起走，這個模型是最簡單，最有利于推廣云計劃、分布式計算的。

不管你做不做容器都應該往幾個方向努力，一是所謂的對生產環境的管理模式。寵物式管理和放牛式管理，寵物式管理是你搞一臺機器，給這個機器起好聽的名，很多公司有專門的機器叫數據庫，這個機器有特殊的人調試。突然有一天這個機器掛了，你得把這個機器修好，這是寵物式管理，你得把這個東西修好，不修好整個業務就停了，數據庫是最典型的。除了數據庫外我們采用的所有管理方式都是放牛式管理，你放一百頭牛，有一只牛吃完口吐白沫倒下了，你的第一反應不是你的牛吃病了，一定是咔，然后再拿一頭新牛過來，如果做到這一點很多事就很簡單。你隨時保證資源，保證有一百頭牛在跑就行了。

二是在國內公有云平臺上，最依賴的還是靜態手動資源配置。因為我們大部分業務都是所謂的daemon job，服務型任務，你的東西一啟動它就要一直運行，占用一定的數量的內存，一定數量的CPU，就持續提供服務。所以這個東西要遷移對你沒有任何好處，可能能夠提高你資源利用率，如果你搞一臺新機器把這個東西分過去。但是同樣的，你在這也是用CPU，那也是用CPU，對你來說花錢一樣花。所以很多時候動態調配在daemon job是沒意義的，除非不停地有機器掛，公有云虛擬化了，已經減少了很多這方面的問題。我們最關心的是留出足夠的富裕量，搞出冗余，不受任何一個多帶帶虛擬機的影響。動態調配對我們意義不大，動態調配唯一有用的地方是你有批處理、周期性任務，他運行時間比較短，你又不關心在什么地方運行，這是容器平臺截然不同的兩個的使用場景，這兩個應用場景可能有不同的方案解決。

最后得出的結論，算我提出的一個口號，怎么樣能夠減輕你運維的壓力，或提高你開發的效率。你是要把所有做的事情，所有需要人力參與的事情工具化、代碼化、半自動化，完全自動化這個事很難，涉及到你要通過實踐積累，把各種各樣的邊緣情況考慮到。現在對我們來說，80%的是半自動化，執行的時候不出錯，很快地執行。這是我們所謂開發編排系統的主要目標。在一個公司里什么任務運行在什么機器上，很多時候存在開發人員的腦袋里，比如數據庫的IP是什么，你如果能想起來，這就說明你們公司的代碼化不夠。代碼化把人才知道的東西都寫到機器里，對我來說不關心數據庫的IP是什么，我只要知道它的域名找到對應的機器連接就行了。

對我們的生產環境，第一什么東西跑在什么機器上，怎么連接。二是搞出常用的屬性管理，比如名字是什么，端口是什么，有什么特點。三是我們仿照Google搞了一個Jobs/Tasks的抽象層，Google里面最大的抽象層，你一個任務可以有多個副本在運行，這個任務今天跑5個副本，明天跑100個，這個集群可以直接搞定，我們把這個概念抄過來，相當于每一個任務都有2-3個Tasks。最后把數據寫進代碼化的配置文件里時，你發現集群可以復制，你在這個集群上可以跑，在那個集群上只要調調資源的對應關系，具體跑在什么地方，你就會發現這個就是所謂的可復制集群，你本地也可以跑一套，在生產環境、配置文件都可以跑一套。這是最關鍵的點，不管你怎么干，你最后都要干一個類似的事，就是把生產環境代碼化。

接下來，基于剛才的知識搞了一個小工具，這些工具是提供原子性的操作。up是啟動，down是干掉，rollingupdate是一個個更新，保證每個更新完了可以啟動進行下一個更新，對研發來說就需要這個東西，他們都理解。你說我有一個網易UI頁面，你點鼠標，他很不理解，他不知道產生什么事情。任何一個集群管理系統，就是要設置所謂的接口，你要提供一些原子化、半自動操作，去協助開發者達到他想要干的事，這是所謂的編排系統最應該提供的東西。

后來我們應該有一個所謂的diff，運行過程中怎么有配置的改變，改變要看一下先改什么，然后再真正應用這些改變。后來又搞了網頁系統，可以用網頁看，以前連網頁都沒有，后來覺得還是不太方便。在網頁系統，以前連網頁都沒有，上可以直接看log，甚至遠程登在某個容器進行操作。這是最小的功能機，最有用的。

最后總結一下，第一點，想要把容器化、或想要把分布式系統做好，你要定死接口，放手實現，對你來說只需要三個接口，build、package、run，能滿足效果，能運行就行了，每個項目都有不同的需求，不可能強求它完全一致。

第二個，生產環境容器化。很多業務有本地依賴，不能挪動。但是最好的情況，第一，你一定要做到軟件把它包起來，你軟件用到的所有資源、所有的文件都是集中在container這個里面的，不會用到別人的東西，中間不會產生交集，這是包起來第一步。這一步很難，很多應用配置文件都寫在系統的不同地方，這個機器上可以跑，那個機器跑不起來，只有包起來才能挪動，別的東西能正常訪問，這是最重要的。如果這兩個東西都做成以后，這個東西做成可復制，可以延伸、可以擴展、可以復制，這就是容器化做好了。

針對DEVOPS實現代碼化、工具化，最后實現自動化就行了。