七牛雲架構師實踐日第 32 期於 11 月 23 日在成都成功舉辦，以「容器技術的實踐與分享」為主題 ，邀請了多名業內大咖，為大家帶來了精彩演講。中移動物聯網有限公司基礎設施研發團隊負責人姜仁杰，在會上作了題為「物聯網業務的 cloud native 實踐與探索」的分享。
姜仁杰，畢業於東北大學，現就職於中移物聯網有限公司，負責物聯網開放平臺基礎設施研發。現擔任開放平臺基礎設施團隊技術負責人,主要負責 OneNET 雲原生基礎設施研發。
本文是對分享內容的整理。
首先我要改變一下大家的對中國移動的固有認識，很多朋友覺得中國移動作為一家傳統運營商，應該不太會有技術研發團隊，至少不太會往技術研發上過多入成本。但我們公司作為中國移動的全資子公司，也算是中國移動在自主研發上的探索與嘗試吧。目前我們物聯網雲平臺這塊就已經有 300 多人的團隊，其中研發人員佔 80% 以上，可以說我們的自主研發實力至少在運營商裡還是比較強的。我們的平臺 100% 自主研發，沒有依靠廠商。
接下來介紹一下我們的業務。我們的物聯網雲平臺名字叫做 OneNET，可以為行業客戶提供物聯網 IaaS/PaaS/SaaS 行業雲服務。當前我們 PaaS 平臺的這塊的設備連接數已經超過 7000 萬了，北向 API 每天調用量差不多 1.3 億左右，整個平臺生態上差不多有 9000 企業用戶，可以說平臺正處於一個快速發展的階段。
上圖是 OneNET 平臺的業務場景介紹。現在所有的廠家包括阿里雲、華為這些公有云的廠商在物聯網戰略方面都在提「雲、管、邊、端」佈局，管是什麼意思呢？管就是通信管道，管道是運營商擅長做的事，我們公司就有自己的管道業務平臺。管道可以理解為怎麼樣去管卡，資費、流量，「雲」這一端就是我們通常認為的雲服務，端就是指設備端，一般是芯片模組或者物聯網操作系統。「邊」就是我後面會講到的邊緣計算。
一個典型的雲管邊端協同的物聯網業務場景就是：設備與邊緣端建立連接，並且在邊緣端做大量的數據的處理和存儲，將少量的處理好的數據再和雲端通過通用物聯網協議來實現交互。同時客戶的 SaaS 應用可以託管在我們雲端的行業雲上。行業雲就是面向物聯網行業的公有云，我們的行業雲預計明年 3 月份就可以推出。
除了直接託管用戶的應用，ISV 還可以把軟件託管到我們的應用市場，賣給不具備研發實力的廠家或客戶，為這種客戶提供端到端的 Iaas/PaaS/Sass 解決方案。如果客戶要求很高，我們可以提供私有化一體機的產品，可以在你自己私有云裡完整部署一套物聯網行業的端到端的 Iaas/PaaS/Sass 的解決方案，另外我們的一體機裡面提供的私有云還可以和公有云組成緩和雲，用戶可以隨時擴展雲服務資源。以上就是我們相對比較完整的應用場景。
首先我來介紹下 OneNET 平臺的應用架構發展歷程吧，有了發展歷程，才能講為什麼後面我們要做對雲原生的一些探索。從開始到現在, OneNET 經歷了差不多 4 年的時間，整個平臺也不是一帆風順發展過來的。我覺得每個企業針對自己的業務都會有一個完整的發展階段，OneNET 也是這樣，從剛開始三四個人的團隊，到現在 300 多人的團隊。業務架構和技術架構的決策原則都會隨著關注點的不同不斷調整。
在 OneNET 初期，最重要的生存，所以初期的架構決策原則就是識別出潛在客戶，找到最核心的需求，要快速上線。另外物聯網 PaaS 是一個很不錯的切入點，所以初期我們主要做 PaaS 這一塊， OneNET 初期就是一個很簡單的單體架構，不過對於初期的需求，我覺得已經足夠了。好了，初期階段過了以後，業務逐漸發展，特別是在 2016 年開始，我們的設備連接數處於爆增的階段，單體機構已經不能再滿足你的的業務發展需求，這裡面的需求來自於幾個方面，第一個是團隊大了之後，大家都在這個單體架構上進行開發，肯定是不太可能了，另外平臺已經要需要保證高可用了，不能說三天兩頭就宕機。因為已經開始有生產業務依靠 OneNET 了。另外，產品功能還得不斷地迭代，來滿足市場以及未來新的需求，還有就是所有研發團隊都要在統一的研發基礎設施上玩，不然就會徹底亂套。初期由於研發缺乏規則和標準，沒有統一的基礎設施，我們在這方面吃了很多虧，走了很多彎路。需求越來越多，研發速度跟不上，運維變更越頻繁，可用性越低，平臺已經危機重重，上線已經變成拆彈，誰都不知道會不會爆炸（全場笑）。
所以，是時候現在我們的單體業務架構進行改造了，但是改造不是請客吃飯，要說服業務團隊去配合你改造是非常難的，因為業務團隊比較有話語權比較強勢，同時他們從心理上還是有牴觸情緒的。但是我覺得業務有牴觸情緒也可以理解，首先你作為一個對他業務的穩定性有威脅的事情，肯定會有所顧慮，同時還會在初期給他們帶來額外的學習成本。好在老闆在這塊還是比較有眼光，知道長痛不如短痛。所以自上而下，我們的壓力小了很多。當然我們自身也下了很多的力氣來說服這個團隊，比如想辦法減少各個業務研發團隊學習成本，又比如用數據來說明我們的優勢和穩定，所以我們目前業務改造還算順利，大家已經開始接受這種服務化的思維。但是初期由於業務改造難度實在太大，只能化繁為簡，先提供一個相對比較簡單的架構，至少讓大家有這個服務化的意識。
雖然做了服務化，實際上還是有很多存在的問題。比如說前端 API 網關與負載均衡框架耦合的問題，對 RPC 框架例如 gRPC 的支持不好。由於網關是用的 Nginx，服務治理需要寫 LUA 進行控制，另外從 DevOps 角度來說，服務的交付到下線的全生命週期管理還有多個階段沒有進行覆蓋，服務化了，但是構建和發佈的頻率也同樣成幾何倍增長。另外，代碼質量這些老問題也越發突出，越來越難以管控。服務化組網趨於複雜，穩定性也無法得到保證。最後一個也是我覺得最重要的，就是老闆和各個團隊對你做的工作的價值沒有一個很直觀的感受，到底好了，好在哪裡？也就是無法衡量服務化後的價值。
雲原生的概念我先給大家解釋一下。雲原生是 2015 年由 pivotal 公司提出來的一個概念， CNCF 也就是雲原生計算基金會，對雲原生給出了一個相對詳細的定義，中文版本是這麼說的：雲原生技術幫助各公司或組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和生命式 API。這些技術能夠構建容錯性好、易於管理、便於觀察和松耦合系統。結合可靠的自動化手段，雲原生技術可以使開發者輕鬆地對系統進行頻繁並可預測的重大變更。CNCF 基金會為了達到這個目標，在旗下也在孵化很多相關的開源的軟件。大家可以去看 CNCF 那張經典的 landscape 圖裡麵包含 CNCF 正式旗下的軟件。
OneNET 現在最新迭代的版本是 4.0，那麼首先我們的痛點和問題上面已經說到了，雲原生剛好也可以幫助我們去解決這些問題，所以我們在應用架構設計和基礎設施方面參照了雲原生的思路：利用微服務+容器+不可變基礎設施+自動化手段去解決上面我提到的關於交付過程中自動化水平較低的問題。其實也就是 DevOps 的方法論裡面所倡導的東西。當然我們的最終的目標也是和上述目標一致的：希望建容錯性好、易於管理、便於觀察和松耦合系統。
首先從應用架構來講，業務架構方面我們會遵照所謂的 12 要素，12 要素是關於微服務和雲原生應用架構的基本原則。是 heroku 這個商業 PaaS 服務提供商提出來的一個關於應用架構指導原則，比如基準代碼，關於配置和依賴的一些建議。大家可自行 google 下細節，由於時間關係，這個我這裡不做重點介紹，另外是服務通信這塊主要就是結合統一 API 和 Service Mesh 實踐，基礎設施這一塊我們主要是基於 K8S 打造自己的 PaaS 平臺，這一塊也是進行中，還有完善的空間。最後指導我們改造的方法論，主要就是 DevOps 了。說到 Devops 感覺現在大家都聽過，但是具體什麼意思比較模糊了，這裡說下我對 DevOps 的理解吧，其實我覺得就是儘量縮短把一個需求變成可用的產品的時間的最佳實踐，在縮短週期的同時要提升交付軟件的質量。當然 Devops 是一套完整的方法論和實踐的集合，我的理解可能只是一方面。
我們基於 Kubernetes 構建了內部的研發基礎設施 PaaS 平臺，devops 這塊就不多說，都是常規技術，服務目錄我們是基於 helm+operator 來做的。監控用的自己的 +prometheus，網絡用的 calico。服務代理那一塊實際是在混合雲方面的探索， kubernetes 有項目叫做 service broker，主要就是混合雲管理的，這個在邊緣計算和公有云協同的場景，非常有用。另外我們在 AI 和大數據在 k8s 上也做了一些探索的實現，到目前沒有批量上。整個 OneNET 的能力們以統一應用市場包括 API 市場的形式，把我們的能力對外輸出，產生一些商業模式。
這是完整的 DevOps 的流水線，也是自源+開源的模式。監控方面我們投入了很多精力去做，因為我們發現可能開源的監控能滿足日常關於監控場景的 95% 的覆蓋，但是另外那 5% 的監控場景，可能會和 20% 以上的引起故障的場景相關，所以我們覺得這種投入是值得的。另外在研發管理這塊，我們自己研發了一個項目管理工具，來進行項目管理，CI/CD 流水線是基於 jenkins 來做的上層封裝，這塊沒什麼可多說的。
在測試這一塊，我們做了一些物聯網場景的全鏈路壓力測試的實踐。全鏈路壓測其實在互聯網公司用的比較多，我們也是借鑑了很多互聯網公司的經驗。我們的痛點和互聯網公司也略微不同，物聯網的場景相對簡單，只有南向和北向的對外提供服務，這不是我們主要的測試點，但是物聯網這個行業有很大的特點就是物聯網行業協議特別多，隨便說出十幾個協議都可以。所以在做壓測的時候按照一個什麼樣的比例的流量來對壓測環境的應用進行整體壓測呢，這個不好預估，所以壓力測試的時候，流量模型這塊不是很好造數據。
於是我們的全鏈路壓測的流程就是：我們將線上流量的 TCP 報文拷貝下來作為一個個文件保存到對象存儲裡面，然後對 TCP 報文進行脫敏，把涉及安全敏感的一些內容抹掉，同時把目的 IP 和端口這些信息修改為壓測環境的，另外還可以利用程序對流量進行放大。然後再把數據通過我們的一個 worker 線程池解析出來推到壓測集群去，最後利用分佈式的壓測集群將力量打到壓測環境，這樣就形成一個和真實環境一模一樣的流量模型，這樣就可以避免自己去造壓力測試模型不準的問題。另外可以結合監控自動生產性能非常豐富的測試報告。在變更方面也可以利用線上流量進行線下的灰度發佈，這樣可以在上線之前，儘量在預發佈環節看到風險和隱患。當然這塊也是在持續優化的階段，還有很多工作需要做。
剛才提到關於監控方面我們也投入了很多人力。監控這塊我們也是站在巨人的肩膀上，我們基於小米開源的 Open-faclon 做了定製化開發，改了他很多東西。比如在 agent 增加對 gRPC 的支持，對 agent 上報數據性能提升優化、增加對自研的鏈路監控 SDK 的數據上報的支持，重寫了整個 portal，重構了數據存儲模塊等等。這樣我們從基礎資源監控到中間件監控到業務層面監控到外圍的服務質量監控我們都可以統一用一套基礎設施來實現。
這是我們鏈路監控的截圖，主要就是做一些鏈路性能的分析。鏈路監控這個互聯網公司也講得比較多，開源的也不少。只是我們支持更多的語言，因為我們內部語言確實很多，所以開源沒辦法做到開箱即用。
另外一個就是我們的服務質量監控，我們對目前雲平臺對外提供的所有服務 API 都有實時監控，我們有一些在各地機房的探針在實時探測我們服務的質量。
另外基於我們的統一監控基礎設施，如果說作為一個應用，有定製化的監控需求，可以通過統一的基礎設施來實現數據的上報。然後再監控 portal 上可以通過圖表組件，可以把自己上傳的數據，通過圖標來實現對監控數據的圖形化的展示，非常靈活。
上面這是我們內部的告警平臺，我們把內部所有的告警做了匯聚。關於告警風暴的過濾我覺得還可以，結合逐步優化的告警策略專家系統，基本上能過濾到只剩 5%，1000 條告警裡只有 50 條會真正發出去，這塊由於業內沒有太多數據，所以沒法橫向對比，但是我們內部還是比較滿意。
另外我剛才提到，老闆或者研發 leader 這個層面，其實他們覺得用這個東西好用與否，或者對他們而言在成本和效益上有沒有真正的提升是需要一個具體可量化的感受的。所以，我覺得研發質量以及交付效率和交付產品性能和質量的可度量的原則是非常重要的。所以說我們的研發質量，像覆蓋率這樣的數據可以通過掃描工具，實時以看板的形式呈現給老闆。像代碼的安全風險、變更的故障比例，老闆一看就知道哪些業務做得好哪些做得不好。自然就可以驅動大家代碼質量的提升。另外，我們可以把性能量化，你的平臺和上週的同比，和本週的環比，這些相關數據可以實時呈現出來，這樣老闆就可以給團隊下一個 KPI，你的性能必須要提升 20% 或 30%。現在就可以有一個比較量化的手段去做這件事。
DevOps 有持續反饋的實踐，我們按照事前、事中、事後這一套端到端可用性方案提升閉環。事前通過我們的壓力測試，通過我們的預發佈環境，在用戶發現問題之前提前發現問題，事中我們可以通過檢查監控是不是足夠靈敏。當然事中發現問題，我們還檢測我們的干預手段是否達到我的目標，我能不能在發生問題之後，第一時間將問題的影響降到最小。在做完這一套完整的動作之後，再去做總結，剛才的手段裡哪個環節是做得不好的，哪個是需要在事前場景裡增加檢測的，做完總結之後再反饋給事前驗證。這是一個完整的端到端閉環，這樣就可以持續去提升我們平臺的可用性。
Service Mesh 在去年下半年開始雲計算領域比較熱門的技術，中文翻譯成服務網格，他是為了解決為服務化後服務實例間通信和服務治理異常複雜的問題。也就是實現服務和服務通信基礎設施的解耦。我們怎樣能實現業務開發人員不用關注調用的服務在哪裡，不用關注怎麼樣去做限流、怎樣保證服務的重試？業務人員只需要開發代碼就好？service mesh 就是將服務治理的這些工具完全和服務本身的業務邏輯解耦。
service Mesh 當前比較主流的實現就是谷歌為主導的 Istio+envoy，我們的方案也是基於這一套。但是我們做了一些改造，因為我們的業務裡面有一部分業務是非 k8s 的，所以我們必須提供一套同時兼容 k8s 和非 k8s 的微服務基礎設施。這裡，我們也參考了Ucloud 提出一套方案。Istio 作為控制平面，主要有三大模塊，一個叫做 pilot，做是做控制策略下發以及和用戶交互的。另外一個 mixer，主要是實現一些後端服務和應用解耦的接口。還有一個叫做 citadel,主要是做安全權限管理的，Istio 主要是依賴 k8s 的服務治理這一部分，另外當前 mixer 對性能有所影響，還有我們都是在內部通信，安全級別不用那麼高，所以，我們只抽取 pilot 來用，mixer 和 citadel 都去調，鏈路監控和其他監控都用我們自己研發的那一套。然後為 pilot 寫了一個 etcd 的 adpater,把數據都存儲在外圍的 etcd 裡面。應用啟動後先到etcd裡面進行服務註冊，並保持監控檢測的心跳連接。這樣就實現了和 kubernets 的解耦。
但是我們發現在實際的實踐中，這樣改造成本和運維成本還是挺高的，為了脫離 K8S 代價看起來很美好，但是實際的要付出很大的代價，所以想要享受技術的紅利，基礎設施也要跟得上才行。為什麼代價很大呢，雖然沒有使用 kubernetes，但因為需要模擬 k8s 的 sidecar 架構，所以而是使用 docker compose 來進行編排管理。但是這樣做也是沒有辦法的辦法，為了統一基礎設施，兼容非 Kubernetes 業務，必須做出一些妥協。但這也是過渡方案吧，後續我們還是會跟隨社區朝著 Istio 大版本的迭代，我們只是在做一些上層的開發。
剛才提到邊緣計算，那什麼是邊緣計算呢，這裡做個粗暴間的介紹，邊緣計算其實就是把雲端的功能完整搬到離客戶設備最近的地方為設備提供服務，我舉個例子，我們在工業互聯網的一些客戶裡接觸到有些機床設備每天產生的數據量大概在 10TG 左右，如果把這些數據全部回傳到雲端是非常困難的。還有自動駕駛，自動駕駛如果斷網等極端情況就失效了那就太可怕了，所以自動駕駛的場景、包括工業互聯網、智慧園區等場景下它大部分計算都需要在車載系統或者車間旁邊的服務器裡面，處理之後直接回傳給設備，這樣確保它的時延低，同時安全性高，因為數據沒有傳到雲端。另外有些廠家國外的設備都是很敏感的，都不會讓你存到雲端去。
我們提供 OneNET Edge提供了很多協議的接入，可以接大部分協議的工業的設備或者傳統物聯網設備，邊緣計算可以支持給設備下發命令，規則引擎，報警通知，流式計算。北向通過 API 實現數據北向數據的推送，可以推給客戶的 MES 或者資產管理的系統。另外我們還支持雲端訓練好的 AI 算法模型，直接在 oneNET Edge上運行。另外 OneNET Edge 是基於 kubernetes 的，所以可以很方便的在遠程運維。客戶的技術支撐可以做得更好。OneNET Edge還支持可拔插的分佈式部署，可以根據客戶現場的計算資源靈活的選擇需要部署的模塊，如果僅僅部署核心模型的話，可以在一個資源很受限的網關裡面就可以實現部署。這裡面容器和 Kubernetes 為我們提供了很好的環境一致性，以及可編排的特性，增強了業務的靈活性。
Serverless 在邊緣計算業務實踐的 Open FaaS，我們把關注的資源粒度從傳統的虛擬機到容器，再到函數級別，有了函數計算（FaaS）用戶只需要寫一個函數，這個函數提交到雲端，雲端啟動過後，函數會輸入參數獲取到。在這個過程中用戶完全不需要運維人員，因為他只寫了一個函數，雲平臺運行就可以了。同時，我是按照調用次數來收費的，晚上沒有人調用就不收費，但是傳統的雲計算是達不到的。FaaS 函數計算的這種場景從資源的角度來講，是非常節約我們的資源。另外，事件驅動，客戶有一些私有化的定製協議，這些協議需要去解析它的協議的報文，不可能每一個協議都要寫接入側的服務，有了FaaS 之後，我自己寫一個 FaaS 函數計算就可以了，不管什麼私有協議，只要是基於 TCP 上來的連接，我都可以自己寫一個 FaaS 函數解析報文，來獲取你的業務邏輯來做計算。FaaS在邊緣計算這一側是有很多潛在的使用場景的。
以 Open FaaS 為例，首先用戶編寫一個函數，然後利用 openfaas 打包工具會將用戶的函數以及 openFaaS 提供的默認模塊 watch dog 打包在一起組成一個容器鏡像。當前端用戶通過 HTTP 請求調某個函數時，首先網關會接收這個 HTTP 請求，網關這裡會監控某個函數的調用請求量，實時決定現在 TPS 是否已經達到某個閾值，若超過就自動擴展後端的函數對應啟動的容器數量。網關將請求轉發給 provider，provider 知道我寫的 A 函數、B 函數在哪兒被部署，會把請求轉到我們後端真實的函數對應的某個容器實例上，實現對函數調用。這個過程當中，你只寫函數，可以根據監控的數據來實現。這樣可以根據業務的併發量級在用戶無感知的情況下實現業務函數的自動縮擴容。當然沒有用戶就直接把它縮為零。而且我的收費模式可以通過調用次數來實現收費，這徹底改變了大家對於雲計算商業模式的觀念。對於 Open FaaS 的改造，通過事件驅動的方式就可以實現對 Open FaaS 的調用。主要是增加對 kafka 的支持，因為他原生只提供rest調用方式。另外我們對 faaS 的性能也做了多處優化。
最後和大家分享我們未來需要解決的三個挑戰。第一，混合雲（雲邊一體）的管理能力：怎麼實現在邊緣端，或者私有云裡用戶去創建一個服務，但是這個服務有可能在公有云裡，然後兩邊組成混合雲的架構為客戶提供服務，這是我們正在為之努力的地方。第二，多數據中心（多 Kubernetes 集群）的統一管理能力。第三，對 Iaas 與 PaaS 統一調度管理的能力做進一步融合，接下來我們也會做一些探索和實踐。
我今天的這裡，謝謝大家。
閱讀更多 七牛雲 的文章
