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

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

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

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

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

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

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

云計算的普及將昂貴的基礎(chǔ)設(shè)施資源變成自來水那樣即取即得、“稱量”計費的同時，也帶來了交付協(xié)助模式的改變。計算資源變?yōu)槿巳硕伎梢酝ㄟ^API和自助服務(wù)輕易獲得，開發(fā)團(tuán)隊獲得了極大的自主性，運維團(tuán)隊的工作也變得加聚焦和高效。在一些成熟的互聯(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架構(gòu)的基礎(chǔ)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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