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

這篇文章給大家介紹智能家居巨頭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 很多接口必選參數寫的看不明白，可讀性不太好

關于智能家居巨頭Aqara基于 KubeSphere怎樣打造物聯網微服務平臺就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。