建站
咨詢
售后
建站咨詢
新聞中心
本篇文章為大家展示了ServiceMesh的探索和實(shí)踐，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。
成都創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站建設(shè)、網(wǎng)站制作、沁水網(wǎng)絡(luò)推廣、成都微信小程序、沁水網(wǎng)絡(luò)營銷、沁水企業(yè)策劃、沁水品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；成都創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供沁水建站搭建服務(wù)，24小時(shí)服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
在ServiceMesh方案成熟之前，我們采用：通過Dart C/C++擴(kuò)展方式調(diào)用各中間件客戶端SO庫（類JNI）。該方案在業(yè)務(wù)初期很好的解決了Dart服務(wù)端生態(tài)建設(shè)問題。但是該方案還存在以下幾個(gè)問題：
運(yùn)維耦合度高。業(yè)務(wù)代碼和客戶端SO庫代碼打包在一起，運(yùn)行在同一進(jìn)程，一旦微服務(wù)框架需要升級，業(yè)務(wù)代碼也需要維護(hù)和重啟。
復(fù)雜性：進(jìn)程內(nèi)的多個(gè)語言環(huán)境，跨語言數(shù)據(jù)表示和傳輸?shù)葐栴}，都會增加系統(tǒng)的復(fù)雜性，降低原有服務(wù)的性能。
接入成本高
新功能滯后
ServiceMesh
由于現(xiàn)有方案存在的一些問題，我們轉(zhuǎn)向ServiceMesh尋找解決問題的思路。
如上圖所示：與目前比較常見的微服務(wù)框架相比，ServiceMesh把微服務(wù)客戶端核心功能獨(dú)立出來，并作為一個(gè)獨(dú)立Proxy進(jìn)程部署在每一個(gè)主機(jī)上，業(yè)務(wù)進(jìn)程通過Proxy進(jìn)程與外界通信。這個(gè)獨(dú)立的Proxy進(jìn)程就是ServiceMesh的核心: SideCar。
業(yè)務(wù)進(jìn)程和SideCar之間最常見的兩種通信方案：1. 基于Iptables的流量攔截轉(zhuǎn)發(fā)方案，2. 業(yè)務(wù)進(jìn)程通過輕量化Mesh客戶端直連SideCar。從實(shí)現(xiàn)原理上看，Iptables方案相比直連方案會有一定的性能損耗和延遲。我們選擇的ALiMesh方案采用了輕量級Mesh客戶端方案。
Mesh化之后，業(yè)務(wù)進(jìn)程只包含業(yè)務(wù)代碼和輕量化的Mesh Client，代碼邏輯變得簡單，問題定位更清晰。業(yè)務(wù)同學(xué)可以更專注業(yè)務(wù)開發(fā)，而不用關(guān)注微服務(wù)龐雜的邏輯。微服務(wù)框架核心功能的開發(fā)維護(hù)擴(kuò)展升級等工作由專門的Mesh團(tuán)隊(duì)負(fù)責(zé)，獨(dú)立升級維護(hù)，與業(yè)務(wù)解耦，業(yè)務(wù)無感知。
ServiceMesh方案解決了現(xiàn)有方案存在的：運(yùn)維成本、接入成本問題，代碼復(fù)雜問題。而且采用開源的Mesh方案，還可以借助開源的力量，不斷增加新的功能。
AliMesh
SideCar的引入，使得原本業(yè)務(wù)跟微服務(wù)之間的進(jìn)程內(nèi)通信轉(zhuǎn)變成進(jìn)程間的通信，進(jìn)出流量增加了一跳，那么ServiceMesh的引入對業(yè)務(wù)性能帶來的影響具體怎么樣？接下來我們基于ALiMesh(Istio開源方案阿里版本)一起分情況看下。
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通過泛化調(diào)用遠(yuǎn)程調(diào)用Java HSF服務(wù)。
而在控制面：ISTIO控制面同步ConfigServer的服務(wù)提供者列表數(shù)據(jù)，SideCar跟ISTIO pilot走原生的服務(wù)同步通道。
由于Http協(xié)議的通用性，該方案接入簡單，快速的驗(yàn)證了Mesh方案的可行性，但是性能還達(dá)不到業(yè)務(wù)的線上要求，經(jīng)測試，主要指標(biāo)如下：
備注：目前閑魚只使用了ServiceMesh OutBound功能。為了模擬線上詳情頁真實(shí)流量情況，每次上游請求處理過程會調(diào)用21次下游Java HSF服務(wù), 所以圖中QPS換算成Mesh流量時(shí)，需要乘以21倍，以下測試都是如此。
如圖所示：Mesh方式相比直連方式，Consumer側(cè)CPU消耗增長一倍，每一次RPC調(diào)用RT增加了近2ms。且HSF Provider側(cè)CPU也有近40%的增加，這一點(diǎn)跟HSF同學(xué)的測試結(jié)果基本吻合。經(jīng)過分析，我們初步定位引起CPU消耗增加的主要原因是Http1.1協(xié)議的連接方式（已經(jīng)使用了連接池）和數(shù)據(jù)編碼。
為了驗(yàn)證該方案的問題所在，我們測試接入了Http2.0方案。Http2.0相比Http1.x，在連接多路復(fù)用、數(shù)據(jù)格式、head壓縮等等方面具有天然的優(yōu)勢。經(jīng)過測試，ALiMesh的性能也較Http1.x有了較大的提升。部分滿足或者接近我們的技術(shù)要求。詳細(xì)指標(biāo)如下圖所示：
如圖所示，優(yōu)化后，業(yè)務(wù)進(jìn)程Consumer側(cè)，CPU和RT消耗稍稍有些超標(biāo)（CPU 增加不超過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庫作為MeshClient，負(fù)責(zé)與Mesh SideCar通信。而在控制面：SideCar與Configsvr直連，同步服務(wù)提供者列表和配置信息，采用差量同步方式，以降低控制面板的CPU消耗。詳細(xì)測試數(shù)據(jù)如下：
經(jīng)過不斷優(yōu)化，最終成功將Mesh CPU增長控制在20%以內(nèi)，每跳RPC調(diào)用RT增加控制在1ms以內(nèi)。
ServiceMesh在閑魚的落地
目前Dart+ALiMesh方案在閑魚服務(wù)端已經(jīng)穩(wěn)定運(yùn)行八個(gè)月+，服務(wù)于閑魚詳情頁、猜你喜歡，租房首頁等業(yè)務(wù), 期間Mesh多次進(jìn)行優(yōu)化、升級、擴(kuò)展功能等運(yùn)維工作，業(yè)務(wù)進(jìn)程都無感，正常對外提供服務(wù)，業(yè)務(wù)同學(xué)不需要參與。
ALiMesh引入后，對線上業(yè)務(wù)RT的影響如下圖所示：橙色的曲線是Mesh化后的業(yè)務(wù)RT監(jiān)控曲線，藍(lán)色的曲線是Mesh化前一周業(yè)務(wù)RT監(jiān)控曲線，排除線上環(huán)境日常的波動后，ALiMesh的引入對線上業(yè)務(wù)RT的影響相當(dāng)小。
說在最后
ServiceMesh方案，將微服務(wù)邏輯和服務(wù)間通信這些與業(yè)務(wù)無關(guān)的邏輯從業(yè)務(wù)應(yīng)用中解耦出來，讓業(yè)務(wù)應(yīng)用瘦身，讓業(yè)務(wù)同學(xué)更專注于業(yè)務(wù)開發(fā)。同時(shí)也讓異構(gòu)語言能夠低成本的建立服務(wù)端生態(tài)，接入現(xiàn)有系統(tǒng)。
當(dāng)然對于性能損失，個(gè)人認(rèn)為總體利大于弊。業(yè)務(wù)團(tuán)隊(duì)可以根據(jù)自己業(yè)務(wù)實(shí)際情況進(jìn)行測試評估，權(quán)衡利弊是否要接入ServiceMesh。
接下來我們會進(jìn)一步擴(kuò)大AliMesh在閑魚的應(yīng)用，并與ALiMesh合作，推動AliMesh在Dart Faas落地，適配更多的中間件。
上述內(nèi)容就是ServiceMesh的探索和實(shí)踐，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
網(wǎng)站標(biāo)題：ServiceMesh的探索和實(shí)踐
網(wǎng)頁路徑：http://www.dlmjj.cn/article/pdgddd.html
