云環(huán)境下微服務(wù)發(fā)現(xiàn)及降級優(yōu)化技術(shù)研究摘要與傳統(tǒng)的在物理機上運行的應(yīng)用程序相比，許多企業(yè)和企業(yè)都以服務(wù)的形式在服務(wù)器上部署應(yīng)用程序。傳統(tǒng)應(yīng)用程序在物理機上的IP地址和端口號很少改變，而微服務(wù)的IP地址和端口號在云環(huán)境中動態(tài)變化。因此，微服務(wù)需要一個特定的服務(wù)發(fā)現(xiàn)機制來搜索微服務(wù)系統(tǒng)中的服務(wù)，然后由服務(wù)使用者調(diào)用。目前，有開源框架，如SpringCloud和Dubbo，提供服務(wù)發(fā)現(xiàn)功能。然而，當SpringCloud和Dubbo應(yīng)用于具有大量服務(wù)的微服務(wù)系統(tǒng)時，存在服務(wù)發(fā)現(xiàn)時間長、成本高的問題。低成本的服務(wù)發(fā)現(xiàn)是微服務(wù)系統(tǒng)穩(wěn)定高效運行的重要保證之一。因此，優(yōu)化微服務(wù)發(fā)現(xiàn)服務(wù)是當前研究的熱點之一。隨著云計算技術(shù)和大數(shù)據(jù)技術(shù)的飛速發(fā)展，微服務(wù)體系結(jié)構(gòu)也逐漸興起。隨著微服務(wù)系統(tǒng)中服務(wù)數(shù)量的快速增長，傳統(tǒng)的服務(wù)發(fā)現(xiàn)機制和服務(wù)降級策略已不能滿足微服務(wù)系統(tǒng)的需求?？紤]到服務(wù)之間的關(guān)系，服務(wù)發(fā)現(xiàn)技術(shù)和服務(wù)降級技術(shù)可以從服務(wù)之間的關(guān)系中進行優(yōu)化。為此，本文提出了一種基于相關(guān)矩陣的微服務(wù)發(fā)現(xiàn)優(yōu)化方法和一種基于服務(wù)間關(guān)系的微服務(wù)降級技術(shù)優(yōu)化方法。關(guān)鍵詞：云環(huán)境微服務(wù)發(fā)現(xiàn)降級優(yōu)化技術(shù)

目錄TOC\o"1-2"\h\u16382摘要 第一章緒論1.1研究背景近年來，隨著云大數(shù)據(jù)技術(shù)的飛速發(fā)展，微服務(wù)技術(shù)也得到了迅速的發(fā)展。與單一風格的體系結(jié)構(gòu)和面向服務(wù)的體系結(jié)構(gòu)相比，微服務(wù)體系結(jié)構(gòu)具有部署獨立、易于擴展、分散性強等優(yōu)點。它很好地解決了單一風格的體系結(jié)構(gòu)不易擴展、維護困難、組織松散的SOA體系結(jié)構(gòu)的不足。因此，許多企業(yè)和企業(yè)都在大力發(fā)展微服務(wù)體系結(jié)構(gòu)，以取代原來單一風格的體系結(jié)構(gòu)或SOA。因此，對微服務(wù)技術(shù)的研究是當前的熱點。盡管近年來微服務(wù)技術(shù)發(fā)展迅速，但仍存在服務(wù)發(fā)現(xiàn)滯后、云環(huán)境下微服務(wù)成本高等問題。服務(wù)降級策略不完善，沒有考慮降級層次。服務(wù)退化技術(shù)是服務(wù)治理技術(shù)的重要組成部分，主要用于保證核心服務(wù)系統(tǒng)的正常運行，延遲或暫停補充服務(wù)或在系統(tǒng)最大流量期間暫停一些輔助服務(wù)的功能，以確保系統(tǒng)的基本服務(wù)運行平穩(wěn)，只有系統(tǒng)是穩(wěn)定的。其他服務(wù)治理技術(shù)具有應(yīng)用空間，服務(wù)退化是其他服務(wù)治理技術(shù)的前提。目前，SpringCloud和Dubbo框架中的Hystrix主要組件提供了服務(wù)降級功能，但沒有考慮分層降級，這保證了基本服務(wù)的正常運行，在保證補充業(yè)務(wù)最大化的同時，提高系統(tǒng)的穩(wěn)定性和用戶體驗。因此，優(yōu)化服務(wù)降級技術(shù)是當前最重要的問題之一。1.2研究意義服務(wù)退化技術(shù)是服務(wù)治理技術(shù)的重要組成部分，主要用于保證核心服務(wù)系統(tǒng)的正常運行，延遲或暫停補充服務(wù)或在系統(tǒng)最大流量期間暫停一些輔助服務(wù)的功能，以確保系統(tǒng)的基本服務(wù)運行平穩(wěn)，只有系統(tǒng)是穩(wěn)定的。其他服務(wù)治理技術(shù)具有應(yīng)用空間，服務(wù)退化是其他服務(wù)治理技術(shù)的前提。目前，SpringCloud和Dubbo框架中的Hystrix主要組件提供了服務(wù)降級功能，但沒有考慮分層降級，這保證了基本服務(wù)的正常運行，在保證補充業(yè)務(wù)最大化的同時，提高系統(tǒng)的穩(wěn)定性和用戶體驗。因此，優(yōu)化服務(wù)降級技術(shù)是當前最重要的問題之一。1.3國內(nèi)外研究現(xiàn)狀自2014年提出微服務(wù)體系結(jié)構(gòu)以來，微服務(wù)技術(shù)發(fā)展迅速，服務(wù)治理技術(shù)發(fā)展迅速。服務(wù)治理技術(shù)主要包括服務(wù)降級技術(shù)、服務(wù)容錯技術(shù)、服務(wù)優(yōu)先級調(diào)度技術(shù)、微服務(wù)靈活性技術(shù)、服務(wù)跟蹤技術(shù)業(yè)務(wù)流限制技術(shù)和業(yè)務(wù)負載均衡技術(shù)。云環(huán)境下微服務(wù)發(fā)現(xiàn)及降級優(yōu)化技術(shù)研究隨著微服務(wù)體系結(jié)構(gòu)的飛速發(fā)展，服務(wù)發(fā)現(xiàn)技術(shù)和服務(wù)降級技術(shù)的研究也在不斷深入，并取得了一定的成果。但它們不能完全滿足公眾對微服務(wù)系統(tǒng)的需求。MaXixi等人提出了一種可信度確定策略，解決了服務(wù)發(fā)現(xiàn)中的高延遲問題，從而在某些特定條件下減少了重復(fù)可信計算的等待時間，建立了基于服務(wù)質(zhì)量（Q）的計算可信度優(yōu)化模型和延遲（L）和風險（R）模型。通過MATLAB仿真實驗驗證了該策略在減少服務(wù)發(fā)現(xiàn)延遲方面的優(yōu)勢。為了提高用戶的適用性，減少服務(wù)發(fā)現(xiàn)的延遲，HuLiu等人提出了一種基于上下文聚類的微服務(wù)發(fā)現(xiàn)算法（ACCMD），引入了服務(wù)上下文和用戶上下文建模根據(jù)服務(wù)上下文的相似性對微服務(wù)進行聚類，通過服務(wù)請求和服務(wù)類的匹配建立候選服務(wù)集。根據(jù)用戶上下文的相似性，對已經(jīng)使用和正在使用候選服務(wù)的用戶進行聚類，并通過將請求者的信息與聚類中的用戶上下文進行比較來過濾候選服務(wù)集中的服務(wù)。劉璐等提出了一種面向機器對機器通信網(wǎng)絡(luò)的高級服務(wù)發(fā)現(xiàn)的社會生態(tài)服務(wù)發(fā)現(xiàn)模型（SESD）。在SESD網(wǎng)絡(luò)中，每個設(shè)備可以執(zhí)行高級服務(wù)搜索以動態(tài)地解決復(fù)雜的查詢，并相互獨立地支持和協(xié)作，以快速發(fā)現(xiàn)和自動配置M2M通信網(wǎng)絡(luò)中可用的任何服務(wù)，以提供實時功能。實驗結(jié)果表明，SESD能夠?qū)崟r自適應(yīng)和自組織，產(chǎn)生更大的靈活性和適應(yīng)性，并具有更好的服務(wù)發(fā)現(xiàn)效率。Suchitra等人設(shè)計了一種基于QoS的可信服務(wù)發(fā)現(xiàn)體系結(jié)構(gòu)，以解決服務(wù)發(fā)現(xiàn)的高延遲問題。在考慮穩(wěn)定性、可靠性、負載和容量的基礎(chǔ)上，根據(jù)相對移動性、剩余能量和可用帶寬選擇核心節(jié)點。仿真結(jié)果表明，所提出的服務(wù)發(fā)現(xiàn)體系結(jié)構(gòu)能夠有效地降低延遲。目前，對微服務(wù)發(fā)現(xiàn)機制的優(yōu)化研究已經(jīng)取得了一定的成果，但還不能解決服務(wù)發(fā)現(xiàn)延遲時間長、代價大的問題。因此，關(guān)于微服務(wù)發(fā)現(xiàn)服務(wù)優(yōu)化的研究成果仍然是有限的。針對上述問題，本文提出了一種基于關(guān)聯(lián)矩陣的服務(wù)發(fā)現(xiàn)算法，該算法基于服務(wù)發(fā)現(xiàn)的全過程，包括服務(wù)發(fā)現(xiàn)的延遲和代價、服務(wù)發(fā)現(xiàn)注冊表和客戶端之間通信的延遲和開銷，以及調(diào)用服務(wù)的延遲和開銷。通過減少服務(wù)發(fā)現(xiàn)的延遲和代價以及相關(guān)服務(wù)調(diào)用的延遲和代價來優(yōu)化服務(wù)發(fā)現(xiàn)機制，從而減少整個服務(wù)發(fā)現(xiàn)過程的延遲和代價。微服務(wù)降級服務(wù)的優(yōu)化策略也取得了一定的效果，但仍不能滿足用戶的需求，即使在流量高峰時期，用戶也至少需要訪問網(wǎng)站，即網(wǎng)站需要可讀性目前對服務(wù)退化的研究還沒有考慮到服務(wù)退化的程度，在高峰時段，為了充分保證基本服務(wù)的正常運行，現(xiàn)有的策略考慮了犧牲系統(tǒng)服務(wù)質(zhì)量通過合并方法對補充業(yè)務(wù)進行降級，包括：當業(yè)務(wù)量超過系統(tǒng)設(shè)置的門限時，自動降級策略流限制、直接業(yè)務(wù)量限制、用戶訪問請求限制這將嚴重降低系統(tǒng)的服務(wù)質(zhì)量。嚴重影響用戶體驗。為了解決這些問題，本文將降級分為多個級別，并根據(jù)系統(tǒng)內(nèi)存的利用率來劃分系統(tǒng)的負載級別，從而在考慮服務(wù)間關(guān)系的基礎(chǔ)上確定降級級別。優(yōu)先考慮降級和非核心服務(wù)，從而提高系統(tǒng)的服務(wù)質(zhì)量和用戶體驗。第二章相關(guān)理論基礎(chǔ)第二章相關(guān)理論基礎(chǔ)第二章相關(guān)理論基礎(chǔ)2.1微服務(wù)技術(shù)2.1.1微服務(wù)架構(gòu)微服務(wù)架構(gòu)是一項在云中部署應(yīng)用和服務(wù)的新技術(shù)。大部分圍繞微服務(wù)的爭論都集中在容器或其他技術(shù)是否能很好的實施微服務(wù)，而紅帽說API應(yīng)該是重點。微服務(wù)可以在“自己的程序”中運行，并通過“輕量級設(shè)備與HTTP型API進行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運行。通過這一點我們就可以將服務(wù)公開與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個API）區(qū)分開來。在服務(wù)公開中，許多服務(wù)都可以被內(nèi)部獨立進程所限制。如果其中任何一個服務(wù)需要增加某種功能，那么就必須縮小進程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進程的架構(gòu)。微服務(wù)技術(shù)已經(jīng)發(fā)展了五年多。在此之前，大多數(shù)系統(tǒng)應(yīng)用程序以單體架構(gòu)的形式存在。單一風格的體系結(jié)構(gòu)開發(fā)簡單直接，管理集中，但開發(fā)效率低。由于整個開發(fā)代碼都是在一個項目中修改的，所以代碼的每一部分都會發(fā)生預(yù)期的情況，并且經(jīng)常發(fā)生沖突。應(yīng)用程序的維護、更新和擴展是一項艱巨的任務(wù)。因此，對于經(jīng)常需要更新的業(yè)務(wù)應(yīng)用程序，單一的應(yīng)用程序樣式是非常不合適的。當微服務(wù)體系結(jié)構(gòu)被提出時，由于其獨立部署、易于擴展和分散的優(yōu)點，微服務(wù)體系結(jié)構(gòu)迅速受到大多數(shù)企業(yè)的青睞，單一的體系結(jié)構(gòu)逐漸被取代。以電子商務(wù)系統(tǒng)為例，系統(tǒng)架構(gòu)如圖2.1所示：圖2.1電子商務(wù)系統(tǒng)單體式架構(gòu)圖微服務(wù)架構(gòu)的前身還有SOA架構(gòu)，SOA架構(gòu)沒有大規(guī)模的、落地的實踐，大部分是停留在理論層次，因此，沒有大眾的支持，所以使用范圍也并不廣泛。以電子商務(wù)系統(tǒng)為例，如圖1.2所示為SOA系統(tǒng)架構(gòu)圖：第二章相關(guān)理論基礎(chǔ)圖2.2電商物流系統(tǒng)SOA架構(gòu)圖相比之下，微服務(wù)的興起是基于大規(guī)模的生產(chǎn)實踐，并有實際的登陸應(yīng)用，如阿里巴巴開發(fā)的開源SpringCloud微服務(wù)框架Pivotal和Dubbo框架，是目前應(yīng)用最廣泛的微服務(wù)平臺體系結(jié)構(gòu)的應(yīng)用框架。與單一風格的體系結(jié)構(gòu)和SOA體系結(jié)構(gòu)相比，微服務(wù)體系結(jié)構(gòu)通過將系統(tǒng)中的服務(wù)層完全分離，避免了開發(fā)工作的重復(fù)，大大提高了開發(fā)效率。微服務(wù)的發(fā)展遵循這樣一個獨特的原則：一個類只有一個函數(shù)，它只做與自身相關(guān)的事情，并且類和類之間保持正交，不相互影響。2.1.2服務(wù)發(fā)現(xiàn)技術(shù)“服務(wù)發(fā)現(xiàn)是一種網(wǎng)絡(luò)協(xié)議,它可以立即自動地檢測到網(wǎng)絡(luò)上計算機的硬件網(wǎng)絡(luò)設(shè)備和服務(wù)。如果計算機上沒有一個有效的服務(wù)發(fā)現(xiàn)模型,則必須由用戶手動配置網(wǎng)絡(luò)硬件,這對于大多數(shù)計算機新手用戶。服務(wù)發(fā)現(xiàn)技術(shù)是所有現(xiàn)代操作系統(tǒng)的一部分,允許計算機彼此聯(lián)網(wǎng),用戶只需相對適度的個人技術(shù)知識就可以上網(wǎng)?！蔽锢頇C器上的傳統(tǒng)應(yīng)用程序運行在端口號和IP地址固定的固定機器上，因此用戶可以通過配置文件響應(yīng)更新的IP地址和端口號。端口號和IP地址都會動態(tài)更改。此外，由于系統(tǒng)的不規(guī)則更新和擴展，服務(wù)實例的數(shù)量也會動態(tài)變化。因此，用戶需要一種特殊的服務(wù)發(fā)現(xiàn)機制來發(fā)現(xiàn)系統(tǒng)中的服務(wù)，因此微服務(wù)服務(wù)發(fā)現(xiàn)技術(shù)應(yīng)運而生。幫助系統(tǒng)在云環(huán)境中找到服務(wù)的網(wǎng)絡(luò)地址，即終端口號和IP地址以及其他服務(wù)細節(jié)。服務(wù)發(fā)現(xiàn)有三個要素：（1）服務(wù)消費者，服務(wù)消費者一般是只用戶，用戶從客戶端發(fā)出服務(wù)請求，有消費的要求，才會有后續(xù)的服務(wù)提供者和服務(wù)注冊中心存在的必要；（2）服務(wù)提供者，服務(wù)提供者一般是指系統(tǒng)中的服務(wù)，一般一個服務(wù)實例包含多個副本以保證系統(tǒng)高可用的要求；（3）服務(wù)注冊中心，服務(wù)注冊中心也就是儲存服務(wù)端口號、IP地址以及其他詳細信息的地方，相當于數(shù)據(jù)庫，目前應(yīng)用比較廣泛的服務(wù)注冊中心有Eureka、Etcd、Consul、Zookeeper等等。2.1.3服務(wù)治理（1）服務(wù)降級技術(shù)是指當服務(wù)器處于最大訪問周期時，微服務(wù)體系結(jié)構(gòu)的總負載超過設(shè)定的閾值，或者入站流量會使總負載超過設(shè)定的閾值。根據(jù)實際業(yè)務(wù)情況，在保證系統(tǒng)某些基本業(yè)務(wù)正常運行的前提下保證了微服務(wù)系統(tǒng)的整體負載降低或保持在正常范圍內(nèi)，使系統(tǒng)正常工作。因此，服務(wù)退化技術(shù)也是服務(wù)治理的重要組成部分。（2）業(yè)務(wù)容錯技術(shù)，是指在沒有及時發(fā)現(xiàn)網(wǎng)絡(luò)通信不穩(wěn)定等情況下，用于處理業(yè)務(wù)的錯誤、超時或停機的技術(shù)。服務(wù)線程池中的線程在短時間內(nèi)耗盡，資源耗盡，導(dǎo)致雪崩效應(yīng)。線程池隔離模式、合并模式等。（3）業(yè)務(wù)優(yōu)先級調(diào)度技術(shù)是指減少一些非核心業(yè)務(wù)的調(diào)度頻率，釋放部分占用的資源，以保證核心業(yè)務(wù)系統(tǒng)的正常運行和系統(tǒng)的穩(wěn)定運行，從而保證在系統(tǒng)資源有限的情況下，系統(tǒng)基本服務(wù)的正常高效運行。發(fā)布服務(wù)通過擴展優(yōu)先級屬性在系統(tǒng)中設(shè)置服務(wù)的優(yōu)先級，服務(wù)提供者將服務(wù)的優(yōu)先級屬性注冊到服務(wù)注冊中心，然后通知服務(wù)使用者，服務(wù)優(yōu)先級由服務(wù)使用者緩存。并根據(jù)不同的調(diào)度策略對服務(wù)優(yōu)先級進行調(diào)度。（4）靈活的微服務(wù)伸縮技術(shù)可分為兩種：第一種是應(yīng)用層伸縮，通過增加或減少服務(wù)實例副本的數(shù)量來滿足系統(tǒng)和服務(wù)消費者的需求；二是擴展IAAS（基礎(chǔ)設(shè)施即服務(wù)）層的資源集合，即根據(jù)系統(tǒng)需求擴展服務(wù)的節(jié)點。例如，將10個節(jié)點的服務(wù)分配給100個節(jié)點。（5）在微服務(wù)體系結(jié)構(gòu)中，由于服務(wù)的劃分，服務(wù)請求將包含多個服務(wù)，每個服務(wù)可以由不同的團隊開發(fā)，部署在不同的位置，使用不同的開發(fā)環(huán)境和語言，因此，跟蹤服務(wù)需要記錄用戶請求發(fā)起了哪些服務(wù)調(diào)用以及處理了哪些服務(wù)。目前最常用的開源組件有SpringCloud框架下的Sleuth組件和Zipkin全鏈接跟蹤組件等。服務(wù)降級技術(shù)是解決系統(tǒng)訪問高峰時期服務(wù)器壓力的重要技術(shù)之一。衡量微服務(wù)系統(tǒng)質(zhì)量的不是用戶數(shù)量少時的性能，而是在巨大壓力下的容災(zāi)能力，服務(wù)退化技術(shù)是其他服務(wù)治理技術(shù)的基礎(chǔ)和前提，而服務(wù)退化技術(shù)是衡量微服務(wù)系統(tǒng)性能的重要指標。因此，服務(wù)退化技術(shù)是服務(wù)治理技術(shù)的重要組成部分。2.2微服務(wù)發(fā)現(xiàn)技術(shù)2.2.1客戶端服務(wù)發(fā)現(xiàn)模式在客戶服務(wù)發(fā)現(xiàn)模式下，用戶發(fā)送客戶服務(wù)請求并查詢服務(wù)注冊，以獲取所請求服務(wù)的端口號和IP地址。然后，通過負載平衡算法集選擇需要可用服務(wù)的服務(wù)實例，請求由客戶端發(fā)送到服務(wù)，服務(wù)響應(yīng)。并將響應(yīng)反饋給客戶端，每個服務(wù)通過restfulapi接口以restfulapi的形式調(diào)用。2.2.2服務(wù)端服務(wù)發(fā)現(xiàn)模式在服務(wù)器端服務(wù)發(fā)現(xiàn)模式中，與客戶端服務(wù)發(fā)現(xiàn)模式相比，有一個額外的負載平衡組件?？蛻舳讼蜇撦d均衡組件發(fā)送服務(wù)請求后，通過負載均衡組件在服務(wù)注冊中心查詢服務(wù)使用者需要呼叫的服務(wù)的端口號和IP地址。找到負載平衡組件后，將客戶端發(fā)送的服務(wù)請求轉(zhuǎn)發(fā)到相應(yīng)的服務(wù)，啟動調(diào)用請求，然后服務(wù)將響應(yīng)返回到負載平衡組件，負載平衡組件響應(yīng)于反饋給客戶的信息。目前，最常用的負載平衡組件是NGINX和SpringCloud框架中的磁帶組件。2.3微服務(wù)降級技術(shù)2.3.1微服務(wù)降級技術(shù)概念什么是服務(wù)降級？當服務(wù)器壓力劇增的情況下，根據(jù)實際業(yè)務(wù)情況及流量，對一些服務(wù)和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務(wù)器資源以保證核心交易正常運作或高效運作?？梢耘e個例子：假如目前有很多人想要給我付錢，但我的服務(wù)器除了正在運行支付的服務(wù)之外，還有一些其它的服務(wù)在運行，比如搜索、定時任務(wù)和詳情等等。然而這些不重要的服務(wù)就占用了JVM的不少內(nèi)存與CPU資源，為了能把錢都收下來（錢才是目標），我設(shè)計了一個動態(tài)開關(guān)，把這些不重要的服務(wù)直接在最外層拒掉，這樣處理后的后端處理收錢的服務(wù)就有更多的資源來收錢了（收錢速度更快了），這就是一個簡單的服務(wù)降級的使用場景。在服務(wù)器端服務(wù)發(fā)現(xiàn)模式中，與客戶端服務(wù)發(fā)現(xiàn)模式相比，有一個額外的組件負載平衡。當客戶端向負載均衡組件發(fā)送服務(wù)請求后，負載均衡組件查詢服務(wù)用戶需要呼叫的服務(wù)的端口號和IP地址到服務(wù)注冊中心。找到負載平衡組件后，將客戶端發(fā)送的服務(wù)請求轉(zhuǎn)發(fā)給相應(yīng)的服務(wù)，啟動請求調(diào)用，服務(wù)將響應(yīng)返回給客戶端的信息返回給負載平衡組件。目前，最常見的負載平衡組件是NGINX和SpringCloud框架中的磁帶組件。2.3.2微服務(wù)降級策略手動降級是指預(yù)先將降級邏輯寫入邏輯代碼中，通過系統(tǒng)配置中心手動修改該值，實現(xiàn)對某些業(yè)務(wù)的手動降級，以維護系統(tǒng)的穩(wěn)定性。目前，最常用的自動降級策略如下：（1）自動化超時降級：對于系統(tǒng)中的非核心服務(wù)，如果數(shù)據(jù)庫訪問或?qū)h程服務(wù)調(diào)用的響應(yīng)非常慢，則可以在配置文件中自動設(shè)置超時，當對服務(wù)的數(shù)據(jù)庫訪問或遠程服務(wù)調(diào)用超過配置文件中設(shè)置的時間時，超時將自動降級。在配置中心預(yù)先設(shè)置門限超時和門限重試超時，并通過異步機制檢測恢復(fù)服務(wù)。（2）統(tǒng)計失敗次數(shù)降級：該策略是通過檢測，預(yù)先設(shè)定熔斷器元件在規(guī)定時間內(nèi)的故障次數(shù)閾值，當在規(guī)定時間內(nèi)服務(wù)的故障次數(shù)達到熔斷器元件的故障次數(shù)閾值時，進行自動降級并通過異步監(jiān)控機制檢測服務(wù)，當指定時間內(nèi)的服務(wù)故障數(shù)低于設(shè)定的閾值時，自動恢復(fù)降級服務(wù)。（3）自動化限流降級：在交通高峰時期，如每年的購物節(jié)和有限的時間內(nèi)，系統(tǒng)的訪問量將在短時間內(nèi)急劇增加。因此，通過限制交通來減輕系統(tǒng)壓力。當流量達到限制閾值時，監(jiān)控請求將被臨時降級和延遲，Web服務(wù)將通過等待隊列（中間過渡接口）、錯誤頁等降級。（4）故障降級：當需要調(diào)用的服務(wù)出故障時(網(wǎng)絡(luò)故障、DNS故障、HTTP狀態(tài)碼異常等)，自動進行降級，并返回默認數(shù)據(jù)、兜底數(shù)據(jù)或者緩存的數(shù)據(jù)，并通過異步監(jiān)測機制探測恢復(fù)情況。第三章基于服務(wù)關(guān)聯(lián)性的微服務(wù)降級技術(shù)優(yōu)化第三章基于服務(wù)關(guān)聯(lián)性的微服務(wù)降級技術(shù)優(yōu)化近年來，隨著云計算技術(shù)的飛速發(fā)展，單一的體系結(jié)構(gòu)正逐漸被微服務(wù)體系結(jié)構(gòu)所取代。盡管微服務(wù)體系結(jié)構(gòu)具有許多優(yōu)點，但它在使用中也存在一些問題：由于微服務(wù)體系結(jié)構(gòu)中的模塊之間是相互獨立的，因此，它的應(yīng)用越來越廣泛。在部署的云環(huán)境中，每個服務(wù)的網(wǎng)絡(luò)地址都會動態(tài)變化，由于服務(wù)之間的相關(guān)性，當調(diào)用一個服務(wù)時，該服務(wù)也會調(diào)用相關(guān)的服務(wù)。因此，增加了服務(wù)發(fā)現(xiàn)的延遲和成本。因此，在一個微服務(wù)體系結(jié)構(gòu)中，如何快速準確地找到和調(diào)用目標子服務(wù)及其相關(guān)服務(wù)是一個亟待解決的問題。目前已有一種通過DNS解析域名來實現(xiàn)服務(wù)發(fā)現(xiàn)的方法，但這種方法在大量服務(wù)的情況下存在著很長的延遲。還提供了一種通過ZooKeeper組件執(zhí)行服務(wù)注冊和服務(wù)發(fā)現(xiàn)的方法，但是由于ZooKeeper滿足分布式系統(tǒng)中的一致性和容錯分區(qū)，因此不能保證可用性。針對上述問題，本章提出了服務(wù)關(guān)聯(lián)矩陣的構(gòu)造方法和基于關(guān)聯(lián)矩陣的服務(wù)發(fā)現(xiàn)算法（AMBSD）。考慮到服務(wù)發(fā)現(xiàn)的延遲和代價，利用延遲和代價理論，得到了基于關(guān)聯(lián)矩陣的服務(wù)發(fā)現(xiàn)算法（AMBSD）的可執(zhí)行條件。實驗結(jié)果表明，該算法在降低時延和代價方面具有一定的優(yōu)越性。3.1問題描述在微服務(wù)系統(tǒng)中，由于服務(wù)之間的相關(guān)性很大，如果一個服務(wù)降級，就會影響到相關(guān)服務(wù)的性能，因此為了保持微服務(wù)系統(tǒng)的穩(wěn)定性我們必須注意降級服務(wù)是否會影響其他服務(wù)和系統(tǒng)可用性?，F(xiàn)有的微服務(wù)降級策略有手動降級、自動超時降級、自動限流降級等，但都存在較大的缺點。手動降級策略在服務(wù)數(shù)量相對較少的系統(tǒng)中是可行的，但在服務(wù)數(shù)量相對較多的系統(tǒng)中，手動降級操作非常困難，成本非常高，顯然不可行。自動降級超時和降級限流可以彌補大規(guī)模微服務(wù)系統(tǒng)中手動降級不可行的缺點，但會導(dǎo)致服務(wù)請求阻塞，導(dǎo)致服務(wù)器崩潰同時，由于對某些業(yè)務(wù)的過度請求，還可能觸發(fā)自動超時降級和自動流限制降級的執(zhí)行條件。因此，與服務(wù)相關(guān)的服務(wù)的執(zhí)行受到影響，導(dǎo)致系統(tǒng)不可用的嚴重后果，這兩種策略都忽略了降級的層次結(jié)構(gòu)。而自動降級的等待時間是通過合并降級的。降級必須一步一步地通過降級級別進行，如圖3.1所示：不分層次地降級會導(dǎo)致服務(wù)器資源的浪費，也會降低服務(wù)質(zhì)量，因此，需要考慮降級哪些服務(wù)以及特定的服務(wù)要降級的程度。圖3.1服務(wù)降級程度示意圖3.2服務(wù)降級理論分析3.2.1微服務(wù)系統(tǒng)穩(wěn)定性本文研究的問題的應(yīng)用場景主要是系統(tǒng)訪問的高峰期，此時要對部分服務(wù)進行降級操作，因此本文設(shè)定通過系統(tǒng)可用性SA以及系統(tǒng)負載情況SL這兩個指標的高低來評判系統(tǒng)的穩(wěn)定性。假設(shè)集群中共有n個節(jié)點，則節(jié)點集合為N={N1，N2，...Nn}，假設(shè)這n個節(jié)點中微服務(wù)的數(shù)量總共為m個，則微服務(wù)集合為M={M1，M2，...Mm}。系統(tǒng)可用性SA是指系統(tǒng)正常運行的時間Tnormal與系統(tǒng)運行總時間T的比，其中，系統(tǒng)運行的總時間由系統(tǒng)正常運行的時間Tnormal和非正常運行時間(故障時間)Tabnormal兩部分組成，系統(tǒng)可用性SA即可表示為：3.2.2微服務(wù)優(yōu)先級在系統(tǒng)訪問高峰期這一應(yīng)用場景下，設(shè)定微服務(wù)優(yōu)先級，微服務(wù)優(yōu)先級越低則越先考慮降級，優(yōu)先級越高則降級順序越靠后。在該場景下，本文設(shè)定微服務(wù)的優(yōu)先級由微服務(wù)內(nèi)存占用率MM和微服務(wù)關(guān)聯(lián)度MR兩部分組成。微服務(wù)Mi的內(nèi)存占用包括以下幾部分：堆內(nèi)存M(i，heap)、線程堆棧申請的內(nèi)存M(i，thread)、微服務(wù)類大?。次⒎?wù)的jar包所占的內(nèi)存大?。㎝(i，class)、以及其他內(nèi)存占用(編譯、垃圾回收等占用的內(nèi)存)M(i，other)。各個節(jié)點內(nèi)存集合MEM表示為MEM={MEM1，MEM2，...，MEMn}，則微服務(wù)Mi在集群中的內(nèi)存占用率MM(i)可以表示為：根據(jù)二八原則，設(shè)定微服務(wù)系統(tǒng)中20%的服務(wù)為核心服務(wù)(即能夠影響整個系統(tǒng)穩(wěn)定性的服務(wù))，即核心服務(wù)數(shù)量為0.2*m，假設(shè)與微服務(wù)Mi關(guān)聯(lián)(即核心服務(wù)依賴于服務(wù)Mi，沒有服務(wù)Mi，核心服務(wù)則無法執(zhí)行，i為服務(wù)序號)的核心服務(wù)的數(shù)量為x，則服務(wù)Mi與核心服務(wù)的關(guān)聯(lián)度MR(i)可以表示為：其中，0≤MR(i)≤1，MR(i)越接近1表示微服務(wù)Mi與核心服務(wù)的關(guān)聯(lián)度越高，MR(i)越接近0表示微服務(wù)Mi與核心服務(wù)的關(guān)聯(lián)度越低。3.3微基于服務(wù)關(guān)聯(lián)性的分級降級算法3.3.1微服務(wù)降級方法在服務(wù)量大的微服務(wù)系統(tǒng)中，由于服務(wù)量大，人工降級方法將面臨操作和維護人員無法及時操作的問題，因此不可能實現(xiàn)自動降級?，F(xiàn)有的自動化服務(wù)降級方法，如Hystrix中基于狀態(tài)反饋的融合調(diào)整算法和Dubbo中的力反饋和故障反饋策略，可以實現(xiàn)服務(wù)的自動降級，但不能實現(xiàn)量化降級。也就是說，一個服務(wù)的降級規(guī)模是無法確定的，如果所有的降級服務(wù)都采用合并的方式，用戶體驗的效果將受到很大的影響，如果與核心服務(wù)相關(guān)的服務(wù)自動降級，系統(tǒng)的可用性將受到影響，這將導(dǎo)致基本服務(wù)無法使用。基于自動反饋的狀態(tài)融合流程調(diào)整算法包括三種狀態(tài)：開、閉和半開。這三個狀態(tài)代表引信的工作狀態(tài)。默認情況下，保險絲處于閉合狀態(tài)。調(diào)用接口失敗的概率是通過存儲在Hystrix命令度量對象中的調(diào)用連接數(shù)和調(diào)用接口失敗的次數(shù)來獲得的。操作維護人員通過微服務(wù)系統(tǒng)的實際情況，設(shè)定呼叫接口的故障概率閾值和同一接口的呼叫次數(shù)閾值。當兩個閾值都超過限制時，熔絲從關(guān)閉狀態(tài)轉(zhuǎn)換為打開狀態(tài)，并且當調(diào)用服務(wù)時，服務(wù)調(diào)用方從遠程調(diào)用切換到本地降級接口。基于狀態(tài)反饋的融合調(diào)整算法提供了一種降級恢復(fù)策略，保證了當服務(wù)訪問的最大周期已經(jīng)過去時，可以恢復(fù)降級的服務(wù)。該策略建立了一個測試窗口，從保險絲到打開狀態(tài)的過渡開始，到保險絲到關(guān)閉或半打開狀態(tài)的過渡結(jié)束。測試窗口時間通常設(shè)置為平均故障處理時間。當接口調(diào)用時間大于平均故障處理時間時，打開狀態(tài)變?yōu)榘氪蜷_狀態(tài)，進行遠程調(diào)用。如果遠程調(diào)用仍然失敗，則保險絲返回打開狀態(tài)。如果所有遠程調(diào)用（或一定比例）都成功，則半打開狀態(tài)變?yōu)殛P(guān)閉狀態(tài)。該算法缺乏對降級層次的考慮，當引信打開時，采用融合的方法進行降級，這將對用戶體驗產(chǎn)生很大的影響。Dubbo的服務(wù)降級策略框架ForceReturn和FailReturn分別表示屏蔽和容錯。強制返回策略直接屏蔽請求并返回運維人員設(shè)置的仿真值，故障返回策略允許請求在請求失敗時返回仿真值。杜博的政策也沒有考慮到降級等級。3.3.2可降級服務(wù)的選取在微服務(wù)系統(tǒng)中，由于服務(wù)之間的依賴性，微服務(wù)的降級應(yīng)避免核心服務(wù)和核心服務(wù)所依賴的服務(wù)，即相關(guān)服務(wù)。這對整個微服務(wù)系統(tǒng)造成了嚴重后果。此外，服務(wù)降級甚至大規(guī)模合并的方式將對用戶體驗產(chǎn)生重大影響，因此有必要將服務(wù)降級或大規(guī)模合并的方式降至最低。針對上述問題，本文提出了一種基于服務(wù)相關(guān)性的分層降級算法它可以保護中心業(yè)務(wù)和與中心業(yè)務(wù)相關(guān)的業(yè)務(wù)，解決中心業(yè)務(wù)降級或與中心業(yè)務(wù)相關(guān)的業(yè)務(wù)降級導(dǎo)致中心業(yè)務(wù)無法運行的問題。如何根據(jù)集群內(nèi)存利用率對服務(wù)的降級級別進行分類，從而解決大規(guī)模的服務(wù)降級甚至融合問題，將極大地影響用戶的體驗。3.4實驗分析3.4.1實驗環(huán)境在本實驗中，我們使用SpringCloud中的Hystrix組件來執(zhí)行服務(wù)降級。在實驗室搭建了三臺高性能服務(wù)器，模擬了實際生產(chǎn)環(huán)境。服務(wù)降級方法是通過修改hystrix源代碼和注釋@hystrix命令（回退方法=“xxxx”）指定的。綜合比較了系統(tǒng)可用性中的自動超時降級算法、自動流限制降級算法和基于服務(wù)關(guān)聯(lián)的分層降級算法在微服務(wù)系統(tǒng)中運行后的系統(tǒng)負載和系統(tǒng)讀寫能力。在微服務(wù)系統(tǒng)中，微服務(wù)類型為100，每個服務(wù)有10個副本服務(wù)，服務(wù)總量為1000，小微服務(wù)系統(tǒng)的服務(wù)總量（包括副本服務(wù)）小于100，中型微服務(wù)系統(tǒng)的服務(wù)總量為幾百個，大型微服務(wù)系統(tǒng)的服務(wù)總量為1000個或更多，通過配置100種微服務(wù)，這10個副本中的每一個都模擬了一個大規(guī)模的微服務(wù)系統(tǒng)，并確保了服務(wù)的高可用性，以防止某些服務(wù)失敗，從而導(dǎo)致系統(tǒng)不可用。服務(wù)部署在Docker容器中，并通過K8S集群進行管理。實驗環(huán)境參數(shù)表：表1.1實驗環(huán)境配置參數(shù)表3.4.2實驗過程實驗通過壓力測試，分別設(shè)置5萬、6萬、7萬、8萬、9萬、10萬、11萬、12萬的并發(fā)量以模擬微服務(wù)系統(tǒng)訪問高峰期，計時測量系統(tǒng)運行時間T、系統(tǒng)可用時間TA、系統(tǒng)可供讀寫時間TRW、系統(tǒng)負載值TL。表1.2是實驗的具體數(shù)據(jù)配置信息：表1.2實驗配置信息表設(shè)置并發(fā)請求量5-12萬，其中5-6萬模擬風暴級別藍色風暴，7-8萬模擬風暴級別黃色風暴，9-10萬模擬風暴級別橙色風暴，11-12萬模擬風暴級別紅色風暴，設(shè)置服務(wù)總量均為3000個，以模擬大型微服務(wù)系統(tǒng)，根據(jù)二八原則，設(shè)置系統(tǒng)核心服務(wù)數(shù)量為服務(wù)總量的20%，即600個，根據(jù)不同的并發(fā)量并根據(jù)式4.10和4.11測量并計算系統(tǒng)可用性A和系統(tǒng)供讀寫能力RW的結(jié)果：比較自動化超時降級算法、自動化限流降級算法以及本文所提出的基于服務(wù)關(guān)聯(lián)性的分級降級算法(SRBHD)在各個情況下進行服務(wù)降級，微服務(wù)系統(tǒng)的性能狀況，包括系統(tǒng)可用性、系統(tǒng)負載情況以及系統(tǒng)的可供讀寫的能力幾方面。以此驗證基于服務(wù)關(guān)聯(lián)性的分級降級算法(SRBHD)在系統(tǒng)訪問高峰期，提升微服務(wù)系統(tǒng)穩(wěn)定性的有效性以及優(yōu)勢。3.4.3仿真結(jié)果分析根據(jù)測量以及式4.10和4.11的計算結(jié)果，得出并發(fā)請求量5-12萬范圍內(nèi)自動化超時降級算法、自動化限流降級算法以及SRBHD算法進行服務(wù)降級后微服務(wù)系統(tǒng)的可用性、負載情況以及可供讀寫的能力的相關(guān)數(shù)據(jù)，并繪制如圖3.2、3.3、3.4所示的微服務(wù)系統(tǒng)性能對比圖：圖3.2系統(tǒng)可用性對比圖如圖4所示為微服務(wù)系統(tǒng)在并發(fā)量從5萬增長到12萬過程中執(zhí)行基于服務(wù)關(guān)聯(lián)性的分級降級算法(SRBHD)、自動化超時降級算法以及自動化限流降級算法，微服務(wù)系統(tǒng)可用性的對比圖，可以看到，從并發(fā)量約為7萬時，系統(tǒng)執(zhí)行自動化超時降級算法以及自動化限流降級算法后的系統(tǒng)可用性迅速下降，而系統(tǒng)執(zhí)行基于服務(wù)關(guān)聯(lián)性的分級降級算法(SRBHD)后的系統(tǒng)可用性下降速度比較緩慢，并且大部分時間系統(tǒng)可用性高達90%以上。圖3.3系統(tǒng)負載情況對比圖如圖2所示為微服務(wù)系統(tǒng)在并發(fā)量從5萬增長到12萬過程中執(zhí)行基于服務(wù)關(guān)聯(lián)性的分級降級算法(SRBHD)、自動化超時降級算法以及自動化限流降級算法，微服務(wù)系統(tǒng)負載情況對比圖，其中，y軸負載的值越小表明系統(tǒng)負載情況越好，越大則表明系統(tǒng)負載情況越差，系統(tǒng)執(zhí)行自動化超時降級算法以及自動化限流降級算法，由圖5可見，系統(tǒng)負載情況變差的速度明顯快于基于服務(wù)關(guān)聯(lián)性的分級降級算法(SRBHD)，并且系統(tǒng)執(zhí)行基于服務(wù)關(guān)聯(lián)性的分級降級算法(SRBHD)的負載值大部分時間都處于0.3以下，表明負載情況比較好。圖3.4系統(tǒng)供讀寫能力對比圖如圖6所示，微服務(wù)系統(tǒng)執(zhí)行基于服務(wù)相關(guān)性的分層降級算法（SRBHD），自動超時降級算法和自動流限制降級算法在并發(fā)過程中從50000增加到120000。通過對微服務(wù)系統(tǒng)讀寫能力的圖形比較表明，Y軸的范圍為0～1。Y軸值越大，微服務(wù)系統(tǒng)可以讀取和寫入的服務(wù)量就越大。Y軸上較小的值表示微服務(wù)系統(tǒng)的讀寫服務(wù)較少。在圖4中，當并發(fā)量約為70000且并發(fā)量約為90000時，Y軸對應(yīng)的系統(tǒng)讀寫能力大大降低，因為當并發(fā)量約為70000時，集群內(nèi)存利用率達到60%，導(dǎo)致一場黃色風暴。一些微服務(wù)系統(tǒng)服務(wù)開始寫和降級，當并發(fā)量達到9萬左右時，集群內(nèi)存利用率達到70%，導(dǎo)致橙色風暴。微服務(wù)系統(tǒng)開始降級寫入。如圖3所示，微服務(wù)系統(tǒng)執(zhí)行基于服務(wù)關(guān)聯(lián)的分層降級算法（SRBHD）。該系統(tǒng)的讀寫性能明顯優(yōu)于運行自動超時降級算法和有限流量自動降級算法的微服務(wù)系統(tǒng)。實驗結(jié)果表明，基于服務(wù)關(guān)聯(lián)的分層降級算法可以有效地提高微服務(wù)系統(tǒng)的可用性和負載，最大限度地保證系統(tǒng)服務(wù)的讀寫能力。從而改善用戶體驗。第四章結(jié)論第四章結(jié)論近年來，隨著云計算和大數(shù)據(jù)技術(shù)的發(fā)展，微服務(wù)體系結(jié)構(gòu)得到了迅速的發(fā)展，與微服務(wù)相關(guān)的技術(shù)成為研究的熱點。問題不斷出現(xiàn)，現(xiàn)有的服務(wù)發(fā)現(xiàn)技術(shù)和服務(wù)降級技術(shù)已經(jīng)不能滿足日益龐大的微服務(wù)系統(tǒng)的需求。延遲服務(wù)發(fā)現(xiàn)的高成本仍然是一個需要解決的問題，因為某些服務(wù)的延遲服務(wù)發(fā)現(xiàn)可能會導(dǎo)致系統(tǒng)服務(wù)調(diào)用被中斷，服務(wù)請求被阻止，從而導(dǎo)致雪崩效應(yīng)。因此，有必要對服務(wù)發(fā)現(xiàn)機制進行優(yōu)化。服務(wù)降級技術(shù)作為服務(wù)管理技術(shù)的重要組成部分，在系統(tǒng)最大流量期間對維護系統(tǒng)的穩(wěn)定起著重要作用。高效的服務(wù)降級策略可以使系統(tǒng)安全穩(wěn)定地運行，順利度過系統(tǒng)的最大流量周期。因此，有必要對服務(wù)降級技術(shù)進行研究。經(jīng)過此次論文設(shè)計，在云環(huán)境下微服務(wù)發(fā)現(xiàn)及降級優(yōu)化技術(shù)方面有了全面的了解，能快捷高效的按照計劃完成微服務(wù)發(fā)現(xiàn)及降級優(yōu)化方面的設(shè)計。之前對云環(huán)境下微服務(wù)發(fā)現(xiàn)及降級有各種疑問，最早做云環(huán)境下微服務(wù)發(fā)現(xiàn)及降級優(yōu)化時思路、方向不正確導(dǎo)致走了很多的彎路，后來通過閱讀專業(yè)書籍與前輩