一個優秀的云原生架構需要注意哪些地方

本文整理自騰訊云容器產品，容器解決方案架構團隊的陳浪交在 Techo 開發者大會云原生專題的分享內容——一個優秀的云原生架構需要注意哪些地方，本文將會給大家分享云原生架構的特點和以及實踐程序中的一些注意事項，

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

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

最底層是云服務商的物理機、物理網路以及物理存盤，之上是虛擬化服務、包括租戶隔離的網路、計算資源以及分布式存盤，到了這層，云服務商提供的產品雖然大同小異，但都還是平臺相關的，

關鍵就是在上一層的PaaS服務層，由它來適配各個廠商的計算、網路、存盤資源，然后對用戶提供統一的訪問介面，具體起來就是云服務提供商的Kubernetes服務在內部會去對接底層的存盤、計算網路、再加上標準的mysql、redis等開源服務，這樣用戶對接的就是一個標準介面的PaaS平臺，就為我們的業務從本地開發環境無縫遷移到公有云、甚至在云服務商之間遷移、混合云、跨云容災等提供了技術前提，

結合以上介紹的背景以及云原生的定義，我們再總結下什么是云原生架構，一個平臺無關的、自動化的、具備容災能力的敏捷的分布式業務系統，

接下來介紹，在構建云原生服務時，有哪些注意事項以及一些個人的一點思考，

CNCF提供的云原生的定義對云原生做了經典概括，下述所講內容也在它的定義范疇之內，包括為什么要做微服務拆分，為什么要容器化、如何做CICD、如何避免故障、以及故障發生時我們有哪些應對措施，最后一起交流下如何檢驗我們的系統是否符合云原生架構，

我們在討論微服務時，其實討論的是一個業務模塊的微服務拆分是否徹底，這決定我們業務模塊能否做到橫向水平擴容、整體能否成為一個分布式系統，比如一個商城系統，庫存服務邏輯變化了是否會影響到商品服務、訂單服務，到雙十一的時候，訂單服務需要大幅擴容，我們能否只擴容一個服務、跟這個服務相關的資料庫表而不影響其它服務，

因此，我們需要盡量減少服務之間的業務邏輯耦合、資料耦合，通過通信來進行資料共享，而不是通過共享資料來進行業務通信，使得我們在做必要的變更時，影響的范圍能降低到最小，

容器是云原生架構的基礎，這是容器的標準化屬性來決定的，如果不使用容器，CICD、自動擴縮容就沒辦法做，我們不知道這些服務依賴什么配置、程式如何啟動、如何停止，我們可以基于自身業務特性自己開發一套CICD系統、擴縮容系統，但是不是通用的，無法移植的，

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

接下來講下CICD，我們的服務容器化之后，CICD也很方便，圍繞容器，圍繞K8s，代碼變成容器鏡像、鏡像發布到不同環境測驗，最后再到線上，藍綠、灰度等策略也很好做，

業務部署后，我們需要有一套問題發現、問題定位的手段，這樣大家才能安心，常用的手段有監控、tracing以及日志系統，

對于監控，我們需要同時做好基礎監控以及業務監控，容器的CPU、記憶體、網路、各種句柄等，業務層面，我們需要監控業務的服務質量，比較常見的就是業務的回應時間、錯誤率等，

通過tracing，我們可以找到具體某個請求在呼叫鏈路上的瓶頸，比如由于某個服務訪問一個不重要的旁路服務，導致延時增加了50ms，如果沒有tracing，很難發現這樣的問題，同時還可以把資料庫、快取等中間件服務的訪問資訊上報到tracing系統，便于排查一些類似資料庫慢查詢、hot key、 big key引起的問題，

日志服務就更重要了，無論是性能問題、業務問題的排查都需要相應的日志，業務容器化后，日志查詢會更加復雜一些，因為容器不會固定運行在某個主機上，需要把容器的日志采集到一個中心化的日志服務，采集容器日志時，有不同的方案，有的小伙伴選擇使用SDK在業務容器里直接把日志打到日志服務，更多的是日志先落盤，然后再通過agent采集到后端存盤，如果業務的log都統一輸出到標準輸出，建議部署daemonset的方式統一采集，如果容器的log輸出到某個檔案，建議使用sidecar的方式會更靈活，同時建議把行程的啟動停止日志以及業務日志分開，在定位容器的啟動失敗等一些關鍵事件時更方便，關于日志平臺，可以使用云服務商的日志服務，也可以自建，根據各自的需求而定，

在設計系統的時候，我們要時刻考慮到，故障是不可避免的，我們隨時要做好故障的預案，

常見的故障有網路故障、硬體故障、系統故障、業務故障，其中網路故障需要考慮業務部署的時候是不是要做好磁區的隔離，比如可以在多個區做容災和流量切換的機制，對于硬體故障，需要考慮一臺母機掛了以后，能夠結合云服務商的能力來保證同一個用戶下面的子機盡量打散；同時為避免單點故障，一個服務可以多一個副本，比如虛擬機掛了以后，可以做一定的冗余，系統軟體建議提供云服務商提供的系統內核，因為他做了很多優化，業務的故障，我們平時在發布程序中不要一次性馬上把業務發布上去，要流量一點一點逐步發到線上，同時要做好一個預案，假如新版本問題，能否馬上回滾到之前的版本，

融合了上面的一些的設計理念之后，我們的業務系統首先要做一定的冗余，在多個可用區部署相同的服務，流量可能對外要提供兩個不同的入口，在入口處對流量進行分配，當出現導致網路隔離的問題時，可以直接從前端進行流量切換，微服務和資料庫也做了拆分，使得每個服務都可以單獨做自動伸縮，整體看來，就是一個比較合理的分布式的業務系統，

關注業務而非基礎設施，這里給大家講一個發生在我們這里的一個真實的故事，

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

接收到這個求助之后，我們跟客戶介紹了TKE的技術方案，整個升級程序需要做大量前置校驗作業，并且還要針對不同的K8s版本做patch、以及適配不同的Linux發行版等，這些作業在客戶的環境里實作起來作業量太大，成本太高，K8s集群的維護是很復雜的，他介于IaaS跟PaaS之間，需要針對Linux內核、K8s內核以及依賴的網路、存盤、計算資源做大量的優化，才能保證集群穩定、高效運行，對團隊來說，需要招聘業界頂級專家，否則當集群功能例外無法解決，可能造成業務大面積受損，

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

我上面講的大部分也是方法論層面的內容，我們的系統從架構上要達到這些目標，這個程序作業量會很大，很復雜，我這里先拋磚引玉，后面我們的嘉賓會詳細介紹他們在容器化實踐程序中的經驗，謝謝大家！

本文相關 PPT 下載方式，請在騰訊云原生后臺回復關鍵字“云原生”獲取，

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

標籤：其他

上一篇：【翻譯】幾個優質的REST API工具

下一篇：快速創建MockAPI