智能家居巨頭 Aqara 基於 KubeSphere 打造物聯網微服務平臺

背景

從傳統運維到容器化的 Docker Swarm 編排，從 Docker Swarm 轉向 Kubernetes，而後在 Kubernetes 運行 SpringCloud 微服務全家桶，到最終擁抱 KubeSphere，並基於 KubeSphere 打造綠米聯創本身的物聯網微服務平臺，綠米聯創已在生產環境中穩定運行 KubeSphere 和 Kubernetes 半年多時間，積累了豐富的微服務應用開發以及應用平臺運維的經驗。本文由深圳綠米聯創科技有限公司的運維工程師魏恆生與徐洋冰投稿，圖片素材來自 Aqara 官網（https://www.aqara.com/）。

Aqara 簡介

深圳綠米聯創科技有限公司（簡稱「綠米聯創」，官網 https://www.aqara.com/）成立於 2009 年，總部位於深圳，覆蓋超低功耗無線傳感器、Zigbee 無線網絡技術、智能家居網關邊緣計算技術、算法與 AI、平臺開放與接入能力等方面。2016年，深圳綠米聯創科技有限公司推出了「全屋智能」理念的自有品牌 Aqara（Aqara 源自拉丁語 acutula，意爲聰明，ARA 是回家的意思，Aqara 將二者結合意味着家庭愈來愈智能化）。Aqara 致力於經過一系列智能家居產品技術以及服務商模式，爲用戶構建更加智慧的生活。Aqara 旗下產品包括溫度、溼度、門窗、人體、水浸、煙霧、燃氣、光照和睡眠等各種傳感器，以及智能開關、插座、窗簾電機、空調控制器、調光器、門鎖等各種智能控制器，目前同時支持行業應用的自動化控制與大數據分析平臺。

Aqara 秉持着「引領物聯技術，服務千家萬戶」的願景，堅持「鍥而不捨追求用戶體驗 堅持不懈創造用戶體驗」的使命，在智能家居行業不斷創新，最終成爲行業領軍品牌。

從傳統運維邁向容器技術

一入運維深似海，魏恆軍做爲一名多年工做經驗的資深運維工程師，從最初的扛機器上機房，在工做中生疏的操做着網線鉗，麻木地安裝着操做系統，費力地部署應用程序和調試着應用服務，以及在那黑夜因一連串告警驚醒，永遠感受本身是個偉大消防員。

Data Center（圖片來自 Unsplash）

技術的快速迭代更新，迎來了微服務，迎來了虛擬化技術，也迎來了容器化與雲原生技術。運維也從最初的人肉運維發展到腳本運維，再到平臺運維，最後到如今的容器運維。本人運維過的機器，不知不覺也從我的維護幾十臺到如今的近千臺服務器，傳統的應用部署方式，每次迭代一次，都須要花費大量的時間去準備配置文件、操做注意事項、數據庫等等，而後再通過一羣人層層審批，再發到線上，這期間已通過了半個月，在這個互聯網比速度的時代，顯然這種傳統方式劣勢很是明顯，而容器應時勢而生。

使用 Docker Swarm 搭建容器編排系統

傳統部署應用方式，資源利用率很是低，時長讓老闆們本狠狠地咬牙切齒。在這種狀況下，本人在 2017 年開始接觸容器，嘗試着在公司上開發與測試環境。當時直接給公司開發、測試環境的資源利用率提升了 50%。到 2018 年，開始在生產環境用 Docker Swarm 排編容器，更顯著提升了資源的利用率。

從命令行到腳本化，最後到平臺化，一路走來步步艱辛。當剛開始加入綠米你們庭，發現綠米運維還處在原始野人階段，回顧四周，我只能屢起袖子頂着壓力分析狀況，發現綠米的微服務架構 80% 以上都是偏內存型服務，資源利用率很是低，尤爲是 CPU、磁盤存儲，十分讓人懊惱。且迭代速度也不盡人意。靜心思靜，決定大改這種情況。從持續集成開始、Jenkins、Harbor 搭建，到測試環境 Docker Swarm 排編。這大大改善了測試環境的交付速度以及交付質量，但慢慢發現，業務量曾漲速度太快，Docker Swarm 排編劣勢明顯：

• 跨平臺支持效果差；

• 業務量訪問高峯期的時候，內部 Service 通訊的時候就會出現超時的問題

從 Docker Swarm 全面轉向 Kubernetes

三架馬車時代已經是過去式，Kubernetes 擊敗 Docker Swarm 和 Mesos 成爲容器編排領域的事實標準。所以，咱們的業務架構從 Docker Swarm 全面轉向 Kubernetes。選擇 Kubernetes 幾年前就在內心紮根，尤爲是近來須要運維近千臺機器的時候，一個運維友好與統一的容器雲平臺成爲了咱們基於 kubernetes 大規模落地雲原生微服務應用的剛需。

開源容器平臺選型：擁抱 KubeSphere

可是對於原生安裝與運維 Kubernetes 仍是藉助第三方開源方案，咱們通過反覆的琢磨，最終選擇了使用第三方開源項目。看來看去 Rancher 和 KubeSphere 成了考慮的選型。

KubeSphere 是由青雲 QingCloud 發起並聯合多個企業共同參與開發的開源項目。對比 Rancher 和 KubeSphere，後者不只有清爽的操做界面，嚮導式的資源建立方式，徹底以應用爲中心，更傾向於 Kubernetes 集羣資源的管理，提供優雅的 API 接口，而且在 Kubernetes 之上集成與包裝了咱們運維開發經常使用的功能組件，例如 Jenkins、Harbor、Promethues、Apache SkyWalking，還支持在任何基礎設施環境部署，因此咱們堅決果斷的選擇了 KubeSphere 容器平臺。

KubeSphere 跨多雲平臺的兼容、以及支持多插件的選擇，在使用過程當中加深了咱們對 Kubernetes 各個模塊的理解、推動了咱們對生產環境落地 Kubernetes 容器編排的步伐。而且，KubeSphere 解放了咱們運維平常面臨的重複的工做，減低了應用的總體維護成本。是運維的一把利器，是互聯網公司的一道福音。

綠米物聯網微服務平臺部署架構

目前公司主要是在騰訊雲上用 7 臺服務器來構建集羣，集羣機器的配置規格以下。

目前全部的無狀態的服務都運行在 KubeSphere，有狀態的數據存儲類服務，咱們使用雲上的 Redis、HBase、Flink、Elasticsearch、MySQL 等集羣服務。

截止目前爲止已經運行半年多且無大問題出現，這推進咱們計劃近期把公司開發、測試、生產環境中全部的有狀態和無狀態服務所有遷移到 KubeSphere 上去。

綠米物聯網微服務平臺設計架構

首先能夠看看綠米物聯網的業務架構圖，目前綠米海外地區的服務，基本上所有都運行在 KubeSphere 之上，包括 Gateway 微服務路由調度、Push、Send 推送、iftt 定時等等。

因爲咱們的業務以 Java 爲主，所以綠米物聯網微服務平臺是基於 SpringCloud 框架進行微服務化，使用 Apollo 分佈式配置中心管理配置，Eureka 註冊中心服務註冊與發現。

結合 Ribbon、Feign 實現微服務負載均衡以及服務調用。同時，咱們使用 Hystrix 線程池實現隔離、熔斷以及降級、sentinel 限流，而 springcloud-gateway 網關路由則用來實現路由調度，日誌使用的是經典的 ELK 組合，APM 使用 SkyWalking 做爲 Java 微服務分佈式系統的應用程序性能監視工具。

如上圖所示，IaaS 咱們使用的是騰訊雲，Platform （平臺層）主要是物聯網業務平臺的微服務，Platform 層的絕大多數應用都運行在 KubeSphere 容器平臺之上，全部子設備經過 Zigbee 協議 鏈接 Hub 設備，即智能網關、智能插座網關、攝像頭等，Hub 設備經過 RPC 協議與綠米智能家居的微服務平臺通訊，微服務平臺爲 App、SaaS 等應用提供數據，反向應用經過一系列安全鑑權、認證來調用綠米微服務平臺，實現控制智能家居設備。服務層擁有鏈路追蹤、基礎監控、CI/CD 等插件。

KubeSphere 讓咱們對 Kubernetes 的入門變得更簡單、加快推動生產環境 Kubernetes 的上線，對業務迭代有明顯的效率提升，而且可以讓研發更快地隨意切換部署驗證各個應用的功能模塊。

截止目前爲止，這一套物聯網微服務平臺已經在咱們綠米聯創的生產運行半年多且無大問題出現，所以，咱們計劃在近期把公司開發、測試、生產環境中全部的有狀態和無狀態服務所有遷移到 KubeSphere 上去。

問答

Q：使用過程有沒有遇到什麼問題？

A: 有的，好比 DevOps 流水線解決 War/Jar 包發佈問題。DevOps 流水線既要解決打包鏡像到鏡像倉庫，同時要兼容老業務 war 包經過 Ansible 分發的部署方式，起初一直沒有解決方案。

通過一番研究後，我理解整個 DevOps 的流程是 jenkins-agent 拉取對應模板的 Pod，跑完 Pipline 的各個流程，但問題又來了，Java 模板的 maven Pod 執行完以後退出了，卻無法獲取到編譯後的 Jar 包。

最終咱們發現，能夠登陸 Jenkins 服務端，選擇 Manage Jenkins => Configure System，找到對應的模板，如截圖所示操做，在 Pipline 裏面指定 mav package -Dpath=${target_path}，方可解決上述解決問題！

Q：什麼樣的應用開發平臺，才能承載智能家居的將來？

A：完善的審計、監控告警，權限分發，而且能自定義優雅的資源擴縮容策略，優雅的插拔式插件個性化定製，平臺自身的常規問題自查策略，以及清晰明瞭的日誌，好在這一切都在 KubeSphere 容器平臺支持了。

Q：KubeSphere 哪些功能或設計還須要改進？

A：建議以下：

• 界面語言切換太隱蔽；
• Granfana 模板集成靈活度能夠再多一點；
• 對 Kubernetes 節點擴容能夠變得更簡單一點、最好支持界面化節點擴容。
• 建立 pipeline 支持 copy from；
• 運行 pipeline 支持多選批量；
• api文檔最好有些 example，如今的 Swagger 不少接口必選參數寫的看不明白，可讀性不太好

後記

很是感謝綠米聯創的兩位用戶帶來的物聯網微服務平臺在智能家居行業的落地實踐分享！從傳統運維到容器化的 Docker Swarm 編排，從 Docker Swarm 轉向 Kubernetes，而後在 Kubernetes 運行 SpringCloud 微服務全家桶，到最終擁抱 KubeSphere，並基於 KubeSphere 打造綠米聯創本身的物聯網微服務平臺，這也是國內一部分企業的應用微服務平臺的演進過程。

若是你們對綠米聯創的物聯網微服務平臺的落地實踐的詳細實現很是感興趣，但願進一步瞭解以及跟兩位工程師交流，歡迎你們加入 KubeSphere 開源社區交流羣。咱們後續會根據你們的須要邀請兩位工程師爲你們作一次線上的技術直播分享。另外，若是您但願分享 KubeSphere 和 Kubernetes 在您企業環境的落地實踐，咱們也很是歡迎您投稿！