《昆虫学报》
0 引言
随着大数据技术AI技术的不断发展,人们的生活也因技术的发展而不断改变着,生活中小孩子常会问大人一些他所好奇,不认识的事物,如昆虫。而目前网络上关于昆虫的资料多而杂,而且没有一个方便的渠道可以让人们快速便捷的得到自己想要的知识。
目前这种集合昆虫数据与智能识别昆虫的APP很少。而随着新技术的不断发展以及中国越来越庞大的青年及少儿群体,人们对于特定知识获取的需求会愈加强烈。本APP旨在为对昆虫感兴趣的群体提供一个实用方便的知识获取窗口。
1 智能昆虫识别APP设计
1.1 总体设计
APP实现对用户所拍摄的昆虫图片进行识别,并能够提供昆虫相关的趣闻知识,以及形象生动的解说视频,让用户不用麻烦的外出寻找昆虫,或查找昆虫相关资料,使得用户便捷快速的获取昆虫相关的知识。
总体分为六个模块,具体如图1所示。
地图定位模块包括定位用户位置,记录拍摄的昆虫。发现模块包括昆虫相关趣闻推广。识别模块包括拍摄照片,并识别昆虫。视频模块包括昆虫相关介绍视频,视频下方可以发表评论进行相关讨论。图鉴模块包括为用户提供诸多昆虫的图像信息。昆虫数据模块包括查询具体的知识与昆虫图集下载。
图1 功能模块图 module diagram
三层开发架构通常都具备比较好的系统性能和效率,它通过中间件实现对数据的访问,中间件则是一个独立的组件,可以根据需求选择合适的中间件组件。
架构设计所有的业务流程都是在系统上层中实现,这就降低了另外两个层次对于数据的处理压力,可以更好的专注在当前层功能实现上。APP架构的交互图如图2所示。
图2 架构工作流程 workflow
图像识别部分,在基于机器学习的智能昆虫分目识别算法应用的文章中已做过论证与说明,在此不再赘述。
1.2 动态配置设计
设计过程中发现客户端大量的硬编码导致其灵活性大大降低,例如一些细小的改动只能通过发布版本解决。就用户升级更新迭代速度慢,时效性差等原因,需要考虑APP的动态化配置设计。
实际中客户端和服务端保持一个长链的连接,当在后台操作配置时,会把这个配置以K/V形式存储,随后通知Processor,后者拿到K/V之后把它推给客户端,整个过程完毕。长链只能保证客户端在线时能第一时间拿到配置中心的值,处于离线状态(例如:用户未打开APP)时就无效了,因此需要想办法使得用户下一次打开APP时可以拿到最新的值,于是设计在保存K/V时,额外存一个flag字段,用来表示这个K/V是否已经成功发送给客户端。
至此就要考虑三个问题:存储、流量和同步策略。
通常一个设备的K/V对不会超过100项,每对Size不超过 1 K,也就是一台设备对应的大小上限为100 K左右,假如设备数为100万,就需要100 G的磁盘空间,所占存储空间是巨大的。考虑到一些配置项会在多个设备共存,便可以把这些配置单独存储,将hash值作为Value。假设Key的size为30字节,Value为10字节,这样就减少到40M的K/V存储空间。然而这样的设计又暴露出新问题,Value的组合会很多,例如原来K1的Value为V1,更新之后变成V2,显然需要新建一组Value,将其中的V1变为 V2,而因为不知道之前的一组 Value是否还有其他设备在引用就只能保存,这样就会使得Value逐渐累积下去,要降低这种累积就需要设计清除算法。为了能够降低复杂度,故引入索引,当某个Key如果有新的Value,只需在对应的Key后面append即可。此时需要同步更新设备的索引,持久化可以异步进行。
模拟单个设备的量可以达到 100 K,如果每次配置有更新就发送100 K的数据这对到达率会有一定影响,尤其在设备网络情况不佳的情况下。因此这里的目标是如何减少数据传输量,同时尽量避免提升复杂度。直接的方法是对数据进行压缩,实际结果证实这是比较简单同时效果也不错的方法。
2 智能昆虫识别APP实现
为实现低维护成本,服务可快速迁移的设计要求开发选用微服务技术。在服务构件过程中应用微服务来构建整体的业务领域组件。其基本思想在于考虑围绕着业务领域组件来创建应用,这些应用可独立地进行开发、管理和加速。因为微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。通过这一点系统就可以将服务公开与微服务架构区分开来。因为在服务公开中,许多服务都可以被内部独立进程所限制,若其中一个服务需要增加某种功能,那么就必须缩小进程范围。而在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。
上一篇:重金属污染地区昆虫多样性比较分析
下一篇:没有了