本文由網易云 發布

作者：林帆

序文

伴隨著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/