一個優秀的雲原生架構需要注意哪些地方
本文整理自騰訊雲容器產品，容器解決方案架構團隊的陳浪交在 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 下載方式，請在騰訊雲原生後台回復關鍵字「雲原生」獲取。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多乾貨！！
