如果你覺得這次峰會和開發人員一點關係沒有，那你就大錯特錯了。因為DevOps就是以開發為主導的自動化運維，而DevOps已經在BAT及各大企業成功落地，這意味我們開發需要接管一些運維工作，來使得專案部署進度加快。

前言

不得不說，這些很多企業很大一部分都是為了DevOps落地而來，我們都收穫滿滿。直到我參加這次峰會，我才發現自己對自動化運維的天賦。我從未想過，把自己對硬體研究+java開發經驗有機結合到一起，就是DevOPs。在我公司近幾個月裡，我對整個開發架構進行了重大的調整，的罪了一些人，現在想想才知道這一切都是對的，我圍繞著的正是DevOps，當時見識有限，不知道有這個詞。
按我的理解，Dev是開發，Ops是部署，之前是運維在部署，而在DevOps的理念下，是開發參與部署。

開篇

可能你會覺得很奇怪，開發幹嘛要干涉運維的工作。可是你仔細想一下，我們專案從持久化構建，到部署生產環境，中間有多少系統環境、版本部署控制的問題。我們曾多少次和運維交涉，一起查問題，而說實話，我們並不懂得很多運維知識。
可能還在猶豫為什麼讓開發瞭解運維，其實我想說的是，部分開發參與自動化部署專案開發還是很有意義的。
在現場，阿里巴巴的DevOps虛擬小組負責人告訴我們，他們經過DevOps培訓，不斷加強開發對部分運維工作的瞭解，使得專案上線速度更快，週期更短。

題外話

昨天，是CNUTCon全球運維技術大會的第一天，我發表的了一篇juejin.im/post/59b508…
文章，但是效果不是很好，關注度很低，可能是我沒寫好，也可能是大家覺得運維跟自己沒有關係。
我也反思了一些，換個角度去介紹這個大會實錄。
我們公司在過去的半年，重點做了：

• 開發自動化運維war包
• 使用docker容器
• 封裝image映象
• 抽取image或war包內的狀態，使得專案無狀態
• 利用環境變數解決測試環境、生產環境配置問題
• 採用jenkins自動化構建
• 統一開發及部署流程，統一開發規則
  等

這些在本次大會中，多多少少都有介紹，當然實現功能以及穩定性肯定比我做的要多的多，但至少，我的思路是對的。下面一起聊聊大會第二天的收穫。

京東物流系統自動化運維平臺技術揭密

早就聽說京東的專案執行在15萬docker容器之上，應用依賴極為複雜，今天一聽，果然名不虛傳啊。

京東運維選型

• Puppet
• Saltstack
• Chef
• Ansible
  因為最終京東方面比較熟悉java，所以排除了Puppet、Chef，而因為Ansible較為基礎不易擴充套件，最終選了salt。

對於java開發工程師，我想spring、mybatis太熟悉不過了，以後去京東應聘可多一條職位了哦。
Drools主要是一個規則引擎；Mvel是一個模版引擎；activiti是一個開源的工作流框架。

總體架構圖還是比較清晰的，關於vpn自然是構建內網環境，據京東老師介紹，他們全網的伺服器ip都是預分配的，我想可以理解為所有的機器在一個內網下，那在不同區域，應該是通過vpn聯通吧。

京東抽取了很多後設資料，當然主要是為了解決“配置中心”的問題，在本次大會中，阿里巴巴成功的一次又一次炫耀了他們的強大的配置中心，會上，老師說他們的專案在不同的環境就是一套，但是如war等自動可智慧識別自己所在環境載入不同配置。會後，我找阿里的天貓互動架構師劉雄昌（花名：邵雍）聊了這個智慧識別，原來他們是基於一個域名，在不同網路下，給域名指向不同的ip，來讀不同的配置檔案。
當然，搜狗郭理勇老師也開了一篇《搜狗配置中心架構的演化與實踐》，下文詳細講。

京東的規則引擎，主要是解決不同機器部署不同應用的問題，他還支援yml檔案。

京東的自動配置基於模版引擎+環境變數實現專案快速部署。

阿里一鍵建站技術解密

阿里的高階技術專家謝吉寶老師給我們介紹了阿里的一鍵建站技術，剛開始我還以為一鍵建站是阿里雲裡的那種為企業一鍵建網站的功能，後來才知道，我太天真了，人家這個可強大的多啊。
那麼什麼是一鍵建站呢，簡單的說，就是快速部署一整套網站，包含所有模組，支援異地容災、流量切換。
那麼效果如何呢，舉個例子，阿里剛開始建一套完整的系統（建造了一個單元專案），需要200人月，相當於100個人幹了2個月；第二階段用了100人月；而現在只需要8個小時，2-3個人參與。

現階段成功

• 支援混合雲架構
• 覆蓋全生命週期
• 過程全自動化
• 8小時內全交付弓丨流1%% , 2天迴歸，1天壓測驗證
• 邊壓邊彈
• 快上快下
• 非電商大促場景的中介軟體環境快速交付

看到阿里的一次部署，全是綠色，心裡滿滿的羨慕啊，一整個單元，阿里能做到全國內任一地點快速部署。

騰訊包管理系統演進

其實，我們公司也做了包管理，當然了那是基於nexus開源框架，之前有介紹過
juejin.im/post/59964f…
有興趣可以看看，快速實現私有maven、docker、npm、gradle私服倉庫。

騰訊的包管理演進

我覺得，對於中小公司使nexus可基本解決問題。

微服務場景下的Serverless架構實踐

lambada最大的特點就是按計算cpu消耗時間來扣費，成本節約幾十倍啊。

並支援高可用自動擴容

看了這個圖，跟我們公司還是比較相似的，流程是類似，但具體實現有些差異。

lambada限制：
資源 限制
記憶體 128M-1536M
臨時磁碟儲存 512M
每個請求最大執行時間 300 秒
request/response body size 6MB
部署包大小 50MB
解壓後的部署包大小 250MB

天貓DevOps轉型實踐

據說在2016年，阿里成立了一個DevOps虛擬小組，為什麼叫虛擬小組呢，因為這個小組裡的成員跨越5個大團隊，15個壯丁，每個人都在做自己事的同時，來處理DevOps工作。當然這些工作會計入kpi，算在績效內。

取消掉應用運維崗位

開發轉運維

經過16年3次嘗試的轉型，不斷DevOps培訓後開許可權，稽核流程急速提高。

逐步交接運維任務，捨棄掉pe的工作，會後，和劉老師交流得知，pe去做更底層、更有意義的事情了。

當然阿里還解決了持續互動-程式碼快速生效問題，主要想辦法利用熱更新技術實現批量預編譯、熱替換，來提高編譯速度。

既然要部署，尤其中介軟體為tomcat，部署後得重啟服務，而重啟服務會中斷服務。阿里怎麼解決呢，採用藍綠部署，先把流量切換到B環境，然後更新測試A環境，部署成功，通過健康檢查再切換回原環境。

阿里還在做自愈模組，就是本次大會重點AIOps了，當然這個過程，目前仍需要人去處理，並沒有完全交由機器。

搜狗配置中心架構演化與實踐

搜狗的配置中心和阿里的配置中心，都是為了除去一些專案狀態的問題。雖然呢，和阿里相比，搜狗有些精簡，但是對於我們中小心公司，搜狗這一套實現起來的確極為簡單。

支援各類配置檔案，據我和搜狗郭理勇老師會後交流，得知，他們支援各類配置檔案，尤其是java的maven工程，大部分class目錄下的配置檔案都可以載入並更新。起初，我不太明白具體的配置檔案，是如何達到秒級送達，然後他跟我解釋說，配置變更是以訂閱者的模式去傳送配置變更訊息，僅僅是一條訊息，而載入配置需要通過http去拉取。在war包啟動時，他們新加了一個listen，這個listen會去比較配置中心的配置檔案，然後拉取；如果配置發生變化，則在訊息回撥裡處理變更邏輯。

當然搜狗的配置中心也是使用了nginx負載均衡，支援水平擴充套件，所以效能上、架構上都高可用。

在看看搜狗的部署，統一部署，載入不同配置，一個image或者一個war解決了所有環境的部署，無需將配置檔案寫入war或image達到高效可持續整合。剛好，目前我也在處理這一塊，遇到的問題，主要是組織結構上的問題，各個專案經理的不配合。在技術上，這條路，值得每個公司學習，借鑑，無狀態專案，使部署更快、更穩定。

最後

今天17點20在上海聽完這次大會，就急忙忙的回南京，大雨淋漓，晚上9點多才到家。現在趕著釋出這一篇文章，時間有限，明天還得上班，我想早點休息了。後面，我會給大家帶來關於本次活動的更多分享，謝謝大家。