一、背景
阿里云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。
- 同时需要订阅灰度后迁移到企业企业实例的服务端订阅以及规则订阅等，防止消息丢失。
