今年 9 月，一家雲原生數據倉庫廠商上市，上市當天市值即破 700 億美元，成為軟體史上最大 IPO。更令人驚訝的是，從不投資上市公司的巴菲特，破例以 IPO 價購買價值 2.5 億美元的股票，還從現股東處額外購買 404 萬股原始股。
雲原生，這個生於雲、長於雲、號稱是「下一個雲時代」的技術體系，已經流行起來了。
Gartner2019 年的報告曾預測，「2020 年，有 50% 的傳統老舊應用被以雲原生化的方式改造，到 2022 年，將有 75% 的全球化企業將在生產中使用雲原生的容器化應用」。前者與 CNBPA 組織完成的《第二期 (2019-2020) 雲原生實踐調研報告》中得到的數據相符。
前不久，CNCF 進行的第八次雲原生調查顯示，在全球疫情大爆發的背景下雲原生工具和技術的持續增長。僅看容器的使用率一項，約 92% 的受訪者表示他們在生產過程中使用容器，這相比 2016 年 3 月的第一次調查的 23% 增長了 300%，也是繼 2018 年的 73%、2019 年的 84% 後的持續躍升。這說明，雲原生時代軟體開發和運維的標準基礎設施已經成熟。
在企業積極進行數字化轉型，全面提升效率的今天，IT 大廠們都不約而同的將雲原生視為發展方向。騰訊、阿里、華為等國內廠商，爭先恐後搶占雲原生基礎設施建設和應用開發管理兩大市場，並在今年下半年陸續推行雲原生戰略：
- 9 月，阿里巴巴成立雲原生技術委員會，推動阿里經濟體全面雲原生化；
- 12 月初，華為發布雲原生 2.0 全景圖，並預測，到 2025 年，所有企業信息技術解決方案都會被雲化，85% 以上企業應用會被部署到雲上；
- 12 月 20 日，騰訊發布了雲原生路線圖，從開發、計算、架構、數據、安全的維度重新定位了雲原生。值得關注的是，這份落地路線圖，首次梳理了騰訊與企業共同落地的典型案例，從實踐角度詮釋了雲原生改造的全過程。
與此同時，企業的雲化動作也在加速，大部分傳統業務雲遷移已經完成。如果說，雲遷移解決了傳統應用軟體在雲環境中的使用問題，也就是「能用」的問題；那麼，原生化改造要解決的就是「好用」的問題。毫不誇張的說，雲原生化可能會成為大部分企業新的分水嶺。
雲原生的改造路線：分步、標準化
大量企業雲原生化改造的過程並非一蹴而就，往往會選擇一種穩妥的方式逐步疊代進行，尤其是傳統企業，系統規模大、關聯關係複雜、網絡架構複雜、技術架構傳統。業務部門要求系統可伸縮、支撐數據的快速增長，又不額外增加成本。技術部門考慮破除商業產品的鎖定的方案、擁抱開源，還希望上雲後的服務質量不比商業產品差。
一般的做法是，先拿一些簡單的模塊試水，摸清路數後再逐步進入深水區，完成企業整體雲原生技術改造。那麼問題來了，企業在雲原生改造過程中，一般會經歷哪些階段？每個階段的側重點是什麼？會用到哪些技術或產品？改造後的衡量標準怎麼定？
騰訊把雲原生改造分為 4 個階段，分別是：開發雲原生、計算雲原生、架構雲原生、數據云原生，在這個過程中，安全雲原生為整個改造過程以及之後的系統運營提供數據安全及穩定性保障。
第一階段：開發雲原生
這一階段的重點是解決「企業研發運維流程效率」問題。在傳統的開發模式中，研發人員需要了解和學習不同 API 的具體使用方式和含義，開發完成還需要負責編譯、打包並申請資源，過程複雜且耗時良久。運維技術支持不足、流程不完善、缺少監管手段等，也讓運維過程緩慢低效。
以騰訊自身的雲原生實踐為例，最先切入的點就是軟體研發運維流程。之前來自技術團隊各方面經常會聽到一些抱怨，開發人員說環境太少，構建發布流程太慢；測試人員抱怨太多非標準版本或者發布，版本質量不可控；運維人員埋怨發布不可控，疲於救火...... 正是因為大家在這裡都很痛，並且涉及到大部分團隊成員，就很容易快速推進。
這個階段完成的好與壞，有兩個關鍵的衡量標準：
- 第一，企業的組織架構、研發運維流程是否符合 DevOps 理念，是否能夠支持企業對應用進行快速的疊代、測試、發布、試錯和優化；
- 第二，是否能建設和使用軟體流程中的工具平台，提升團隊協作效率，同時根據流程規範搭建一個自動化的「構建 - 測試 - 灰度發布」平台，減少因為「人」的因素導致的低效或者失誤。
舉個栗子
微信讀書小程序，繼承了微信讀書 APP 最核心的閱讀功能，同時也是七對外分享與運營的最重要渠道，在上線 10 個月之內，日均 PV 過千萬。而這離不開「小程序雲開發」為微信讀書研發團隊帶來的效能提升，上線 10 個月，微信讀書小程序累計發布了 349 次版本，開發效率分別是 APP 和 H5 的 4 倍與 2 倍。
微信讀書小程序上線之初，由於原先使用的 Node 框架上線流程繁瑣、面對突發流量運維響應慢以及開發人力不足等原因，開發效率極低。
通過「小程序雲開發」，他們開始逐步使用雲開發替代原有的 Node 服務，從小程序端獲取的數據通過雲函數、雲存儲等功能傳輸到 Server 後台，並生成業務發展數據的報表，相當於一套從後台到前端的完整服務。
小程序·雲開發，讓前端代碼和服務端代碼共存在一個項目中，統一的技術棧、統一的 IDE 環境，可以調試開發更高效，還支持動態擴容，這使得微信讀書小程序研發團隊效率大大提升。
不僅如此，相應的，技術團隊也因為「小程序雲開發」的前後端統一，也重新調整了分工。以前其團隊按照前端開發、Node 開發和運維人員進行分工，現在前端負責全棧開發，團隊的關注點更多集中在服務性能、穩定性、資源利用率方面。
第二階段：計算雲原生
這個階段有兩個關鍵詞：「容器化」、 「Serverless 化」。改造目標是降低對 IaaS 層的異構和差異、資源的部署和調度 (包括計算資源、網絡資源、存儲資源) 的關注。
這個階段涉及的業務模塊大多與「數據」相關度低，比如無狀態類服務 (Web 網站、接入 層服務、邏輯層服務等)，消息觸發類服務 (轉碼、定時任務等)。所以往往改造成本較低，灰度驗證也容易，一旦出現問題也能夠快速恢復。改造成本和風險較低，也最適合在雲原生改造初始階段切入的地方。
這個階段同樣有 3 個關鍵的衡量標準，在改造完成後，我們的業務模塊能否具備：
- 第一，極致的調度能力包括：自動伸縮、跨界點、跨集群、跨機房的調度等；
- 第二，全面的故障容災能力包括：業務、節點、機房的容災；
- 第三，極簡的運維模式，需要屏蔽 IaaS 差異和具備 Serverless 計算能力。
舉個栗子
作業幫歷時 3 個月，通過容器化改造並向騰訊雲容器服務 TKE 遷移，讓整體成本下降 43%，接口響應提升 10%，穩定性從 99.95% 提升到 99.995%，發布效率提升兩個數量級，平穩支撐了疫情期間業務爆髮式增長。
作業幫的業務，大規模使用 Kubernetes 原生的負載均衡和服務發現，而 Kubernetes 在分散的流量調度架構上天然存在瓶頸，容易導致業務負載嚴重不均衡。另外，作業幫的業務對服務間時延敏感，部分業務連接超時時間設置為 5 毫秒，無法承受細微系統調度和網絡波動，容易引起業務大面積超時。服務間訪問會帶來巨大的 DNS 並發，極易觸發主機的 QOS 限速和引起主機的 conntrack 衝突……
此外，改造過程中排查並解決的典型問題有：
- 解決 IPVS 模式高並發場景下連接復用引發連接異常 (對應 issue https://github.com/kubernetes/kuber- netes/issues/81775)，內核補丁已被 Linux 社區接受；
- 在高配節點 (核數多) 下 IPVS 規則過多引髮網絡毛刺問題；
- 大 Pod(占用核數多，單核占用高) 在高配節點 (核數多) 場景下，CPU 負載均衡引髮網絡毛刺的 問題等。
作業幫將在線業務、大數據離線任務、GPU 業務都進行了容器化改造，改造方案如下：
- 在線業務方面，作業幫開發語言眾多，通過 Service Mesh 實現多語言的服務治理與服務感知；
- 為提升 GPU 資源率用率與隔離性，作業幫採用共享 GPU 模式，並在業務層通過限制入口流量的方式做了不同 Pod GPU 使用量的隔離；
- 由於在線業務和 GPU 業務的特性，CPU 利用率波峰波谷明顯，作業幫採用大數據容器化及在離線混合部署方案提升節點資源使用率；
- 通過 EMR on TKE 方案，在不改變原有 yarn 集群使用模式的前提下，漸進式的將大數據任務調度到 TKE 在線集群，並通過 TLinux 提供的 CPU 離線調度器，實現離線任務對在線任務的避讓，從而在保障在線任務不受影響的前提下，離線任務充分利用 CPU 資源；
- 利用 EMR on EKS 方案，將緊急的大數據任務或者臨時的計算任務運行在 EKS 彈性集群里，避免了複雜的資 源規劃及儲備工作。
第三階段：架構雲原生
這個階段會深入到複雜的軟體架構層面，伴隨著微服務化和架構改造，因此難度較大，但收益也會更大。
在改造過程中，一些成熟的框架服務的使用，能讓改造事半功倍。例如微服務平台 TSF、服務網格、雲開發 TCB 等，它們集成了很多運維能力，包括日誌、監控、服務註冊和發現、故障容災等。除了提高研發效率外，也能提升改造後系統的整體運維能力。
在這個階段其實也有兩個關鍵的衡量標準：
- 第一，整個架構的微服務化改造是否拆分到位，流量是否可以調度、可以治理、可以觀測；
- 第二，企業的研發和運維模式是否極簡，企業能否聚焦在業務邏輯本身的開發和運維上。
舉個栗子
南網雲平台由南網數研院牽頭，騰訊雲負責承建，2019 年 12 月 31 日就已正式上線。今年 2 月 12 日，南網雲平台進行了首次電費結算業務, 該系統共發行 2000 多萬用戶電費數據，省網通道同步 1.2 億條數據。2 月 16 日當天，日訪問量超過 100 多萬人。
而在此前，南網用了 45 天就完成了總部基地主節點的擴容和 9 個分子公司雲平台的上線，平均響應時間 0.52s，保障了億級網際網路客戶平台、電力市場交易系統等 376 個重要系統和 519 個微服務的安全穩定運行，實現主節點 58 個存量雲應用遷移，分節點 6 個異構雲納管。
電網是關係國計民生的基礎性行業，安全運行要求高，業務複雜度高，應用呈現多樣化，IT 基礎設施的複雜程度也遠超傳統企業客戶。這對南網雲平台的安全性、可靠性、靈活性和可控運行提出了更高的要求：
- 需要支持南網的基礎設施標準化，以多樣化的應用架構，全面支撐南網金融業務、綜合能源業務等企業級應用的快速生成；
- 需要具備靈活性和擴展性，方便統一規劃管理和統一技術標準，提升系統集成效果，減少運維難度和工作量；
- 需要具備彈性伸縮、資源快速交付、開發測試敏捷、應用快速部署、故障資源和 IT 資源標準化等能力，包括一級部署多級管理的主分節點、兩地三中心、開發環境、測試環境，節點總數達到 4000 個；
- 災備採用平台連續性和應用連續性保護機制，根據南網業務系統需求，結合國家標準《信息安全技術信息系統災難恢復規範》，災備等級分為 2、3、4 和 5 級。採用兩地三中心災備建設模式，同城雙活，異地容災。
改造的具體方案是：
- 對南網現有的多個業務系統的共用能力進行分析和整合，實現系統解耦；
- 搭建微服務架構，逐步積累南網雲的中台能力。
- 圍繞南網調度運行、電網管理、運營管控和客戶服務等業務，根據微服務治理平台的監控服務負載情況、CPU 使用率、內存使用率、響應時間、請求 QPS，自動增減服務節點；
- 結合日誌與監控數據，當出現風險時，通過日誌和監控快速定位問題，監測可能發生的意外和故障，提前預警和告警；
- 通過自動化工具實現南網雲的微服務研發和運維流水線；
- 數據中心採用雙 region 設計，所有雲平台均同時部署分布式存儲與集中式存儲。其中，集中式存儲組成同城同步複製、異地複製的集群。業務側使用 TSF 微服務平台就近路由和跨可用區實現容災，業務同時部署在兩個可用區。開啟就近路由後服務消費者會將請求流量路由到相同的可用區；當同一可用區不可用時，自動進行跨可用區的服務調用實現服務容災。
第四階段：數據云原生
在這個階段，企業的雲原生改造已經進入到深水區，目標是將 Kubernetes、Serverless 的技術和理念應用到「數據服務」中，讓「數據服務」也具備極致的彈性伸縮能力，在資源成本上能夠做到最優。
這個階段有三個關鍵的衡量標準：
- 第一，數據服務的計算與存儲是否分離，存儲是否可以支持不同存儲介質；
- 第二，數據服務的算力資源是否能夠真正做到按需分配，按量計費，並且在需要的時候自動且快速自動擴充；
- 第三，數據算力與在線業務能否做到混部，最大限度的提升資源利用率，降低我們企業的成本。
舉個栗子
疫情防控期間，健康碼成為全球疫情下中國科技抗疫「智慧防線」的重要一環。健康碼落地 20 個省級行政區，覆蓋 300 多個市縣，承載訪問量累計達 260 億次，覆蓋人口超 10 億，成為全國服務用戶最多的「健康碼」。
健康碼涉及的應用場景繁多，數據類型方面需要支持如通行時間、車輛信息等結構化信息查詢，也有如街道 / 社區 / 小區名這樣的長文本信息。另外，伴隨著疫情防控的需要的調整，還需具備快速調整增刪欄位的功能；在查詢方面，不僅需要支持傳統的結構化信息的查詢，還需要支持關鍵字的搜索技術、海量數據的聚合分析技術以及地理位置區域計算技術。
傳統的關係資料庫 MySQL，在事務型應用及多業務多表關聯查詢方面有著出色的表現，但是面對健康碼系統複雜繁多的數據類型，特別是文本關鍵字搜索能力時顯得捉襟見肘。對於比較熱門的 NoSQL 類產品 MongoDB，雖然能滿足多樣化的數據類型的支持，且可以根據業務的需要隨時動態的增加欄位且不影響業務正常的查詢寫入，但是同樣缺少文本關鍵字的檢索能力。
而在海量數據的存儲方面，雖然相當多的大數據產品，如 hive 數倉、Hbase 等，擁有海量的數據存儲能力，且具備一定的數據分析能力，但整個技術棧及架構比較重，需要維護的開源組件繁多，通常需要一支專門的運維團隊進行集群的日常維護。對於開發人員來說，開發方法及接口也較為複雜。
因此，該項目資料庫採用了 Elasticsearch（以下簡稱 ES）。具體的項目方案如下：
隨著疫情防控在全國範圍內的鋪開，接入健康碼的省市自治區快速的增加，截止目前已掃碼次數達 16 億次，覆蓋 9 億用戶。如何應對業務急速的數據查詢增長？
- 需要支撐 10 億級別的數據訪問和查詢數據的急速增長。索引數據通過分區算法分割為多個數據分片 (shard)，平均分布在集群的多個節點上。通過節點和數據分片的能力，可以線性的擴展索引數據寫入查詢的吞吐。
- 需要存儲系統 7*24 小時不間斷提供服務。騰訊雲 ES 集群在多個可用區機房中平均部署節點，如果設置的副本數和可用區數目一致，當有一個節點乃至一個可用區機房不可用，剩餘節點中的分片仍是一份完整的數據，且主從分片可以自動切換，集群仍然可以持續的對外提供寫入查詢服務。
- 為防止因不嚴謹的聚合分析語句導致節點發生 OOM 問題造成的集群雪崩。騰訊雲 ES 在存儲內核上開發了基於實際內存的熔斷限流機制。當集群發現部分節點的 JVM 使用率超過設定的熔斷閥值，即會進行服務降級，梯度攔截部分查詢請求，直至 JVM 使用率超過 95% 導致最終熔斷，阻止所有查詢請求。這一熔斷請求攔截機制會覆蓋 Rest 層及 Transport 層，通過將熔斷提前至 Rest 層，可以儘早攔截請求，降低集群在熔斷狀態下的查詢壓力。
- 在數據備份方面，通過 ES 索引生命周期管理功能，定時增量的備份底層數據文件到騰訊雲對象存儲 COS。需要時即可隨時將數據備份恢復至任意集群，做到數據的萬無一失。
無所不在：安全雲原生
企業在進行雲原生化建設的同時，安全能力應貫穿雲原生的整個生命周期，這稱之為「安全雲原生」。
在開發階段，提供集成的代碼級安全及合規檢測能力，提前發現風險隱患，或通過向開發者提供安全 SDK，使產品具備內生安全能力。處於發布階段的製品 (例如容器鏡像) 需要持續地進行自動掃描和更新， 從而避免遭受漏洞、惡意軟體、危險代碼以及其它不當行為的侵害。完成這些檢查之後，應該對製品進行簽名來保障其完整性和不可否認性。
在部署階段，集成的安全性能夠對工作負載的屬性進行實時的持續驗證 (例如完 整性簽名、容器鏡像和運行時的安全策略等)。在上線運行階段，能夠提供對應用、服務和工作負載的運行時 防護、並通過態勢感知能力和雲平台的靈活、彈性機制，對網絡安全事件進行實時自動化響應並進行協同處置，幫助客戶實現高效的安全防護及合規。
安全雲原生部署達標參考標準:
- 第一，代碼安全漏洞和開源合規檢測；
- 第二，自動化鏡像加固及掃描 ; 鏡像簽名及安全 策略的實時校驗；
- 第三，應用、服務、工作負載的動態可彈性擴展運行時防護；
- 第四，安全事件的自動化響應。
寫在最後
現代企業的 IT 規劃要面對兩個緊迫事實，一是當前的客戶需求、行業競爭狀態已和 20 年前、10 年前全然不同，企業業務的更新速度很多已經從以周為單位提升到按小時計；二是雲原生是新生事物，企業技術人員從零學習、到消化吸收、再到創新都需要人力成本和技術試錯成本。
當面臨著行業競爭緊迫、技術試錯成本和人才培養成本的三大壓力，找到一個合適的參照，以此為基礎疊代自己的業務解決方案和產品技術架構，是當前很多企業所需要的操作。
目前，騰訊針對雲原生的產品就有 30 多個，服務著幾十萬家企業。這篇文章里的所有案例，來自騰訊雲原生服務的真實場景。後續也希望能看到越來越多的落地案例，為有雲原生改造需求的企業，提供參考。
延伸閱讀：
2021年，不能錯過的十大技術趨勢 | InfoQ特別策劃-InfoQ
關注我並轉發此篇文章，即可獲得學習資料~若想了解更多，也可移步InfoQ官網，獲取InfoQ最新資訊～