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

本文整理自騰訊雲容器產品，容器解決方案架構團隊的陳浪交在 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 下載方式，請在騰訊雲原生後臺回覆關鍵字「雲原生」獲取。