本文整理自騰訊云容器產(chǎn)品，容器解決方案架構(gòu)團(tuán)隊(duì)的陳浪交在 Techo 開發(fā)者大會云原生專題的分享內(nèi)容——一個優(yōu)秀的云原生架構(gòu)需要注意哪些地方。本文將會給大家分享云原生架構(gòu)的特點(diǎn)和以及實(shí)踐過程中的一些注意事項(xiàng)。

從CNCF給出的云原生官方的定義可以看出，云原生架構(gòu)其實(shí)是一種方法論，沒有對開發(fā)語言、框架、中間件等做限制，它是一些先進(jìn)的設(shè)計(jì)理念的融合，包括容器、微服務(wù)、盡量解耦合、敏捷、容災(zāi)、頻繁迭代、自動化等。

云計(jì)算發(fā)展到今天已經(jīng)比較成熟了，同時伴隨著開源社區(qū)的發(fā)展，有個明顯的趨勢就是云服務(wù)商都在努力提供一個平臺無關(guān)的服務(wù)，也就是云原生服務(wù)，強(qiáng)大如AWS也沒辦法阻擋，這個趨勢的演變也值得探討，由于時間有限，線下有機(jī)會可以交流下。由于云原生技術(shù)跟平臺無關(guān)，使得用戶可以從適配各個云服務(wù)商中解脫出來，從而更加聚焦在業(yè)務(wù)本身。方便讓大家對云服務(wù)商的云原生平臺有一個比較感性的認(rèn)知，我們一起來看下云原生服務(wù)的層級架構(gòu)。

最底層是云服務(wù)商的物理機(jī)、物理網(wǎng)絡(luò)以及物理存儲，之上是虛擬化服務(wù)、包括租戶隔離的網(wǎng)絡(luò)、計(jì)算資源以及分布式存儲。到了這層，云服務(wù)商提供的產(chǎn)品雖然大同小異，但都還是平臺相關(guān)的。

關(guān)鍵就是在上一層的PaaS服務(wù)層，由它來適配各個廠商的計(jì)算、網(wǎng)絡(luò)、存儲資源，然后對用戶提供統(tǒng)一的訪問接口，具體起來就是云服務(wù)提供商的Kubernetes服務(wù)在內(nèi)部會去對接底層的存儲、計(jì)算網(wǎng)絡(luò)、再加上標(biāo)準(zhǔn)的mysql、redis等開源服務(wù)。這樣用戶對接的就是一個標(biāo)準(zhǔn)接口的PaaS平臺，就為我們的業(yè)務(wù)從本地開發(fā)環(huán)境無縫遷移到公有云、甚至在云服務(wù)商之間遷移、混合云、跨云容災(zāi)等提供了技術(shù)前提。

結(jié)合以上介紹的背景以及云原生的定義，我們再總結(jié)下什么是云原生架構(gòu)，一個平臺無關(guān)的、自動化的、具備容災(zāi)能力的敏捷的分布式業(yè)務(wù)系統(tǒng)。

接下來介紹，在構(gòu)建云原生服務(wù)時，有哪些注意事項(xiàng)以及一些個人的一點(diǎn)思考。

CNCF提供的云原生的定義對云原生做了經(jīng)典概括，下述所講內(nèi)容也在它的定義范疇之內(nèi)，包括為什么要做微服務(wù)拆分，為什么要容器化、如何做CICD、如何避免故障、以及故障發(fā)生時我們有哪些應(yīng)對措施，最后一起交流下如何檢驗(yàn)我們的系統(tǒng)是否符合云原生架構(gòu)。

我們在討論微服務(wù)時，其實(shí)討論的是一個業(yè)務(wù)模塊的微服務(wù)拆分是否徹底，這決定我們業(yè)務(wù)模塊能否做到橫向水平擴(kuò)容、整體能否成為一個分布式系統(tǒng)。比如一個商城系統(tǒng)，庫存服務(wù)邏輯變化了是否會影響到商品服務(wù)、訂單服務(wù)，到雙十一的時候，訂單服務(wù)需要大幅擴(kuò)容，我們能否只擴(kuò)容一個服務(wù)、跟這個服務(wù)相關(guān)的數(shù)據(jù)庫表而不影響其它服務(wù)。

因此，我們需要盡量減少服務(wù)之間的業(yè)務(wù)邏輯耦合、數(shù)據(jù)耦合，通過通信來進(jìn)行數(shù)據(jù)共享，而不是通過共享數(shù)據(jù)來進(jìn)行業(yè)務(wù)通信，使得我們在做必要的變更時，影響的范圍能降低到最小。

容器是云原生架構(gòu)的基礎(chǔ)，這是容器的標(biāo)準(zhǔn)化屬性來決定的，如果不使用容器，CICD、自動擴(kuò)縮容就沒辦法做，我們不知道這些服務(wù)依賴什么配置、程序如何啟動、如何停止，我們可以基于自身業(yè)務(wù)特性自己開發(fā)一套CICD系統(tǒng)、擴(kuò)縮容系統(tǒng)，但是不是通用的，無法移植的。

有人說沒有集裝箱就沒有全球化，這里的容器就是集裝箱，大家想是不是這個道理。容器還有很多優(yōu)點(diǎn)，首先可以降低成本，K8s知道如何調(diào)度把容器到合適的機(jī)器上，使得集群節(jié)點(diǎn)使用率均衡、并且提高節(jié)點(diǎn)的資源使用率，可運(yùn)維性也上來了。

接下來講下CICD，我們的服務(wù)容器化之后，CICD也很方便，圍繞容器，圍繞K8s，代碼變成容器鏡像、鏡像發(fā)布到不同環(huán)境測試，最后再到線上，藍(lán)綠、灰度等策略也很好做。

業(yè)務(wù)部署后，我們需要有一套問題發(fā)現(xiàn)、問題定位的手段，這樣大家才能安心。常用的手段有監(jiān)控、tracing以及日志系統(tǒng)。

對于監(jiān)控，我們需要同時做好基礎(chǔ)監(jiān)控以及業(yè)務(wù)監(jiān)控，容器的CPU、內(nèi)存、網(wǎng)絡(luò)、各種句柄等，業(yè)務(wù)層面，我們需要監(jiān)控業(yè)務(wù)的服務(wù)質(zhì)量，比較常見的就是業(yè)務(wù)的響應(yīng)時間、錯誤率等。

通過tracing，我們可以找到具體某個請求在調(diào)用鏈路上的瓶頸，比如由于某個服務(wù)訪問一個不重要的旁路服務(wù)，導(dǎo)致延時增加了50ms，如果沒有tracing，很難發(fā)現(xiàn)這樣的問題，同時還可以把數(shù)據(jù)庫、緩存等中間件服務(wù)的訪問信息上報(bào)到tracing系統(tǒng)，便于排查一些類似數(shù)據(jù)庫慢查詢、hot key、 big key引起的問題。

日志服務(wù)就更重要了，無論是性能問題、業(yè)務(wù)問題的排查都需要相應(yīng)的日志，業(yè)務(wù)容器化后，日志查詢會更加復(fù)雜一些，因?yàn)槿萜鞑粫潭ㄟ\(yùn)行在某個主機(jī)上，需要把容器的日志采集到一個中心化的日志服務(wù)，采集容器日志時，有不同的方案，有的小伙伴選擇使用SDK在業(yè)務(wù)容器里直接把日志打到日志服務(wù)，更多的是日志先落盤，然后再通過agent采集到后端存儲，如果業(yè)務(wù)的log都統(tǒng)一輸出到標(biāo)準(zhǔn)輸出，建議部署daemonset的方式統(tǒng)一采集，如果容器的log輸出到某個文件，建議使用sidecar的方式會更靈活。同時建議把進(jìn)程的啟動停止日志以及業(yè)務(wù)日志分開，在定位容器的啟動失敗等一些關(guān)鍵事件時更方便。關(guān)于日志平臺，可以使用云服務(wù)商的日志服務(wù)，也可以自建，根據(jù)各自的需求而定。

在設(shè)計(jì)系統(tǒng)的時候，我們要時刻考慮到，故障是不可避免的，我們隨時要做好故障的預(yù)案。

常見的故障有網(wǎng)絡(luò)故障、硬件故障、系統(tǒng)故障、業(yè)務(wù)故障，其中網(wǎng)絡(luò)故障需要考慮業(yè)務(wù)部署的時候是不是要做好分區(qū)的隔離，比如可以在多個區(qū)做容災(zāi)和流量切換的機(jī)制。對于硬件故障，需要考慮一臺母機(jī)掛了以后，能夠結(jié)合云服務(wù)商的能力來保證同一個用戶下面的子機(jī)盡量打散；同時為避免單點(diǎn)故障，一個服務(wù)可以多一個副本，比如虛擬機(jī)掛了以后，可以做一定的冗余。系統(tǒng)軟件建議提供云服務(wù)商提供的系統(tǒng)內(nèi)核，因?yàn)樗隽撕芏鄡?yōu)化。業(yè)務(wù)的故障，我們平時在發(fā)布過程中不要一次性馬上把業(yè)務(wù)發(fā)布上去，要流量一點(diǎn)一點(diǎn)逐步發(fā)到線上，同時要做好一個預(yù)案，假如新版本問題，能否馬上回滾到之前的版本。

融合了上面的一些的設(shè)計(jì)理念之后，我們的業(yè)務(wù)系統(tǒng)首先要做一定的冗余，在多個可用區(qū)部署相同的服務(wù)，流量可能對外要提供兩個不同的入口，在入口處對流量進(jìn)行分配，當(dāng)出現(xiàn)導(dǎo)致網(wǎng)絡(luò)隔離的問題時，可以直接從前端進(jìn)行流量切換，微服務(wù)和數(shù)據(jù)庫也做了拆分，使得每個服務(wù)都可以單獨(dú)做自動伸縮。整體看來，就是一個比較合理的分布式的業(yè)務(wù)系統(tǒng)。

關(guān)注業(yè)務(wù)而非基礎(chǔ)設(shè)施。這里給大家講一個發(fā)生在我們這里的一個真實(shí)的故事。

有一天一個客戶聯(lián)系到我們說他出十萬塊錢，讓我們幫他們做一個事情，客戶在騰訊上部署了一個K8s生產(chǎn)集群需要升級到更高版本，他們發(fā)現(xiàn)K8s集群升級時，集群的容器會重啟一遍，但是對比騰訊云上提供的TKE集群，從一個版本升級到另外一個版本，容器不需要重啟，對業(yè)務(wù)來說是無感知的、透明的。

接收到這個求助之后，我們跟客戶介紹了TKE的技術(shù)方案，整個升級過程需要做大量前置校驗(yàn)工作，并且還要針對不同的K8s版本做patch、以及適配不同的Linux發(fā)行版等，這些工作在客戶的環(huán)境里實(shí)現(xiàn)起來工作量太大，成本太高。K8s集群的維護(hù)是很復(fù)雜的，他介于IaaS跟PaaS之間，需要針對Linux內(nèi)核、K8s內(nèi)核以及依賴的網(wǎng)絡(luò)、存儲、計(jì)算資源做大量的優(yōu)化，才能保證集群穩(wěn)定、高效運(yùn)行。對團(tuán)隊(duì)來說，需要招聘業(yè)界頂級專家，否則當(dāng)集群功能異常無法解決，可能造成業(yè)務(wù)大面積受損。

最后給大家介紹下，其他的業(yè)界專家提供的，怎么從個人的環(huán)境里面的服務(wù)遷移到公有云上，他總結(jié)了一些必要的步驟，和上云的一個成熟度模型，同時還有我們怎么樣去驗(yàn)證我們的業(yè)務(wù)系統(tǒng)是不是一個服務(wù)云原生架構(gòu)的系統(tǒng)，他提了很多問題，根據(jù)這些問題來檢驗(yàn)我們的系統(tǒng)是否符合云原生架構(gòu)。由于演講時間已經(jīng)超過了預(yù)定的15分鐘，這里就不一條條來過了，感興趣的同學(xué)可以下來參考原始的資料，相信大家會有收獲。

我上面講的大部分也是方法論層面的內(nèi)容，我們的系統(tǒng)從架構(gòu)上要達(dá)到這些目標(biāo)，這個過程工作量會很大，很復(fù)雜，我這里先拋磚引玉。后面我們的嘉賓會詳細(xì)介紹他們在容器化實(shí)踐過程中的經(jīng)驗(yàn)。謝謝大家！

本文相關(guān) PPT 下載方式，請?jiān)隍v訊云原生后臺回復(fù)關(guān)鍵字“云原生”獲取。

【騰訊云原生】云說新品、云研新術(shù)、云游新活、云賞資訊，掃碼關(guān)注同名公眾號，及時獲取更多干貨！！