作者：賀宇&華為云布道師

　　在容器技術、編排系統、微服務理念等云化技術和管理方法的帶動下，應用上云已然成為一種趨勢，云原生理念應運而生。一方面，云計算已經重塑了軟件的整個生命周期，從架構設計到開發，再到構建、交付和運維等所有環節；另一方面，企業 IT 架構也隨之發生巨大變化，而業務又深度依賴 IT 能力。而這帶來了一定程度的復雜性和挑戰性。

　　云原生理念被認為是云計算發展的必然導向，采用基于云原生理念的技術和方法：以容器為基石，通過微服務化的改造，融合 DevOps 理念，有助于更好地實現業務“遷于云”或“生于云”，能夠幫助企業快速構建更加適合云的敏捷應用服務。

　　QCon 全球軟件開發大會于 5 月 6 日在北京正式拉開帷幕。5 位華為云布道師在“AI 與云原生實踐”專場發表了精彩演講。演講內容聚焦當前云原生的技術痛點以及 AI 相關的解決方案，向業界輸出了華為在相關技術層面的實踐經驗。

　　1、ServiceComb 協同開源和業界力量共同解決微服務痛點難題

　　華為云布道師首先分析了微服務的痛點以及面臨的挑戰，對于微服務的具體實踐，也給出了自己的看法。

　　微服務是用戶應用上云、全面解耦的基石

　　傳統 IT 應用開發過程中遇到的典型問題，比如煙囪型架構遇到的資源分散、數據不通問題；互聯網+轉型的傳統企業遇到業務上新周期長、流量不確定等問題，還有集團性大企業在數字化轉型過程中遇到個性化需求激增、多廠商難集成難管控等問題。

　　隨著云原生技術的發展，以虛擬機為資源服務的資源云化開始向以應用為中心提供能力服務的應用云化演進。微服務憑借其獨立、輕量級、去中心化、松耦合等特征，結合云上完善的自動化運維體系，幫助用戶構筑快速試錯、短平快交付、按需彈性的能力，解決用戶關心的痛點問題。因此，微服務也成為云化時代的流行架構，可以說，微服務是用戶應用上云、全面解耦的基石。

　　然而，微服務不是“萬能鑰匙”，它面臨著如何高效開發和上線、保障高可靠、問題快速定位與恢復、遺留系統低成本遷移等挑戰。這些都是華為各產品線微服務化實踐的精華，也因此衍生了易用、開放、多場景、企業級的微服務解決方案。

　　Apache ServiceComb 開源微服務解決方案

　　華為在 2017 年 6 月將內部實踐了 5 年、商用了 3 年的微服務解決方案無保留地開源到 ServiceComb，并捐贈給 Apache 基金會。2018 年 10 月成長為 Apache 基金會首個微服務頂級項目。

　　面對團隊協作困難、資源利用率低、問題定位困難、分布式事務和多語言等在微服務開發中遇到的挑戰，ServiceComb 堅持“將復雜留給自己，將極簡留給用戶”的設計理念，通過構建標準契約管理、異步內核、編程/通信模型分離、精細化監控治理、插件式集成等關鍵技術能力，幫助用戶實現最小成本改造、減少基礎設施運維工作量、提升系統性能和資源利用率、問題定位效率和靈活擴展。

　　“提供一站式的開源微服務解決方案，致力于幫助企業、用戶和開發者將企業應用輕松微服務化上云，并實現對微服務應用的高效運維管理”是 ServiceComb 社區的愿景。ServiceComb 不會止步，它將協同開源和業界的力量，在自己的技術積累基礎上繼續將微服務行業發展壯大，并分享給遇到微服務化難題的企業、用戶和開發者。同時，也將和同樣面臨數字化轉型的企業、用戶和開發者共同探討和持續創新解決微服務難題，促使行業更快地向云化轉型。

　　Apache ServiceComb 是如何幫助用戶實現微服務轉型的？

　　在大型企業做數字化轉型過程中，往往會遇到服務難拆分、開發效率低、系統性能弱、多語言集成以及多廠商集成導致的項目周期長、業務難打通、標準不統一等問題，這些都是單體的架構以及在傳統的微服務框架里面經常遇到的典型痛點。

　　ServiceComb 通過提供扎實的微服務技術支撐，結合更快、更穩、更經濟的華為云 ServiceStage 一站式應用開發平臺提供的支持多種編程語言，集成 Eclipse、IDEA、Jenkins、Maven 等多種工具生態，支持線下開發環境和線上云環境的無縫集成，面向 DevOps 提供應用開發、編譯、構建、發布、部署、配置、壓測、上線、運維和治理等全棧、全生命周期能力，幫助企業、用戶和開發者，快速實現數字化轉型上云。

• 沉淀服務化轉型要素、微服務拆分原則，確定合理及可持續演進的系統架構設計；

• 提供一鍵式腳手架、開箱即用的服務治理，降低微服務開發入門門檻；

• 支持 springmvc/pojo/jaxrs 多種編程風格，提升遺留系統重構效率，用戶最小改動實現微服務化；

• 首創服務契約管理，使數據、服務標準化，多廠商開發場景過程可管控，提升最終交付質量；

• 同時支持同步 / 異步通信共存和靈活組合，適應多場景的高性能訴求；

• 提供精細化監控和度量，解決多團隊 / 服務協作場景定位難問題，保障業務的線上運行質量；

• 融合華為開源的 Mesher 方案實現多語言支持，快速集成遺留應用及三方系統，并實現統一治理；

• 提供跨 DC、異構服務中心互通方案，支持跨云、跨 DC、多異構系統集成。

　　小結

　　ServiceComb 始終保持扎實做微服務，認真做開源的初心，協同開源和業界的力量，在自己的技術積累基礎上繼續將微服務行業發展壯大，共同解決微服務開發的痛點難題，為企業、用戶和開發者做實事。在推廣 ServiceComb 社區的過程中，不僅僅推廣技術，更是堅持同時布道微服務理念、微服務方法論和 Apache 開源文化，希望能竭盡所能在吸取業界智慧的同時為業界盡可能地多做貢獻。

　　2、容器多云 & 混合云解決方案（MCP）

　　在容器多云&混合云方面，華為云布道師分享了關于華為全球首個容器多云 & 混合云解決方案的實踐。

　　追溯華為云的歷史，華為云一直持續關注如何便利地實現混合云管理。近年來，隨著容器技術的迅速普及，其帶來的應用發布和部署接口的標準化給多云管理帶來極大的助力。華為云多年來也在容器領域持續引領 Kubernetes 社區 Federation 開源項目的構建。Kubernetes Federation 是容器多云 & 混合云解決方案的核心組件，通過 Kubernetes Federation 可以把容器應用非常方便地部署到多個 kubernetes 集群中并進行拉通管理。

　　目前容器多云 & 混合云解決方案已經驗證多個容器云的混合管理，包括各廠商的公有云以及私有云 Kubernetes 產品，也可以管理用戶基于開源自建的 Kubernetes 集群，實現應用的跨云部署和訪問，提供多云互聯網接入和容災能力。

　　而 CCE HCS Online，是華為基于 CCE 做的線下擴展，可以幫助用戶在本地的數據中心部署華為云 CCE 的 Kubernetes 服務。容器多云 & 混合云解決方案也可以很方便地拉通公有云 CCE 以及 CCE HCS Online 進行混合云統一管理。

　　另外在混合云場景下，容器多云 & 混合云解決方案也提供了多樣化的擴展插件能力：如基于 Prometheus 實現多云的統一監控框架，并支持多集群監控數據匯聚展示，并提供跨云的應用彈性伸縮能力；在混合云場景下，可以使用 Istio 進行跨集群的微服務調用、容災限流、調用跟蹤。

　　華為容器多云 & 混合云解決方案整體架構

華為容器多云&混合云解決方案整體架構

　　容器混合云，可以支持跨云管理，避免廠商鎖定。當前容器多云 & 混合云解決方案測試過管理包括華為云、OpenShift、阿里云以及用戶自建的 Kubernetes，也可以很方便靈活地調整各個集群中負載數量，實現應用靈活遷移和容災。

　　華為容器混合云和多云解決方案舉例

避免廠商鎖定

　　統一開放管理平臺

　　高效容災管理

　　3、CaaS 架構演進之路

　　華為云布道師周暉在演講中，首先回顧了 CaaS 架構演進歷程。

　　華為云布道師周暉

　　最早的 PaaS 來源于 Heroku。2007 年，Heroku 在云上提供應用托管服務，它有兩個非常大的貢獻：一個是貢獻了云原生的 12 要素；另一個是 Buildpack 機制，可以自動構建，自動打包，自動運行。Heroku 是公有云并沒有開源，沒有成為開源 PaaS 平臺，但是它為云原生、為容器做出了貢獻。從 2009 年開始，IBM 發布 WebSphere 的中間件，包括 Workload deployer，本質上是應用服務器的多租戶，難以支持第三方的應用服務器，不是現代意義上的 PaaS，后來的 Oracle 基于 Weblogic 的 PaaS 也是這條道路。

　　CaaS 架構演進之路

　　到 2011 年，Cloud Foundry 出現，它是現代意義上 PaaS 的雛形，引入了現代 PaaS 的概念。Cloud Foundry 目前仍在持續穩定的發展。

　　2013 年 Mesos 和 2014 年底 DockerSwarm 出現，但最后沒有修成正果。相反，Kubernetes 取得了成功。Kubernetes 的架構非常好，能夠真正形成生態。跟 Cloud Foundry 不一樣，Kubernetes 是對一個應用計算模型的抽象，應用只需要一個運行環境——Pod，其他交給 Kubernetes 來調度。至于是云原生應用還是大數據應用，這個模型抽象都可以適應。Kubernetes 分離了控制面和工作負載面，所有應用相關的功能，比如日志、監控等均不在模型中。作為工作負載的一部分，反觀 Cloud Foundry，把日志、監管、負載均衡均放在系統架構中，這樣嚴重約束了架構。如果要替換 Cloud Foundry 的日志，監管會有相當大的工作量，相當于是顛覆原來的 CF 架構。

　　為什么 Mesos 沒有走下去？Mesos 的架構來源于大數據架構，大數據的架構就是 Master 加 Slave。Mesos 連架構的名稱沒都改，它就是以大數據的模型來運行應用，顯然不合適。大數據是要以任務調度為主，但應用很多都是長周期的運行的，所有 Mesos 后來又加了一個馬拉松。

　　Kubernetes 的 Pod 是個非常好的設計，帶來了強大的可擴展性。只要在 Pod 中增加一個監管、日志的容器，就可以帶來相應的功能。再比如服務網格，只要在應用 Pod 中增加一個邊車容器，就可以實現應用的代理。這樣幾乎可以無限擴張各種功能，進而帶來了 Kubernetes 強大的生態。

　　而無論是 Cloud Foundry、Mesos、DockerSwarm 都缺乏 Pod 這種模型的架構，要擴展功能都會比較復雜，而功能擴展負載，必定會弱化其生態。

　　DockerSwarm 最后基本上也被邊緣化了。DockerSwarm 是做一個容器的抽象，缺乏 Pod 這種可擴展性的架構模型。

　　2019 年 PaaS 技術趨勢

　　對于 2019 年 PaaS 技術趨勢，周暉給出了自己的判斷：

　　2019 年，CNCF 的趨勢就是“ 從 K8s 獨木到 CNCF 生態森林"。從 2018 年至今，有 6 個 CNCF 項目畢業。而 Kubernetes 也成為事實標準，它所有的競爭對手 Mesos、Cloud Foundry、DockerSwarm 都支持部署 Kubernetes；即使是強大的公有云，如 AWS 有自己的調度，最后也提供了 Kubernetes 服務；微軟也有自己的調度 Service Fabric，2018 年也提供 Kubernetes 服務。從這些角度來看，Kubernetes 基本上就是云的應用平臺 OS。

　　第二個技術趨勢點是服務網格，服務網格是微服務領域發展的里程碑，促使微服務進展到新的階段，使得微服務應用有了新的選擇，可以不用代碼框架，而是通過平臺來實現微服務治理等功能，消除了目前微服務框架的痛點---現有應用微服務改造需要基于微服務框架重構。

　　第三個技術趨勢點是 Kubernetes 多云，包括今年 Google 發布其 Anthos 的容器多云服務。

　　第四，基于容器的邊緣計算也是逐步成為新的技術熱點。

　　第五，Serverless 也是 PaaS 的一個熱點趨勢，基于 Kubernetes 的 Serverless 得到越來越多的大廠商認可，并相繼推出了現有的產品或服務。

　　華為云容器創新

　　華為云容器是一個加速創新的過程，2015 年有一個比較大的創新點，2016 年有 2 個，2017 年有 3 個，2018 年有 6 個，并且每年以 50%~100% 的速度增長。今年上半年已經有 3 個了。2015 年華為選擇了 Kubernetes 作為容器服務的核心平臺，發展至今已經有 4 年了。一方面，華為云對 Kubernetes/CNCF 社區積極貢獻，另外一方面將成熟的部分做成商業化服務提供給客戶。華為云在 Kubernetes 的發展上，無論是對社區的貢獻還是企業級的功能，都是業界領先的。

　　華為云容器創新

　　有人說，對于開發者而言，云原生是最好的時代。以容器、服務網絡、微服務、Serverless 為代表的云原生技術，正在用一種全新的方式構建應用。除了云原生，AI 在推動企業數字化轉型上的影響力正在爆發。

　　4、Mask-RCNN 快速模型開發

　　華為云布道師孟繁亮針對如何基于 Mask R-CNN 快速完成模型開發，與現場開發者展開討論。

華為云布道師孟繁亮

　　Mask R-CNN 的核心

　　什么是 Mask R-CNN？Mask 模型不單單可以做圖像輪廓型的標注，甚至配以適當的數據集，連人體、姿態、骨骼、頭、軀干、四肢動作都可以標注。Mask R-CNN 核心的三大部分是 CNN、RPN、ROI。

Mask R-CNN 架構

　　Mask R-CNN 的演進歷程分為幾個階段：最早從R-CNN 開始，它的底層是 CNN 網絡。之后又出現了一個 Faster R-CNN，后來又加了 RPN 網絡，可以更好地處理一張圖片里面比較小的物體的問題，最后演化成 Mask R-CNN。之所以不斷演進是為了追求更有效的數據利用率，這里面的關鍵點，其實是 CNN、特征 ROI、RPN 特點是如何演化的。

　　具體看 Mask R-CNN 的構成，從 Faster R-CNN 進入，由 FCN 去處理摳圖，主體是 ResNet+FPN，最后增加 Mask。其中，ResNet 解決了傳統的人機神經網絡訓練不好收斂的問題。

　　舉例來說，人臉識別出來的效果一定是人臉越近會越大，人臉越遠會越小。這時候產生一個問題：怎么有效地把大的人臉識別出來？又怎么把小的人臉識別出來？

　　在 Mask R-CNN 里面，對一張圖做 5 種層次的卷積計算。根據 ResNet 圖，提取 C1 到 C5，標注從 C2 到 C5，做一個特征金字塔的計算。

RestNet——>FPN——>RPN

　　當我們有了很多特征之后，怎么樣從大大小小的特征里面收集有用的特征？于是引入了模框的概念。模框會把邊緣標出來，并根據不同的抽象層次，用這些模框去對比原始的標注信息。RPN 利用特征圖做兩件事情，一件事情是判定前景和背景，另外一件事是獲得最準確的推薦區域。

　　分類和目標檢測是指通過 full connect 層與 softmax 計算每個 region proposal 具體屬于哪個類別（如人，馬，車等），輸出 cls_prob 概率向量。同時再次利用 bounding box regression 獲得每個 region proposal 的位置偏移量 bbox_pred，用于回歸獲得更加精確的目標檢測框。

分類和目標檢測

　　5、NLP 在企業智能場景的算法應用

　　NLP 在近一兩年實現了顯著的突破，OpenAI 等技術的誕生、遷移學習等技術的成功應用使得 NLP 技術在不同行業領域內的發展不斷壯大。但與此同時，不同領域不同的場景中會遇到各種各樣的難題，例如面向企業的智能客服系統、智能助手、智能外呼等場景都會有很強的領域屬性。

　　華為云布道師在 QCon 現場深度解析了 NLP 在企業智能場景中的算法應用、模型優化，以及如何快速構建諸如智能對話系統等企業智能應用。

NLP 對話系統架構

　　自然語言相關的產品，大多對底層能力的要求很高，需要長期積累 NLP 基礎能力，這也是常常被忽略的一點。比如分詞，經常是系統效果不好的關鍵因素，在不同的場景可能用到的分詞粒度不一樣。同時需要能更好地把領域知識（如詞典等）與模型最更好的融合。再比如命名實體識別（NER），大部分與自然語言相關的一些問題，不管是問答、對話還是輿情都可能用到 NER，企業場景里的 NER 任務經常需要識別該領域或場景特有的類別。同時也需要高質量的標注數據來訓練模型，比較好的解決辦法是做多種方式融合的方案，比如說規則，與機器學習，深度學習的融合。

　　在對話系統中很常見的問題是意圖識別。一句話過來，讓機器人去理解其中的意圖，然后根據意圖決定后面該做哪些事情，這其實是個典型的文本分類問題，尤其是在企業場景中，容易遇到冷啟動的問題。可以考慮根據不同階段，選取不同模型。比如，前期冷啟動中使用一些無監督模型，或者一個基礎模型做分類；在數據量逐漸積累增多后，采用深度學習模型通常能夠取得較好的效果，現在也有研究人員利用知識圖譜對知識做泛化抽象，以增強模型效果。

　　與智能對話相關的應用場景有很多，在智能呼叫中心里有非常多跟語音語義相關的應用，如智能客服機器人、智能呼叫中心、外呼機器人等。在呼叫中心里，坐席人員接打電話，如果想知道坐席人員服務質量怎么樣，傳統方法是人工抽檢。而現在用機器做質檢，判斷坐席人員說話有沒有不恰當的地方。機器人也可以輔助坐席人員，幫助快速找到答案，從而提升坐席效率和用戶體驗。

　　6、寫在最后

　　在中國市場，云原生仍然是一個較為新的概念，多數中國企業在云原生的專業知識、部署開發以及管理應用的能力仍不成熟。令人欣慰的是，在云原生道路上，云廠商們已經充分意識到了云原生將是企業數字化轉型的加速器。

　　如今，大多數企業開始全面擁抱云計算，在 All-in-Cloud 全面到來的時代，有三個重要轉變：基礎設施的云化、核心技術的互聯網化、業務的數據化和智能化。在各行各業中，都有很多業務應用從誕生之初就生長在云端，各個企業也因此越來越像互聯網公司，而技術能力被視為不可或缺的核心競爭力。

　　正如人類社會發展伴隨著技術革命與社會大分工一樣，云原生技術的出現解耦了很多復雜性，這是 IT 技術的進步。

　　通過本次華為云“AI 與云原生實踐”專場的技術布道，讓開發者對云原生、容器、NLP、機器學習等技術有了更進一步了解，而華為云在上述技術上的實踐方案也在向業界不斷滲透，貢獻自己的一份力量。

　　此外，華為云另外兩位布道師也在今天的 QCon 大會上發表了演講，探討議題是：華為云深度學習在文本分類中的實踐，K8s 為 AI 應用提供大規模 GPU 算力之實踐。請大家持續關注。

總結

以上是生活随笔為你收集整理的AI与云原生，技术圈最火热的搭档的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。