從DevOps到Cloud Native，應用上雲姿式全解鎖

本文由網易雲 發佈

做者：林帆

序文

伴隨着IaaS、PaaS等雲端基礎設施技術的成熟，「應用上雲」成爲許多企業軟件部門的心頭大事。經過把傳統軟件系統搬到雲上，一方面可讓業務方得到更多的資源靈活性，另外一方面也能夠緩解運營方的成本壓力，讓硬件資源再也不成爲阻礙流量和業務增加的障礙。上雲這件看起來輕鬆的事，其實倒是一項系統性的工程。只有到真正作起來時候纔會發現一地雞毛的問題，且不說技術方面引入的變化，組織部門隔閡、開發流程陳舊、配套工具落後、人員意識保守...隨時冒出來情況，足以讓這個許多人最初覺得只是改改架構從新部署的工做變得複雜度遠超預期。

特別是在早幾年時候，「雲原生應用」的概念比較模糊，應用上雲到底要作哪些事情並無過權威明確的定義。雖然有Google、Facebook和許多國內外互聯網企業總結出的案例，但都不具備普適性，一些規模不大的企業照搬照抄效仿，試圖一步到位，結果落得邯鄲學步的下場。從這個角度來看，網易雲出品的《雲原生應用架構實踐》的確是一本可讓人眼前一亮的書，它針對互聯網應用前期拼靈活、中期拼增加、後期拼穩定的特色，明確的指出了處於不一樣規模和時期的企業，實施上雲策略應該徹底不一樣，並針對三種典型的發展階段闡述了企業應該採用的實踐和轉型途徑。

圖片來自互聯網

從DevOps到Cloud Native

運用「雲原生應用」架構的一條很重要原則是：最大化雲對業務的價值提高。提到這個大概很容易令人聯想到另外一個如今一樣很火的詞「DevOps」。

雲計算的普及將昂貴的基礎設施資源變成自來水那樣即取即得、「稱量」計費的同時，也帶來了交付協助模式的改變。計算資源變爲人人均可以經過API和自助服務輕易得到，開發團隊得到了極大的自主性，運維團隊的工做也變得加聚焦和高效。在一些成熟的互聯網企業中的開發與運維邊界開始變得再也不那麼清晰。在這樣的環境下，比利時諮詢師Patrick Debois受到Flickr公司實踐的啓發，於2009年提出了DevOps理念。要早於Heroku創始人Adam Wiggins於2012年提出的The Twelve-Factor App宣言，而這個宣言提倡的實踐後來造成了Cloud Native架構的基礎。

能夠說，DevOps和Cloud Native都是在雲基礎設施的背景裏誕生的。二者所提倡的思想也有許多類似性，例如，DevOps從端到端交付效率的角度着手，提倡全局優化，減小跨團隊協做摩擦，提倡全功能團隊的組織結構，促使了微服務實踐的出現。而微服務的架構形式偏偏也是Cloud Native實踐中所提倡的一種可以充分發揮雲端基礎設施能力的架構模式。相似的例子還有提倡服務能力API化、交付流程自動化和可視化等等。

從更高的層次來看。DevOps關注在流程和協作方面的改進，順便引入了一些技術工具手段；而Cloud Native本來關注的就是架構的設計和對雲基礎設施的利用，但也涉及到了流程和工具。因此，與其撇清二者的關係，不如將Cloud Native看做是DevOps在架構領域的延伸。

初創企業的雲原生架構

許多初創企業選擇採用雲平臺來發布本身的應用，並不是是因爲這些雲提供很好的擴展性、開放性，或是豐富的功能，而僅僅是出於平臺的具備精確計費和穩定、可靠、易用等「高性價比」的特質。處於這個階段的企業一般只須要不多的服務器實例，以及簡單好用的架構，無需劃分組件，所以也不存在集成的煩惱。

在這樣的企業中使用複雜的交付工具和流程無異於用牛刀殺雞。我曾在一個短暫的小型項目當中犯過這樣的經驗性錯誤，那是一個十分簡單的Web服務，出於習慣，我煞有其事地爲項目設計了自動化的發佈流水線：構建、打包、發佈測試環境、發佈線上環境。全部東西部署在一個雲主機上，用容器隔離，測試環境和線上環境只是用了不一樣的端口，一切運轉良好。直到有一天服務器修改了密碼，運行在容器裏的Jenkins服務沒法鏈接上主機端口，不停打印錯誤日誌，很快把整個主機磁盤所有寫滿。好在問題發生在工做時間，被及時發現，沒有致使什麼損失。這件事對我啓發並不是是使用流水線不對，而是咱們把注意力放在了作一堆自動化的東西，卻沒有利用雲平臺把最該作的事先作好，好比說監控。

雲端架構對於初創企業的最大價值在於它能簡化運維，爲小項目添置專職的運維人員是一件奢侈的事，但已經疲於奔命的開發人員顯然不肯意抽出太多時間來打理線上環境的平常雜事。此時若能用好雲平臺提供的服務器監控、數據庫備份、服務健康檢查等能力，等同於將應用和雲進行了充分的互動，也就是Cloud Native設計的體現。

圖片來自互聯網

成長期企業的雲原生架構

當企業的業務模式獲得驗證，愈來愈多的訪問流量和用戶數據既是產品經理們渴望看到的業績，也是項目開發團隊面臨的巨大的考驗和挑戰。這個階段的服務複雜度到了必定規模，拆分組件是必然選擇，跨團隊的集成開始出現。同時爲了抗住更大的併發訪問壓力，服務的橫向擴展性成爲十分重要的事情。此外，服務的安全性也逐漸須要提上日程。

前面提到的十二要素（The Twelve-Factor App）原則如今開始發揮做用，這一階段是雲基礎設施最能體現價值的階段，也是在網絡上充斥的大量介紹Cloud Native實踐文章所假設的業務規模狀態。爲了協調和可視化團隊之間的交付進度，一般須要引入持續集成和持續交付實踐。面對衆口難調的用戶羣體，灰度發佈和A/B測試是一般會採用的局部試錯手段。監控依然是必不可少的主題，更全面、更準確及時的故障事件通知是保障服務規模化的關鍵。服務數目愈來愈多，日誌的管理也是要被提到檯面上的事情，經過分析業務的日誌，還能對用戶行爲和系統潛在問題進行更早的預測。天天遲早波盪起伏的流量每每也須要大規模的服務擴縮容。同時，更多的數據庫、更多的消息中間件也帶來了更多的平常管理工做。這些林林總總的問題，若是要讓項目團隊本身重頭設計解決方案，不知要作到猴年馬月。

處於成長期的企業，充分發揮雲所帶來的平臺優點，意味着調用一個API就能實現服務器存儲容量的變動，一個CPU過載的告警就可以馬上觸發新節點的建立、初始化和集羣的擴容，零維護工做量的高效消息隊列，零管理成本的多副本高可用數據庫。一方面將應用設計成可以充分利用雲端集成設施能力、具有水平擴展條件、可以編排部署的服務組；另外一方面儘可能避免在基礎設施能力上重複造輪子，利用雲平臺簡化總體架構的複雜度。這些Cloud Native因素也是許多互聯網產品成功的外在保障和內在動力。

穩按期企業的雲原生架構

可以真正經受市場的打磨進入穩按期的企業和產品並很少見，一旦積累到足夠多的粘性用戶，跨過產品增加期的鴻溝，就彷彿駛入了一片代表平靜但實則暗流涌動的深海。這些可以存活下來的互聯網產品一般都是已經深深植根於Cloud Native實踐的，不論他們是否有主動意識到Cloud Native的存在：沒有一個龐大到幾千人的團隊可以不依賴平臺和雲，或是不採用先進的交付流程實踐，徹底聽任開發人員重頭實現全部基礎服務、採用小做坊式的簡單粗暴發布流程可以把產品作成功的。

這些企業所面臨的問題再也不是如何使用Cloud Native，而是如何更好地利用雲的能力將在現有業務領域上的優點從1到100的複製到其餘的領域上，以得到更大的成功。所以不斷的組織重組、尋找創新的突破口都是司空見慣之事。微服務架構是當下許多進入穩按期的企業正在探索的方向，經過微服務的拆分，特別是基於領域驅動設計這樣的先進實踐，可以將企業的技術架構與業務架構更好的匹配，爲未來可能發生的業務領域擴張提供信心和保障。

在這個階段，資金充沛的企業會開始考慮自建數據中心，經過前期的一次性投入，從更長遠的時間跨度裏節約成本。兩地三中心、主備或者多活容災等問題開始提入議程。接下來，在這些數據中心之上構建本身的定製化私有云平臺，繼續更高級的基於雲的交付實踐探索。也有些企業依然會選擇繼續在公有云（易小云：別忘了專屬雲，本質也是公有云，但私密性、定製性更強）擴張本身的業務，或者將二者結合，造成混合雲的架構。這種應用與雲高度融合的實踐算得上是Cloud Native的一種終極形態。

圖片來自互聯網

總結

當你們都還在吵吵嚷嚷着要應用上雲的時候，有這麼一羣人，他們靜下心來將本身在雲端開發的各類實踐沉澱下來，匯聚成了《雲原生應用架構實踐》這本十分精彩Cloud Native枕邊書。相信它能陪伴你們的技術成長之路，邁過互聯網產品的增加鴻溝，走向Cloud Native的康莊大道。

做者簡介：林帆，DevOps和容器技術諮詢師，目前就任於ThoughtWorks，從事軟件開發運維諮詢以及社區推廣工做，在容器規模化運維方面有豐富經驗。StuQ特約課程講師，著有《CoreOS實踐之路》一書，並在CSDN、InfoQ等多家業內媒體發表有許多相關領域文章。

瞭解 網易雲 ：

網易雲官網：www.163yun.com/

新用戶大禮包：www.163yun.com/gift

網易雲社區：sq.163yun.com/