哪吒：猪八戒十年DevOps演进之路
前言
時間先回退到2011年，那時候我剛加入豬八戒，加入公司之前我還不知道svn、git是什么東西，連發布代碼也是用的最傳統的FTP上傳方式。而早在2009年，來自Flickr員工在一場會議中所揭露了如何改善Dev和Ops的合作，達到了單日10次發布的高速度，催生了后來的DevOps運動。（題外話FTP的方式幾秒就能發一次代碼）所以DevOps到底解決了什么問題呢？接下來結合豬八戒的不同階段給大家介紹一下我們的DevOps演進之路。
豬八戒devops演進之路
1、初創期
雖然2009年就提出了DevOps，但國內很少人聽說過這個名稱，但是這并不代表我們沒有去解決dev和ops的協作問題。
那一年豬八戒網僅有4臺物理機，托管在某IDC機房，總的工程數20左右，均為PHP工程，技術人員20左右，由于迭代的頻率很高，每天發布30+次，公司僅有2個運維人員，所以如果沒有自動化的方式是很難完成這么高頻率的發布的，所以有了公司第一版的“DevOps”。
如下圖：
上圖的流程特別簡單，使用svn管理代碼，有兩個固定的分支，一個用于發布到測試環境，一個用于發布到線上環境。研發提交代碼后，通過svn自帶的hooks功能配合rsync將代碼分發到對應的服務器，由于當時所有應用都是部署在一臺物理機，所以只需要全量pull即可完成發布。通過這套簡單的流程即可實現研發合并并提交代碼即可發布上線。解決了快速發布的問題。
?
2、業務增長期
時間到了2013年，業務也快速增長服務器、應用、研發人員都出現了很大規模的增長，伴隨著很多問題也出現了，隨意的發布讓線上環境變得很不穩定，配置文件變更不當導致全站500頻頻出現。虛擬機的引入也讓之前的發布方式變得難以支持。所以此時急需對之前的發布方式進行升級，來滿足現階段的需求。
如下圖：
這個階段最大的變化是大量使用虛擬化，并對應用進行了獨立部署，同時為了控制發布取消了svn hooks引入了SYN系統（我們內部取名）。
SYN主要解決以下幾個問題
1、權限控制（可以控制到工程、環境、發布時間）
2、引入exclude_list來解決配置文件變更的問題
3、工程代碼映射關系（CMDB1.0維護工程和機器的關系）
4、代碼分發
通過SYN系統的引入，線上的穩定性開始變好，配置文件研發提交申請由運維人員統一進行維護，出現配置異常的情況也大幅下降，然而發布的效率也相對之前減少了很多。
3、多語言
時間到了2015年，業務規模和人員規模再次出現了大幅增長，開發語言也由以前的純PHP到大量引入JAVA語言，顯然之前的SYN系統已經不能滿足需求。這時我們開始引入Jenkins來解決CI的事情。其他結構基本沒有多大的變化。
如下圖：
我們繼續沿用了之前的SYN系統來控制權限，但是CI部分全部交給了Jenkins，這個階段我們的CMDB也完成了代碼、工程、資源的100%關聯。所以CD部分也變得非常方便，有一個短暫的階段為了解決多部門聯調的問題，出現了10套測試環境，得益于CMDB信息完善以及一些自動化的能力，所以在資源足夠的情況下可以很快速的完成一套環境的搭建。
4、微服務、容器
時間到了2016年，這個時候公司也引入了很多大廠的大牛，微服務、容器、DevOps也進入了我們世界，于是就有了長達2年的DevOps研發之路。
先看一個圖：
這種架構我相信了解過DevOps的都不會陌生，這里我重點介紹3個不一樣的地方。
（1）基于JIRA的研發流程管控。通過JIRA管理研發流程，發布的時候嚴格校驗狀態，確保所有發布均符合研發規范。
（2）SDL和流水線結合（DevSecOps），從創建工程的安全評審，到每次提交代碼的自動掃描，再到發布的安全測試，確保每一次發布的代碼都是安全的。
（3）豬八戒容器云，完美實現了流水線和多個K8S集群的封裝，解決了跨機房部署等問題，目前豬八戒網90%的工程均運行在容器中，較之前使用虛擬機部署減少資源60%以上，大幅減少了IT成本，同時服務發現、滾動發布、動態擴容等也讓業務更加穩定。
附容器云項目核心組件（如果大家對容器云感興趣可以在評論區留言）：
目前我們的流水線每天支持業務發布150+次，發布成功率99.8%+，完成一次從測試環境到線上發布平均耗時595s。
?
5、一站式研發平臺
DevOps只是研發過程中的一部分，所以我們需要有一套新的平臺來解決工程的全生命周期管理。去年10月份我們開始以需求為出發點，圍繞工程全生命周期管理的平臺打造。底層架構和上面的沒有什么區別，只是對產品做了大量減法，讓產品的用戶體驗更好，下面從功能角度簡單介紹一下我們的一站式研發平臺。
（1）重新定義工程類型，對歷史所有工程進行盤點最終梳理出6大類型便于研發準確的創建工程。根據類型不同最小化的讓用戶輸入信息。
（2）本著誰定義，誰負責的DevOps理念，一站式研發平臺把所有權限交給了工程負責人。工程負責人可以完成配置、發布，接收告警等所有工程管理配置功能。
（3）需求發布
前面已經提到，我們對研發流程管控是較為嚴格的，任何需求的發布都需要經過嚴格的流程審批，每個流程可以發布的內容也是嚴格限制的。為此我們引入需求管理，把每次交付串聯起來。
（4）技術架構
一站式研發平臺圍繞項目全生命周期，以場景化的方式把可能用到的研發工具串聯起來，各個功能仍然由不同的子系統完成。整體架構如下圖。
?
對于云原生的一些看法
我個人是比較擁抱云的，特別是云原生，我們目前業務雖然都在云上，但是全都是使用的云的基礎設施，其他服務全都是內部團隊在做，從投入的角度來說確實很大，而且期間也不乏走了很多彎路，我也聽到很多關于擁抱云原生應用后的一些擔憂，確實有利有弊，自建對于技術團隊來說更加靈活因為技術相對可控，一旦擁抱云就會有很多限制，畢竟云上都是通用能力，如果有大量定制化的需求很難得到滿足。另外如果企業已經投入了大量的成本有一套自有的能力，上云短期也會有很大的適應、改造和資金成本。
引用孫子兵法開篇的第一句話“兵者，國之大事，死生之地，存亡之道，不可不察也”。是否擁抱亦是如此。
本篇文章主要是整體介紹，不涉及過多技術實現細節，如果各位對哪方面感興趣可以在文末留言，后續我們的技術大牛輸出相關技術細節文章。
?
- EOF -
想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信
申請備注（姓名+公司+技術方向）才能通過哦！
技術人成長精彩文章推薦
阿里高級技術專家宋意：平凡人在阿里十年的成長之旅
RocketMQ 大神丁威親述參與開源社區的方式
多隆：從工程師到阿里巴巴合伙人
為什么說IT科技公司應該留住35歲員工？
工程師的基本功是什么？如何練習？聽美團技術大咖怎么說
美團技術專家云鵬:寫給工程師的十條精進原則!
找CTO杜仲：再談中年危機和應對策略
阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話
Erik Dietrich：二十年的編程，教會我的五件事！
支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路
Mobvista首席架構師蔡超：工作感悟之失敗與成功，我的8點總結
奈學教育CEO孫玄：成為一個有情懷的工程師，我的12點思考
Netstars CTO陳斌：架構師的成長之路
阿里技術專家麒燁：修煉測試基本功
左耳朵耗子：程序員如何把控自己的職業？
阿里6年，我的技術蛻變之路！
程序員管理思維修煉，只需要反復閱讀本篇
“教授”洪強寧和他穿越的技術江湖
大神手把手教你投身技術18年而沒有中年危機的秘訣
阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽
CTO 技術管理的“三板斧”
技術管理者必備管理模板
張一鳴：優秀年輕人的五個特點
技術團隊的工程師文化：效率與價值
美團大咖：程序員35歲前應做好的技術積累
史海峰：萬字長文剖析技術人如何成長
? ?END ? ?? #技術人必備#點個在看，讓更多人看見
總結
以上是生活随笔為你收集整理的哪吒：猪八戒十年DevOps演进之路的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Depth-aware CNN
- 下一篇： pytorch自定义数据集DataLod