计算机科学与技术毕业论文-云环境下微服务发现及降级优化技术研究

云环境下微服务发现及降级优化技术研究摘要与传统的在物理机上运行的应用程序相比，许多企业和企业都以服务的形式在服务器上部署应用程序。传统应用程序在物理机上的IP地址和端口号很少改变，而微服务的IP地址和端口号在云环境中动态变化。因此，微服务需要一个特定的服务发现机制来搜索微服务系统中的服务，然后由服务使用者调用。目前，有开源框架，如SpringCloud和Dubbo，提供服务发现功能。然而，当SpringCloud和Dubbo应用于具有大量服务的微服务系统时，存在服务发现时间长、成本高的问题。低成本的服务发现是微服务系统稳定高效运行的重要保证之一。因此，优化微服务发现服务是当前研究的热点之一。随着云计算技术和大数据技术的飞速发展，微服务体系结构也逐渐兴起。随着微服务系统中服务数量的快速增长，传统的服务发现机制和服务降级策略已不能满足微服务系统的需求。考虑到服务之间的关系，服务发现技术和服务降级技术可以从服务之间的关系中进行优化。为此，本文提出了一种基于相关矩阵的微服务发现优化方法和一种基于服务间关系的微服务降级技术优化方法。关键词：云环境微服务发现降级优化技术

目录TOC\o"1-2"\h\u16382摘要 第一章绪论1.1研究背景近年来，随着云大数据技术的飞速发展，微服务技术也得到了迅速的发展。与单一风格的体系结构和面向服务的体系结构相比，微服务体系结构具有部署独立、易于扩展、分散性强等优点。它很好地解决了单一风格的体系结构不易扩展、维护困难、组织松散的SOA体系结构的不足。因此，许多企业和企业都在大力发展微服务体系结构，以取代原来单一风格的体系结构或SOA。因此，对微服务技术的研究是当前的热点。尽管近年来微服务技术发展迅速，但仍存在服务发现滞后、云环境下微服务成本高等问题。服务降级策略不完善，没有考虑降级层次。服务退化技术是服务治理技术的重要组成部分，主要用于保证核心服务系统的正常运行，延迟或暂停补充服务或在系统最大流量期间暂停一些辅助服务的功能，以确保系统的基本服务运行平稳，只有系统是稳定的。其他服务治理技术具有应用空间，服务退化是其他服务治理技术的前提。目前，SpringCloud和Dubbo框架中的Hystrix主要组件提供了服务降级功能，但没有考虑分层降级，这保证了基本服务的正常运行，在保证补充业务最大化的同时，提高系统的稳定性和用户体验。因此，优化服务降级技术是当前最重要的问题之一。1.2研究意义服务退化技术是服务治理技术的重要组成部分，主要用于保证核心服务系统的正常运行，延迟或暂停补充服务或在系统最大流量期间暂停一些辅助服务的功能，以确保系统的基本服务运行平稳，只有系统是稳定的。其他服务治理技术具有应用空间，服务退化是其他服务治理技术的前提。目前，SpringCloud和Dubbo框架中的Hystrix主要组件提供了服务降级功能，但没有考虑分层降级，这保证了基本服务的正常运行，在保证补充业务最大化的同时，提高系统的稳定性和用户体验。因此，优化服务降级技术是当前最重要的问题之一。1.3国内外研究现状自2014年提出微服务体系结构以来，微服务技术发展迅速，服务治理技术发展迅速。服务治理技术主要包括服务降级技术、服务容错技术、服务优先级调度技术、微服务灵活性技术、服务跟踪技术业务流限制技术和业务负载均衡技术。云环境下微服务发现及降级优化技术研究随着微服务体系结构的飞速发展，服务发现技术和服务降级技术的研究也在不断深入，并取得了一定的成果。但它们不能完全满足公众对微服务系统的需求。MaXixi等人提出了一种可信度确定策略，解决了服务发现中的高延迟问题，从而在某些特定条件下减少了重复可信计算的等待时间，建立了基于服务质量（Q）的计算可信度优化模型和延迟（L）和风险（R）模型。通过MATLAB仿真实验验证了该策略在减少服务发现延迟方面的优势。为了提高用户的适用性，减少服务发现的延迟，HuLiu等人提出了一种基于上下文聚类的微服务发现算法（ACCMD），引入了服务上下文和用户上下文建模根据服务上下文的相似性对微服务进行聚类，通过服务请求和服务类的匹配建立候选服务集。根据用户上下文的相似性，对已经使用和正在使用候选服务的用户进行聚类，并通过将请求者的信息与聚类中的用户上下文进行比较来过滤候选服务集中的服务。刘璐等提出了一种面向机器对机器通信网络的高级服务发现的社会生态服务发现模型（SESD）。在SESD网络中，每个设备可以执行高级服务搜索以动态地解决复杂的查询，并相互独立地支持和协作，以快速发现和自动配置M2M通信网络中可用的任何服务，以提供实时功能。实验结果表明，SESD能够实时自适应和自组织，产生更大的灵活性和适应性，并具有更好的服务发现效率。Suchitra等人设计了一种基于QoS的可信服务发现体系结构，以解决服务发现的高延迟问题。在考虑稳定性、可靠性、负载和容量的基础上，根据相对移动性、剩余能量和可用带宽选择核心节点。仿真结果表明，所提出的服务发现体系结构能够有效地降低延迟。目前，对微服务发现机制的优化研究已经取得了一定的成果，但还不能解决服务发现延迟时间长、代价大的问题。因此，关于微服务发现服务优化的研究成果仍然是有限的。针对上述问题，本文提出了一种基于关联矩阵的服务发现算法，该算法基于服务发现的全过程，包括服务发现的延迟和代价、服务发现注册表和客户端之间通信的延迟和开销，以及调用服务的延迟和开销。通过减少服务发现的延迟和代价以及相关服务调用的延迟和代价来优化服务发现机制，从而减少整个服务发现过程的延迟和代价。微服务降级服务的优化策略也取得了一定的效果，但仍不能满足用户的需求，即使在流量高峰时期，用户也至少需要访问网站，即网站需要可读性目前对服务退化的研究还没有考虑到服务退化的程度，在高峰时段，为了充分保证基本服务的正常运行，现有的策略考虑了牺牲系统服务质量通过合并方法对补充业务进行降级，包括：当业务量超过系统设置的门限时，自动降级策略流限制、直接业务量限制、用户访问请求限制这将严重降低系统的服务质量。严重影响用户体验。为了解决这些问题，本文将降级分为多个级别，并根据系统内存的利用率来划分系统的负载级别，从而在考虑服务间关系的基础上确定降级级别。优先考虑降级和非核心服务，从而提高系统的服务质量和用户体验。第二章相关理论基础第二章相关理论基础第二章相关理论基础2.1微服务技术2.1.1微服务架构微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。微服务技术已经发展了五年多。在此之前，大多数系统应用程序以单体架构的形式存在。单一风格的体系结构开发简单直接，管理集中，但开发效率低。由于整个开发代码都是在一个项目中修改的，所以代码的每一部分都会发生预期的情况，并且经常发生冲突。应用程序的维护、更新和扩展是一项艰巨的任务。因此，对于经常需要更新的业务应用程序，单一的应用程序样式是非常不合适的。当微服务体系结构被提出时，由于其独立部署、易于扩展和分散的优点，微服务体系结构迅速受到大多数企业的青睐，单一的体系结构逐渐被取代。以电子商务系统为例，系统架构如图2.1所示：图2.1电子商务系统单体式架构图微服务架构的前身还有SOA架构，SOA架构没有大规模的、落地的实践，大部分是停留在理论层次，因此，没有大众的支持，所以使用范围也并不广泛。以电子商务系统为例，如图1.2所示为SOA系统架构图：第二章相关理论基础图2.2电商物流系统SOA架构图相比之下，微服务的兴起是基于大规模的生产实践，并有实际的登陆应用，如阿里巴巴开发的开源SpringCloud微服务框架Pivotal和Dubbo框架，是目前应用最广泛的微服务平台体系结构的应用框架。与单一风格的体系结构和SOA体系结构相比，微服务体系结构通过将系统中的服务层完全分离，避免了开发工作的重复，大大提高了开发效率。微服务的发展遵循这样一个独特的原则：一个类只有一个函数，它只做与自身相关的事情，并且类和类之间保持正交，不相互影响。2.1.2服务发现技术“服务发现是一种网络协议,它可以立即自动地检测到网络上计算机的硬件网络设备和服务。如果计算机上没有一个有效的服务发现模型,则必须由用户手动配置网络硬件,这对于大多数计算机新手用户。服务发现技术是所有现代操作系统的一部分,允许计算机彼此联网,用户只需相对适度的个人技术知识就可以上网。”物理机器上的传统应用程序运行在端口号和IP地址固定的固定机器上，因此用户可以通过配置文件响应更新的IP地址和端口号。端口号和IP地址都会动态更改。此外，由于系统的不规则更新和扩展，服务实例的数量也会动态变化。因此，用户需要一种特殊的服务发现机制来发现系统中的服务，因此微服务服务发现技术应运而生。帮助系统在云环境中找到服务的网络地址，即终端口号和IP地址以及其他服务细节。服务发现有三个要素：（1）服务消费者，服务消费者一般是只用户，用户从客户端发出服务请求，有消费的要求，才会有后续的服务提供者和服务注册中心存在的必要；（2）服务提供者，服务提供者一般是指系统中的服务，一般一个服务实例包含多个副本以保证系统高可用的要求；（3）服务注册中心，服务注册中心也就是储存服务端口号、IP地址以及其他详细信息的地方，相当于数据库，目前应用比较广泛的服务注册中心有Eureka、Etcd、Consul、Zookeeper等等。2.1.3服务治理（1）服务降级技术是指当服务器处于最大访问周期时，微服务体系结构的总负载超过设定的阈值，或者入站流量会使总负载超过设定的阈值。根据实际业务情况，在保证系统某些基本业务正常运行的前提下保证了微服务系统的整体负载降低或保持在正常范围内，使系统正常工作。因此，服务退化技术也是服务治理的重要组成部分。（2）业务容错技术，是指在没有及时发现网络通信不稳定等情况下，用于处理业务的错误、超时或停机的技术。服务线程池中的线程在短时间内耗尽，资源耗尽，导致雪崩效应。线程池隔离模式、合并模式等。（3）业务优先级调度技术是指减少一些非核心业务的调度频率，释放部分占用的资源，以保证核心业务系统的正常运行和系统的稳定运行，从而保证在系统资源有限的情况下，系统基本服务的正常高效运行。发布服务通过扩展优先级属性在系统中设置服务的优先级，服务提供者将服务的优先级属性注册到服务注册中心，然后通知服务使用者，服务优先级由服务使用者缓存。并根据不同的调度策略对服务优先级进行调度。（4）灵活的微服务伸缩技术可分为两种：第一种是应用层伸缩，通过增加或减少服务实例副本的数量来满足系统和服务消费者的需求；二是扩展IAAS（基础设施即服务）层的资源集合，即根据系统需求扩展服务的节点。例如，将10个节点的服务分配给100个节点。（5）在微服务体系结构中，由于服务的划分，服务请求将包含多个服务，每个服务可以由不同的团队开发，部署在不同的位置，使用不同的开发环境和语言，因此，跟踪服务需要记录用户请求发起了哪些服务调用以及处理了哪些服务。目前最常用的开源组件有SpringCloud框架下的Sleuth组件和Zipkin全链接跟踪组件等。服务降级技术是解决系统访问高峰时期服务器压力的重要技术之一。衡量微服务系统质量的不是用户数量少时的性能，而是在巨大压力下的容灾能力，服务退化技术是其他服务治理技术的基础和前提，而服务退化技术是衡量微服务系统性能的重要指标。因此，服务退化技术是服务治理技术的重要组成部分。2.2微服务发现技术2.2.1客户端服务发现模式在客户服务发现模式下，用户发送客户服务请求并查询服务注册，以获取所请求服务的端口号和IP地址。然后，通过负载平衡算法集选择需要可用服务的服务实例，请求由客户端发送到服务，服务响应。并将响应反馈给客户端，每个服务通过restfulapi接口以restfulapi的形式调用。2.2.2服务端服务发现模式在服务器端服务发现模式中，与客户端服务发现模式相比，有一个额外的负载平衡组件。客户端向负载均衡组件发送服务请求后，通过负载均衡组件在服务注册中心查询服务使用者需要呼叫的服务的端口号和IP地址。找到负载平衡组件后，将客户端发送的服务请求转发到相应的服务，启动调用请求，然后服务将响应返回到负载平衡组件，负载平衡组件响应于反馈给客户的信息。目前，最常用的负载平衡组件是NGINX和SpringCloud框架中的磁带组件。2.3微服务降级技术2.3.1微服务降级技术概念什么是服务降级？当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。可以举个例子：假如目前有很多人想要给我付钱，但我的服务器除了正在运行支付的服务之外，还有一些其它的服务在运行，比如搜索、定时任务和详情等等。然而这些不重要的服务就占用了JVM的不少内存与CPU资源，为了能把钱都收下来（钱才是目标），我设计了一个动态开关，把这些不重要的服务直接在最外层拒掉，这样处理后的后端处理收钱的服务就有更多的资源来收钱了（收钱速度更快了），这就是一个简单的服务降级的使用场景。在服务器端服务发现模式中，与客户端服务发现模式相比，有一个额外的组件负载平衡。当客户端向负载均衡组件发送服务请求后，负载均衡组件查询服务用户需要呼叫的服务的端口号和IP地址到服务注册中心。找到负载平衡组件后，将客户端发送的服务请求转发给相应的服务，启动请求调用，服务将响应返回给客户端的信息返回给负载平衡组件。目前，最常见的负载平衡组件是NGINX和SpringCloud框架中的磁带组件。2.3.2微服务降级策略手动降级是指预先将降级逻辑写入逻辑代码中，通过系统配置中心手动修改该值，实现对某些业务的手动降级，以维护系统的稳定性。目前，最常用的自动降级策略如下：（1）自动化超时降级：对于系统中的非核心服务，如果数据库访问或对远程服务调用的响应非常慢，则可以在配置文件中自动设置超时，当对服务的数据库访问或远程服务调用超过配置文件中设置的时间时，超时将自动降级。在配置中心预先设置门限超时和门限重试超时，并通过异步机制检测恢复服务。（2）统计失败次数降级：该策略是通过检测，预先设定熔断器元件在规定时间内的故障次数阈值，当在规定时间内服务的故障次数达到熔断器元件的故障次数阈值时，进行自动降级并通过异步监控机制检测服务，当指定时间内的服务故障数低于设定的阈值时，自动恢复降级服务。（3）自动化限流降级：在交通高峰时期，如每年的购物节和有限的时间内，系统的访问量将在短时间内急剧增加。因此，通过限制交通来减轻系统压力。当流量达到限制阈值时，监控请求将被临时降级和延迟，Web服务将通过等待队列（中间过渡接口）、错误页等降级。（4）故障降级：当需要调用的服务出故障时(网络故障、DNS故障、HTTP状态码异常等)，自动进行降级，并返回默认数据、兜底数据或者缓存的数据，并通过异步监测机制探测恢复情况。第三章基于服务关联性的微服务降级技术优化第三章基于服务关联性的微服务降级技术优化近年来，随着云计算技术的飞速发展，单一的体系结构正逐渐被微服务体系结构所取代。尽管微服务体系结构具有许多优点，但它在使用中也存在一些问题：由于微服务体系结构中的模块之间是相互独立的，因此，它的应用越来越广泛。在部署的云环境中，每个服务的网络地址都会动态变化，由于服务之间的相关性，当调用一个服务时，该服务也会调用相关的服务。因此，增加了服务发现的延迟和成本。因此，在一个微服务体系结构中，如何快速准确地找到和调用目标子服务及其相关服务是一个亟待解决的问题。目前已有一种通过DNS解析域名来实现服务发现的方法，但这种方法在大量服务的情况下存在着很长的延迟。还提供了一种通过ZooKeeper组件执行服务注册和服务发现的方法，但是由于ZooKeeper满足分布式系统中的一致性和容错分区，因此不能保证可用性。针对上述问题，本章提出了服务关联矩阵的构造方法和基于关联矩阵的服务发现算法（AMBSD）。考虑到服务发现的延迟和代价，利用延迟和代价理论，得到了基于关联矩阵的服务发现算法（AMBSD）的可执行条件。实验结果表明，该算法在降低时延和代价方面具有一定的优越性。3.1问题描述在微服务系统中，由于服务之间的相关性很大，如果一个服务降级，就会影响到相关服务的性能，因此为了保持微服务系统的稳定性我们必须注意降级服务是否会影响其他服务和系统可用性。现有的微服务降级策略有手动降级、自动超时降级、自动限流降级等，但都存在较大的缺点。手动降级策略在服务数量相对较少的系统中是可行的，但在服务数量相对较多的系统中，手动降级操作非常困难，成本非常高，显然不可行。自动降级超时和降级限流可以弥补大规模微服务系统中手动降级不可行的缺点，但会导致服务请求阻塞，导致服务器崩溃同时，由于对某些业务的过度请求，还可能触发自动超时降级和自动流限制降级的执行条件。因此，与服务相关的服务的执行受到影响，导致系统不可用的严重后果，这两种策略都忽略了降级的层次结构。而自动降级的等待时间是通过合并降级的。降级必须一步一步地通过降级级别进行，如图3.1所示：不分层次地降级会导致服务器资源的浪费，也会降低服务质量，因此，需要考虑降级哪些服务以及特定的服务要降级的程度。图3.1服务降级程度示意图3.2服务降级理论分析3.2.1微服务系统稳定性本文研究的问题的应用场景主要是系统访问的高峰期，此时要对部分服务进行降级操作，因此本文设定通过系统可用性SA以及系统负载情况SL这两个指标的高低来评判系统的稳定性。假设集群中共有n个节点，则节点集合为N={N1，N2，...Nn}，假设这n个节点中微服务的数量总共为m个，则微服务集合为M={M1，M2，...Mm}。系统可用性SA是指系统正常运行的时间Tnormal与系统运行总时间T的比，其中，系统运行的总时间由系统正常运行的时间Tnormal和非正常运行时间(故障时间)Tabnormal两部分组成，系统可用性SA即可表示为：3.2.2微服务优先级在系统访问高峰期这一应用场景下，设定微服务优先级，微服务优先级越低则越先考虑降级，优先级越高则降级顺序越靠后。在该场景下，本文设定微服务的优先级由微服务内存占用率MM和微服务关联度MR两部分组成。微服务Mi的内存占用包括以下几部分：堆内存M(i，heap)、线程堆栈申请的内存M(i，thread)、微服务类大小（即微服务的jar包所占的内存大小）M(i，class)、以及其他内存占用(编译、垃圾回收等占用的内存)M(i，other)。各个节点内存集合MEM表示为MEM={MEM1，MEM2，...，MEMn}，则微服务Mi在集群中的内存占用率MM(i)可以表示为：根据二八原则，设定微服务系统中20%的服务为核心服务(即能够影响整个系统稳定性的服务)，即核心服务数量为0.2*m，假设与微服务Mi关联(即核心服务依赖于服务Mi，没有服务Mi，核心服务则无法执行，i为服务序号)的核心服务的数量为x，则服务Mi与核心服务的关联度MR(i)可以表示为：其中，0≤MR(i)≤1，MR(i)越接近1表示微服务Mi与核心服务的关联度越高，MR(i)越接近0表示微服务Mi与核心服务的关联度越低。3.3微基于服务关联性的分级降级算法3.3.1微服务降级方法在服务量大的微服务系统中，由于服务量大，人工降级方法将面临操作和维护人员无法及时操作的问题，因此不可能实现自动降级。现有的自动化服务降级方法，如Hystrix中基于状态反馈的融合调整算法和Dubbo中的力反馈和故障反馈策略，可以实现服务的自动降级，但不能实现量化降级。也就是说，一个服务的降级规模是无法确定的，如果所有的降级服务都采用合并的方式，用户体验的效果将受到很大的影响，如果与核心服务相关的服务自动降级，系统的可用性将受到影响，这将导致基本服务无法使用。基于自动反馈的状态融合流程调整算法包括三种状态：开、闭和半开。这三个状态代表引信的工作状态。默认情况下，保险丝处于闭合状态。调用接口失败的概率是通过存储在Hystrix命令度量对象中的调用连接数和调用接口失败的次数来获得的。操作维护人员通过微服务系统的实际情况，设定呼叫接口的故障概率阈值和同一接口的呼叫次数阈值。当两个阈值都超过限制时，熔丝从关闭状态转换为打开状态，并且当调用服务时，服务调用方从远程调用切换到本地降级接口。基于状态反馈的融合调整算法提供了一种降级恢复策略，保证了当服务访问的最大周期已经过去时，可以恢复降级的服务。该策略建立了一个测试窗口，从保险丝到打开状态的过渡开始，到保险丝到关闭或半打开状态的过渡结束。测试窗口时间通常设置为平均故障处理时间。当接口调用时间大于平均故障处理时间时，打开状态变为半打开状态，进行远程调用。如果远程调用仍然失败，则保险丝返回打开状态。如果所有远程调用（或一定比例）都成功，则半打开状态变为关闭状态。该算法缺乏对降级层次的考虑，当引信打开时，采用融合的方法进行降级，这将对用户体验产生很大的影响。Dubbo的服务降级策略框架ForceReturn和FailReturn分别表示屏蔽和容错。强制返回策略直接屏蔽请求并返回运维人员设置的仿真值，故障返回策略允许请求在请求失败时返回仿真值。杜博的政策也没有考虑到降级等级。3.3.2可降级服务的选取在微服务系统中，由于服务之间的依赖性，微服务的降级应避免核心服务和核心服务所依赖的服务，即相关服务。这对整个微服务系统造成了严重后果。此外，服务降级甚至大规模合并的方式将对用户体验产生重大影响，因此有必要将服务降级或大规模合并的方式降至最低。针对上述问题，本文提出了一种基于服务相关性的分层降级算法它可以保护中心业务和与中心业务相关的业务，解决中心业务降级或与中心业务相关的业务降级导致中心业务无法运行的问题。如何根据集群内存利用率对服务的降级级别进行分类，从而解决大规模的服务降级甚至融合问题，将极大地影响用户的体验。3.4实验分析3.4.1实验环境在本实验中，我们使用SpringCloud中的Hystrix组件来执行服务降级。在实验室搭建了三台高性能服务器，模拟了实际生产环境。服务降级方法是通过修改hystrix源代码和注释@hystrix命令（回退方法=“xxxx”）指定的。综合比较了系统可用性中的自动超时降级算法、自动流限制降级算法和基于服务关联的分层降级算法在微服务系统中运行后的系统负载和系统读写能力。在微服务系统中，微服务类型为100，每个服务有10个副本服务，服务总量为1000，小微服务系统的服务总量（包括副本服务）小于100，中型微服务系统的服务总量为几百个，大型微服务系统的服务总量为1000个或更多，通过配置100种微服务，这10个副本中的每一个都模拟了一个大规模的微服务系统，并确保了服务的高可用性，以防止某些服务失败，从而导致系统不可用。服务部署在Docker容器中，并通过K8S集群进行管理。实验环境参数表：表1.1实验环境配置参数表3.4.2实验过程实验通过压力测试，分别设置5万、6万、7万、8万、9万、10万、11万、12万的并发量以模拟微服务系统访问高峰期，计时测量系统运行时间T、系统可用时间TA、系统可供读写时间TRW、系统负载值TL。表1.2是实验的具体数据配置信息：表1.2实验配置信息表设置并发请求量5-12万，其中5-6万模拟风暴级别蓝色风暴，7-8万模拟风暴级别黄色风暴，9-10万模拟风暴级别橙色风暴，11-12万模拟风暴级别红色风暴，设置服务总量均为3000个，以模拟大型微服务系统，根据二八原则，设置系统核心服务数量为服务总量的20%，即600个，根据不同的并发量并根据式4.10和4.11测量并计算系统可用性A和系统供读写能力RW的结果：比较自动化超时降级算法、自动化限流降级算法以及本文所提出的基于服务关联性的分级降级算法(SRBHD)在各个情况下进行服务降级，微服务系统的性能状况，包括系统可用性、系统负载情况以及系统的可供读写的能力几方面。以此验证基于服务关联性的分级降级算法(SRBHD)在系统访问高峰期，提升微服务系统稳定性的有效性以及优势。3.4.3仿真结果分析根据测量以及式4.10和4.11的计算结果，得出并发请求量5-12万范围内自动化超时降级算法、自动化限流降级算法以及SRBHD算法进行服务降级后微服务系统的可用性、负载情况以及可供读写的能力的相关数据，并绘制如图3.2、3.3、3.4所示的微服务系统性能对比图：图3.2系统可用性对比图如图4所示为微服务系统在并发量从5万增长到12万过程中执行基于服务关联性的分级降级算法(SRBHD)、自动化超时降级算法以及自动化限流降级算法，微服务系统可用性的对比图，可以看到，从并发量约为7万时，系统执行自动化超时降级算法以及自动化限流降级算法后的系统可用性迅速下降，而系统执行基于服务关联性的分级降级算法(SRBHD)后的系统可用性下降速度比较缓慢，并且大部分时间系统可用性高达90%以上。图3.3系统负载情况对比图如图2所示为微服务系统在并发量从5万增长到12万过程中执行基于服务关联性的分级降级算法(SRBHD)、自动化超时降级算法以及自动化限流降级算法，微服务系统负载情况对比图，其中，y轴负载的值越小表明系统负载情况越好，越大则表明系统负载情况越差，系统执行自动化超时降级算法以及自动化限流降级算法，由图5可见，系统负载情况变差的速度明显快于基于服务关联性的分级降级算法(SRBHD)，并且系统执行基于服务关联性的分级降级算法(SRBHD)的负载值大部分时间都处于0.3以下，表明负载情况比较好。图3.4系统供读写能力对比图如图6所示，微服务系统执行基于服务相关性的分层降级算法（SRBHD），自动超时降级算法和自动流限制降级算法在并发过程中从50000增加到120000。通过对微服务系统读写能力的图形比较表明，Y轴的范围为0～1。Y轴值越大，微服务系统可以读取和写入的服务量就越大。Y轴上较小的值表示微服务系统的读写服务较少。在图4中，当并发量约为70000且并发量约为90000时，Y轴对应的系统读写能力大大降低，因为当并发量约为70000时，集群内存利用率达到60%，导致一场黄色风暴。一些微服务系统服务开始写和降级，当并发量达到9万左右时，集群内存利用率达到70%，导致橙色风暴。微服务系统开始降级写入。如图3所示，微服务系统执行基于服务关联的分层降级算法（SRBHD）。该系统的读写性能明显优于运行自动超时降级算法和有限流量自动降级算法的微服务系统。实验结果表明，基于服务关联的分层降级算法可以有效地提高微服务系统的可用性和负载，最大限度地保证系统服务的读写能力。从而改善用户体验。第四章结论第四章结论近年来，随着云计算和大数据技术的发展，微服务体系结构得到了迅速的发展，与微服务相关的技术成为研究的热点。问题不断出现，现有的服务发现技术和服务降级技术已经不能满足日益庞大的微服务系统的需求。延迟服务发现的高成本仍然是一个需要解决的问题，因为某些服务的延迟服务发现可能会导致系统服务调用被中断，服务请求被阻止，从而导致雪崩效应。因此，有必要对服务发现机制进行优化。服务降级技术作为服务管理技术的重要组成部分，在系统最大流量期间对维护系统的稳定起着重要作用。高效的服务降级策略可以使系统安全稳定地运行，顺利度过系统的最大流量周期。因此，有必要对服务降级技术进行研究。经过此次论文设计，在云环境下微服务发现及降级优化技术方面有了全面的了解，能快捷高效的按照计划完成微服务发现及降级优化方面的设计。之前对云环境下微服务发现及降级有各种疑问，最早做云环境下微服务发现及降级优化时思路、方向不正确导致走了很多的弯路，后来通过阅读专业书籍与前辈