istio大咖秀中百度分享解讀

本文內(nèi)容來(lái)自bilibili視頻，如有誤讀或者侵權(quán)請(qǐng)聯(lián)系作者刪除

總結(jié)如下

1.基于自有組件naming agent進(jìn)行服務(wù)發(fā)現(xiàn)，故障時(shí)可以自動(dòng)切換成直連模式
2.基于服務(wù)訂閱模式進(jìn)行配置增量更新
3.通過(guò)bgrpc優(yōu)化envoy內(nèi)核來(lái)提升性能
4.修改pilot使其支持私有化協(xié)議
5.支持配置的灰度發(fā)布

百度服務(wù)治理現(xiàn)狀時(shí)間線

13年探索sidecar模式
16年百度網(wǎng)盤應(yīng)用sidecar模式
16年9月 service mesh提出，百度開始研發(fā)bmesh（go開發(fā)）
18年7月 istio1.0的發(fā)布
19年 百度內(nèi)部確定基于istio+envoy模式進(jìn)行研發(fā)

為什么要引入service mesh（什么樣的場(chǎng)景適合）

多語(yǔ)言技術(shù)棧（語(yǔ)言技術(shù)棧單一可以不引入）
更細(xì)粒度的服務(wù)治理，提供統(tǒng)一的服務(wù)治理
產(chǎn)品研發(fā)能力不強(qiáng)（通過(guò)service mesh提供統(tǒng)一的功能，否則需要獨(dú)立開發(fā)）

百度內(nèi)部架構(gòu)方案一

image.png

1.通過(guò)envoy直接連接注冊(cè)中心
2.自主開發(fā)mesh logic來(lái)和k8s apiserver對(duì)接，寫入sidecar CRD
3.大幅降低xds推送量，減少了envoy中配置數(shù)
4.java agent探針，所以只支持java

百度內(nèi)部架構(gòu)方案二

image.png

1.通過(guò)naming agent來(lái)實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)
2.將envoy地址配置到naming中
3.naming會(huì)把包含envoy地址的請(qǐng)求轉(zhuǎn)到envoy上
4.如果沒有envoy地址就采用直連模式
5.mesh方案，支持多語(yǔ)言
6.支持link訂閱，能夠支持xds根據(jù)訂閱模式進(jìn)行增量下發(fā)
7.istio不支持私有化協(xié)議，改造istio使其支持私有化協(xié)議
8.改造了envoy內(nèi)核，使其包含brpc并且能夠在envoy內(nèi)核和brpc內(nèi)核進(jìn)行切換，提升性能

mesh帶來(lái)的好處

1.提高運(yùn)維管理的能力，機(jī)房切換流量，夸機(jī)房流量切換
2.提高產(chǎn)品發(fā)布能力，通過(guò)版本控制，可以回滾，溯源
3.服務(wù)網(wǎng)格可編程能力，提高了平臺(tái)化能力

提問(wèn)

1. 請(qǐng)問(wèn)，istio組件，包括數(shù)據(jù)面和控制面發(fā)生故障時(shí)，有哪些快速fallback的方案，之前閱讀了大佬的相關(guān)文章，這塊好像沒有細(xì)講，謝謝--Heaven
答：百度是通過(guò)envoy和naming集成，當(dāng)遇見故障時(shí)，快速切換為直連模式，防止對(duì)業(yè)務(wù)產(chǎn)生影響。
2. 有些服務(wù)QoS想設(shè)置guaranteed，但是istio的sidecar不是 request和litmit一樣的。要guaranteed的話必須sidecar的QoS相關(guān)配置也要改。你們是怎么做的？如果改，建議設(shè)置為多少？感謝大佬！
答：目前使用的pod的容量是envoy50到200兆左右，cpu為應(yīng)用cpu的10%左右。具體其實(shí)需要實(shí)際場(chǎng)景進(jìn)行qos壓測(cè)才可以，這只是建議的值。
3. 你好。作為業(yè)務(wù)方的技術(shù)負(fù)責(zé)人，被中間件團(tuán)隊(duì)推動(dòng)上Istio，目前帶來(lái)的收益主要是服務(wù)治理方向的。從業(yè)務(wù)迭代效率的角度看，上Istio的增量收益抵不上遷移成本的代價(jià)；另外還降低了業(yè)務(wù)方工作的技術(shù)含量。請(qǐng)問(wèn)有沒有實(shí)踐中，業(yè)務(wù)方在Mesh化的過(guò)程中獲得顯著收益的例子？
答：遷移確實(shí)具有一定的成本，業(yè)務(wù)mesh化可以帶來(lái)服務(wù)治理時(shí)效性增強(qiáng)，可以把不同技術(shù)棧統(tǒng)一起來(lái)。
4. 為什么沒有采用mcp over xds的方案？ 而是獨(dú)立搭建了api server 和 etcd？ 
答：目前k8s支持這種單獨(dú)搭建的方式，比較方便，還是復(fù)用istio部署方案。
5. pilot的多業(yè)務(wù)方案是怎么做的？ 如果是多個(gè)pilot的話，那獨(dú)立的k8s api server和etcd也要多個(gè)么？
答：目前百度是用同一套，也是可以獨(dú)立部署的。
6. envoy 的brpc改造方案，會(huì)考慮開源么？ 怎么follow后續(xù)社區(qū)envoy的最新代碼呢
答：brpc本身就是開源的，百度只是把它集成到envoy的內(nèi)核中了。目前這塊需要等istio社區(qū)穩(wěn)定之后會(huì)輸出到社區(qū)。
7. 內(nèi)部的mesh方案，考慮通過(guò)百度云的方式對(duì)外輸出么？ 
答：目前已經(jīng)輸出了。
8. 隨著istio新版本的不斷發(fā)布，內(nèi)部使用的版本是否跟進(jìn)了開源新版本，跟進(jìn)社區(qū)版本升級(jí)有什么經(jīng)驗(yàn)分享？ 
答：目前還在等待版本的穩(wěn)定，繼續(xù)跟進(jìn)社區(qū)動(dòng)態(tài)，后續(xù)輸出到社區(qū)。
9. envoy filter管理麻煩的話，nshead，dubbo等多協(xié)議支持是怎么實(shí)現(xiàn)的？在pilot中是如何管理的？ 
答：通過(guò)改造pilot，實(shí)現(xiàn)配置化管理，來(lái)支持多協(xié)議。
10. 引入兩個(gè)sidecar后問(wèn)題定位的成本和難度會(huì)大福增加，這塊有什么經(jīng)驗(yàn)可以分享
答：根據(jù)envoy的configdump和調(diào)用連，指標(biāo)監(jiān)控來(lái)分析和定位問(wèn)題。
11. sidecar帶來(lái)的額外成本問(wèn)題誰(shuí)來(lái)買單？業(yè)務(wù)認(rèn)可嗎
答：百度業(yè)務(wù)認(rèn)可，內(nèi)部已經(jīng)推廣。
12. sidecar可以使用的的資源配額是怎么分配管理的，動(dòng)態(tài)的還是靜態(tài)的，有什么經(jīng)驗(yàn)
答：200兆。cpu是業(yè)務(wù)應(yīng)用的10%，但是還需要壓測(cè)。和前面問(wèn)題類似。
13. sidecar的監(jiān)控是怎么做的？ 權(quán)限，成本方面可能都有一些疑問(wèn)
答：
14. Naming這個(gè)agent和框架非常不錯(cuò)，請(qǐng)問(wèn)Naming可以支持負(fù)載均衡么， 也就是PodX訪問(wèn)PodY的時(shí)候，naming不要返回PodY真實(shí)IP，而是返回負(fù)載均衡的VIP給PodX; 十分感謝-Ken
答：沒采用這種方式，后續(xù)可以使用vip方式。
15. 這種架構(gòu)的話，PodX主動(dòng)出公網(wǎng)的邏輯是怎樣的呢，也是通過(guò)ip-masq 做NAT嗎？
答：這個(gè)和百度的內(nèi)部網(wǎng)絡(luò)架構(gòu)有關(guān)系。
16. Naming agent是部署在哪個(gè)容器？
答：?jiǎn)螜C(jī)的，host部署一個(gè)。
17. Pliot在落地過(guò)程中部署模型，大規(guī)模envoy注冊(cè)后，是否存在一些性能瓶頸，有什么優(yōu)化的經(jīng)驗(yàn)？
答：百度也做了很多pilot的優(yōu)化，比如100萬(wàn)行的crd配置，大概10s就能夠完成匹配。大規(guī)模envoy注冊(cè)的話，連接數(shù)變多了，可以通過(guò)pilot水平擴(kuò)展來(lái)解決。
18. 雖然老師不一定有關(guān)注這一塊，但也提個(gè)問(wèn)題看看吧。 envoy流量劫持是在userSpace還要經(jīng)TCP協(xié)議棧其實(shí)損耗非常大的，后續(xù)Envoy有考慮byPass Kernel，直接傳包給網(wǎng)卡驅(qū)動(dòng)提速么（例如DPDK、SPDK）
答：還未大規(guī)模進(jìn)行落地，不過(guò)系統(tǒng)真是的瓶頸其實(shí)也不再這塊。
19. 流量都經(jīng)過(guò)sidecar后，sidecar在trace這方面是怎么考慮和設(shè)計(jì)的？
答：原生就是智慧trace的，有traceid，spanid這些，只要進(jìn)行適配就可以。
20. 對(duì)于inbound流量的限流是如何設(shè)計(jì)的呢？
答：這塊原生不支持，是通過(guò)envoy filter來(lái)實(shí)現(xiàn)的。
21. 私有協(xié)議如果要變更的時(shí)候，是不是要級(jí)聯(lián)更新？
答：題目不明確，未回答。
22. 支持服務(wù)治理的配置灰度下發(fā)嗎？可以簡(jiǎn)單說(shuō)下實(shí)現(xiàn)方案嗎
答：目前百度是支持配置灰度的，這個(gè)原生不支持，百度自己實(shí)現(xiàn)，后續(xù)單獨(dú)發(fā)一篇文章講一下。
23. 你們 內(nèi)部對(duì)于 istio deployment 里的 version 字段在落地時(shí)有大規(guī)模使用嗎？我們最近在基于 istio 做灰度發(fā)布，但是每次灰度都要給他一個(gè)版本號(hào)，導(dǎo)致完成之后 deployment 名稱就從 v1 變成 v2 以此累加，這樣還會(huì)導(dǎo)致 deployment 本身的回滾功能失效。
答：不用非得使用version，還有其他的label標(biāo)簽可以使用或者自定義。
24. Envoy對(duì)于我司來(lái)說(shuō)技術(shù)儲(chǔ)備其實(shí)不是很夠， 請(qǐng)問(wèn)貴司剛上線的時(shí)候， Envoy有沒有遇到哪些問(wèn)題。 特別是穩(wěn)定性和故障方面。 如果能建議一下envoy應(yīng)該如何監(jiān)控，那就perfect.
答：主要就是靠識(shí)別出envoy故障后，能夠快速切換到直連方式來(lái)解決。
25. 對(duì)于 dubbo 的泛化調(diào)用，探針會(huì)實(shí)時(shí)檢測(cè)調(diào)用關(guān)系的變化么？如果 sidecar 還沒有被生成，這個(gè)時(shí)候流量請(qǐng)求阻塞怎么處理呢？一直等待還是直接拒絕？如果服務(wù)是新的請(qǐng)求呢？
答：naming實(shí)現(xiàn)，不會(huì)出現(xiàn)這種情況，會(huì)在sidecar生成后在進(jìn)行流量轉(zhuǎn)發(fā)，否則流量還是直連模式。
26. link模型解決xDS問(wèn)題，可以再詳細(xì)介紹一下整個(gè)邏輯鏈路么？例如consumer和provider的link數(shù)據(jù)是怎么獲得的
答：這是百度自己做的一個(gè)產(chǎn)品配置頁(yè)面，提供服務(wù)訂閱，然后根據(jù)訂閱關(guān)系進(jìn)行配置下發(fā)。
27. 2ms的Envoy額外消耗，請(qǐng)問(wèn)是怎么查看的呢? curl endpoint 跟 curl envoy 做一次對(duì)比么
答：差不多，基本就是直連和過(guò)sidecar請(qǐng)求來(lái)進(jìn)行交叉對(duì)比。
28. Envoy注入后業(yè)務(wù)pod會(huì)存在2個(gè)container， 那么envoy的配額是怎么限制的呢？ 比如限制4核心可能就是2個(gè)容器（1個(gè)pod）里面的配額了； 
答：前面介紹了。
29. 就是我們?cè)诼涞氐臅r(shí)候，會(huì)遇到部分服務(wù)有sidecar，部分沒有(服務(wù)A會(huì)被其他10個(gè)服務(wù)調(diào)用)，一般如何去判斷配置設(shè)置在哪里，是在outbound（其他10個(gè)服務(wù)部署sidecar）處還是inbound處（服務(wù)A部署sidecar）。這個(gè)有沒有什么比較好的實(shí)踐
答：還是naming組件實(shí)現(xiàn)，如果能匹配到就過(guò)envoy，匹配不到就走直連模式
30. Envoy如何實(shí)現(xiàn)長(zhǎng)連接的動(dòng)態(tài)開關(guān)的？
答：通過(guò)開發(fā)一個(gè)listener，通過(guò)listener來(lái)監(jiān)聽envoy的長(zhǎng)連接，當(dāng)變更的時(shí)候進(jìn)行控制。