背景：從傳統運維到容器化的 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 排編劣勢明顯：
1. 跨平臺支持效果差;
2. 業務量訪問高峰期的時候，內部 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：建議如下：
1. 界面語言切換太隱蔽;
2. Granfana 模板集成靈活度可以再多一點;
3. 對 Kubernetes 節點擴容可以變得更簡單一點、最好支持界面化節點擴容。
4. 創建 pipeline 支持 copy from;
5. 運行 pipeline 支持多選批量;
6. api文檔最好有些 example，現在的 Swagger 很多接口必選參數寫的看不明白，可讀性不太好
後記
非常感謝綠米聯創的兩位用戶帶來的物聯網微服務平臺在智能家居行業的落地實踐分享!從傳統運維到容器化的 Docker Swarm 編排，從 Docker Swarm 轉向 Kubernetes，然後在 Kubernetes 運行 SpringCloud 微服務全家桶，到最終擁抱 KubeSphere，並基於 KubeSphere 打造綠米聯創自己的物聯網微服務平臺，這也是國內一部分企業的應用微服務平臺的演進過程。
如果大家對綠米聯創的物聯網微服務平臺的落地實踐的詳細實現非常感興趣，希望進一步了解以及跟兩位工程師交流，歡迎大家加入 KubeSphere 開源社區交流群。我們後續會根據大家的需要邀請兩位工程師為大家做一次線上的技術直播分享。另外，如果您希望分享 KubeSphere 和 Kubernetes 在您企業環境的落地實踐，我們也非常歡迎您投稿!
About KubeSphere
KubeSphere (https://kubesphere.io)是在 Kubernetes 之上構建的以應用為中心的開源容器平臺，提供全棧的 IT 自動化運維的能力，簡化企業的 DevOps 工作流。
KubeSphere 已被 Aqara 智能家居、本來生活、新浪、雲智匯、微眾銀行、VNG Corporation、Radore 等海內外數千家企業採用。KubeSphere 提供了運維友好的嚮導式操作界面和豐富的企業級功能，包括 Kubernetes 資源管理、DevOps (CI/CD)、應用生命周期管理、微服務治理 (Service Mesh)、多租戶管理、監控日誌、告警通知、存儲與網絡管理、GPU support 等功能，幫助企業快速構建一個強大和功能豐富的容器雲平臺。