《當(dāng)紅架構(gòu)Cloud Native，怎么搭建才能成為上云助攻手？》要點(diǎn)：
本文介紹了當(dāng)紅架構(gòu)Cloud Native，怎么搭建才能成為上云助攻手？，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

作者：陳諤,網(wǎng)易云基礎(chǔ)服務(wù)總經(jīng)理,現(xiàn)負(fù)責(zé)網(wǎng)易云計(jì)算平臺(tái)產(chǎn)品線建設(shè),對(duì)分布式系統(tǒng)設(shè)計(jì)開(kāi)發(fā)、云計(jì)算平臺(tái)系統(tǒng)架構(gòu)有一定的經(jīng)驗(yàn)和理解.近年來(lái)致力于帶領(lǐng)團(tuán)隊(duì)推進(jìn)公司開(kāi)發(fā)技術(shù)棧的標(biāo)準(zhǔn)化、工具化.

網(wǎng)易云基礎(chǔ)服務(wù)團(tuán)隊(duì)：網(wǎng)易云基礎(chǔ)服務(wù)擁有優(yōu)質(zhì)的硬件資源,經(jīng)驗(yàn)豐富的研發(fā)運(yùn)維團(tuán)隊(duì),為各類客戶提供IaaS、PaaS服務(wù).同時(shí)深度整合Docker與Kubernetes技術(shù),打造專業(yè)的容器服務(wù).

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

一、什么是Cloud Native?

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

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

二、如何實(shí)踐云原生?

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

1、使用公有云

彈性

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

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

另一方面,由于公有云的規(guī)模化效應(yīng),網(wǎng)絡(luò)質(zhì)量是自建不可比擬的：

有些公有云出入口的帶寬很大,甚至有些互聯(lián)網(wǎng)大廠的公有云平臺(tái),用的基礎(chǔ)設(shè)施跟公司整體業(yè)務(wù)是一體的；
帶寬大的另一個(gè)好處是可以抵御DDoS和CC攻擊；
其次,公有云有更強(qiáng)的排障能力.國(guó)內(nèi)的國(guó)情,網(wǎng)絡(luò)故障是非常難以排查的,需要有專門的IT團(tuán)隊(duì)才能做好.

Managed Cloud Service

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

高可用保障

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

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

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

公有云的取舍

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

1)Design For Failure：公有云傾向于更快失敗(影響范圍受控)、更快恢復(fù).如果你用的是物理機(jī),出現(xiàn)問(wèn)題時(shí)你會(huì)關(guān)注這個(gè)物理機(jī)是不是還“活著”.而公有云如果發(fā)現(xiàn)一臺(tái)機(jī)器掛了,會(huì)直接進(jìn)行服務(wù)遷移和重啟,因?yàn)楣性票旧碛蠸LA的承諾,為了保證系統(tǒng)的魯棒性,會(huì)更快地把這些疑似故障的節(jié)點(diǎn)排除掉.

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

• 一方面以可用域?yàn)榛A(chǔ),實(shí)現(xiàn)高可用；
• 另一方面,將數(shù)據(jù)狀態(tài)和業(yè)務(wù)邏輯分離,如果業(yè)務(wù)被遷移走了,只要掛上原來(lái)的盤就可以恢復(fù)了；
• 節(jié)點(diǎn)可重啟或重建.

3)Design For Scale：虛擬化性能稍弱于物理機(jī),公有云更追求交付的性能指標(biāo)的穩(wěn)定,避免租戶業(yè)務(wù)間的影響,支持業(yè)務(wù)做Scale.對(duì)于開(kāi)發(fā)者來(lái)說(shuō)：

• 一方面,要知道你采購(gòu)的磁盤、網(wǎng)絡(luò)能夠提供的性能是什么,根據(jù)這些QoS指標(biāo)去做容量的規(guī)劃；
• 另一方面要基于負(fù)載均衡、集群管理等能力去做Scale Out,而不是讓機(jī)器規(guī)格越變?cè)酱?

2、項(xiàng)目工程化

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

合理的版本控制工具

那么,如何做到項(xiàng)目的工程化呢?首先要選擇合理的版本控制工具與策略：

• Git是社區(qū)和業(yè)界公認(rèn)的一個(gè)比較好的工具；
• 建議每個(gè)應(yīng)用采用單一的Codebase(12Factors-1: Codebase),把整個(gè)開(kāi)發(fā),構(gòu)建,發(fā)布的流程串聯(lián)起來(lái),不至于拉下一個(gè)base還要決定這里面的代碼哪一部分要拿去構(gòu)建.

常見(jiàn)的版本控制策略包括：

• 基于Merge的多分支策略,這種模式和多人協(xié)作的方式是匹配的,可以看到大家協(xié)作產(chǎn)生的代碼從分支到合并的過(guò)程,但是分支很多也造成了管理的復(fù)雜度很高；
• 如果團(tuán)隊(duì)能切割得比較小,功能比較集中的話,可以采用基于Rebase的單Master分支策略,它沒(méi)有Merge信息,管理起來(lái)比較簡(jiǎn)單.

基于配置的依賴管理

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

聲明依賴(Maven等),而不是把你的軟件包全拷貝在代碼庫(kù)下面,實(shí)現(xiàn)自動(dòng)構(gòu)建
建議聲明所有的依賴,包括運(yùn)行環(huán)境的初始化,不隱式依賴系統(tǒng)庫(kù)(12Factors-2: Dependencies)

接下來(lái)要合理拆分模塊,可以按業(yè)務(wù)拆分模塊,同時(shí)實(shí)現(xiàn)公共代碼的模塊化.

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

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

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

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

• 運(yùn)維成本：一旦服務(wù)多了,環(huán)境搭建、故障診斷、運(yùn)維的工作量都會(huì)成倍增加；
• 服務(wù)拆分之后,各個(gè)服務(wù)間的生命周期是不一致的,要做生命周期的分離,就需要處理更多的異常.服務(wù)間存在更多的約束,還是異步的,如依賴關(guān)系、版本,要保證消息能夠可靠地到達(dá)那里；
• 另一方面,還會(huì)有分布式事務(wù)的問(wèn)題,雖然解決起來(lái)不難,但是會(huì)侵入你的業(yè)務(wù).

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

• 提取Service API,理解業(yè)務(wù)中的服務(wù)抽象；
• 數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候就考慮服務(wù)的劃分；
• 避免跨服務(wù)事務(wù),對(duì)跨服務(wù)事務(wù)進(jìn)行標(biāo)記；
• 如果項(xiàng)目發(fā)展起來(lái),遇到的第一個(gè)問(wèn)題通常是數(shù)據(jù)庫(kù)會(huì)掛掉,所以在業(yè)務(wù)初期就做分庫(kù)分表是很有必要的；
• 選擇事務(wù)支持更好的數(shù)據(jù)庫(kù),如果你用缺乏事務(wù)支持的數(shù)據(jù)庫(kù)做業(yè)務(wù)的后端,當(dāng)你要做服務(wù)化拆分或分布式事務(wù)的時(shí)候,可能會(huì)比用MySQL的痛苦很多.

4、實(shí)施微服務(wù)

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

收益

• 控制迭代更新的影響域,而單體架構(gòu)很難評(píng)估patch的影響范圍；
• 加速迭代,提交代碼心里負(fù)擔(dān)小,迭代也能加快；
• 隔離局部故障；
• 防止代碼架構(gòu)層面的腐化,比如開(kāi)發(fā)過(guò)程中為了趕進(jìn)度,可能會(huì)把原有的架構(gòu)推倒重來(lái).如果用微服務(wù)架構(gòu),最多只需要將自己負(fù)責(zé)的那個(gè)模塊重新設(shè)計(jì).

成本

• 更多的依賴(eg: ZooKeeper,MQ),要做一個(gè)注冊(cè)中心；
• 運(yùn)維復(fù)雜度,幾十個(gè)服務(wù)發(fā)布更新,運(yùn)維的復(fù)雜度必然會(huì)上升；
• 技術(shù)實(shí)現(xiàn)的侵入性,在這個(gè)過(guò)程中難免要用到一些微服務(wù)化的框架,雖然對(duì)代碼的侵入性不大,但對(duì)架構(gòu)的侵入性還是不可避免的.

降低實(shí)施成本

• 良好的工程化,不要給運(yùn)維的工作帶來(lái)很多困難；
• 使用基于云端托管的PaaS服務(wù)；
• 使用基于云端托管的編排服務(wù),幫你去做集群化的運(yùn)維和管理的工作.

基于Kubernetes簡(jiǎn)化微服務(wù)實(shí)施

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

• 使用VIP+域名暴露服務(wù)：對(duì)比“注冊(cè)中心”,采用域名服務(wù)具有更小的侵入性,更少的依賴
• 支持名稱空間隔離,簡(jiǎn)化測(cè)試環(huán)境部署

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

• 無(wú)需在程序中訪問(wèn)注冊(cè)中心獲取成員列表進(jìn)行軟負(fù)載均衡；
• 無(wú)需內(nèi)網(wǎng)負(fù)載均衡層次增加網(wǎng)絡(luò)開(kāi)銷.

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

用Kubernetes還可以讓你獲得自動(dòng)化運(yùn)維能力：

• 自動(dòng)擴(kuò)縮容
• 自動(dòng)故障處理(重試、遷移)
• 自動(dòng)化滾動(dòng)更新,通過(guò)健康檢查與滾動(dòng)的配合實(shí)現(xiàn)無(wú)縫更新
• 還可以基于Service 抽象實(shí)現(xiàn)藍(lán)綠發(fā)布

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

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

5、DevOps

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

DevOps 與微服務(wù)

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

實(shí)施DevOps

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

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

1)Jenkins-容器-鏡像倉(cāng)庫(kù)-服務(wù)編排

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

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

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

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

性能管理服務(wù)：微服務(wù)架構(gòu)下依賴關(guān)系復(fù)雜,發(fā)生性能問(wèn)題時(shí)難以定位源頭及影響范圍,性能管理服務(wù)可提供調(diào)用關(guān)系拓?fù)?及時(shí)統(tǒng)計(jì)慢響應(yīng)及錯(cuò)誤響應(yīng),有利于發(fā)現(xiàn)性能問(wèn)題與定位故障.以網(wǎng)易云為例,利用Kubernetes提供元信息,利用AOP對(duì)常用庫(kù)做instrumentation,可在無(wú)須配置及侵入代碼的情況下,自動(dòng)繪制拓?fù)?分析性能.

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

三、總結(jié)

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

1. 使用公有云；
2. 重視項(xiàng)目工程化；
3. 項(xiàng)目起步時(shí)建立服務(wù)化思維,而不要急于采用服務(wù)化架構(gòu)帶來(lái)不必要的負(fù)擔(dān)；
4. 實(shí)施微服務(wù)需權(quán)衡收益與成本,基于Kubernetes可簡(jiǎn)化微服務(wù)實(shí)施；
5. DevOps能與微服務(wù)架構(gòu)良好匹配,但實(shí)施DevOps需要完善的工具鏈支持.

文章來(lái)自微信公眾號(hào)：DBAPlus社群

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4288.html