本篇文章為大家展示了ServiceMesh的探索和實(shí)踐，內(nèi)容簡(jiǎn)明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過(guò)這篇文章的詳細(xì)介紹希望你能有所收獲。

10年積累的網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶(hù)對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶(hù)得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先建設(shè)網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有鳳泉免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

在ServiceMesh方案成熟之前，我們采用：通過(guò)Dart C/C++擴(kuò)展方式調(diào)用各中間件客戶(hù)端SO庫(kù)（類(lèi)JNI）。該方案在業(yè)務(wù)初期很好的解決了Dart服務(wù)端生態(tài)建設(shè)問(wèn)題。但是該方案還存在以下幾個(gè)問(wèn)題：

• 運(yùn)維耦合度高。業(yè)務(wù)代碼和客戶(hù)端SO庫(kù)代碼打包在一起，運(yùn)行在同一進(jìn)程，一旦微服務(wù)框架需要升級(jí)，業(yè)務(wù)代碼也需要維護(hù)和重啟。

• 復(fù)雜性：進(jìn)程內(nèi)的多個(gè)語(yǔ)言環(huán)境，跨語(yǔ)言數(shù)據(jù)表示和傳輸?shù)葐?wèn)題，都會(huì)增加系統(tǒng)的復(fù)雜性，降低原有服務(wù)的性能。

• 接入成本高

• 新功能滯后

ServiceMesh

由于現(xiàn)有方案存在的一些問(wèn)題，我們轉(zhuǎn)向ServiceMesh尋找解決問(wèn)題的思路。

如上圖所示：與目前比較常見(jiàn)的微服務(wù)框架相比，ServiceMesh把微服務(wù)客戶(hù)端核心功能獨(dú)立出來(lái)，并作為一個(gè)獨(dú)立Proxy進(jìn)程部署在每一個(gè)主機(jī)上，業(yè)務(wù)進(jìn)程通過(guò)Proxy進(jìn)程與外界通信。這個(gè)獨(dú)立的Proxy進(jìn)程就是ServiceMesh的核心: SideCar。

業(yè)務(wù)進(jìn)程和SideCar之間最常見(jiàn)的兩種通信方案：1. 基于Iptables的流量攔截轉(zhuǎn)發(fā)方案，2. 業(yè)務(wù)進(jìn)程通過(guò)輕量化Mesh客戶(hù)端直連SideCar。從實(shí)現(xiàn)原理上看，Iptables方案相比直連方案會(huì)有一定的性能損耗和延遲。我們選擇的ALiMesh方案采用了輕量級(jí)Mesh客戶(hù)端方案。

Mesh化之后，業(yè)務(wù)進(jìn)程只包含業(yè)務(wù)代碼和輕量化的Mesh Client，代碼邏輯變得簡(jiǎn)單，問(wèn)題定位更清晰。業(yè)務(wù)同學(xué)可以更專(zhuān)注業(yè)務(wù)開(kāi)發(fā)，而不用關(guān)注微服務(wù)龐雜的邏輯。微服務(wù)框架核心功能的開(kāi)發(fā)維護(hù)擴(kuò)展升級(jí)等工作由專(zhuān)門(mén)的Mesh團(tuán)隊(duì)負(fù)責(zé)，獨(dú)立升級(jí)維護(hù)，與業(yè)務(wù)解耦，業(yè)務(wù)無(wú)感知。

ServiceMesh方案解決了現(xiàn)有方案存在的：運(yùn)維成本、接入成本問(wèn)題，代碼復(fù)雜問(wèn)題。而且采用開(kāi)源的Mesh方案，還可以借助開(kāi)源的力量，不斷增加新的功能。

AliMesh

SideCar的引入，使得原本業(yè)務(wù)跟微服務(wù)之間的進(jìn)程內(nèi)通信轉(zhuǎn)變成進(jìn)程間的通信，進(jìn)出流量增加了一跳，那么ServiceMesh的引入對(duì)業(yè)務(wù)性能帶來(lái)的影響具體怎么樣？接下來(lái)我們基于ALiMesh(Istio開(kāi)源方案阿里版本)一起分情況看下。

ALiMesh提供了2種接入方案：Http方式、HSF方式。其中Http方式又分為Http1.0和Http2.0方式。

AliMesh http方案（快速接入）

如圖所示，Http方式下：在數(shù)據(jù)面，業(yè)務(wù)進(jìn)程與SideCar，SideCar與Service Provider之間采用Http協(xié)議交互，數(shù)據(jù)編碼采用Json。業(yè)務(wù)進(jìn)程集成了基于Http協(xié)議的Mesh Client，Mesh SideCar通過(guò)泛化調(diào)用遠(yuǎn)程調(diào)用Java HSF服務(wù)。

而在控制面：ISTIO控制面同步ConfigServer的服務(wù)提供者列表數(shù)據(jù)，SideCar跟ISTIO pilot走原生的服務(wù)同步通道。

由于Http協(xié)議的通用性，該方案接入簡(jiǎn)單，快速的驗(yàn)證了Mesh方案的可行性，但是性能還達(dá)不到業(yè)務(wù)的線上要求，經(jīng)測(cè)試，主要指標(biāo)如下：

備注：目前閑魚(yú)只使用了ServiceMesh OutBound功能。為了模擬線上詳情頁(yè)真實(shí)流量情況，每次上游請(qǐng)求處理過(guò)程會(huì)調(diào)用21次下游Java HSF服務(wù), 所以圖中QPS換算成Mesh流量時(shí)，需要乘以21倍，以下測(cè)試都是如此。

如圖所示：Mesh方式相比直連方式，Consumer側(cè)CPU消耗增長(zhǎng)一倍，每一次RPC調(diào)用RT增加了近2ms。且HSF Provider側(cè)CPU也有近40%的增加，這一點(diǎn)跟HSF同學(xué)的測(cè)試結(jié)果基本吻合。經(jīng)過(guò)分析，我們初步定位引起CPU消耗增加的主要原因是Http1.1協(xié)議的連接方式（已經(jīng)使用了連接池）和數(shù)據(jù)編碼。

為了驗(yàn)證該方案的問(wèn)題所在，我們測(cè)試接入了Http2.0方案。Http2.0相比Http1.x，在連接多路復(fù)用、數(shù)據(jù)格式、head壓縮等等方面具有天然的優(yōu)勢(shì)。經(jīng)過(guò)測(cè)試，ALiMesh的性能也較Http1.x有了較大的提升。部分滿(mǎn)足或者接近我們的技術(shù)要求。詳細(xì)指標(biāo)如下圖所示：

如圖所示，優(yōu)化后，業(yè)務(wù)進(jìn)程Consumer側(cè)，CPU和RT消耗稍稍有些超標(biāo)（CPU 增加不超過(guò)20%）。為了探索更高性能，更低延遲的方案，我們轉(zhuǎn)向了HSF私有協(xié)議方案。

AliMesh HSF擴(kuò)展協(xié)議方案（高性能）

如圖所示，HSF方案下，HSF RPC協(xié)議實(shí)現(xiàn)為Mesh SideCar的一個(gè)擴(kuò)展協(xié)議。在數(shù)據(jù)面：業(yè)務(wù)進(jìn)程與SideCar，SideCar與Service Provider 之間采用HSF 2.0私有協(xié)議，數(shù)據(jù)編碼采用Hessian 1.0。業(yè)務(wù)進(jìn)程集成了Mesh化改造的HSFCPP SO庫(kù)作為MeshClient，負(fù)責(zé)與Mesh SideCar通信。而在控制面：SideCar與Configsvr直連，同步服務(wù)提供者列表和配置信息，采用差量同步方式，以降低控制面板的CPU消耗。詳細(xì)測(cè)試數(shù)據(jù)如下：

經(jīng)過(guò)不斷優(yōu)化，最終成功將Mesh CPU增長(zhǎng)控制在20%以?xún)?nèi)，每跳RPC調(diào)用RT增加控制在1ms以?xún)?nèi)。

ServiceMesh在閑魚(yú)的落地

目前Dart+ALiMesh方案在閑魚(yú)服務(wù)端已經(jīng)穩(wěn)定運(yùn)行八個(gè)月+，服務(wù)于閑魚(yú)詳情頁(yè)、猜你喜歡，租房首頁(yè)等業(yè)務(wù), 期間Mesh多次進(jìn)行優(yōu)化、升級(jí)、擴(kuò)展功能等運(yùn)維工作，業(yè)務(wù)進(jìn)程都無(wú)感，正常對(duì)外提供服務(wù)，業(yè)務(wù)同學(xué)不需要參與。

ALiMesh引入后，對(duì)線上業(yè)務(wù)RT的影響如下圖所示：橙色的曲線是Mesh化后的業(yè)務(wù)RT監(jiān)控曲線，藍(lán)色的曲線是Mesh化前一周業(yè)務(wù)RT監(jiān)控曲線，排除線上環(huán)境日常的波動(dòng)后，ALiMesh的引入對(duì)線上業(yè)務(wù)RT的影響相當(dāng)小。

說(shuō)在最后

ServiceMesh方案，將微服務(wù)邏輯和服務(wù)間通信這些與業(yè)務(wù)無(wú)關(guān)的邏輯從業(yè)務(wù)應(yīng)用中解耦出來(lái)，讓業(yè)務(wù)應(yīng)用瘦身，讓業(yè)務(wù)同學(xué)更專(zhuān)注于業(yè)務(wù)開(kāi)發(fā)。同時(shí)也讓異構(gòu)語(yǔ)言能夠低成本的建立服務(wù)端生態(tài)，接入現(xiàn)有系統(tǒng)。

當(dāng)然對(duì)于性能損失，個(gè)人認(rèn)為總體利大于弊。業(yè)務(wù)團(tuán)隊(duì)可以根據(jù)自己業(yè)務(wù)實(shí)際情況進(jìn)行測(cè)試評(píng)估，權(quán)衡利弊是否要接入ServiceMesh。

接下來(lái)我們會(huì)進(jìn)一步擴(kuò)大AliMesh在閑魚(yú)的應(yīng)用，并與ALiMesh合作，推動(dòng)AliMesh在Dart Faas落地，適配更多的中間件。

上述內(nèi)容就是ServiceMesh的探索和實(shí)踐，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。

網(wǎng)頁(yè)題目：ServiceMesh的探索和實(shí)踐-創(chuàng)新互聯(lián)
URL標(biāo)題：http://chinadenli.net/article4/ecooe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開(kāi)發(fā)、定制開(kāi)發(fā)、全網(wǎng)營(yíng)銷(xiāo)推廣、電子商務(wù)、云服務(wù)器、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)