每秒1W并发写入的iot设备采集系统,多大成本?多少人开发?如何设计?

[云计算] 季雨林 2020/4/19 20:59:26

前言

每秒一万并发写入,这个要求其实对于iot行业来讲,并非什么高峰值,稍微有些规模的系统,都得轻则几千,重则上万的并发写入能力。

对于很多大部分开发者而言,听过了太多大厂技术大牛的大型架构分享:读写分离,消息队列,缓存中间件,负载均衡,分布式数据库,时序数据库等等等等,这里说这些技术并非无用,只是杀鸡焉用牛刀。比如读写分离,适合场景是读远远大于写的时候才适合;比如消息队列,也不是写入多了就必须采用;比如时序数据库,只要能负载业务,不造成太大成本即可,虽然GPS数据用nosql更合适,但不是必须要用nosql;


一组数据库单机压测数据

首先要强调一下,iops能力与硬件承载力有直接关系,以上数据明显可见的是物理硬盘上的写入性能远远高于虚拟机环境的虚拟硬盘。另外就是表结构的合理,具体表结构设计思路,见我的《mysql,sqlserver数据库单表数据过大的处理方式》

单纯实现这个一万并发写入而言,并非多难的事情,在不使用缓存的情况下,单纯使用关系型数据库SqlServer或者Mysql,就可以实现如下性能(测试结果被我简化):

介质类型
单机实测IOPS指标
笔记本5400转的机械硬盘3000
笔记本120G三星EV950固态硬盘5000 
阿里云ECS自带的40G 高效硬盘400
阿里云ECS额外买的20G SSD硬盘2000


架构说明

稍微扩展一下,采用分布式的思路,就可以轻松翻倍,白话文就是一台数据库不够那就分两台。至于实现多台数据库的技术细节无非就那么几个,要么主数据库路由分流,要么数据库预留扩容节点空间。

至于说系统的最大承载力是多少,其实并非无上限,而是尽可能提高瓶颈点约束!这就已经可以称之为无限承载力,因为已经足够超过了系统的最大实际场景!

如果采用云架构的思路,集群+分布式,则可以轻松扩大承载量,再如果结合缓存中间件,消息队列等云产品,即可实现无限扩容(瓶颈值提高到云厂商机房规模限制之下)


在这里补充强调一下分布式和集群的区别:

分布式:垂直任务分割,比如最典型入门架构,web服务器+db服务器

集群:水平业务扩容,比如最典型的通过负载均衡实现N台web服务器一起工作


实际架构方案:

当时的GPS设备特点是每10s回发一次位置数据,实际并发TCP长连接的100万台设备,交通高峰时候,大约有30万工作在实时定位状态,相当于每秒写入3万的坐标。

这个并发写入能力也不过才是题目里1万并发的三倍。为了提高可用性,服务器采用采用多数量低配置方案:2核4G服务器几十台,数据库多台(其中有GPS轨迹数据库2台),缓存最早采用的memcached,后来更换的redis。至于消息队列一直到我离开这个团队都还没有正式切换使用。



云架构方案,对比物理机房方案

这也是我为什么从最初的物理机机房,到阿里云弹性架构的技术架构路线变革原因,在传统物理机架构方案里,虽然可以获得超高的单机性能,可是对于扩容代价极高,简单总结我遇到过的困难如下:

  • 网间线路故障

南方电信访问北方联通,曾经因为跨网导致过3天设备离线。最后选用阿里云,自带的BGP线路优势,消除了多运营商线路商带来的问题。

  • 网络地域延迟

曾经对比过,四川用户明显对于访问青岛联通网络存在高延迟。这一点也是通过换用阿里云杭州节点,网络延迟综合覆盖全国均有较好的表现

  • 机房专线太贵

这个可以打电话咨询客服,光纤专线,10M一个月都得上千到上万不等,具体价格需要跟运营商的客户经理去谈。换用阿里云之后,首先是带宽,超过5M部分是每月每兆80元,价格可控透明。其次是iot行业的回收数据占用的是上行带宽,免费高带宽,不受制于购买的带宽大小。

服务器硬件成本,买云服务之所以省心,这部分差异相当明显,我2年写坏过一块企业级一万转的SAS硬盘,常年不停机运行的硬件消耗真的很严重。这还只是硬件成本,为了运转服务器,我们还要聘请入门级专职和专业级兼职的服务器运维工程师。换用阿里云之后,甚至只需要软件开发工程师的入门级别运维能力即可。

  • 网络设施约束

当时买的思科防火墙CAS5525,最大支持的TCP连接数只有25万,采用云服务则直接享受不约束连接数的高昂的骨干网络设备优势。

还有很多,一时半会说不完,总之物理机方案的很多细节都不利于扩容。


总结一下:

单机方案,单机性能超高,但是扩容起来代价很高。

采用云方案,单机性能下降一些,但是可以轻松配套云产品,实现“弹性扩容”。

业务扩容能力(赚钱能力),很多时候要超过高性能的单机负载能力(省钱能力)。任何一个公司,都会选择更重视赚钱能力大于省钱能力的方案,因此上云才成为趋势!最后插个广告,欢迎通过我采购阿里云!联系QQ:2459331980 



原文地址: https://www.opengps.cn/Blog/View.aspx?id=687 文章的更新编辑依此链接为准。欢迎关注源站原创文章!

评论

暂无评论!

发表评论:

用于接收作者回复信息
点击更换验证码 - openGPS提示