智能家居巨頭Aqara基于 KubeSphere怎樣打造物聯(lián)網(wǎng)微服務平臺

這篇文章給大家介紹智能家居巨頭Aqara基于 KubeSphere怎樣打造物聯(lián)網(wǎng)微服務平臺，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

背景

從傳統(tǒng)運維到容器化的 Docker Swarm 編排，從 Docker Swarm 轉(zhuǎn)向 Kubernetes，然后在 Kubernetes 運行 SpringCloud 微服務全家桶，到最終擁抱 KubeSphere，并基于 KubeSphere 打造綠米聯(lián)創(chuàng)自己的物聯(lián)網(wǎng)微服務平臺，綠米聯(lián)創(chuàng)已在生產(chǎn)環(huán)境中穩(wěn)定運行 KubeSphere 和 Kubernetes 半年多時間，積累了豐富的微服務應用開發(fā)以及應用平臺運維的經(jīng)驗。本文由深圳綠米聯(lián)創(chuàng)科技有限公司的運維工程師魏恒生與徐洋冰投稿，圖片素材來自 Aqara 官網(wǎng)（https://www.aqara.com/）。

Aqara 簡介

深圳綠米聯(lián)創(chuàng)科技有限公司（簡稱“綠米聯(lián)創(chuàng)”，官網(wǎng) https://www.aqara.com/）成立于 2009 年，總部位于深圳，覆蓋超低功耗無線傳感器、Zigbee 無線網(wǎng)絡技術(shù)、智能家居網(wǎng)關(guān)邊緣計算技術(shù)、算法與 AI、平臺開放與接入能力等方面。2016年，深圳綠米聯(lián)創(chuàng)科技有限公司推出了“全屋智能”理念的自有品牌 Aqara（Aqara 源自拉丁語 acutula，意為聰明，ARA 是回家的意思，Aqara 將兩者結(jié)合意味著家庭越來越智能化）。Aqara 致力于通過一系列智能家居產(chǎn)品技術(shù)以及服務商模式，為用戶構(gòu)建更加智慧的生活。Aqara 旗下產(chǎn)品包括溫度、濕度、門窗、人體、水浸、煙霧、燃氣、光照和睡眠等各類傳感器，以及智能開關(guān)、插座、窗簾電機、空調(diào)控制器、調(diào)光器、門鎖等各類智能控制器，目前同時支持行業(yè)應用的自動化控制與大數(shù)據(jù)分析平臺。

Aqara 秉持著“引領(lǐng)物聯(lián)技術(shù)，服務千家萬戶”的愿景，堅持“持之以恒追求用戶體驗 堅持不懈創(chuàng)造用戶體驗”的使命，在智能家居行業(yè)不斷創(chuàng)新，最終成為行業(yè)領(lǐng)軍品牌。

從傳統(tǒng)運維邁向容器技術(shù)

一入運維深似海，魏恒軍作為一名多年工作經(jīng)驗的資深運維工程師，從最初的扛機器上機房，在工作中生疏的操作著網(wǎng)線鉗，麻木地安裝著操作系統(tǒng)，費力地部署應用程序和調(diào)試著應用服務，以及在那黑夜因一連串告警驚醒，永遠感覺自己是個偉大消防員。

Data Center（圖片來自 Unsplash）

技術(shù)的快速迭代更新，迎來了微服務，迎來了虛擬化技術(shù)，也迎來了容器化與云原生技術(shù)。運維也從最初的人肉運維發(fā)展到腳本運維，再到平臺運維，最后到現(xiàn)在的容器運維。本人運維過的機器，不知不覺也從個人維護幾十臺到現(xiàn)在的近千臺服務器，傳統(tǒng)的應用部署方式，每次迭代一次，都需要花費大量的時間去準備配置文件、操作注意事項、數(shù)據(jù)庫等等，然后再經(jīng)過一群人層層審批，再發(fā)到線上，這期間已經(jīng)過了半個月，在這個互聯(lián)網(wǎng)比速度的時代，顯然這種傳統(tǒng)方式劣勢非常明顯，而容器應時勢而生。

使用 Docker Swarm 搭建容器編排系統(tǒng)

傳統(tǒng)部署應用方式，資源利用率非常低，時長讓老板們本狠狠地咬牙切齒。在這種情況下，本人在 2017 年開始接觸容器，嘗試著在公司上開發(fā)與測試環(huán)境。當時直接給公司開發(fā)、測試環(huán)境的資源利用率提高了 50%。到 2018 年，開始在生產(chǎn)環(huán)境用 Docker Swarm 排編容器，更顯著提高了資源的利用率。

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

• 跨平臺支持效果差；

• 業(yè)務量訪問高峰期的時候，內(nèi)部 Service 通信的時候就會出現(xiàn)超時的問題

從 Docker Swarm 全面轉(zhuǎn)向 Kubernetes

三架馬車時代已是過去式，Kubernetes 擊敗 Docker Swarm 和 Mesos 成為容器編排領(lǐng)域的事實標準。因此，我們的業(yè)務架構(gòu)從 Docker Swarm 全面轉(zhuǎn)向 Kubernetes。選擇 Kubernetes 幾年前就在心里扎根，尤其是近來需要運維近千臺機器的時候，一個運維友好與統(tǒng)一的容器云平臺成為了我們基于 kubernetes 大規(guī)模落地云原生微服務應用的剛需。

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

但是對于原生安裝與運維 Kubernetes 還是借助第三方開源方案，我們經(jīng)過反復的琢磨，最終選擇了使用第三方開源項目。看來看去 Rancher 和 KubeSphere 成了考慮的選型。

KubeSphere 是由青云 QingCloud 發(fā)起并聯(lián)合多個企業(yè)共同參與開發(fā)的開源項目。對比 Rancher 和 KubeSphere，后者不僅有清爽的操作界面，向?qū)降馁Y源創(chuàng)建方式，完全以應用為中心，更傾向于 Kubernetes 集群資源的管理，提供優(yōu)雅的 API 接口，并且在 Kubernetes 之上集成與包裝了我們運維開發(fā)常用的功能組件，例如 Jenkins、Harbor、Promethues、Apache SkyWalking，還支持在任何基礎(chǔ)設(shè)施環(huán)境部署，所以我們毫不猶豫的選擇了 KubeSphere 容器平臺。

KubeSphere 跨多云平臺的兼容、以及支持多插件的選擇，在使用過程中加深了我們對 Kubernetes 各個模塊的理解、推進了我們對生產(chǎn)環(huán)境落地 Kubernetes 容器編排的步伐。并且，KubeSphere 解放了我們運維日常面臨的重復的工作，減低了應用的整體維護成本。是運維的一把利器，是互聯(lián)網(wǎng)公司的一道福音。

綠米物聯(lián)網(wǎng)微服務平臺部署架構(gòu)

目前公司主要是在騰訊云上用 7 臺服務器來構(gòu)建集群，集群機器的配置規(guī)格如下。

目前所有的無狀態(tài)的服務都運行在 KubeSphere，有狀態(tài)的數(shù)據(jù)存儲類服務，我們使用云上的 Redis、HBase、Flink、Elasticsearch、MySQL 等集群服務。

截止目前為止已經(jīng)運行半年多且無大問題出現(xiàn)，這推動我們計劃近期把公司開發(fā)、測試、生產(chǎn)環(huán)境中所有的有狀態(tài)和無狀態(tài)服務全部遷移到 KubeSphere 上去。

綠米物聯(lián)網(wǎng)微服務平臺設(shè)計架構(gòu)

首先可以看看綠米物聯(lián)網(wǎng)的業(yè)務架構(gòu)圖，目前綠米海外地區(qū)的服務，基本上全部都運行在 KubeSphere 之上，包括 Gateway 微服務路由調(diào)度、Push、Send 推送、iftt 定時等等。

由于我們的業(yè)務以 Java 為主，因此綠米物聯(lián)網(wǎng)微服務平臺是基于 SpringCloud 框架進行微服務化，使用 Apollo 分布式配置中心管理配置，Eureka 注冊中心服務注冊與發(fā)現(xiàn)。

結(jié)合 Ribbon、Feign 實現(xiàn)微服務負載均衡以及服務調(diào)用。同時，我們使用 Hystrix 線程池實現(xiàn)隔離、熔斷以及降級、sentinel 限流，而 springcloud-gateway 網(wǎng)關(guān)路由則用來實現(xiàn)路由調(diào)度，日志使用的是經(jīng)典的 ELK 組合，APM 使用 SkyWalking 作為 Java 微服務分布式系統(tǒng)的應用程序性能監(jiān)視工具。

如上圖所示，IaaS 我們使用的是騰訊云，Platform （平臺層）主要是物聯(lián)網(wǎng)業(yè)務平臺的微服務，Platform 層的絕大多數(shù)應用都運行在 KubeSphere 容器平臺之上，所有子設(shè)備通過 Zigbee 協(xié)議 連接 Hub 設(shè)備，即智能網(wǎng)關(guān)、智能插座網(wǎng)關(guān)、攝像頭等，Hub 設(shè)備通過 RPC 協(xié)議與綠米智能家居的微服務平臺通信，微服務平臺為 App、SaaS 等應用提供數(shù)據(jù)，反向應用通過一系列安全鑒權(quán)、認證來調(diào)用綠米微服務平臺，實現(xiàn)控制智能家居設(shè)備。服務層擁有鏈路追蹤、基礎(chǔ)監(jiān)控、CI/CD 等插件。

KubeSphere 讓我們對 Kubernetes 的入門變得更簡單、加快推進生產(chǎn)環(huán)境 Kubernetes 的上線，對業(yè)務迭代有明顯的效率提高，并且能夠讓研發(fā)更快地隨意切換部署驗證各個應用的功能模塊。

截止目前為止，這一套物聯(lián)網(wǎng)微服務平臺已經(jīng)在我們綠米聯(lián)創(chuàng)的生產(chǎn)運行半年多且無大問題出現(xiàn)，因此，我們計劃在近期把公司開發(fā)、測試、生產(chǎn)環(huán)境中所有的有狀態(tài)和無狀態(tài)服務全部遷移到 KubeSphere 上去。

問答

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

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

經(jīng)過一番研究后，我理解整個 DevOps 的流程是 jenkins-agent 拉取對應模板的 Pod，跑完 Pipline 的各個流程，但問題又來了，Java 模板的 maven Pod 執(zhí)行完之后退出了，卻沒法獲取到編譯后的 Jar 包。

最終我們發(fā)現(xiàn)，可以登錄 Jenkins 服務端，選擇 Manage Jenkins => Configure System，找到對應的模板，如截圖所示操作，在 Pipline 里面指定 mav package -Dpath=${target_path}，方可解決上述解決問題！

Q：什么樣的應用開發(fā)平臺，才能承載智能家居的未來？

A：完善的審計、監(jiān)控告警，權(quán)限分發(fā)，并且能自定義優(yōu)雅的資源擴縮容策略，優(yōu)雅的插拔式插件個性化定制，平臺自身的常規(guī)問題自查策略，以及清晰明了的日志，好在這一切都在 KubeSphere 容器平臺支持了。

Q：KubeSphere 哪些功能或設(shè)計還需要改進？

A：建議如下：

• 界面語言切換太隱蔽；

• Granfana 模板集成靈活度可以再多一點；

• 對 Kubernetes 節(jié)點擴容可以變得更簡單一點、最好支持界面化節(jié)點擴容。

• 創(chuàng)建 pipeline 支持 copy from；

• 運行 pipeline 支持多選批量；

• api文檔最好有些 example，現(xiàn)在的 Swagger 很多接口必選參數(shù)寫的看不明白，可讀性不太好

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