雲計算發展到今天已經比較成熟了，同時伴隨著開源社區的發展，有個明顯的趨勢就是雲服務商都在努力提供一個平臺無關的服務，也就是雲原生服務，強大如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分鐘，這裡就不一條條來過了，感興趣的同學可以下來參考原始的資料，相信大家會有收穫。
我上面講的大部分也是方法論層面的內容，我們的系統從架構上要達到這些目標，這個過程工作量會很大，很複雜，我這裡先拋磚引玉。後面我們的嘉賓會詳細介紹他們在容器化實踐過程中的經驗。謝謝大家！