摘要：此文已由作者林帆授權網(wǎng)易云社區(qū)發(fā)布。好在問題發(fā)生在工作時間，被及時發(fā)現(xiàn)，沒有導致什么損失。此外，服務的安全性也逐漸需要提上日程。這種應用與云高度融合的實踐算得上是的一種終極形態(tài)。

此文已由作者林帆授權網(wǎng)易云社區(qū)發(fā)布。

歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術產(chǎn)品運營經(jīng)驗。

序文
伴隨著IaaS、PaaS等云端基礎設施技術的成熟，“應用上云”成為許多企業(yè)軟件部門的心頭大事。通過把傳統(tǒng)軟件系統(tǒng)搬到云上，一方面可以讓業(yè)務方獲得更多的資源靈活性，另一方面也可以緩解運營方的成本壓力，讓硬件資源不再成為阻礙流量和業(yè)務增長的障礙。上云這件看起來輕松的事，其實卻是一項系統(tǒng)性的工程。只有到真正做起來時候才會發(fā)現(xiàn)一地雞毛的問題，且不說技術方面引入的變化，組織部門隔閡、開發(fā)流程陳舊、配套工具落后、人員意識保守...隨時冒出來狀況，足以讓這個許多人最初以為只是改改架構重新部署的工作變得復雜度遠超預期。

特別是在早幾年時候，“云原生應用”的概念比較模糊，應用上云到底要做哪些事情并沒有過權威明確的定義。雖然有Google、Facebook和許多國內(nèi)外互聯(lián)網(wǎng)企業(yè)總結出的案例，但都不具有普適性，一些規(guī)模不大的企業(yè)照搬照抄效仿，試圖一步到位，結果落得邯鄲學步的下場。從這個角度來看，網(wǎng)易云出品的《云原生應用架構實踐》的確是一本可以讓人眼前一亮的書，它針對互聯(lián)網(wǎng)應用前期拼靈活、中期拼增長、后期拼穩(wěn)定的特點，明確的指出了處于不同規(guī)模和時期的企業(yè)，實施上云策略應該完全不同，并針對三種典型的發(fā)展階段闡述了企業(yè)應該采用的實踐和轉(zhuǎn)型途徑。

圖片來自互聯(lián)網(wǎng)

從DevOps到Cloud Native
運用“云原生應用”架構的一條很重要原則是：最大化云對業(yè)務的價值提升。提到這個大概很容易使人聯(lián)想到另一個現(xiàn)在同樣很火的詞“DevOps”。

云計算的普及將昂貴的基礎設施資源變成自來水那樣即取即得、“稱量”計費的同時，也帶來了交付協(xié)助模式的改變。計算資源變?yōu)槿巳硕伎梢酝ㄟ^API和自助服務輕易獲得，開發(fā)團隊獲得了極大的自主性，運維團隊的工作也變得加聚焦和高效。在一些成熟的互聯(lián)網(wǎng)企業(yè)中的開發(fā)與運維邊界開始變得不再那么清晰。在這樣的環(huán)境下，比利時咨詢師Patrick Debois受到Flickr公司實踐的啟發(fā)，于2009年提出了DevOps理念。要早于Heroku創(chuàng)始人Adam Wiggins于2012年提出的The Twelve-Factor App宣言，而這個宣言提倡的實踐后來形成了Cloud Native架構的基礎。

可以說，DevOps和Cloud Native都是在云基礎設施的背景里誕生的。兩者所提倡的思想也有許多相似性，例如，DevOps從端到端交付效率的角度著手，提倡全局優(yōu)化，減少跨團隊協(xié)作摩擦，提倡全功能團隊的組織結構，促使了微服務實踐的出現(xiàn)。而微服務的架構形式恰恰也是Cloud Native實踐中所提倡的一種能夠充分發(fā)揮云端基礎設施能力的架構模式。類似的例子還有提倡服務能力API化、交付流程自動化和可視化等等。

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

初創(chuàng)企業(yè)的云原生架構
許多初創(chuàng)企業(yè)選擇采用云平臺來發(fā)布自己的應用，并非是由于這些云提供很好的擴展性、開放性，或是豐富的功能，而僅僅是出于平臺的具有精確計費和穩(wěn)定、可靠、易用等“高性價比”的特質(zhì)。處于這個階段的企業(yè)通常只需要很少的服務器實例，以及簡單好用的架構，無需劃分組件，因此也不存在集成的煩惱。

在這樣的企業(yè)中使用復雜的交付工具和流程無異于用牛刀殺雞。我曾在一個短暫的小型項目當中犯過這樣的經(jīng)驗性錯誤，那是一個十分簡單的Web服務，出于習慣，我煞有其事地為項目設計了自動化的發(fā)布流水線：構建、打包、發(fā)布測試環(huán)境、發(fā)布線上環(huán)境。所有東西部署在一個云主機上，用容器隔離，測試環(huán)境和線上環(huán)境只是用了不同的端口，一切運轉(zhuǎn)良好。直到有一天服務器修改了密碼，運行在容器里的Jenkins服務無法連接上主機端口，不停打印錯誤日志，很快把整個主機磁盤全部寫滿。好在問題發(fā)生在工作時間，被及時發(fā)現(xiàn)，沒有導致什么損失。這件事對我啟發(fā)并非是使用流水線不對，而是我們把注意力放在了做一堆自動化的東西，卻沒有利用云平臺把最該做的事先做好，比如說監(jiān)控。

云端架構對于初創(chuàng)企業(yè)的最大價值在于它能簡化運維，為小項目添置專職的運維人員是一件奢侈的事，但已經(jīng)疲于奔命的開發(fā)人員顯然不愿意抽出太多時間來打理線上環(huán)境的日?，嵤隆４藭r若能用好云平臺提供的服務器監(jiān)控、數(shù)據(jù)庫備份、服務健康檢查等能力，等同于將應用和云進行了充分的互動，也就是Cloud Native設計的體現(xiàn)。

圖片來自互聯(lián)網(wǎng)

成長期企業(yè)的云原生架構
當企業(yè)的業(yè)務模式得到驗證，越來越多的訪問流量和用戶數(shù)據(jù)既是產(chǎn)品經(jīng)理們渴望看到的業(yè)績，也是項目開發(fā)團隊面臨的巨大的考驗和挑戰(zhàn)。這個階段的服務復雜度到了一定規(guī)模，拆分組件是必然選擇，跨團隊的集成開始出現(xiàn)。同時為了抗住更大的并發(fā)訪問壓力，服務的橫向擴展性成為十分重要的事情。此外，服務的安全性也逐漸需要提上日程。

前面提到的十二要素（The Twelve-Factor App）原則現(xiàn)在開始發(fā)揮作用，這一階段是云基礎設施最能體現(xiàn)價值的階段，也是在網(wǎng)絡上充斥的大量介紹Cloud Native實踐文章所假設的業(yè)務規(guī)模狀態(tài)。為了協(xié)調(diào)和可視化團隊之間的交付進度，通常需要引入持續(xù)集成和持續(xù)交付實踐。面對眾口難調(diào)的用戶群體，灰度發(fā)布和A/B測試是通常會采用的局部試錯手段。監(jiān)控依然是必不可少的主題，更全面、更準確及時的故障事件通知是保障服務規(guī)?；年P鍵。服務數(shù)目越來越多，日志的管理也是要被提到臺面上的事情，通過分析業(yè)務的日志，還能對用戶行為和系統(tǒng)潛在問題進行更早的預測。每天早晚波蕩起伏的流量往往也需要大規(guī)模的服務擴縮容。同時，更多的數(shù)據(jù)庫、更多的消息中間件也帶來了更多的日常管理工作。這些林林總總的問題，如果要讓項目團隊自己重頭設計解決方案，不知要做到猴年馬月。

處于成長期的企業(yè)，充分發(fā)揮云所帶來的平臺優(yōu)勢，意味著調(diào)用一個API就能實現(xiàn)服務器存儲容量的變更，一個CPU過載的告警就能夠立刻觸發(fā)新節(jié)點的創(chuàng)建、初始化和集群的擴容，零維護工作量的高效消息隊列，零管理成本的多副本高可用數(shù)據(jù)庫。一方面將應用設計成能夠充分利用云端集成設施能力、具備水平擴展條件、能夠編排部署的服務組；另一方面盡量避免在基礎設施能力上重復造輪子，利用云平臺簡化整體架構的復雜度。這些Cloud Native因素也是許多互聯(lián)網(wǎng)產(chǎn)品成功的外在保障和內(nèi)在動力。

穩(wěn)定期企業(yè)的云原生架構
能夠真正經(jīng)受市場的打磨進入穩(wěn)定期的企業(yè)和產(chǎn)品并不多見，一旦積累到足夠多的粘性用戶，跨過產(chǎn)品增長期的鴻溝，就仿佛駛入了一片表明平靜但實則暗流涌動的深海。這些能夠存活下來的互聯(lián)網(wǎng)產(chǎn)品通常都是已經(jīng)深深植根于Cloud Native實踐的，不論他們是否有主動意識到Cloud Native的存在：沒有一個龐大到幾千人的團隊能夠不依賴平臺和云，或是不采用先進的交付流程實踐，完全放任開發(fā)人員重頭實現(xiàn)所有基礎服務、采用小作坊式的簡單粗暴發(fā)布流程能夠把產(chǎn)品做成功的。

這些企業(yè)所面臨的問題不再是如何使用Cloud Native，而是如何更好地利用云的能力將在現(xiàn)有業(yè)務領域上的優(yōu)勢從1到100的復制到其他的領域上，以獲得更大的成功。因此不斷的組織重組、尋找創(chuàng)新的突破口都是司空見慣之事。微服務架構是當下許多進入穩(wěn)定期的企業(yè)正在探索的方向，通過微服務的拆分，特別是基于領域驅(qū)動設計這樣的先進實踐，能夠?qū)⑵髽I(yè)的技術架構與業(yè)務架構更好的匹配，為將來可能發(fā)生的業(yè)務領域擴張?zhí)峁┬判暮捅Ｕ稀?/p>

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

圖片來自互聯(lián)網(wǎng)

總結
當大家都還在吵吵嚷嚷著要應用上云的時候，有這么一群人，他們靜下心來將自己在云端開發(fā)的各種實踐沉淀下來，匯聚成了《云原生應用架構實踐》這本十分精彩Cloud Native枕邊書。相信它能陪伴大家的技術成長之路，邁過互聯(lián)網(wǎng)產(chǎn)品的增長鴻溝，走向Cloud Native的康莊大道。

作者簡介：林帆，DevOps和容器技術咨詢師，目前就職于ThoughtWorks，從事軟件開發(fā)運維咨詢以及社區(qū)推廣工作，在容器規(guī)?；\維方面有豐富經(jīng)驗。StuQ特約課程講師，著有《CoreOS實踐之路》一書，并在CSDN、InfoQ等多家業(yè)內(nèi)媒體發(fā)表有許多相關領域文章。

網(wǎng)易云為您提供容器服務，歡迎點擊免費試用。

文章來源： 網(wǎng)易云社區(qū)