​簡介：未來的數字世界是什麼樣子？手握雲原生地圖的企業，又將如何顛覆數字化？帶著這些疑問，我們採訪了教育、金融、新零售、互娛、傳媒等領域的多位大咖，他們是數字創新的引領者，也是用雲原生技術創造業務價值的踐行者。接下來，就讓我們一起聽聽通過“雲原生”，他們發生了哪些改變？ 01 2020 年， 中國市場開啟了雲原生大規模落地的元年。 從那時起，雲原生廣泛走入非網際網路企業視野。 雲原生架構在這兩年逐漸成為應用部署的主流方式。 企業數字化轉型若要深入發展，實現規模數字化， 具備彈性、分散式和持續演進的現代化應用形態， 是企業實現數字創新的重要途徑和手段。  未來的數字世界是什麼樣子？ 手握雲原生地圖的企業，又將如何顛覆數字化？ 帶著這些疑問，我們採訪了 教育、金融、新零售、互娛、傳媒等領域的多位大咖， 他們是數字創新的引領者， 也是用雲原生技術創造業務價值的踐行者。 接下來，就讓我們一起聽聽 通過“雲原生”，他們發生了哪些改變？ 作業幫

​

降本增效是公司對基礎架構的一大要求。在應用側要提升單位算力承載量，通俗來講就是 QPS。但我們面臨的一個挑戰就是作業幫技術棧太多元了，如何整體提升 QPS？再看資源側，儲存、網路這些資源要麼是剛需，要麼就是很難控制成本，資源側降本的重點還是計算資源，而對於計算資源我們需要提升單位成本的算力。

“在我看來，在降本增效的過程當中要格外注意一點，降本不能降質，降低成本時，穩定性、效率、安全不能打折扣。我們選擇和阿里雲一起，選擇開源的力量再結合一定的自研解決相關問題。在應用層面，我們提升了主流技術棧的執行效能，對於使用最多的檢索服務進行架構重構，以此來提升效能和運維效率。

在計算和儲存分離中，我們引入 Fluid 做一個關鍵的紐帶。

Fluid 是一款基於 K8s 的資料編排系統，用於解決雲原生過程中遇到的訪問資料過程複雜、訪問資料慢等一系列問題，JindoRuntime用於實現快取的加速，當我們使用Fliud和JindoRuntime完成整個檢索系統的重構之後，獲得的收益也比較明顯。作業幫的資料更新週期從之前小時級別縮短到三分鐘以內，運維整個機器交付從之前天級別縮短到了小時級別，程式效能提升 30%，帶來了萬核級別資源的縮減。

未來，作業幫會將更多線上服務遷到 ECI 之上來實現真正的削峰，並且更具價效比的 IaaS 資源，這也是我們一直嘗試和探索的方向。”

網易雲音樂

​

網易雲音樂最初的音視訊技術大多都應用在曲庫的資料處理上，雲音樂曲庫團隊與音視訊演算法團隊一起共建了網易雲音樂音視訊演算法處理平臺，落地了 60 多種音視訊演算法，尤其是在近一年來，服務化的算法佔到了一半，這些演算法向雲音樂 100+ 的業務場景提供了服務能力。但更復雜的演算法、更多的業務場景，對網易雲音樂的服務化效率、運維部署和彈效能力都提出了更高的要求，在我們上雲之前，在內部已經用到了 1000 臺以上不同規格的雲主機及物理機。

"我們在一週內快速試用了函式計算 FC，然而一個完整的、高可靠的架構，需要考慮更多的因素。因此我們的改造重點是把算力任務通過函式計算 FC 彈出去，系統在整體的對外輸入輸出上仍保持不變。

在引入函式計算的第一階段，特徵提取類的演算法得到了10 倍速的提升；稀疏類的演算法在成本上得到了極大的節約。除此之外，通過函式計算的映象快取加速能力，優化了節點的啟動速度，讓所有的服務拉起可以在秒級完成。這些工作，降低了演算法運維處理中的運維成本，讓我們能夠更聚焦在演算法及業務自身。

未來希望通過 Serverless 技術進一步解放我們在運維上的人力投入，並將從儲存上進行嘗試，讓更多場景的音視訊演算法可以實現。"

安利

​

網際網路的衝擊下，安利除了需要適應網際網路場景下的敏捷、快速、低成本試錯的核心需求，還需要適應網際網路場景下的高併發、秒殺、大促等場景。

“雲原生中介軟體為安利構建基於網際網路業務中臺架構的新電商平臺，充分發揮雲原生產品的技術優勢，支撐 10000 筆/秒的訂單峰值。雲原生中介軟體重構了安利社交商業IT基礎，打造了安利全球數字化的標杆。”

分眾傳媒

​

傳統伺服器無法滿足分眾傳媒業務高速增長帶來的新需求，耗時太長、資源利用率低、運維複雜，對人員技能要求高。

耗時太長：以前的人工上刊無法及時知道上刊是否正確或者錯誤，需要花費很多時間去核對和修改；

資源利用率低：上刊集中在週六和週日，因此所有資源基本在週六週日使用，大部分時間段不需要使用伺服器資源，這就導致資源利用率低；

運維複雜、人員技能要求高：由於業務的複雜度對相關業務人員的技能要求也高，需要招聘更高階的人員來支援對應的運維工作。

“對於我們來說，上雲有兩個選擇。第一個是用 K8s 自己搭建一套容器叢集，第二個是用函式計算 FC。如果用 K8s 請求雲主機，我們需要自己搭建 K8s，通過對外的 API 來提供請求；而使用 Serverless 計算平臺，我們不需要關心用了多少伺服器或者多少人力，只需要關心每一次 API 請求是否正確到達，就可以確認每次是否有確切識別到圖片，並把識別錯誤的東西發出來，通知到上刊人員。

阿里雲函式計算 FC 支援一分鐘內擴充到 7000+ 的例項。如果我們自己部署 K8s 會牽扯到很多人力和物力，因此我們最終選擇了 FC。

自動彈性收縮：只需要設定每週六週日有兩百萬處理量，要在兩天完成，其中高峰是早上 9 點-10 點或者下午 3 點-4 點，就可以實現資源的自動彈性收縮；

資源免運維：不需要請專業運維人員；

可提供大規模的識別能力：當我們請求每天上刊人員在早上六點、七點、八點上刊時，可以實時提供算力。

未來我們還會考慮將 Serverless 和 Kafka 結合，用在大資料的處理上，這樣的效率會更高；在視訊直播流實時推送到視訊終端的部分，我們也在嘗試使用 Serverless 來解決。”

南瓜電影

​

一場熱映電影加速了南瓜電影對於技術升級的思考。某電影上映後新註冊使用者爆發，自然爆點，日新增註冊使用者極速突破 80 萬。流量總入口，API，閘道器，撐不住，緊接著後端服務、資料庫，全鏈路緊急擴容：業務快速恢復，但整個運維過程耗時 4 小時。

"當時有兩個方案擺在我們面前，一是自建 K8s，雖然能很好解決高密部署的問題，但是 K8s 學習成本實在是太高了，搭個環境跑跑容易，但正兒八經上生產的話還是要組建好專業團隊，短期內顯然無法完成。二是Serverless應用引擎 SAE，當時覺得 SAE 不用改造，WAR/JAR包部署，自動彈性，不用買機器，不用運維機器且監控安全。

我們從知道 SAE，到跟阿里雲的溝通，以及整個上線，一共是三天時間。到第五天，順利完成部署上線。到第七天，把剩下30多個系統以同樣的方式快速遷移到 SAE 上。

7 天完成了南瓜電影 Serverless 改造：在彈性上，會按照使用者的最優化進行自動調整。其次是免運維，SAE 的運維速度比人工更加快捷。最後是釋出更快，監控做得也更完善。使用 SAE 後，運維效率提升 70%，成本下降超過 40%，擴容效率提升 10 倍以上，這是給我們帶來的直觀改變”

02 雲原生技術大大降低了數字化的門檻， 使得企業能夠專注業務本身， 而無需花太多心力在 IaaS 和 PaaS 層面。 隨著基礎雲服務已經進入成熟階段， 各類上層應用以雲原生為技術底座， 逐步構建起雲上的 IT 服務生態閉環。 雲原生的落地爆發絕非偶然， 而是企業數字化轉型升級的必經之路， 並決定企業數字化轉型的結果。 從技術升級到場景落地， 屬於雲原生的時代正在全面到來。

原文連結

本文為阿里雲原創內容，未經允許不得轉載。