首页 > 云计算 > 公有云实践 > 一键实现设备高稳定高安全管理——设备管理运维类
阿里云IoT物联网平台2020年初上线企业实例,企业实例在功能、计费 、稳定性方面相比原有公共实例有不小优势 (企业实例相关内容请参考 实例概述 ) 。 但如何从公共实例迁移到企业实例,并不是一个简单的事情。实例的业务场景中涉及用户服务、阿里云IoT物联网平台服务、设备等,业务链路长、场景复杂。

图1
如上图1为一个典型的IoT业务场景。
业务场景中涉及用户服务、阿里云IoT物联网平台服务、设备,业务链路长、场景复杂,给实例迁移工具设计带来了很大的挑战。
设备无法修改,需要降低用户改造成本。IoT设备可能部署在地下、安装在商场中或者散落在城市不同角落(如公共自行车),同时设备数量会很多,手动升级设备几乎不可能。同时OTA涉及用户设备二次改造开发, 设备型号碎片化、SDK版本碎片化存量设备改造成本高, OTA升级周期会较长。
涉及功能和业务方多,影响面广对于稳定性要求高。IoT物联网平台涉及控制台功能如产品管理、设备管理、拓扑管理、分组管理、标签、检索等众多功能。
业务数据类型多且异构,数据需要按照业务维度迁移,无法采用工具统一进行。阿里云IoT物联网平台涉及数据如产品、设备、脚本、拓扑等多张表,同时数据存储在RDS、DRDS、OTS、TSDB云产品中。业务模型上按照产品维度迁移产品、设备涉及的数据,不能采用工具如DTS统一进行。
业务链路长设备流量和用户控制流量路由需一致,业务上需要无损,用户改造方案成本高。已经迁移到企业实例的设备,通过 长连接连接到企业实例中,用户可能不知道控制设备时会控制失败。
企业实例迁移面临 设备无法修改、涉及功能和业务方多、业务数据类型多且异构、业务链路长设备流量和用户控制流量路由需一致四个方面的挑战,对我们的产品和技术设计方案从用户使用门槛、稳定性提出了一定的要求。
用户迁移过程可灰度、可监控、可回滚。用户设备体量大从几千到几十万都有,且设备都是通过长连接连接到平台,迁移的时间必然较长。同时用户设备可能涉及到民生如公共交通领域,升级需要凌晨按区域先灰度然后升级。升级的过程中用户需要能够感知和监控升级是否成功,作为服务提供者我们自己也需要能监控服务成功信息避免故障的发生。方案实现中采用状态机结合异步任务方式处理,做到用户侧状态可控,数据迁移执行稳定。
设备不做改造,用户服务端少改造。基于开发成本考量,方案设计中需要兼容设备能自动路由到企业实例,避免设备改造。用户服务端少改造,保障和设备路由一致性避免业务有损。
用户迁移企业实例,涉及用户服务端开发不是简单的开发一下切下流量,需要业务评估、改造、发布、切流同时需要和我们提供的实例迁移无缝的结合。我们从迁移过程可控、系统设计稳定、监控等方面保障迁移过程可灰度、可监控、可回滚。

图2
整个迁移过程主要分为4部分:业务评估、系统改造、实例升级、接口切流。

图3
如图3所示,实例迁移过程分为不同的状态,很适合采用状态机方式管理业务流程避免业务代码耦合。同时采用分布式锁,保障任务状态唯一。
由于实例迁移数据从业务模型上是按照产品维度,迁移产品下所有的设备。需要先查询出产品和设备涉及的数据,然后迁移到对应的企业实例存储(存储目前逻辑隔离,物理隔离单元化项目已经进行中)。根据业务诉求和数据特性,采用不同的策略。
需要迁移的数据类型多、迁移的设备数量多,导致迁移的时间比较久。需要保证异常情况下数据迁移的稳定可靠,避免ECS宕机、应用发布、依赖服务异常时迁移的稳定性。
实例迁移过程中,设备数量多且状态更新查询频繁,迁移任务和迁移设备状态更新需要考虑对于的压力,同时考虑功能对于实时性和容错的需求。由于实例迁移任务和设备状态重要程度,在存储上进行拆分,实例迁移任务存RDS,任务设备设备详情存OTS。
数据的查询依赖高效的检索服务,通过配置方式可以支持RDS、OTS数据使用SQL的方式查询方式。

图4
监控面向受众包括阿里云IoT物联网平台用户和IoT内部开发者,其需要看到的监控指标和展示方式各不相同。从用户和功能开发者的诉求触发,针对不同场景进行埋点(日志、存储),采用现有的监控产品构建我们的监控告警体系。

图5
实例迁移过程,采用设备不改造,服务端少改造的方式策略,避免阿里云IoT物联网平台用户改造成本过高。
用户设备
用户服务端
由于迁移企业实例后开放API必须传实例id, 用户系统调用开放API控制设备需要和设备迁移保持同步。
同时需要订阅灰度后迁移到企业企业实例的服务端订阅以及规则订阅等,防止消息丢失。
物联网平台产品介绍详情:

阿里云物联网平台客户交流群
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70017009/viewspace-2916899/ ,如需转载,请注明出处,否则将追究法律责任。