林业害虫应用与云原生的结合之缺陷管理

Posted 2021-06-09 悄悄成长

林业害虫应用与云原生的结合之缺陷管理

温*******

（*******，*******区，中国，*******）

摘要: 本论文主要介绍了基于林业有害生物智能4e识别系统的项目经历介绍、缺陷管理的常见等级、缺陷管理的基本流程和实际应用过程与效果。云原生架构的提出在几年之前，随着存储技术和网络通信技术的发展，云原生得以快速的发展而通过这次软件杯赛题“林业有害生物智能识别”，我们的应用也参与了这次的云原生架构的浪潮之中，尽可能的使用云原生架构来使得我们的应用更加可靠、稳定。云原生架构带来的便捷性、高效性、可靠性为当今的各种应用带来了极大的扩展、优化。

关键词：云原生；高效性；可靠性；稳定；林业害虫；缺陷

中图分类号：                        文件标识码：            文章编号：

Defect management of the combination of forest pest application and cloud native

Xu*******

(*******, *******City, ******* China, *******)

Abstract:This paper mainly introduces the project experience based on the forest pest intelligent identification system, the common level of defect management, the basic process of defect management and the actual application process and effect Cloud native architecture was proposed a few years ago. Through the software Cup title "intelligent identification of forest pests", our application has also participated in the wave of cloud native architecture. We try our best to use cloud native architecture to make our application more reliable and stable. With the development of storage technology and network communication technology, cloud native architecture has been developed rapidly. The convenience, efficiency and reliability brought by cloud native architecture have brought great expansion and Optimization for today\'s various applications.

Key words: Cloud Native; High efficiency; Reliability; stable; Forest pests；defect

我们小组选择的题目是“林业有害生物智能识别”，我们开发的应用主要的功能是林业有害生物的检测，可以检测出拍摄或者相册中选择的照片中的有害生物，可以框出图片中的有害生物，并且给出有害生物的种类、个数，并且拥有有害生物的库，可以快速高效的添加或者去除有害生物的资料等信息。而我负责的部分主要是搜寻数据集、进行数据爬取、数据强化、进行图片标注、android的控件模板的制作等等。

一、究竟什么是云原生

云原生是云计算时代的新的团队文化，新的技术架构，和新的工程方式。

云原生指的是一个灵活的工程团队，遵循敏捷的研发原则，使用高度自动化的研发工具，开发专门基于并部署在云基础设施上的应用，以满足快速变化的客户需求。这些应用采用自动化的，可扩展的，和高可用的架构。这个工程团队通过高效的云计算现网的运维来提供这一应用服务，并且根据线上反馈对服务进行不断地改进。

二、云原生应用的特征

一般的云原生的应用都会具有以下这些特征：

1、普遍可访问

云原生的应用可以在任何地方从多前端访问。不需要特殊访问设备。没有网络或者地域的限制。

2、高可用性

云原生的应用可以充分利用云技术保持随时在线（24x7）。由于云服务多由计算集群提供，集群中一个节点的单点失败对服务影响小。节点失败也会触发自动恢复机制。新的服务节点会被启动，补充失去的资源。服务的升级和变更会采用灰度部署。在这个过程里，会对计算集群中的节点逐渐升级。。

3、高扩展性

云原生应用可以被在线用户随时访问。各种原因都有可能导致应用的流量在短时间内激增。云原生的应用可以随业务的需要随时迅捷地线性伸缩资源以应对流量在短时间内的大幅波动。

4、可监控

云原生的应用在现网的运行一定不会是一个黑盒子。运维人员可以通过运维工具实时收集应用服务的健康信息。基于这些现网信息，运维人员可以及时察觉和解决现网出现的各种问题。

5、安全性

云原生的应用通过对服务部署的网络（VPC）的设计，利用对网关和防火墙的设计和配置，对应用服务提供多层的安全保护。可抵御众多常规安全威胁。

6、可迁移性

云原生的应用一定会具有很强的可迁移性。云原生的应用会与底层的云计算基础设施分离。整个应用易于迁移到不同的云计算供应商。甚至应用的不同服务可以部署到不同的云计算供应商。整个应用仍然可以正常且有效地运行。

7、演进式设计与快速迭代

云原生的应用由于使用微服务架构，微服务之间相互解耦，导致它们可以独立开发，测试，部署和运维。这样每个服务可以独立创新。只要保持接口稳定，不会对应用的其他部分产生影响。而且云原生的工程团队会使用高度自动化的研发测试和运维工具。这使得云原生的应用的更新可以更加快速频繁。达成创新速度提高的最终目的。

上面总结了云原生的应用应该具备的一些主要特征。可以用来辨别一个应用是不是真正的云原生的应用。

三、云原生架构的相关概念

CNCF给出了云原生应用的三大特征：

容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。

动态管理：通过集中式的编排调度系统来动态的管理和调度。

面向微服务：明确服务间的依赖，互相解耦。

云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。

CNCF给出的云原生的定义则是：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
        云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

那么到底什么是“云原生”呢？它分表层含义和深层含义。表层含义从字面上理解就比较容易了，我们管母语叫“Native Language”，也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时，大部分的程序都是从本地环境移植到云上的，它们在设计是就根本没考虑云环境的问题。

上面讲到了，只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢？

它主要有两个部分:
        第一部分是服务调用。不论是微服务之间的调用，还是微服务调用数据库或前端调用后端，调用的方式都是一样的。都需要知道IP地址，端口和协议，例如“http://127.0.0.1:80”, 其中“http”是协议，“127.0.0.1”是IP地址，“80”是端口。由于程序是部署在k8s上的，k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器，并创建新的服务器，IP地址就变成了动态的，而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名，并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的，软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。

第二部分是数据的持久存储。在程序运行时，经常要访问持久存储（硬盘）上的数据，例如日志，配置文件或临时共享数据。程序在容器中运行，一旦出现问题，容器会被摧毁，k8s会自动重新生成一个与原来一模一样的容器，并在上面重新部署应用程序。在集群环境下，用户感觉不到容器故障，因为系统已经自动修复了。但当容器被摧毁时，容器上的数据也一起被摧毁了，因此要保证程序运行的连续性，就要让持久存储不受容器故障的影响。

四、与云原生的相结合

根据以上对云原生的定义与理解，我们的应用充分的参与了云原生的开发当中。

我们的应用采用的是云存储，用户本地只保留极少的数据，大部分数据都是在用户使用过程中远程访问云数据库来返回数据，例如用户浏览病虫害库，用户所访问到的图片、文字描述等信息都是存储在云端之中，这样既保证了数据的安全性，又能减少应用的体积，方便用户的使用。

而我们的主要功能有害生物的识别，这一功能也是需要用户实时上传图片，然后云端所部署的模型对上传来的图片进行检测识别，给前端用户返回结果。而前端则只需要对返回来的结果进行解析展示即可，解析展示的过程当中，也是调用云端的数据库中的云函数，来获取和展示详细的信息。

而我们的云数据库，是可以采用现有的服务器运营商提供的数据库，此类数据库大部分都是充分采用了云原生的理念，采用的是稳定可靠、可弹性伸缩的在线数据库服务，即当访问数据库的次数和频率突然增大时，云端可以动态的分配服务器资源，可以快速的满足前端访问的需要，而且数据也是多地备份，大大的减少了数据丢失的概率。虽然这样做可能会导致自己的用户数据外流，应用数据外泄，不过对于我们现阶段的学生来说，采用这些大运营商的服务器是最省心的选择。当然，到之后开发的应用可以部署在自己公司的服务器上，这样的话就不用担心数据外泄的问题了，不过数据的安全与否，就要取决于公司的能力了。

虽然要充分的与云原生相结合，但是由于赛题的需要，我们还需要做一些离线的应用部分，那就是离线的目标检测，这就要求我们把模型部署到手机端，这不仅要对手机的算力有一定的要求，也对我们的模型有着极高的要求，对于部署在云端的模型来说，因为服务器的算力强大，可能只需要几毫秒就可以计算完成，但是对于手机来说，可能需要一两秒，而一些老旧的机型甚至需要七八秒，这就要求我们的模型进行简化。因此，我们部署在手机端的模型和部署在服务器上的模型是不同的，对于部署在服务器端的模型，我们要求其精度足够高，由于服务器的强大，其计算时间不会太多，所以只需要考虑精度这一因素便可以了，而对于手机端的来说，为了追求速度上的提升，则必须要牺牲一定的精度，而且要大幅度的缩减模型的体积，因此，对于离线识别来说，其精度是较在线来说是偏低的。

而对于数据的存储、在线预测这两块不同的功能来说，我们则是把这两块放到了不同的服务器之上，也算是做到了“伪微服务”，这样做不仅可以分担每个服务器的压力，还可以针对某个模块、功能进行升级，从而不影响整体的内容，这也像是组件式开发，将各个模块做成独立的组件，组件之间通过统一的、开发的接口进行通讯。这样可以极大的扩大应用的可扩展性，使得应用后期的功能扩展变得更为简单。

五、缺陷管理和基本流程

1、缺陷种类及级别

1.1建议问题的软件缺陷：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。

1.2较小错误的软件缺陷：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚。

1.3一般错误的软件缺陷：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。

1.4严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。

1.5致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。

2、缺陷管理和基本流程

缺陷管理是最开始也是最基础的测试必备技能。在工作了很多年后仍然会发现大量的测试人员没有办法合理的做好缺陷管理。在我眼中的缺陷管理包含缺陷的描述、缺陷的定义、缺陷的跟踪、缺陷的度量分析。

四、结语

一般来说缺陷有两种情况，一个是违反了所谓的规则，还有一种是我们无法接受这样的情况。我们做一个软件面向的对象是不同的，甚至我们需要超出用户需求来做一点东西的，所以对于缺陷的判断成为了一个非常困难的事情。

技术架构的演变是非常快的，各种新兴的技术也是层出不穷，目前云原生的优势很明显，也很适合当下的应用开发模式，但是随着之后的技术更新迭代，可能会出现更加新颖、高效的概念、架构，此时又需要根据实际的需求来更改架构，不过亘古不变的是应用开发的思想，是对整体设计的充分理解，能够明确应用的需求、目标，这样才可以在浪潮狂颠的技术更新迭代中屹立不带。

参考文献

[1]百度百科，（https://baike.baidu.com/item/%E4%BA%91%E5%8E%9F%E7%94%9F）2021.5

[1]百度百科，（https://www.jianshu.com/p/a37baa7c3eff）2021.5

[1]百度百科，（http://dockone.io/article/2991）2021.5

[1]百度百科，（https://zhuanlan.zhihu.com/p/120073918）2021.5