百万到千万在线,美的 IoT 平台踩坑历程

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 百万到千万在线,美的 IoT 平台踩坑历程 顺炽国 美的
2.
3. 个人简介 顺炽国 重要经历 美的IoT-云平台 IoT平台负责人 5000 w/d 2008 江苏省电信短信平台 5w/s 2014 酷狗音乐搜索服务 30w/s 2021 美的IoT云平台
4. 目录 01 简介 02 连接之坑 03 交互之坑 04 消息之坑 05 架构之坑
5. 01 美的IoT简介
6. 美的物联网愿景 连接用户与家庭 为亿万家庭提供最佳的全屋智能家居体验
7. 美的美居 - 全屋智能场景 餐具 清洗 一键 报警 干燥 换气 极速 升温 浴室一键呼救 水温 调节 音乐 播放 灯光 调节 一键零冷水 餐前暖碗 烟灶联动 清爽微蒸烤 定时洗碗 健康存储 单品能力 • 洗护 场景联动 洗完 通知 衣物 烘干 • 安防 自动 晾衣 洗衣完成播报通知 除湿 干燥 洗衣机晾衣架联动 • 烹饪 • 营养 烘干提醒 • 衣物洗护 厨房 卫浴 • 衣物烘晾 阳台 • 湿度调节 空气检测联动净化器 室 • 娱乐 自动净化 • 安防 • 娱乐 空间场景 空间场景 智能场景 空气 净化 循环空气模式 • 空气 厅 环境 检测 除湿机智能除湿 • 空气 影院模式 • • • 智能产品 • 安全 • ⻝材 • 水 ⻔锁异常警报 回家场景 餐具 存储 一键烘衣 • 清洁 开启清新空气 离家场景 抽烟 换气 夏日凉爽沐浴 冬季快速沐浴 ⻔锁 报警 微波加 热 餐前预洗 沐浴后自动干燥 空气 净化 火力 蒸烤 火力蒸 烤 ⻛扇睡眠防着凉 聚会模式 湿度 调节 ⻛速 调节 • • • 场景联动 单品能力 智能产品
8. 设备卡片 - 控制与丰富的内容服务 设备控制 推荐 控制⻚ 推荐⻚ 超级 插件⻚ ■ 用户体验一致 ■ 清晰易懂易用 ■ 控制一触即达 ■ 用户运营阵地 ■ 丰富推荐内容 ■ 提高用户活跃 ■ 集合通用信息 ■ 一键售后报修 ■ 耗材轻松购买 超级插件⻚
9. ⻝谱 - 海量⻝谱,享受一键烹饪的乐趣 17000+智能⻝谱,在家吃遍世界美⻝ 手机操控一键烹饪,轻松坐等美味出炉
10. 服务 - 售后服务主阵地 工程师 美居服务 用户 首⻚ 丰富的售后服务能力,打 造服务体验闭环 维修 一键报修,故障自助排除 建议,使用方便快捷 售后系统 在线 客服 清洗 家电深度保养,专人服务 价格透明,60天售后 智能在线客服,时刻响应 用户需要 维修服务 保养服务 网点 查询 网点地图模式,精准导航 快速直达 说明 书 掌上电子说明书,方便自 助解决问题 自助服务 上⻔服务 安装服务 美的工程师 清洗服务 电子说明书 耗材提醒、购买 故障自查 滤芯防伪 网点查询 收费标准 保修政策 在线客服
11. 美的物联网发展历程 2000w 40w/s 1500w 30w/s 1000w 20w/s 500w 10w/s 实时在线 设备消息 2018 2019 2020 2021 2022
12. 万物之始,大道至简,衍化至繁 老子《道德经》
13. 02 连接之坑
14. 连接之坑 — 配网 2.连接路由 智能设备 3.设备上云 路由器 云 1.AP配网 4.绑定设备 App应用
15. 连接之坑 — 配网安全 4.成功绑定设备 老王家 云 用户家 3.设备连云 设备为什么自动改变 工作状态? 2.设备连接老王家Wifi 老王家路由器 智能设备 1.发现AP热点并配网 (录入老王家Wifi热点和密码) 隔壁老王
16. 连接之坑 — 配网安全解决方案之后确权 4.绑定设备? 须操作设备指定物理按键完成确权 老王家 云 3.设备连云 用户家 3.设备连云 2.连接路由 2.设备连接老王家Wifi 老王家路由器 智能设备 5.确权 1.重启AP并配网 1.发现AP热点并配网 (录入老王Wifi热点和密码) 隔壁老王 4.绑定 路由器
17. 连接之坑 — 配网安全解决方案之免确权 • 自己的设备,为什么还要再操作物 理键才能控制? • 空调这么高怎么按…… 云 3.绑定时综合判断AP信号强度 是否手工开启AP,免除确权操作 1.手工开启AP,记录AP信号强度 2.连接云 智能设备
18. 连接之坑 — 设备接入 智能设备 100w+ 负载均衡服务 access.xxx.com 接入层服务集群
19. 连接之坑 — 设备接入问题 智能设备 负载均衡服务 接入层服务集群 1000w+ access.xxx.com 100w+ • • • • DNS绑定IP限制 生效时间久 负载分配不均衡 异常处理需要代码适配 SLB单节点连接数限制 服务升级导致服务节点连接重 连,引起流量冲击
20. 连接之坑 — 设备接入问题:智能DNS 智能设备 智能DNS SLB groupA addr 基于智能DNS按区域,动态 规划入口SLB集群地址 SLB groupA addr • • • • √DNS绑定IP限制 生效时间久 负载分配不均衡 异常处理需要代码适配 SLB IP GroupA 接入层服务集群A SLB IP GroupB 接入层服务集群B 根据分配的入口地址连接
21. 连接之坑 — 设备接入问题:设备寻址 智能设备 ADNS(设备寻址服务) 1.获取设备接入点 路由策略 配置管理 集群管理 离线重置 • • • • √DNS绑定IP限制 √实时生效 √动态切换设备区域 √基于SLB及后端服务压 力可动态调节接入点 多个接入集群 2.存储接入地址 SLB IP GroupA 接入层服务集群A SLB IP GroupB 接入层服务集群B 3.连接指定接入服务
22. 连接之坑 — 设备接入问题 智能设备 存量设备 新设备 智能DNS ADNS(设备寻址服务) SLB IP GroupA 接入层服务集群A SLB IP GroupB 接入层服务集群B 根据入口地址连接
23. !"#$%&'()*" 连接之坑 — 设备接入问题:TCP平滑升级 接入层服务升级或重启时,之上的所有连接会断开并重连,引发短时流量⻛暴。 旧版本服务 新版本服务 解决思路 通知旧服务连接并传递FD 利用uds(unix domain socket)将旧服务的 tcp fd控制权转移到新服务,由新服务接管 tcp fd 继续数据处理,从而避免TCP断开 重连引起的流量冲击,减少发版对用户的 影响。 启动并创建UDS监听 创建uds连接 循环发送 发送tcp fd(设置SCM_RIGHTS) 恢复连接 清理资源退出服务 关闭UDS监听
24. 03 交互之坑
25. 交互之坑 — 设备控制 用户家 云 1.远程控制(云端控制) 路由器 智能设备 3.本地控制 2.本地控制(局域网控制) 用户 中控屏、网关 网关子设备
26. 交互之坑 — 云端控制(旧) 网关 业务 鉴权 服务 App应用 三方语音平台 开放 平台 网关 链路⻓,入口多 设备 消息 处理 服务 待发送 队列 响应消 息队列 基于同步阻塞队列,高并发 时阻塞严重,请求大量堆积 设备 接入 服务 集群 消息 适配 分发 设备 控制 服务 协议 转换 服务 下行消 息队列 多次MQ交换,且响应回调 重度依赖Redis及MQ 智能设备 上行消 息队列 消息未区分隔离,上报 处理阻塞会相互影响
27. 交互之坑 — 设备控制之云端控制 网关 业务 鉴权 服务 App应用 三方语音平台 开放 平台 网关 设备 消息 处理 服务 待发送 队列 响应消 息队列 服务框架异步化改造, 移除同步锁等待机制 设备 接入 服务 集群 消息 适配 及发 设备 控制 服务 协议 转换 服务 下行消 息队列 合并、移除非必要节 点,无状态化改造 上行消 息队列 消息分拆,隔离 智能设备
28. 交互之坑 — 云端控制-无状态改造 控制请求基于同步等待,因此控制服务必须保持状态等待设备异步响应控制结果,旧服务依赖 redis存储请求及节点,同时依赖MQ作节点队列异步获取,性能较差 旧逻辑 优化逻辑 1byte 设备控制 node1 node1 3.消费并处理请求响应 设备控制 node1 2.写入对应Topic 写入 1.查询设备控制请求所在节点 请求状态 消息 适配 分发 1. 利用控制协议的 msgid在响应时会带回特 性,将最msgid最高位标 记为node id,剩余位继 续按序编号 node2 设备控制 node2 sequence number msgid rpc/http 控制响应服务 rpc/http 写入 设备控制 node2 node Id 7byte 2. 从响应的msgid中的 最高位拆解出node id, 利用服务治理框架的tag 快速找到请求节点回调
29. 交互之坑 — 云端控制-改造优化 网关 控制 业务 服务 App应用 三方语音平台 下行消 息队列 设备 控制 交互 开放 平台 网关 协议 转换 服务 控制 响应 服务 控制响 应 上报事 件 设备 接入 服务 集群 智能设备
30. 交互之坑 — 云端控制改造效果 TPS: RT: 900/s 16000/s 1200ms 355ms
31. 04 消息之坑
32. 消息之坑 — Kafka再平衡问题 智能设备 设备 接入 服务 集群 设备 上报 消息 消息 处理 服务 集群 业务消 息 业务服务 业务消 息 业务服务 业务消 息 业务服务
33. 消息之坑 — Kafka再平衡问题 智能设备 设备 接入 服务 集群 设备数上升 升级、重启 设备 上报 消息 消息突增 消息 处理 服务 集群 堆积且不消费 业务消 息 业务服务 业务消 息 业务服务 业务消 息 业务服务 影响业务服务
34. 消息之坑 — 问题分析 消息通道过于集中,单点压力大 消息都生产到同一个Broker集群 和Topic 02 消费线程池使用阻塞队列 消费线程池使用了固定大小的 阻塞队列,当消费大量消息 时,处理线程处理时间过⻓导 致消费线程阻塞,触发Kafka主 动再平衡 过渡依赖Redis及DB 01 消息的处理过程过渡依赖 03 Redis及DB来处理数据,流 量过大时Redis及DB是较严 重的瓶颈
35. 消息之坑 — 问题分析:阻塞队列 work thread pool kafka consumer thread 100 循环调用execute poll 待处理消息队列 5000 BLOCK 工作线程池 4000 执行完成,继续执行poll方法 任务队列 (LinkedBlockingQueue) 初始化了有界阻塞队 列,当线程池满且执行 任务超过最大队列数 时,会阻塞调用线程
36. 消息之坑 — 问题分析:阻塞队列优化 work thread pool kafka consumer thread poll 流控 正常流量 超过限制流量 100 循环调用execute 恢复消费 待处理消息队列 暂停消费 工作线程池 unlimited 执行完成,继续执行poll方法 任务队列 (LinkedBlockingQueue)
37. 消息之坑 — 基于配置规则:从源头拆分 设备接入服务 cluster1 生产者1 消息 解析 路由 管理 消息处理—洗衣机 report wash topic 生产者2 生产者3 消息处理—⻛扇 report fans topic cluster2 消息处理—空调 report aircondition topic 路由配置同步 配置中心服务 更新路由配置 路由规则 MQ集群、Topic信息 fans_* Cluster1,fans_topic wash_* Cluster1,wash_topic ac_* Cluster2, ac_topic …… …… 根据企业、品类、设备型号、消 息类型等信息,可以根据流量情 况动态扩展处理集群
38. 消息之坑 — 重复消息、缓存及影子 生产者 时序性 设备上报有严格的时序性要求,否则会导致状态错乱 key did value message 1.使用did作为Kafka消息的Key,确保 同个设备消息顺序写入同一个分片 共享缓存 大量的设备会共享基础信息,导致redis⻓时间在较高水位 p0 p1 p2 p3 p4 p5 重复消息 部分设备大量重复上报,基于共享缓存等机制过滤成 本巨大 2.每个处理节点只处理固定范围的DID, 可以在做本地快速缓存及重复消息过滤 消息处理服务A 消息处理服务B 重复消息过滤 重复消息过滤 本地缓存 本地缓存 3.共享业务缓存,避免再平衡或 重启大量请求拥入业务服务
39. 消息之坑 — 改造效果 网络带宽 Redis CPU Redis QPS 44% 56% 60.9% MySQL CPU 65%
40. 05 架构之坑
41. 架构之坑 — 云端架构迭代过程 2013 2018 2020 2021 2022 设备接入 微服务治理 云原生、分布式运行时 提供给各事业部设备接入、 逐步废弃各业务领域混用的 平台服务分层、云原生化改 消息处理、上报及控制的核 Dubbo、Spring Cloud、 造、多云能力构建,基于分 心链路服务,业务应用独立 SLB、HAProxy等各种参 布式运行时框架进一步简化 差不⻬的治理技术,统一基 业务开发复杂度及可观测性 平台业务融合 事业部所有独立业务的App 融合为一个美的美居,IoT 平台统一承接所有设备接 入、控制 、上报,以及C端 用户的所有业务 于Consul+Fabio的边⻋服 务改造,全链路跟踪、 CMDB建设、进一步完善监 控系统 共享数据、缓存改造 改造所有服务依赖统一数据库 及缓存的严重问题,在保证 App版本快速迭代的情况下, 持续了近一年多的时间改造完 成,SLA得到大幅度提升
42. 架构之坑 — 为何选用 consul+fabio? registry register subscribe/notify invoke consumer svc provider svc 跨架构服务发现 通讯协议差异 service registry micro svc invoke api gateway micro svc 强依赖注入 config server monitor invoke HAProxy Nginx micro svc request svc invoke HAProxy Nginx invoke invoke micro svc micro svc micro svc SLB 异构语言适配 人工维护成本、⻛险 滥用中间件 micro svc micro svc request svc invoke invoke micro svc SLB micro svc
43. 架构之坑 — Consul+fabio register/unregister register/unregister register/unregister 服务节点 服务节点 服务节点 service A service B service B invoke service B health check health check load balancing health check
44. 架构之坑 — 改造过程 01 统一服务接口 02 新旧治理并存 03 流量切换 04 移除旧框架 应用服务屏弃所有框架特有接口, 提前搭建Consul服务集群,同时 逐步切换服务配置(以及部分代 所有流量切换完成,将旧治理框架 服务间仅允许HTTP、GRPC两类对 将服务节点进行边⻋化部署 码),将调用地址切换成GRPC、 中的注册、中间件资源等进行清 外暴露接口,标准化消息总线架 (consul client、fabio),现有服务 HTTP的本地调用。同时监控链路 理,确保所有业务基于同一框架。 构,异步事件统一使用消息总线解 迭代增加Consul的服务注册(基 流量变化,确保旧链路没有流量。 耦 于CMDB的管理程序),此阶段应 用无须变更。
45. 架构之坑 — 新的问题 治理能力欠缺 可观测性不足 可替代性缺失 配置能力集成 如:流控、熔断、安全 如:全链路、Metrics、 基于Consul、fabio,无法较 Consul虽然提供了配置能 Logging 轻易的切换为其它治理框架 力,业务侧则需要集成 状态存储 可扩展性 事件绑定 资源隔离性 服务无状态改造后,需要中间 Fabio缺失二次开发能力,实现 基于EDA架构的服务,都需要 状态存储,只能依赖中间件 对请求的处理、过滤等能力需要 编写MQ的生产及消费者,依赖 在多环境,如:沙箱、生产灰 借助外部服务 耦合性较强 Consul SDK 度验证环境隔离等
46. 架构之坑 — 分布式运行时(DAPR) 成熟度不足,仍然在高速迭代中 组件接口抽象对老旧服务迁移有障碍 单体应用设计,存在一定⻛险
47. 架构之坑 — 业务分层与 FaaS FaaS运行框架 业务接口 触发器 美的美居 函数运行集群 FaaS管理 资源调度 主动请求 业务接口 小程序 业务 中台 网关 业务 接口 网关 流量灰度 事件驱动 调试 定时任务 运行环境(函数加载、运行、卸载、更新、 沙箱……)、平台资源接口封装 业务接口 屏端应用 监控 事件 通用能力:鉴权、灰度、缓存、配置、存储、平台能力调用、消息及事件 IoT平台服务API仓库 服务管理 接口管理 IoT平台通用服务 部署 开 发 者 平 台 FaaS函数开发 业务研发
48. 如无必要,勿增实体 《奥卡姆剃刀》
49.
50.

ホーム - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-16 09:25
浙ICP备14020137号-1 $お客様$