课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,越来越多的人都在学习计算机编程开发技术,下面我们就通过案例分析来了解一下,软件开发测试与维护都有哪些问题。
测试之痛
现如今后端领域已经进入了云原生时代,微服务架构早已经是事实标准。其中通讯方面是以的事件驱动方式(Event-driven),这表示所有的请求都是通过RPC即以接口调用的方式实现的。一个合理划分的微服务,在稍具规模的情况下拥有的接口数量保守估计至少是在十位数以上,因此对接口级别、服务级别的阈值获取将变得相当繁琐和困难。
接口压测
如前文提到的,即使是同一个接口,每轮压测的结果也会有差距。这是因为机器资源在测试中同时会受到垃圾回收、线程/进程资源抢占、磁盘I/O抖动、网络带宽质量等因素的影响。在服务级别的测试、线上环境中,此类问题会被进一步放大。为此,测试人员不得不多次测量求个均值以求准确。
服务级压测
不同接口显然对资源的消耗程度不同,因其包含读、写、下游扇出等各种情况时延也会产生差异。对于服务级别的限流阈值确定可以说是相当困难,因为基于接口级的阈值组合会在不同用户请求不同接口时产生波动。为此进行流量录制并全链路压测虽能够阈值的范围,但仍无法做到精准,且成本过大。
维护之痛
所有测试以及线上环境中,关键其实是计算资源的配置。所测试机器的CPU核心数和内存等配置时刻影响着测试结果。再者,如今基于容器网络如k8s的自动资源scale能力,会使得基于具体数字的阈值设定难以维护。再者,秒级的流量限制显然对于100ms内突发流量洪峰无法做出有效干预,导致服务异常过载。
干预成本
当无论遇到线上激增流量机器指标异常、自动扩容等导致阈值不再适用,进而要增加或者减小时,工程师从发现问题到上机操作发布配置的耗时已经错过了干预的佳时机。
认知负担
从上述测量流程来看,工程师必须对计算资源、接口业务、容器配合、调度时机等各方面有足够认知才能应对各种流量突发状况,显然会消耗大量的精力和时间。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。