一鍵實現裝置高穩定高安全管理

一、背景

阿里雲IoT物聯網平臺2020年初上線企業例項，企業例項在功能、計費 、穩定性方面相比原有公共例項有不小優勢 （企業例項相關內容請參考 例項概述 ） 。 但如何從公共例項遷移到企業例項，並不是一個簡單的事情。例項的業務場景中涉及使用者服務、阿里雲IoT物聯網平臺服務、裝置等，業務鏈路長、場景複雜。

二、業務介紹&挑戰

圖1

如上圖1為一個典型的IoT業務場景。

• 共享裝置聯網接入阿里雲IoT物聯網平臺，然後上報資料。
  
• 使用者應用透過阿里雲IoT物聯網平臺的 訊息通訊，接收裝置上報的資料、狀態等。
• 消費者，透過使用者提供的APP掃碼認證授權後，可以檢視共享裝置狀態，然後控制共享裝置提供服務。
  
• APP連線使用者應用，鑑權後開始計費。使用者應用呼叫阿里雲IoT物聯網平臺提供的裝置控制服務，控制裝置開始工作。
  
• 裝置執行過程中，上報裝置狀態。服務完成後上報狀態，透過資料流同步給使用者應用，使用者推送PUSH給APP，提醒消費者，服務結束提醒計費等資訊。
  

業務場景中涉及使用者服務、阿里雲IoT物聯網平臺服務、裝置，業務鏈路長、場景複雜，給例項遷移工具設計帶來了很大的挑戰。

裝置無法修改，需要降低使用者改造成本。IoT裝置可能部署在地下、安裝在商場中或者散落在城市不同角落（如公共腳踏車），同時裝置數量會很多，手動升級裝置幾乎不可能。同時OTA涉及使用者裝置二次改造開發， 裝置型號碎片化、SDK版本碎片化存量裝置改造成本高， OTA升級週期會較長。

涉及功能和業務方多，影響面廣對於穩定性要求高。IoT物聯網平臺涉及控制檯功能如產品管理、裝置管理、拓撲管理、分組管理、標籤、檢索等眾多功能。

業務資料型別多且異構，資料需要按照業務維度遷移，無法採用工具統一進行。阿里雲IoT物聯網平臺涉及資料如產品、裝置、指令碼、拓撲等多張表，同時資料儲存在RDS、DRDS、OTS、TSDB雲產品中。業務模型上按照產品維度遷移產品、裝置涉及的資料，不能採用工具如DTS統一進行。

業務鏈路長裝置流量和使用者控制流量路由需一致，業務上需要無損，使用者改造方案成本高。已經遷移到企業例項的裝置，透過 長連線連線到企業例項中，使用者可能不知道控制裝置時會控制失敗。

三、例項遷移設計

企業例項遷移面臨 裝置無法修改、涉及功能和業務方多、業務資料型別多且異構、業務鏈路長裝置流量和使用者控制流量路由需一致四個方面的挑戰，對我們的產品和技術設計方案從使用者使用門檻、穩定性提出了一定的要求。

使用者遷移過程可灰度、可監控、可回滾。使用者裝置體量大從幾千到幾十萬都有，且裝置都是透過長連線連線到平臺，遷移的時間必然較長。同時使用者裝置可能涉及到民生如公共交通領域，升級需要凌晨按區域先灰度然後升級。升級的過程中使用者需要能夠感知和監控升級是否成功，作為服務提供者我們自己也需要能監控服務成功資訊避免故障的發生。方案實現中採用狀態機結合非同步任務方式處理，做到使用者側狀態可控，資料遷移執行穩定。

裝置不做改造，使用者服務端少改造。基於開發成本考量，方案設計中需要相容裝置能自動路由到企業例項，避免裝置改造。使用者服務端少改造，保障和裝置路由一致性避免業務有損。

四、例項遷移可控

使用者遷移企業例項，涉及使用者服務端開發不是簡單的開發一下切下流量，需要業務評估、改造、釋出、切流同時需要和我們提供的例項遷移無縫的結合。我們從遷移過程可控、系統設計穩定、監控等方面保障遷移過程可灰度、可監控、可回滾。

4.1 例項如何遷移

圖2

整個遷移過程主要分為4部分：業務評估、系統改造、例項升級、介面切流。

• 業務評估。例項升級前需要評估業務影響，具體參考文件 例項遷移。
• 系統改造。針對評估的點，對業務系統進行相容改造。
  

• 如例項升級後，開放介面需要傳企業例項id。
  

• 例項遷移。透過IoT例項遷移功能，對待遷移產品進行遷移。
  

• 灰度遷移。灰度遷移部分裝置，觀察影響面。
  
• 灰度遷移後，如系統使用規則引擎流轉。需要系統使用新的規則引擎配置，並重啟應用。
  
• 全量遷移。灰度後無異常，開始全量遷移。
  
• 回滾。全量遷移過程中如果業務有問題可以進行回滾。
  

• 介面切流。
  

• 如裝置控制介面，針對已遷移到企業例項裝置傳企業例項id。
  

4.2 例項遷移系統設計例

圖3

狀態管理

       如圖3所示，例項遷移過程分為不同的狀態，很適合採用狀態機方式管理業務流程避免業務程式碼耦合。同時採用分散式鎖，保障任務狀態唯一。

資料遷移

由於例項遷移資料從業務模型上是按照產品維度，遷移產品下所有的裝置。需要先查詢出產品和裝置涉及的資料，然後遷移到對應的企業例項儲存（儲存目前邏輯隔離，物理隔離單元化專案已經進行中）。根據業務訴求和資料特性，採用不同的策略。

• 資料複製一份
  

• 如產品、規則引擎相關資料。產品資料裝置執行過程中會使用到，產品下部分裝置已遷移到企業例項，部分裝置未遷移到企業例項，需要保證業務相容需要複製一份相同的資料。
  

• 資料先增加後刪除
  

• 裝置資料全域性唯一，需要保障資料唯一性，因此先增加後刪除
  

非同步任務

需要遷移的資料型別多、遷移的裝置數量多，導致遷移的時間比較久。需要保證異常情況下資料遷移的穩定可靠，避免ECS當機、應用釋出、依賴服務異常時遷移的穩定性。

• 採用非同步任務方式，抽象例項遷移過程。灰度遷移、全量遷移、遷移回滾採用任務方式執行，並配合狀態機業務可中斷從業務維度保障穩定。
  
• 例項遷移任務執行過程中，針對任務心跳保活、異常檢測、異常重試、限流排隊等策略保障業務執行的可靠性。
  
• 業務執行過程，業務錯誤（約定錯誤碼）介面級別重試，系統異常任務維度重試。
  

儲存&查詢

例項遷移過程中，裝置數量多且狀態更新查詢頻繁，遷移任務和遷移裝置狀態更新需要考慮對於的壓力，同時考慮功能對於實時性和容錯的需求。由於例項遷移任務和裝置狀態重要程度，在儲存上進行拆分，例項遷移任務存RDS，任務裝置裝置詳情存OTS。

資料的查詢依賴高效的檢索服務，透過配置方式可以支援RDS、OTS資料使用SQL的方式查詢方式。

五、監控設計

圖4

監控面向受眾包括阿里雲IoT物聯網平臺使用者和IoT內部開發者，其需要看到的監控指標和展示方式各不相同。從使用者和功能開發者的訴求觸發，針對不同場景進行埋點（日誌、儲存），採用現有的監控產品構建我們的監控告警體系。

• 資料收集
  

• 資料遷移系統，可以將任務執行的狀態持久化儲存到RDS中。裝置的遷移狀態由於資料量比較到可以儲存到OTS或者Hbase中。遷移過程中的一些操作，可以列印日誌，收集到雲產品SLS中。
  
• 業務系統如系統A和系統B，針對裝置線上量、訊息量進行統計列印到日誌中，透過雲產品SLS收集。
  

• 資料聚合
  

• 針對日誌SLS、RDS、OTS不同維度的資料，按需進行不同的維度聚合分析。
  

• 資料展示
  

• 針對阿里雲IoT物聯網平臺使用者，聚合後的資料採用雲監控的檢視。提供不同例項關鍵鏈路業務指標對比，如裝置線上數、訊息數、規則引擎流轉數。
  
• 針對IoT內部開發者sunfire提供關鍵介面維度監控如介面成功率，系統異常。Grafana聚合統計分析提供基礎的大盤展示外，還提供不同任務狀態的告警，避免如任務積壓等異常。
  

六、裝置少改造

圖5

例項遷移過程，採用裝置不改造，服務端少改造的方式策略，避免阿里雲IoT物聯網平臺使用者改造成本過高。

使用者裝置

• 裝置連線到物聯網平臺時，統一接入層能查詢到裝置資訊，判斷企業例項資訊，自動路由到企業例項。
  
• 裝置建連認證過程中依賴的一些資料，如拓撲關係，雲端也做了響應的相容，避免閘道器子裝置的場景例項遷移過程中建連認證失敗。
  

使用者服務端

由於遷移企業例項後開放API必須傳例項id,   使用者系統呼叫開放API控制裝置需要和裝置遷移保持同步。

• 使用者系統透過規則引擎，訂閱例項升級狀態變更訊息。
  
• 當例項遷移過程中，裝置遷移完成後的訊息中會流轉裝置成功的訊息。
  
• 使用者系統修改已經儲存的裝置例項資訊，呼叫介面時傳新的例項ID。
  
• 同時需要訂閱灰度後遷移到企業企業例項的服務端訂閱以及規則訂閱等，防止訊息丟失。