自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

在 Dubbo3.0 上服務(wù)治理的實(shí)踐

網(wǎng)絡(luò)
在云原生大背景下,Apache Dubbo 3.0 選擇全面擁抱云原生,對(duì) Dubbo 架構(gòu)升級(jí),提出了全新的服務(wù)發(fā)現(xiàn)模型、下一代 RPC 協(xié)議和云原生基礎(chǔ)設(shè)施適配等。

Dubbo3.0 介紹

自從 Apache Dubbo 在 2011 年開(kāi)源以來(lái),經(jīng)過(guò)多年一眾大規(guī)模互聯(lián)網(wǎng)、IT 公司的實(shí)踐積累了大量經(jīng)驗(yàn),Dubbo 憑著對(duì) Java 用戶(hù)友好、功能豐富、治理能力強(qiáng)等優(yōu)點(diǎn)在過(guò)去取得了很大的認(rèn)可,成為國(guó)內(nèi)外流行主流的 RPC 框架之一。

但隨著云原生時(shí)代的到來(lái),對(duì)以 Apache Dubbo、Spring Cloud 等為代表的 Java 微服務(wù)治理體系提出了新的要求,包括期望應(yīng)用可以更快的啟動(dòng)、應(yīng)用通信的協(xié)議穿透性可以更高、能夠?qū)Χ嗾Z(yǔ)言的支持更加友好等。比如 Spring 在今年也推出了其基于 GraalVM 的 Spring Native Beta 解決方案,擁有毫秒級(jí)啟動(dòng)的能力、更高的處理性能等。

這樣的背景對(duì)下一代 Apache Dubbo 提出了兩大要求:

1、要保留已有開(kāi)箱即用和落地實(shí)踐背景下帶來(lái)的好處,這也是眾多開(kāi)發(fā)者所期望的;

2、盡可能地遵循云原生思想,能更好的復(fù)用底層云原生基礎(chǔ)設(shè)施、貼合云原生微服務(wù)架構(gòu)。

Dubbo 3.0 是在云原生背景下誕生的,使用 Dubbo 構(gòu)建的微服務(wù)遵循云原生思想,能更好的復(fù)用底層云原生基礎(chǔ)設(shè)施、貼合云原生微服務(wù)架構(gòu)。這體現(xiàn)在:

服務(wù)支持部署在容器、Kubernetes 平臺(tái),服務(wù)生命周期可實(shí)現(xiàn)與平臺(tái)調(diào)度周期對(duì)齊;
支持經(jīng)典 Service Mesh 微服務(wù)架構(gòu),引入了 Proxyless Mesh 架構(gòu),進(jìn)一步簡(jiǎn)化 Mesh 的落地與遷移成本,提供更靈活的選擇;
作為橋接層,支持與 SpringCloud、gRPC 等異構(gòu)微服務(wù)體系的互調(diào)互通。
在云原生大背景下,Apache Dubbo 3.0 選擇全面擁抱云原生,對(duì) Dubbo 架構(gòu)升級(jí),提出了全新的服務(wù)發(fā)現(xiàn)模型、下一代 RPC 協(xié)議和云原生基礎(chǔ)設(shè)施適配等。

Dubbo3.0 商業(yè)版

下面我先介紹阿里云上微服務(wù)治理相關(guān)的三款云產(chǎn)品:EDAS、MSE、SAE。

EDAS

阿里云 aPaaS 產(chǎn)品,一站式部署發(fā)布平臺(tái),同時(shí)它是一艘航母,具備微服務(wù)治理、監(jiān)控、壓測(cè)、限流降級(jí)等一系列能力,同時(shí)它也是一個(gè) AIOps 平臺(tái)。

EDAS 3.0 作為分布式架構(gòu)、數(shù)字化轉(zhuǎn)型上云的首選在線(xiàn)業(yè)務(wù)應(yīng)用托管平臺(tái),在微服務(wù)治理、應(yīng)用發(fā)布變更以及智能運(yùn)維等多個(gè)維度為用戶(hù)應(yīng)用提供智能化、自動(dòng)化的解決方案。

"在 PaaS 層面,我們始終擁抱開(kāi)源技術(shù),并保持和社區(qū)版本兼容的時(shí)效性;在企業(yè)特性上,例如服務(wù)治理、應(yīng)用監(jiān)控等方面,我們提供一個(gè)穩(wěn)定成熟的產(chǎn)品,來(lái)降低企業(yè)構(gòu)建互聯(lián)網(wǎng)化應(yīng)用的門(mén)檻,例如企業(yè)級(jí)應(yīng)用服務(wù) EDAS 3.0 就是這樣一個(gè)典型的產(chǎn)品"。

——阿里巴巴合伙人、阿里云智能基礎(chǔ)產(chǎn)品事業(yè)部 高級(jí)研究員 蔣江偉

MSE

微服務(wù)引擎(Micro Service Engine,簡(jiǎn)稱(chēng) MSE)是一個(gè)面向業(yè)界主流開(kāi)源微服務(wù)生態(tài)的一站式微服務(wù)平臺(tái), 幫助微服務(wù)用戶(hù)更穩(wěn)定、更便捷、更低成本的使用開(kāi)源微服務(wù)技術(shù)構(gòu)建微服務(wù)體系。提供注冊(cè)中心、配置中心全托管(兼容 Nacos/ZooKeeper/Eureka)、網(wǎng)關(guān)(兼容 Zuul/Kong/Spring Cloud Gateway)和無(wú)侵入的開(kāi)源增強(qiáng)服務(wù)治理能力。

SAE

Serverless 應(yīng)用引擎(簡(jiǎn)稱(chēng) SAE)是首款面向應(yīng)用的 Serverless PaaS,提供成本更優(yōu)、效率更高的一站式應(yīng)用托管方案。支持 Spring Cloud/Dubbo/HSF 應(yīng)用零改造上云,提供監(jiān)控診斷、自動(dòng)構(gòu)建鏡像、Java 全鏈路加速、多發(fā)布策略、秒級(jí)自動(dòng)彈性等能力,支持 Jenkins/云效/插件等部署應(yīng)用,還能通過(guò) Docker 鏡像部署任何語(yǔ)言的應(yīng)用。

以上三款云產(chǎn)品所有的服務(wù)治理能力開(kāi)箱即用,支持近五年來(lái)市面上所有開(kāi)源 Dubbo、Spring Cloud 框架,包括 Dubbo 3.0;以下的所有能力無(wú)需修改一行代碼與配置,您只需將您的 Dubbo 3.0 的應(yīng)用接入 EDAS/MSE/SAE ,都是開(kāi)箱即用的能力。

1、完整的服務(wù)契約詳情

在治理的過(guò)程中,服務(wù)契約是所有功能的原材料。在進(jìn)行測(cè)試驗(yàn)證其可用性的時(shí)候,需要知道服務(wù)提供的方法,并根據(jù)方法參數(shù)自動(dòng)填充模板,進(jìn)而進(jìn)行測(cè)試;在配置流量規(guī)則時(shí)候,需要能知道方法的參數(shù),從而根據(jù)流量特征來(lái)進(jìn)行流量規(guī)則配置;在進(jìn)行服務(wù)降級(jí)、服務(wù)鑒權(quán)等配置的時(shí)候,需要根據(jù)方法的具體名稱(chēng)和參數(shù)類(lèi)型,來(lái)給不同的方法在不同的參數(shù)或者返回值的時(shí)候進(jìn)行不同的降級(jí)/鑒權(quán)策略。

開(kāi)源的 Swagger 已經(jīng)做得比較不錯(cuò)了,但是 MSE 的服務(wù)契約更加簡(jiǎn)單高效。開(kāi)源的 Swagger 只需要引入依賴(lài),并在編碼的時(shí)候配置好 @API 注解,然后啟動(dòng)一個(gè) Swagger 的 Server 端就能看到詳情,美中不足的是沒(méi)有適配 Dubbo。

考慮到要讓用戶(hù)不修改任何代碼配置就能使用,且老舊版本的應(yīng)用代碼和鏡像也得支持。因?yàn)槿绻枰_(kāi)發(fā)的話(huà),會(huì)因?yàn)榍秩胄员容^大會(huì)影響迭代效率,我們還是選擇了 Agent 方案,這樣可以做到無(wú)需修改任何代碼和配置,只需要將應(yīng)用接入 One Agent,就可以在 MSE 控制臺(tái)看到微服務(wù)的詳情。

當(dāng)然,如果應(yīng)用本身已經(jīng)接入了 Swagger,我們也能夠做到很好的兼容支持。最后我們可以簡(jiǎn)單地看一下服務(wù)契約的效果,已經(jīng)同時(shí)支持了 Spring Cloud 和 Dubbo 應(yīng)用。

可以詳細(xì)的查看應(yīng)用注冊(cè)了哪些服務(wù),以及這些服務(wù)的消費(fèi)者有哪些;
可以詳細(xì)地查看應(yīng)用提供的所有微服務(wù)方法;
可以詳細(xì)地查看應(yīng)用提供的所有方法的返回值、參數(shù)的詳情;
服務(wù)測(cè)試、服務(wù)降級(jí)、服務(wù)鑒權(quán)這些功能,能夠直接獲取服務(wù)契約的數(shù)據(jù)以便后續(xù)的治理規(guī)則配置。

2、全鏈路流量控制

在微服務(wù)場(chǎng)景下,想讓流量精確命中到整個(gè)鏈路上的某一個(gè)應(yīng)用的灰度版本,想要控制流量在整條鏈路上完整且精確地按照預(yù)期流轉(zhuǎn),目前開(kāi)源并沒(méi)有提供這樣的能力。但是我們常會(huì)碰到以下的場(chǎng)景,導(dǎo)致我們不得不去面對(duì)全鏈路流量控制的這個(gè)訴求。

如何做到項(xiàng)目/測(cè)試環(huán)境隔離?

我們首先通過(guò)新建項(xiàng)目環(huán)境,給每個(gè)項(xiàng)目環(huán)境都有唯一的一個(gè)項(xiàng)目標(biāo)簽。當(dāng)流量帶上這個(gè)項(xiàng)目標(biāo)簽后會(huì)路由到該項(xiàng)目環(huán)境,否則會(huì)去主干環(huán)境。項(xiàng)目環(huán)境隔離帶來(lái)的好處是每個(gè)開(kāi)發(fā)人員都可以有自己的項(xiàng)目環(huán)境,防止開(kāi)發(fā)者們開(kāi)發(fā)過(guò)程中的互相影響。

如何實(shí)現(xiàn)全鏈路灰度?

我們首先劃分出灰度的機(jī)器,然后對(duì)線(xiàn)上所有應(yīng)用部署灰度版本,灰度流量全部進(jìn)入灰度版本,正常流量進(jìn)入生產(chǎn)版本?;叶劝姹局会槍?duì)灰度流量驗(yàn)證,有效減少風(fēng)險(xiǎn)。當(dāng)我們要灰度發(fā)布 N 個(gè)應(yīng)用,需要做到灰度流量在這 N 個(gè)應(yīng)用的灰度版本之間路由。

下面這張圖很好地說(shuō)明使用流量控制讓我們的開(kāi)發(fā)同學(xué)在開(kāi)發(fā)環(huán)境 1 和開(kāi)發(fā)環(huán)境 2 各自部署各自的應(yīng)用,可以實(shí)現(xiàn)環(huán)境隔離與全鏈路灰度的能力。

但是如果沒(méi)有全鏈路流量控制的這套機(jī)制,各種開(kāi)發(fā)/灰度/生產(chǎn)環(huán)境都要進(jìn)行邏輯或者物理隔離,這就需要部署N套整套的微服務(wù)架構(gòu),成本非常高。

可以看到上圖的基于全鏈路流量控制的方案才是更加合理的部署方案設(shè)計(jì),我們提供了開(kāi)箱即用全鏈路流量控制的能力,下面以電商架構(gòu)中的下單場(chǎng)景為例介紹全鏈路流控功能。

客戶(hù)下單后流量從入口應(yīng)用(或者微服務(wù)網(wǎng)關(guān))進(jìn)來(lái),調(diào)用交易中心,交易中心再調(diào)用商品中心,商品中心調(diào)用下游的庫(kù)存中心。交易中心和商品中心各有兩個(gè)新版本(1和2)在運(yùn)行,需要對(duì)這兩個(gè)新版本進(jìn)行灰度驗(yàn)證。此時(shí)在入口應(yīng)用(或者微服務(wù)網(wǎng)關(guān))上期望將滿(mǎn)足特定流控規(guī)則的請(qǐng)求流量路由到新版本,其余流量全部路由到線(xiàn)上(正式)版本。

我們只需在 EDAS 控制臺(tái)創(chuàng)建如下全鏈路流量控制規(guī)則:

同時(shí)我們還提供了流量控制的監(jiān)控大盤(pán),可以實(shí)時(shí)查看各個(gè)應(yīng)用的 qps 指標(biāo),來(lái)確認(rèn)流量走向是否符合預(yù)期。

3、標(biāo)簽路由

EDAS/MSE 服務(wù)治理提供了標(biāo)簽路由的流量控制能力。每個(gè) pod/ecs 都可以打上標(biāo)簽,標(biāo)簽被識(shí)別后會(huì)在控制臺(tái)上展示,然后我們可以對(duì)標(biāo)簽設(shè)置比例和內(nèi)容規(guī)則。

可以設(shè)置各個(gè)標(biāo)簽的流量比例:

也可以點(diǎn)擊流量規(guī)則設(shè)置各個(gè)標(biāo)簽的內(nèi)容流量規(guī)則:

如果有全鏈路訴求。上述 "是否透?jìng)?quot; 開(kāi)關(guān)可以用來(lái)透?jìng)鳂?biāo)簽。

4、開(kāi)箱即用的服務(wù)測(cè)試

服務(wù)測(cè)試即為用戶(hù)提供一個(gè)云上私網(wǎng) Postman ,讓用戶(hù)能夠輕松調(diào)用自己的服務(wù)。用戶(hù)無(wú)需感知云上復(fù)雜的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu),無(wú)需關(guān)系服務(wù)的協(xié)議,無(wú)需自建測(cè)試工具,只需要通過(guò)控制臺(tái)即可實(shí)現(xiàn)服務(wù)調(diào)用。支持 Dubbo 3.0 框架,以及 Dubbo 3.0 主流的 Triple 協(xié)議。

5、離群實(shí)例摘除

在微服務(wù)架構(gòu)中,當(dāng)服務(wù)提供者的應(yīng)用實(shí)例出現(xiàn)異常時(shí),服務(wù)消費(fèi)者無(wú)法及時(shí)感知,會(huì)影響服務(wù)的正常調(diào)用,進(jìn)而影響消費(fèi)者的服務(wù)性能甚至可用性。

在上圖的示例場(chǎng)景中,系統(tǒng)包含 4 個(gè)應(yīng)用,A、B、C 和 D,其中應(yīng)用 A 會(huì)分別調(diào)用應(yīng)用 B、C 和 D。當(dāng)應(yīng)用 B、C 或 D 的某些實(shí)例異常時(shí)(如圖中應(yīng)用 B、C 和 D 標(biāo)識(shí)的各有 1個(gè)和 2 個(gè)異常實(shí)例),如果應(yīng)用 A 無(wú)法感知,會(huì)導(dǎo)致部分調(diào)用失??;如果業(yè)務(wù)代碼寫(xiě)的不夠優(yōu)雅,有可能影響應(yīng)用 A 的性能甚至整個(gè)系統(tǒng)的可用性。

在這里,主要介紹一下離群實(shí)例摘除。那什么是離群實(shí)例,在微服務(wù)集群中出現(xiàn)間歇性的單機(jī)抖動(dòng)( load 極高、 CPU 短時(shí)無(wú)法響應(yīng)、線(xiàn)程池滿(mǎn)等),由于這些個(gè)別節(jié)點(diǎn)的抖動(dòng)會(huì)導(dǎo)致整體集群的服務(wù)質(zhì)量下降。這種情況在云上時(shí)常出現(xiàn),特別是對(duì)于一些大客戶(hù)來(lái)說(shuō),這種能力極為重要。為了提高業(yè)務(wù)的穩(wěn)定性,我們需要一種自動(dòng)化的方案當(dāng)出現(xiàn)離群實(shí)例時(shí),可以自動(dòng)將其摘除,同時(shí)當(dāng)其恢復(fù)健康后,又需要將其放回集群繼續(xù)提供服務(wù)。

一句話(huà)總結(jié):提供了業(yè)務(wù)單點(diǎn)異常自愈能力。

我們只需要選擇框架類(lèi)型與應(yīng)用,然后配置允許的錯(cuò)誤率下限即可。

6、服務(wù)鑒權(quán)

相比于開(kāi)源的 Dubbo 3.0,MSE 提供了開(kāi)箱即用的服務(wù)鑒權(quán)能力,保護(hù)你的敏感業(yè)務(wù),可以做到精準(zhǔn)地控制服務(wù)調(diào)用的權(quán)限。

當(dāng)我們的業(yè)務(wù)發(fā)展后,我們的服務(wù)還會(huì)遇到權(quán)限控制的需求:比如優(yōu)惠券部門(mén)的某個(gè)應(yīng)用,同時(shí)包含了優(yōu)惠券查詢(xún)接口和優(yōu)惠券發(fā)放接口,對(duì)于優(yōu)惠券查詢(xún)接口來(lái)說(shuō),默認(rèn)公司內(nèi)部的所有應(yīng)用都有權(quán)限調(diào)用的;但優(yōu)惠券發(fā)放接口只有客服和運(yùn)營(yíng)部門(mén)的某些應(yīng)用才有權(quán)限調(diào)用。

如下圖所示,MSE 用戶(hù)可以對(duì)自己的服務(wù)進(jìn)行權(quán)限管理,這里以 Dubbo 為例,下圖中配置表明,應(yīng)用 cartservice 發(fā)布的 com.alibabacloud.hipstershop.CartService 服務(wù)的 addItemToCart 的方法,只允許 frontend 這個(gè)應(yīng)用調(diào)用。

精準(zhǔn)的權(quán)限管理,可以讓你更好地管理微服務(wù)調(diào)用的權(quán)限,保證業(yè)務(wù)的合規(guī)性,保障數(shù)據(jù)的安全。

7、服務(wù) Mock

相比于開(kāi)源 Dubbo 3.0 服務(wù) Mock 能力,MSE 提供的是開(kāi)箱即用的完整解決方案。

當(dāng)您遇到業(yè)務(wù)高峰期,發(fā)現(xiàn)下游的服務(wù)提供者遇到性能瓶頸,甚至影響業(yè)務(wù)時(shí)。您可以通過(guò)服務(wù) Mock 實(shí)現(xiàn)服務(wù)降級(jí),對(duì)部分的服務(wù)消費(fèi)者進(jìn)行降級(jí)操作,讓不重要的業(yè)務(wù)方不進(jìn)行真實(shí)地調(diào)用,直接返回 Mock 的結(jié)果,將寶貴的下游服務(wù)提供者資源保留給重要的業(yè)務(wù)調(diào)用方使用,從而提升整體服務(wù)的穩(wěn)定性。

開(kāi)源已有的 Sentinel、Hystrix 等開(kāi)源的熔斷降級(jí),主要是對(duì)不穩(wěn)定的弱依賴(lài)服務(wù)調(diào)用進(jìn)行熔斷降級(jí),暫時(shí)切斷不穩(wěn)定調(diào)用,避免局部不穩(wěn)定因素導(dǎo)致整體的雪崩。熔斷降級(jí)作為保護(hù)自身的手段,通常在服務(wù)消費(fèi)端進(jìn)行配置。

服務(wù)降級(jí)功能既支持在服務(wù)調(diào)用報(bào)錯(cuò)時(shí)候進(jìn)行降級(jí),同時(shí)也支持在服務(wù)調(diào)用正常時(shí)也開(kāi)啟,這樣可以很好地保護(hù)服務(wù)提供者,將有限的資源更多地分配給關(guān)鍵的服務(wù)消費(fèi)者。

在開(kāi)發(fā)的過(guò)程中,相信我們大家都到過(guò),下游依賴(lài)方開(kāi)發(fā)進(jìn)度比較慢,導(dǎo)致自己的開(kāi)發(fā)進(jìn)度被 block 的情況,在使用 微服務(wù)治理 Mock 功能之后,可以通過(guò)固定地 Mock 某個(gè)返回值,從而使得開(kāi)發(fā)的過(guò)程不需要依賴(lài)于下游依賴(lài)方的進(jìn)度,同時(shí)還可以靈活地在控制臺(tái)變更 Mock 的規(guī)則,從而達(dá)到快速開(kāi)發(fā)的目的。

如下圖所示,當(dāng)應(yīng)用接入 MSE 之后,就可以在控制臺(tái)中通過(guò)如下方式來(lái)提供服務(wù) Mock 的功能。

8、服務(wù)監(jiān)控

對(duì)于Dubbo應(yīng)用線(xiàn)上監(jiān)控以及診斷能力是必不可少的能力,我們提供了以下完整且開(kāi)箱即用的應(yīng)用監(jiān)控能力,可以讓?xiě)?yīng)用的運(yùn)維變得輕松高效。

應(yīng)用詳情

應(yīng)用依賴(lài)服務(wù)以及應(yīng)用實(shí)例/狀態(tài)碼統(tǒng)計(jì)

應(yīng)用的系統(tǒng)信息與慢調(diào)用次數(shù)監(jiān)控

應(yīng)用數(shù)據(jù)的統(tǒng)計(jì)分析

應(yīng)用的調(diào)用拓?fù)浞治?/strong>

小結(jié)

EDAS/MSE/SAE 服務(wù)治理中心是商業(yè)化版的 Dubbo Admin,但不止于此,我們通過(guò)無(wú)侵入方式增強(qiáng)市面上 Dubbo/Spring Cloud 等框架的全部版本,提供了一站式完整的微服務(wù)治理能力的解決方案。

不只是 Dubbo3.0

同時(shí),EDAS/MSE/SAE 服務(wù)治理也將 Dubbo 3.0 一些優(yōu)秀的設(shè)計(jì)以及能力通過(guò)無(wú)侵入服務(wù)治理能力普惠到 Dubbo 2.x 以及 Spring Cloud 框架。

1、微服務(wù)與K8s生命周期對(duì)齊

Pod 的生命周期與服務(wù)調(diào)度息息相關(guān)。

如果微服務(wù)沒(méi)有實(shí)現(xiàn)其接口,當(dāng)部署架構(gòu) K8s 化,在應(yīng)用的 縮容、擴(kuò)容、重啟、新版本發(fā)布 這些過(guò)程中,會(huì)出現(xiàn)影響業(yè)務(wù)的錯(cuò)誤,所以要配置好微服務(wù)在 K8s 環(huán)境下的健康檢查。

其實(shí)僅僅是做健康檢查其實(shí)不夠:因?yàn)槌霈F(xiàn)上述場(chǎng)景的原因可能有很多:

1、應(yīng)用的下線(xiàn)過(guò)程中:應(yīng)用提供者正常收到 kill 信號(hào),提供者處理完在途請(qǐng)求再停止,注冊(cè)中心感知提供者下線(xiàn),消費(fèi)者收到下線(xiàn)通知,消費(fèi)者刷新調(diào)用列表 等等這些過(guò)程中,都可能出現(xiàn)錯(cuò)誤和延遲。

2、應(yīng)用上線(xiàn)過(guò)程中也可能出問(wèn)題:服務(wù)還未注冊(cè)訂閱完成Pod的健康檢查已經(jīng)就緒,Dubbo 還沒(méi)準(zhǔn)備好大流量就進(jìn)來(lái)了,數(shù)據(jù)庫(kù)/Redis 建立連接導(dǎo)致初次請(qǐng)求失敗,JVM 類(lèi)加載出現(xiàn)鎖導(dǎo)致啟動(dòng)緩慢,健康檢查寫(xiě)的有問(wèn)題導(dǎo)致滾動(dòng)發(fā)布過(guò)程中沒(méi)有一個(gè)健康的節(jié)點(diǎn)等等。

上述的階段,都有可能出現(xiàn)問(wèn)題,這些問(wèn)題都是需要解決和保證的。這個(gè)可以通過(guò)開(kāi)源的方式一個(gè)個(gè)去解決,比如調(diào)整注冊(cè)中心的配置,調(diào)整連接池的配置,調(diào)整鏡像打包文件,自己寫(xiě)代碼實(shí)現(xiàn)在途請(qǐng)求處理完的邏輯等等。也可以選擇使用 MSE 方案,不需要修改代碼,只需要接入 MSE 即可, 只需要接入一次,接入過(guò)程在 5 分鐘之內(nèi)。

Readiness 檢查

MSE 會(huì)提供一個(gè) Readiness 接口,該接口會(huì)在微服務(wù)啟動(dòng)完全就緒后,返回的 status 會(huì)成為 200,否則返回 503。

Liveness 檢查

MSE 會(huì)提供一個(gè) Liveness 接口,該接口在判斷微服務(wù)就緒后且服務(wù)狀態(tài)為健康,返回的 status 會(huì)成為 200,否則返回 503 。

我們只需將相關(guān)配置配置在K8s提供的接口上即可。

2、無(wú)損上下線(xiàn)

若您的應(yīng)用沒(méi)有具備無(wú)損下線(xiàn)的能力,您的任何應(yīng)用在發(fā)布的過(guò)程中會(huì)造成短暫的服務(wù)不可用,短時(shí)間內(nèi)業(yè)務(wù)監(jiān)控會(huì)出現(xiàn)大量 io 異常報(bào)錯(cuò)。如果您的業(yè)務(wù)沒(méi)做好事務(wù),那么還會(huì)引起數(shù)據(jù)不一致的問(wèn)題,您需要緊急手動(dòng)訂正錯(cuò)誤數(shù)據(jù)。每次發(fā)布,您需要發(fā)告示停機(jī)發(fā)布,否則您的用戶(hù)會(huì)出現(xiàn)一段時(shí)間服務(wù)不可用,會(huì)對(duì)用戶(hù)產(chǎn)品體驗(yàn)造成影響。

對(duì)于任何一個(gè)線(xiàn)上應(yīng)用,如何在服務(wù)更新部署過(guò)程中保證業(yè)務(wù)無(wú)感知是開(kāi)發(fā)者必須要解決的問(wèn)題,即從應(yīng)用停止到重啟恢復(fù)服務(wù)這個(gè)階段不能影響正常的業(yè)務(wù)請(qǐng)求,目前開(kāi)源的框架均不能很好地解決這個(gè)問(wèn)題。

當(dāng)您的應(yīng)用接入MSE/EDAS/SAE 后,將通過(guò)無(wú)侵入的方式自動(dòng)增強(qiáng) Dubbo 和 Spring Cloud 流量的無(wú)損下線(xiàn)能力。微服務(wù)治理中心將無(wú)損下線(xiàn)的能力整合在 K8S 的生命周期中,對(duì) ACK 集群中的應(yīng)用進(jìn)行部署、回滾、縮容等操作時(shí),會(huì)自動(dòng)實(shí)現(xiàn)無(wú)損下線(xiàn)的效果。

3、服務(wù)并行注冊(cè)訂閱

Dubbo 默認(rèn)服務(wù)注冊(cè)/訂閱行為是串行執(zhí)行,當(dāng)您的 Dubbo 應(yīng)用中服務(wù)數(shù)過(guò)多,該流程會(huì)變得很長(zhǎng),影響應(yīng)用啟動(dòng)時(shí)長(zhǎng),存在一定的穩(wěn)定性風(fēng)險(xiǎn);為了應(yīng)用可以更快的啟動(dòng),MSE 會(huì)通過(guò)無(wú)侵入的方式增強(qiáng)你的微服務(wù)框架,只需加一個(gè)開(kāi)關(guān),就能開(kāi)啟服務(wù)并行注冊(cè)與訂閱,大大減少應(yīng)用啟動(dòng)時(shí)長(zhǎng)。

總結(jié)

Apache Dubbo 3.0.0 是捐給 Apache 后的一個(gè)里程碑版本,代表著 Apache Dubbo 全面擁抱云原生的一個(gè)節(jié)點(diǎn)。

EDAS/MSE/SAE 服務(wù)治理能力也在隨著云原生微服務(wù)的發(fā)展以及 Dubbo 的演進(jìn)而不斷豐富,隨著客戶(hù)大規(guī)模上云后,一些云原生場(chǎng)景下微服務(wù)的痛點(diǎn)也不斷浮出水面,我們致力于無(wú)侵入的微服務(wù)治理增強(qiáng),在解決客戶(hù)痛點(diǎn)的過(guò)程中保證云上客戶(hù)的業(yè)務(wù)永遠(yuǎn)在線(xiàn),使得云原生微服務(wù)的架構(gòu)升級(jí)更加 easy 。

責(zé)任編輯:梁菲 來(lái)源: 阿里云云棲號(hào)
相關(guān)推薦

2022-03-15 18:33:34

URL重構(gòu)Dubbo3.0

2023-06-01 08:10:56

2023-10-18 07:16:41

2021-09-06 09:46:26

Dubbo 服務(wù)端開(kāi)發(fā)

2022-09-09 10:01:11

服務(wù)網(wǎng)格云原生交付請(qǐng)求

2009-07-06 18:17:57

運(yùn)維管理Broadview C廣通科技

2023-11-02 17:52:30

架構(gòu)模式微服務(wù)服務(wù)治理

2021-07-14 08:00:12

DubboRSocket 協(xié)議

2025-03-20 10:50:08

RedisCaffeine緩存監(jiān)控

2021-07-16 13:11:10

分布式消息微服務(wù)

2021-06-23 09:49:12

微服務(wù)分布式RocketMQ

2024-01-10 18:49:47

2020-11-26 18:30:33

機(jī)器學(xué)習(xí)Kubernetes開(kāi)發(fā)

2022-12-16 09:29:23

攜程微服務(wù)

2023-06-02 18:37:14

Dubbo異步化接口

2023-03-15 18:34:26

資源治理數(shù)據(jù)治理業(yè)務(wù)線(xiàn)

2023-02-24 13:29:11

2022-12-26 16:34:51

開(kāi)源云原生

2021-06-05 06:52:16

Kubernetes

2016-12-23 09:09:54

TensorFlowKubernetes框架
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)