當(dāng)紅架構(gòu)Cloud Native，怎么搭建才能成為上云助攻手？

如何讓云成為業(yè)務(wù)成功的基石而不是障礙，是技術(shù)團隊需要不斷思考的問題，Cloud-Native正是一種讓業(yè)務(wù)技術(shù)架構(gòu)向云而生，充分利用云特性的技術(shù)理念與方法論。在近期網(wǎng)易云技術(shù)布道系列活動中，網(wǎng)易云基礎(chǔ)服務(wù)總經(jīng)理陳諤帶來了如何從0到1實踐Cloud-Native的精彩分享。

一、什么是Cloud Native？

說到Cloud Native，國內(nèi)大多數(shù)都翻譯成云原生，就是讓云成為成功的基石，而不是障礙。陳諤對于為什么要實現(xiàn)云原生應(yīng)用深有體會，網(wǎng)易從2012年開始實施云化的戰(zhàn)略，當(dāng)?shù)谝话嬖朴嬎闫脚_建好的時候，開始引導(dǎo)公司的項目逐漸向云遷移。這個過程中就遇到了一個問題：用上云之后，并沒有變得效率奇高，甚至有些項目的效率反而有所下降，大家都有很多抱怨。

從那時陳諤就有一個想法，云計算怎樣才能成為公司和開發(fā)團隊成功的基石，而不是用上云之后給你制造麻煩。他認(rèn)為要做到這一點首先要理解云的優(yōu)勢，規(guī)避云的弱點；另一方面要充分利用云的各層能力，幫助你去成功。所以云原生就是采用適合云端的軟件架構(gòu)和研發(fā)模式去做這個事情。

二、如何實踐云原生？

關(guān)于如何實踐云原生，陳諤為大家分享了一些建議。假設(shè)大家不是類似BAT這樣規(guī)模的公司，或者有非常強大的IT團隊，在選擇技術(shù)路線時，陳諤建議大家使用公有云，為什么呢？

1、使用公有云

彈性

首先，使用公有云起步的成本非常低，不需要你去租機房、買物理機，每個月幾百塊錢就可以起步了。如果你成功了，在爆發(fā)性增長時，公有云也有足夠大的資源彈性幫助你從一臺Scale到幾百臺，而不需要臨時去買服務(wù)器。

網(wǎng)絡(luò)質(zhì)量

另一方面，由于公有云的規(guī)?；?yīng)，網(wǎng)絡(luò)質(zhì)量是自建不可比擬的：

有些公有云出入口的帶寬很大，甚至有些互聯(lián)網(wǎng)大廠的公有云平臺，用的基礎(chǔ)設(shè)施跟公司整體業(yè)務(wù)是一體的；

帶寬大的另一個好處是可以抵御DDoS和CC攻擊；

其次，公有云有更強的排障能力。國內(nèi)的國情，網(wǎng)絡(luò)故障是非常難以排查的，需要有專門的IT團隊才能做好。

Managed Cloud Service

云計算有數(shù)據(jù)庫、中間件這些服務(wù)，并且不需要你去關(guān)注高可用部署、故障恢復(fù)、擴縮容等系統(tǒng)層面的運維，操作系統(tǒng)內(nèi)核級掌控、中間件源碼級維護也均由云提供商負(fù)責(zé)，并且有明確的SLA保障。

高可用保障

此外，云計算可以幫你做高級別的高可用保障。日常的高可用保障，比如雙機熱備也好，冷備也好，都比不過公有云提供的多可用區(qū)的保障。云的多可用區(qū)至少是IDC級別的，在一個可用區(qū)內(nèi)就像一張大網(wǎng)一樣，至少保證三層的連接，保證你的業(yè)務(wù)都是互通的，整體架構(gòu)不用考慮跨機房的問題。

云還有多Region的保障，有一些公司會做異地多活的架構(gòu)，當(dāng)然這對業(yè)務(wù)的侵入性是很大的，但至少可以用多Region的設(shè)施，來做數(shù)據(jù)的災(zāi)備。

另外，云的進化速度很快，會持續(xù)地更新，現(xiàn)在大多數(shù)都是基于Linux的技術(shù)棧，可能會不時地出現(xiàn)bug或安全漏洞，如果自己去跟進是非常困難的，公有云一般都會有專業(yè)的團隊，及時跟進和修復(fù)這些安全問題，又省下了用戶一筆人員開銷。

公有云的取舍

當(dāng)然，公有云要支持這么大規(guī)模的用戶，本身有一定的取舍。

1）Design For Failure：公有云傾向于更快失?。ㄓ绊懛秶芸兀?、更快恢復(fù)。如果你用的是物理機，出現(xiàn)問題時你會關(guān)注這個物理機是不是還“活著”。而公有云如果發(fā)現(xiàn)一臺機器掛了，會直接進行服務(wù)遷移和重啟，因為公有云本身有SLA的承諾，為了保證系統(tǒng)的魯棒性，會更快地把這些疑似故障的節(jié)點排除掉。

2）由于公有云這樣的特性，日常業(yè)務(wù)必須結(jié)合公有云能力實施高可用架構(gòu)：

一方面以可用域為基礎(chǔ)，實現(xiàn)高可用；

另一方面，將數(shù)據(jù)狀態(tài)和業(yè)務(wù)邏輯分離，如果業(yè)務(wù)被遷移走了，只要掛上原來的盤就可以恢復(fù)了；

節(jié)點可重啟或重建。

3）Design For Scale：虛擬化性能稍弱于物理機，公有云更追求交付的性能指標(biāo)的穩(wěn)定，避免租戶業(yè)務(wù)間的影響，支持業(yè)務(wù)做Scale。對于開發(fā)者來說：

一方面，要知道你采購的磁盤、網(wǎng)絡(luò)能夠提供的性能是什么，根據(jù)這些QoS指標(biāo)去做容量的規(guī)劃；

另一方面要基于負(fù)載均衡、集群管理等能力去做Scale Out，而不是讓機器規(guī)格越變越大。

2、項目工程化

除了上面提到的基礎(chǔ)設(shè)施，在項目的工程化方面，陳諤也為大家?guī)砹艘恍﹩⑹尽ＫJ(rèn)為項目工程化是研發(fā)協(xié)作與云端運維的基礎(chǔ)，也是很多團隊在起步時可能會忽視的事情。項目的整個流程中，開發(fā)、測試、發(fā)布的每一步都涉及到公司內(nèi)角色之間的協(xié)作，如果這些步驟做得不流暢，每一個環(huán)節(jié)的銜接非常困難，效率就會變的非常低，所以項目工程化是對高效構(gòu)建、發(fā)布、運行流程的支持。

合理的版本控制工具

那么，如何做到項目的工程化呢？首先要選擇合理的版本控制工具與策略：

Git是社區(qū)和業(yè)界公認(rèn)的一個比較好的工具；

建議每個應(yīng)用采用單一的Codebase（12Factors-1: Codebase），把整個開發(fā)，構(gòu)建，發(fā)布的流程串聯(lián)起來，不至于拉下一個base還要決定這里面的代碼哪一部分要拿去構(gòu)建。

常見的版本控制策略包括：

基于Merge的多分支策略，這種模式和多人協(xié)作的方式是匹配的，可以看到大家協(xié)作產(chǎn)生的代碼從分支到合并的過程，但是分支很多也造成了管理的復(fù)雜度很高；

如果團隊能切割得比較小，功能比較集中的話，可以采用基于Rebase的單Master分支策略，它沒有Merge信息，管理起來比較簡單。

基于配置的依賴管理

然后可以去做基于配置的依賴管理：

聲明依賴（Maven等），而不是把你的軟件包全拷貝在代碼庫下面，實現(xiàn)自動構(gòu)建

建議聲明所有的依賴，包括運行環(huán)境的初始化，不隱式依賴系統(tǒng)庫（12Factors-2: Dependencies）

接下來要合理拆分模塊，可以按業(yè)務(wù)拆分模塊，同時實現(xiàn)公共代碼的模塊化。

使用Docker實現(xiàn)環(huán)境一致性

之前在網(wǎng)易，對穩(wěn)定性要求很高的產(chǎn)品，其發(fā)布流程通常都很曲折，主要原因在于環(huán)境的不一致。陳諤的建議是使用Docker實現(xiàn)環(huán)境的一致性，Docker容器完整虛擬化了Linux操作系統(tǒng)，將業(yè)務(wù)代碼與運行環(huán)境裝箱為Docker容器發(fā)布到生產(chǎn)環(huán)境，差異僅僅為外部注入的配置（如數(shù)據(jù)庫地址等），容器內(nèi)部文件在開發(fā)環(huán)境一旦發(fā)布則不再變化，從而保證開發(fā)環(huán)境與生產(chǎn)環(huán)境一致。

3、服務(wù)化的思維

工程化是做業(yè)務(wù)架構(gòu)，建立一個高效團隊的基礎(chǔ)，接下來要考慮的就是服務(wù)化的思維。微服務(wù)是當(dāng)下很流行的概念，采用微服務(wù)確實能為應(yīng)用的迭代和架構(gòu)帶來很多好處。但服務(wù)化的架構(gòu)會帶來額外的負(fù)擔(dān)，如果一個項目還處在初期階段，我們的建議則是服務(wù)化思維先于服務(wù)化架構(gòu)。

運維成本：一旦服務(wù)多了，環(huán)境搭建、故障診斷、運維的工作量都會成倍增加；

服務(wù)拆分之后，各個服務(wù)間的生命周期是不一致的，要做生命周期的分離，就需要處理更多的異常。服務(wù)間存在更多的約束，還是異步的，如依賴關(guān)系、版本，要保證消息能夠可靠地到達(dá)那里；

另一方面，還會有分布式事務(wù)的問題，雖然解決起來不難，但是會侵入你的業(yè)務(wù)。

雖然業(yè)務(wù)初期，不適合服務(wù)化，但應(yīng)該為后續(xù)的服務(wù)化做一些準(zhǔn)備，否則后面想拆分的時候會變得非常困難：

提取Service API，理解業(yè)務(wù)中的服務(wù)抽象；

數(shù)據(jù)庫設(shè)計的時候就考慮服務(wù)的劃分；

避免跨服務(wù)事務(wù)，對跨服務(wù)事務(wù)進行標(biāo)記；

如果項目發(fā)展起來，遇到的第一個問題通常是數(shù)據(jù)庫會掛掉，所以在業(yè)務(wù)初期就做分庫分表是很有必要的；

選擇事務(wù)支持更好的數(shù)據(jù)庫，如果你用缺乏事務(wù)支持的數(shù)據(jù)庫做業(yè)務(wù)的后端，當(dāng)你要做服務(wù)化拆分或分布式事務(wù)的時候，可能會比用MySQL的痛苦很多。

4、實施微服務(wù)

隨著業(yè)務(wù)的壯大，是否要采用微服務(wù)，就要去衡量微服務(wù)帶來的收益是否大于成本？

收益

控制迭代更新的影響域，而單體架構(gòu)很難評估patch的影響范圍；

加速迭代，提交代碼心里負(fù)擔(dān)小，迭代也能加快；

隔離局部故障；

防止代碼架構(gòu)層面的腐化，比如開發(fā)過程中為了趕進度，可能會把原有的架構(gòu)推倒重來。如果用微服務(wù)架構(gòu)，最多只需要將自己負(fù)責(zé)的那個模塊重新設(shè)計。

成本

更多的依賴（eg: ZooKeeper，MQ），要做一個注冊中心；

運維復(fù)雜度，幾十個服務(wù)發(fā)布更新，運維的復(fù)雜度必然會上升；

技術(shù)實現(xiàn)的侵入性，在這個過程中難免要用到一些微服務(wù)化的框架，雖然對代碼的侵入性不大，但對架構(gòu)的侵入性還是不可避免的。

降低實施成本

良好的工程化，不要給運維的工作帶來很多困難；

使用基于云端托管的PaaS服務(wù)；

使用基于云端托管的編排服務(wù)，幫你去做集群化的運維和管理的工作。

基于Kubernetes簡化微服務(wù)實施

利用基于Kubernetes的基礎(chǔ)設(shè)施可以簡化微服務(wù)，一方面Kubernetes提供了基于域名的服務(wù)發(fā)現(xiàn)：

使用VIP+域名暴露服務(wù)：對比“注冊中心”，采用域名服務(wù)具有更小的侵入性，更少的依賴

支持名稱空間隔離，簡化測試環(huán)境部署

Kubernetes還可以做基于iptables的透明RPC分發(fā)：

無需在程序中訪問注冊中心獲取成員列表進行軟負(fù)載均衡；

無需內(nèi)網(wǎng)負(fù)載均衡層次增加網(wǎng)絡(luò)開銷。

比如，服務(wù)A訪問服務(wù)B的虛擬IP VIP，利用iptables做DNAT，轉(zhuǎn)成B中的所有成員，服務(wù)A可以直接，并利用probability特性按權(quán)重分發(fā)請求，比域名做輪轉(zhuǎn)的負(fù)載均衡效果要好，因為iptables可控，域名不可控。

用Kubernetes還可以讓你獲得自動化運維能力：

自動擴縮容

自動故障處理（重試、遷移）

自動化滾動更新，通過健康檢查與滾動的配合實現(xiàn)無縫更新

還可以基于Service 抽象實現(xiàn)藍(lán)綠發(fā)布

Kubernetes以解耦的基礎(chǔ)服務(wù)層的方式提供了對服務(wù)化的支持，避免了代碼實現(xiàn)層面的耦合，通過云端托管Kubernetes服務(wù)能夠?qū)崿F(xiàn)服務(wù)化的成本大幅降低。而且Kubernetes對業(yè)務(wù)沒有侵入性，實現(xiàn)服務(wù)化的代價相對會比較小，后面業(yè)務(wù)變得非常重，需要細(xì)粒度控制時，再用到其它框架也沒有什么影響。

我們深度整合了Docker技術(shù)和Kubernetes集群編排技術(shù)，所以網(wǎng)易云中會有一個Kubernetes Master，所有租戶的業(yè)務(wù)都可以使用這個Master，不用用戶自己維護。

5、DevOps

前面講到的都是云原生相關(guān)的技術(shù)，實際上實現(xiàn)云原生還需要一些研發(fā)、運維和組織架構(gòu)上的方式調(diào)整，比如DevOps。DevOps的出現(xiàn)是為了解決運維角色與開發(fā)角色的矛盾，運維追求的是可用率優(yōu)先，而開發(fā)希望應(yīng)用能快速更新迭代。

DevOps 與微服務(wù)

微服務(wù)架構(gòu)能夠支持更高頻的迭代，降低更新迭代的風(fēng)險，這與DevOps的目標(biāo)是一致；但是微服務(wù)架構(gòu)也會給運維帶來成倍的工作量，可基于DevOps分散運維操作，而不是集中依賴少量運維角色。

實施DevOps

實施DevOps需要CI/CD、編排、故障診斷等工具鏈的支持，同時需要運維實現(xiàn)從操作到審計的職能轉(zhuǎn)換，運維工作前置，在前期和開發(fā)團隊合作。很多運維還需要開發(fā)工具，提高運轉(zhuǎn)效率。

基于DevOps工具鏈支持微服務(wù)架構(gòu)

1）Jenkins-容器-鏡像倉庫-服務(wù)編排

Pipeline as Code：實施服務(wù)化后持續(xù)集成的復(fù)雜度成倍增加，需要定義大量的流程，包含大量Jobs，以代碼的方式管理Pipeline能夠支持審計，有效管理復(fù)雜性并降低維護成本。

2）日志服務(wù)-分布式跟蹤系統(tǒng)-性能管理服務(wù)

日志服務(wù)：Kafka+ELK套件，以網(wǎng)易云為例自動完成容器日志收集，并提供訂閱接口可對接ELK。

分布式跟蹤系統(tǒng)：在微服務(wù)架構(gòu)下必須要做到與單體架構(gòu)同樣的服務(wù)請求的調(diào)用路徑跟蹤能力，才能夠有效定位故障。可參考的框架有Zipkin，需要對RPC框架等做instrumentation，在調(diào)用過程中攜帶額外的頭信息。

性能管理服務(wù)：微服務(wù)架構(gòu)下依賴關(guān)系復(fù)雜，發(fā)生性能問題時難以定位源頭及影響范圍，性能管理服務(wù)可提供調(diào)用關(guān)系拓?fù)洌皶r統(tǒng)計慢響應(yīng)及錯誤響應(yīng)，有利于發(fā)現(xiàn)性能問題與定位故障。以網(wǎng)易云為例，利用Kubernetes提供元信息，利用AOP對常用庫做instrumentation，可在無須配置及侵入代碼的情況下，自動繪制拓?fù)洌治鲂阅堋?/span>

下圖是我們內(nèi)部性能管理的拓?fù)浣貓D：

三、總結(jié)

最后，陳諤將云原生架構(gòu)實現(xiàn)的要點總結(jié)如下，希望能給云計算的用戶帶來有價值的參考：

1.使用公有云；

2.重視項目工程化；

3.項目起步時建立服務(wù)化思維，而不要急于采用服務(wù)化架構(gòu)帶來不必要的負(fù)擔(dān)；

4.實施微服務(wù)需權(quán)衡收益與成本，基于Kubernetes可簡化微服務(wù)實施；

5.DevOps能與微服務(wù)架構(gòu)良好匹配，但實施DevOps需要完善的工具鏈支持。

原文來自:DBAplus社群

免責(zé)聲明：以上內(nèi)容為本網(wǎng)站轉(zhuǎn)自其它媒體，相關(guān)信息僅為傳遞更多信息之目的，不代表本網(wǎng)觀點，亦不代表本網(wǎng)站贊同其觀點或證實其內(nèi)容的真實性。