3月25日，網(wǎng)易云技術(shù)布道系列第三期?對(duì)話架構(gòu)師活動(dòng)在網(wǎng)易杭州園區(qū)舉辦，網(wǎng)易云基礎(chǔ)服務(wù)總經(jīng)理陳諤、美麗聯(lián)合集團(tuán)研發(fā)部副總裁曾憲杰和51信用卡CTO郭威分別從云原生應(yīng)用技術(shù)、技術(shù)人員的成長(zhǎng)和技術(shù)對(duì)業(yè)務(wù)的價(jià)值等方面帶來了干貨分享。本文將為大家重點(diǎn)解讀網(wǎng)易云基礎(chǔ)服務(wù)總經(jīng)理陳諤帶來的分享：Cloud Native 實(shí)踐從0到1。
陳諤，網(wǎng)易云基礎(chǔ)服務(wù)總經(jīng)理，現(xiàn)負(fù)責(zé)網(wǎng)易云計(jì)算平臺(tái)產(chǎn)品線建設(shè)，對(duì)內(nèi)主導(dǎo)公司軟件基礎(chǔ)設(shè)施云化改造，建設(shè)網(wǎng)易私有云將網(wǎng)易互聯(lián)網(wǎng)產(chǎn)品線遷入私有云環(huán)境，對(duì)外打造公有云產(chǎn)品，實(shí)踐網(wǎng)易云計(jì)算戰(zhàn)略。對(duì)分布式系統(tǒng)設(shè)計(jì)開發(fā)、云計(jì)算平臺(tái)系統(tǒng)架構(gòu)有一定的經(jīng)驗(yàn)和理解。個(gè)人同時(shí)致力于提升尋求解決方案幫助開發(fā)人員提升開發(fā)效率，近年來一直帶領(lǐng)團(tuán)隊(duì)推進(jìn)公司開發(fā)技術(shù)棧的標(biāo)準(zhǔn)化、工具化。
什么是Cloud Native？
說到Cloud Native，國(guó)內(nèi)大多數(shù)都翻譯成云原生，就是讓云成為成功的基石，而不是障礙。陳諤對(duì)于為什么要實(shí)現(xiàn)云原生應(yīng)用深有體會(huì)，網(wǎng)易從2012年開始實(shí)施云化的戰(zhàn)略，當(dāng)?shù)谝话嬖朴?jì)算平臺(tái)建好的時(shí)候，開始引導(dǎo)公司的項(xiàng)目逐漸向云遷移。這個(gè)過程中就遇到了一個(gè)問題：用上云之后，并沒有變得效率奇高，甚至有些項(xiàng)目的效率反而有所下降，大家有很多抱怨。
從那個(gè)時(shí)候陳諤就有一個(gè)想法，云計(jì)算怎樣才能成為公司和開發(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ì)，當(dāng)擇技術(shù)路線的時(shí)候，陳諤建議大家使用公有云，為什么呢？
使用公有云
彈性
首先，使用公有云起步的成本非常低，不需要你去租機(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ù)庫、中間件這些服務(wù)，并且不需要你去關(guān)注高可用部署、故障恢復(fù)、擴(kuò)縮容等系統(tǒng)層面的運(yùn)維，操作系統(tǒng)內(nèi)核級(jí)掌控、中間件源碼級(jí)維護(hù)也均由云提供商負(fù)責(zé)，并且有明確的SLA保障。
高可用保障
另外，云計(jì)算可以幫你做高級(jí)別的高可用保障。日常的高可用保障，比如雙機(jī)熱備也好，冷備也好，都比不過公有云提供的多可用區(qū)的保障。云的多可用區(qū)至少是IDC級(jí)別的，在一個(gè)可用區(qū)內(nèi)就像一張大網(wǎng)一樣，至少保證三層的連接，保證你的業(yè)務(wù)都是互通的，整體架構(gòu)不用考慮跨機(jī)房的問題。
云還有多Region的保障，有一些公司會(huì)做異地多活的架構(gòu)，當(dāng)然這對(duì)業(yè)務(wù)的侵入性是很大的，但至少可以用多Region的設(shè)施，來做數(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ù)這些安全問題，又省下了用戶一筆人員開銷。
公有云的取舍
當(dāng)然，公有云要支持這么大規(guī)模的用戶，本身有一定的取舍
Design For Failure：公有云傾向于更快失敗（影響范圍受控）、更快恢復(fù)。如果你用的是物理機(jī)，出現(xià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)排除掉。
由于公有云這樣的特性，日常業(yè)務(wù)必須結(jié)合公有云能力實(shí)施高可用架構(gòu)：
- 一方面以可用域?yàn)榛A(chǔ)，實(shí)現(xiàn)高可用；
- 另一方面，將數(shù)據(jù)狀態(tài)和業(yè)務(wù)邏輯分離，如果業(yè)務(wù)被遷移走了，只要掛上原來的盤就可以恢復(fù)了；
- 節(jié)點(diǎn)可重啟或重建
Design For Scale：虛擬化性能稍弱于物理機(jī)，公有云更追求交付的性能指標(biāo)的穩(wěn)定，避免租戶業(yè)務(wù)間的影響，支持業(yè)務(wù)做Scale。對(duì)于開發(fā)者來說：
- 一方面，要知道你采購的磁盤、網(wǎng)絡(luò)能夠提供的性能是什么，根據(jù)這些QoS指標(biāo)去做容量的規(guī)劃；
- 另一方面要基于負(fù)載均衡、集群管理等能力去做Scale Out，而不是讓機(jī)器規(guī)格越變?cè)酱蟆?/li>
項(xiàng)目工程化
除了上面提到的基礎(chǔ)設(shè)施，在項(xiàng)目的工程化方面，陳諤也為大家?guī)砹艘恍﹩⑹?。陳諤認(rèn)為項(xiàng)目工程化是研發(fā)協(xié)作與云端運(yùn)維的基礎(chǔ)，也是很多團(tuán)隊(duì)在起步的時(shí)候可能會(huì)忽視的事情。項(xiàng)目的整個(gè)流程中，開發(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è)開發(fā)，構(gòu)建，發(fā)布的流程串聯(lián)起來，不至于拉下一個(gè)base還要決定這里面的代碼哪一部分要拿去構(gòu)建。
常見的版本控制策略包括：
- 基于Merge的多分支策略，這種模式和多人協(xié)作的方式是匹配的，可以看到大家協(xié)作產(chǎn)生的代碼從分支到合并的過程，但是分支很多也造成了管理的復(fù)雜度很高；
- 如果團(tuán)隊(duì)能切割得比較小，功能比較集中的話，可以采用基于Rebase的單Master分支策略，它沒有Merge信息，管理起來比較簡(jiǎn)單。
基于配置的依賴管理
然后可以去做基于配置的依賴管理：
- 聲明依賴（Maven等），而不是把你的軟件包全拷貝在代碼庫下面，實(shí)現(xiàn)自動(dòng)構(gòu)建
- 建議聲明所有的依賴，包括運(yùn)行環(huán)境的初始化，不隱式依賴系統(tǒng)庫（12Factors-2: Dependencies）
接下來要合理拆分模塊，可以按業(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ù)庫地址等），容器內(nèi)部文件在開發(fā)環(huán)境一旦發(fā)布則不再變化，從而保證開發(fā)環(huán)境與生產(chǎn)環(huán)境一致。
服務(wù)化的思維
工程化是做業(yè)務(wù)架構(gòu)，建立一個(gè)高效團(tuán)隊(duì)的基礎(chǔ)，接下來要考慮的就是服務(wù)化的思維。微服務(wù)是當(dāng)下很流行的概念，采用微服務(wù)確實(shí)能為應(yīng)用的迭代和架構(gòu)帶來很多好處。但服務(wù)化的架構(gòu)會(huì)帶來額外的負(fù)擔(dān)，如果一個(gè)項(xiàng)目還處在初期階段，網(wǎng)易云的建議則是服務(wù)化思維先于服務(wù)化架構(gòu)。
- 運(yùn)維成本：一旦服務(wù)多了，環(huán)境搭建、故障診斷、運(yùn)維的工作量都會(huì)成倍增加。
- 服務(wù)拆分之后，各個(gè)服務(wù)間的生命周期是不一致的，要做生命周期的分離，就需要處理更多的異常。服務(wù)間存在更多的約束，還是異步的，如依賴關(guān)系、版本，要保證消息能夠可靠地到達(dá)那里；
- 另一方面，還會(huì)有分布式事務(wù)的問題，雖然解決起來不難，但是會(huì)侵入你的業(yè)務(wù)
雖然業(yè)務(wù)初期，不適合服務(wù)化，但是應(yīng)該為后續(xù)的服務(wù)化做一些準(zhǔn)備，否則后面想拆分的時(shí)候會(huì)變得非常困難：
- 提取Service API，理解業(yè)務(wù)中的服務(wù)抽象
- 數(shù)據(jù)庫設(shè)計(jì)的時(shí)候就考慮服務(wù)的劃分
- 避免跨服務(wù)事務(wù)，對(duì)跨服務(wù)事務(wù)進(jìn)行標(biāo)記
- 如果項(xiàng)目發(fā)展起來，遇到的第一個(gè)問題通常是數(shù)據(jù)庫會(huì)掛掉，所以在業(yè)務(wù)初期就做分庫分表是很有必要的
- 選擇事務(wù)支持更好的數(shù)據(jù)庫，如果你用缺乏事務(wù)支持的數(shù)據(jù)庫做業(yè)務(wù)的后端，當(dāng)你要做服務(wù)化拆分或分布式事務(wù)的時(shí)候，可能會(huì)比用MySQL的痛苦很多
實(shí)施微服務(wù)
隨著業(yè)務(wù)的壯大，是否要采用微服務(wù)，就要去衡量微服務(wù)帶來的收益是否大于成本？
收益
- 控制迭代更新的影響域，而單體架構(gòu)很難評(píng)估patch的影響范圍
- 加速迭代，提交代碼心里負(fù)擔(dān)小，迭代也能加快
- 隔離局部故障
- 防止代碼架構(gòu)層面的腐化，比如開發(fā)過程中為了趕進(jìn)度，可能會(huì)把原有的架構(gòu)推倒重來。如果用微服務(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è)過程中難免要用到一些微服務(wù)化的框架，雖然對(duì)代碼的侵入性不大，但對(duì)架構(gòu)的侵入性還是不可避免的
降低實(shí)施成本
- 良好的工程化，不要給運(yùn)維的工作帶來很多困難
- 使用基于云端托管的 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ā)
- 無需在程序中訪問注冊(cè)中心獲取成員列表進(jìn)行軟負(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ā)請(qǐng)求，比域名做輪轉(zhuǎn)的負(fù)載均衡效果要好，因?yàn)閕ptables可控，域名不可控。
用Kubernetes還可以讓你獲得自動(dòng)化運(yùn)維能力
- 自動(dòng)擴(kuò)縮容
- 自動(dòng)故障處理（重試、遷移）
- 自動(dòng)化滾動(dòng)更新，通過健康檢查與滾動(dòng)的配合實(shí)現(xiàn)無縫更新
- 還可以基于Service 抽象實(shí)現(xiàn)藍(lán)綠發(fā)布
Kubernetes 以解耦的基礎(chǔ)服務(wù)層的方式提供了對(duì)服務(wù)化的支持，避免了代碼實(shí)現(xiàn)層面的耦合，通過云端托管 Kubernetes 服務(wù)能夠?qū)?shí)現(xiàn)服務(wù)化的成本大幅降低。而且Kubernetes對(duì)業(yè)務(wù)沒有侵入性，實(shí)現(xiàn)服務(wù)化的代價(jià)相對(duì)會(huì)比較小，后面業(yè)務(wù)變得非常重，需要細(xì)粒度控制的時(shí)候，再用到其它框架也沒有什么影響。
網(wǎng)易云深度整合了Docker技術(shù)和Kubernetes集群編排技術(shù)，網(wǎng)易云中會(huì)有一個(gè)Kubernetes Master，所有租戶的業(yè)務(wù)都可以使用這個(gè)Master，不用用戶自己維護(hù)。
DevOps
前面講到的都是云原生相關(guān)的技術(shù)，實(shí)際上實(shí)現(xiàn)云原生還需要一些研發(fā)、運(yùn)維和組織架構(gòu)上的方式調(diào)整，比如DevOps。DevOps的出現(xiàn)是為了解決運(yùn)維角色與開發(fā)角色的矛盾，運(yùn)維追求的是可用率優(yōu)先，而開發(fā)希望應(yīng)用能快速更新迭代。
DevOps 與微服務(wù)
微服務(wù)架構(gòu)能夠支持更高頻的迭代，降低更新迭代的風(fēng)險(xiǎn)，這與 DevOps 的目標(biāo)是一致；但是微服務(wù)架構(gòu)也會(huì)給運(yùn)維帶來成倍的工作量，可基于DevOps分散運(yùn)維操作，而不是集中依賴少量運(yùn)維角色。
實(shí)施DevOps
實(shí)施DevOps需要CI/CD、編排、故障診斷等工具鏈的支持，同時(shí)需要運(yùn)維實(shí)現(xiàn)從操作到審計(jì)的職能轉(zhuǎn)換，運(yùn)維工作前置，在前期和開發(fā)團(tuán)隊(duì)合作。很多運(yùn)維還需要開發(fā)工具，提高運(yùn)轉(zhuǎn)效率。
基于DevOps工具鏈支持微服務(wù)架構(gòu)
Jenkins-容器-鏡像倉庫-服務(wù)編排
Pipeline as Code：實(shí)施服務(wù)化后持續(xù)集成的復(fù)雜度成倍增加，需要定義大量的流程，包含大量Jobs，以代碼的方式管理Pipeline能夠支持審計(jì)，有效管理復(fù)雜性并降低維護(hù)成本
日志服務(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)用路徑跟蹤能力，才能夠有效定位故障?？蓞⒖嫉目蚣苡衂ipkin, 需要對(duì)RPC框架等做instrumentation，在調(diào)用過程中攜帶額外的頭信息。
性能管理服務(wù)：微服務(wù)架構(gòu)下依賴關(guān)系復(fù)雜，發(fā)生性能問題時(shí)難以定位源頭及影響范圍，性能管理服務(wù)可提供調(diào)用關(guān)系拓?fù)?，及時(shí)統(tǒng)計(jì)慢響應(yīng)及錯(cuò)誤響應(yīng)，有利于發(fā)現(xiàn)性能問題與定位故障。以網(wǎng)易云為例，利用Kubernetes提供元信息，利用AOP對(duì)常用庫做instrumentation，可在無須配置及侵入代碼的情況下，自動(dòng)繪制拓?fù)?，分析性能。下圖是網(wǎng)易云內(nèi)部性能管理的拓?fù)浣貓D：
總結(jié)
最后，陳諤將云原生架構(gòu)實(shí)現(xiàn)的要點(diǎn)總結(jié)如下，希望能給云計(jì)算的用戶帶來有價(jià)值的參考：
- 使用公有云
- 重視項(xiàng)目工程化
- 項(xiàng)目起步時(shí)建立服務(wù)化思維，而不要急于采用服務(wù)化架構(gòu)帶來不必要的負(fù)擔(dān)
- 實(shí)施微服務(wù)需權(quán)衡收益與成本，基于Kubernetes可簡(jiǎn)化微服務(wù)實(shí)施
- DevOps能與微服務(wù)架構(gòu)良好匹配，但實(shí)施DevOps需要完善的工具鏈支持
