華為云-張偉-華為云服務網格數據面演進與實踐.pdf

《華為云-張偉-華為云服務網格數據面演進與實踐.pdf》由會員分享，可在線閱讀，更多相關《華為云-張偉-華為云服務網格數據面演進與實踐.pdf（36頁珍藏版）》請在三個皮匠報告上搜索。

1、華為云服務網格數據面演進與華為云服務網格數據面演進與實踐實踐張張偉偉 華為華為云云 ASMASM服務網格架構師服務網格架構師華為云服務網格數據面華為云服務網格數據面演進演進與與實踐實踐張偉ASM服務網格架構師“Istio權威指南第二版核心作者。18年開發經驗，先后就職于億陽信通、北電、甲骨文、Polycom、阿里巴巴及華為等公司，作為核心開發人員開發過傳輸網管系統、Tuxedo交易中間件、ts-server多媒體轉碼服務、GTS（seata）高性能事務云服務、SC高性能注冊中心、ASM數據面等多個產品，有豐富的架構設計及開發經驗，現主要負責華為云ASM服務網格數據面代理產品的方案設計及開發工作

2、?！闭埐迦肽恼掌v師簡介講師簡介網格數據面運維增強功能介紹ASM網格數據面的演進路線目錄目錄Istio+Kubernetes：云原生應用治理+云原生應用設施服務治理部署運維核心理念：核心理念：1.1.非侵入式非侵入式SidecarSidecar注入技術注入技術，將數據面組件注入到應用所在的容器，通過劫持應用流量來進行功能實現，應用無感知。2.2.北向北向APIAPI基于基于K8s CRDK8s CRD實現實現，完全聲明式，標準化。3.3.數據面與控制面通過數據面與控制面通過xDSxDS gRPCgRPC標準化協議標準化協議通信，支持訂閱模式。核心特性：核心特性：1.1.服務服務&流量治理：流

3、量治理：熔斷，故障注入，豐富的負載均衡算法，限流，健康檢查，灰度發布，藍綠部署等2.2.流量與訪問可視化：流量與訪問可視化：提供應用級別的監控，分布式調用鏈，訪問日志等3.3.安全連接：安全連接：通過mTLS、認證、鑒權等安全措施幫助企業在零信任的網絡中運行應用華為云ASM，全托管的應用服務網格基礎設施VMMetricLoggingTracing應用拓撲APMAPMCCECCEASMASM流量治理流量治理彈性擴縮容彈性擴縮容灰度發布灰度發布認證和授權認證和授權應用部署應用部署服務發現和訪問服務發現和訪問服務運行診斷服務運行診斷訪問親和性訪問親和性多云混合云多集群、多基礎設施服務統一管理多云混合

4、云多集群、多基礎設施服務統一管理控制面控制面數據面數據面MCPMCPSWRSWRCI/CDCI/CDCCICCIIEFIEFSvcEnvoyCCESvcEnvoyCCISvcEnvoyIEFSvcEnvoySvcSvcSvc3rd svc業務業務 覆蓋全應用形態，支持容器、虛機、邊緣、傳統微服務、第三方服務等多種應用平滑接入、統一治理。支持多云、混合云復雜場景多種網絡條件下服務跨集群流量混合管理；大規模網格；提供智能運維、智能擴縮容，幫助用戶自動透明的管理應用訪問 高性能、低損耗、輕量、多形態網格數據面，支持每POD、每Node形態，加快Sidecar轉發效率，優化網格控制面資源。 ASM產品

5、在運維能力上針對現有Envoy進行了增強，可以對一些普遍由于引入代理的時延增加類問題快速定位。ASM產品的發展路線從Sidecar和節點模式NodeProxy逐漸演進到下一代L4/L7分離式架構。這一演進旨在提升用戶資源利用率的同時，實現更快的L4層快速路徑數據治理以及更具彈性的L7層遠程處理能力。亮點亮點介紹介紹案例案例背景：常見的時延問題背景：常見的時延問題1.多個客戶線程同時訪問Envoy，TCP分片或應用發送消息分片使得同一個應用消息處理時間拉長，而且不一定可以穩定重現。2.客戶端處理響應較慢，導致Envoy上游讀服務端響應水位被關閉，造成整體請求處理時間較長。問題基本描述：問題基本描

6、述：3.Envoy內用戶自定義插件編寫不當，導致請求整體處理時間較長。1.客戶線上服務支持用戶使用HTTP請求上傳文檔，文檔本身10k左右，有時延達到秒級。通過Envoy AccessLog只能看出Envoy內時延較高，但不知道在哪個階段引起。2.此為線上偶現問題，再嘗試上傳相同文檔則在幾十毫秒內完成傳輸。3.從OS層面觀察內核數據發送無延遲，HTTP數據量本身不大，不應在不同調用時呈現較大的時延差異。4.測試環境下無法穩定重現，此問題定位最終耗時幾周。5.最后判斷由于Istio ingressgateway網關處理較大并發時，用戶消息被分片處理，且Envoy事件處理不及時導致完整HTTP完成

7、處理較慢。案例案例背景背景 線上問題、測試環境無法穩定重現、即使重現在Envoy現有日志也沒法直接判斷。問題與挑戰問題與挑戰1.時延類問題需要在請求整個梳理路徑中，對L4數據收發、插件執行、連接池觀察等多個方面進行綜合分析。2.可以結合tcpdump抓包查看客戶端到Envoy、Envoy之間、Envoy到目標服務之間包時間戳的差異（需要NTP校準各個部分的系統時間）。3.需要將更詳細的觀測狀態記錄到AccessLog中，作為日常觀測手段，可以快速對不同時延類問題進行判斷。破題思路破題思路解決問題思路：簡要但不簡單；經驗解決問題思路：簡要但不簡單；經驗-能力能力核心核心實踐：增強實踐：增強Env

8、oyEnvoy運維日志輸出信息運維日志輸出信息1.增強 Envoy 的請求級別信息，提供更詳細的信息，包括：調用操作系統讀寫操作的耗時是否使用安全連接處理連接的線程 ID及連接ID是否出現 HTTP 消息分片分片是否出現由于連接內緩存限制導致的流控流控插件插件框架執行時間上游連接池在 HTTP 協議中是否被重用重用處理 HTTP 響應時收到的 HTTP 頭部和數據部分是否存在較大時間間隔等信息2.日志增強增強信息可以幫助快速定位時延問題，例如系統調用阻塞、消息分片、Envoy 自身插件處理時間過長、到達緩存水位暫停接收等。3.日志增強功能不會影響現有的 Envoy 內的請求級別服務維度日志，而

9、是作為日常運維手段的補充。4.可以提供更全面的請求級別信息，幫助運維人員更好地分析和調優系統性能，快速定位潛在的性能瓶頸和延遲問題。打通打通 EnvoyEnvoy請求處理請求處理鏈路中鏈路中L4L7L4L7自身自身運行狀態觀察能力運行狀態觀察能力判斷HTTP大小，以及Envoy L4接收及發送的數據量和Envoy處理中自身增加的HTTP頭部大?。褐挥蠬TTP Header部分的下游請求日志：成果成果展示展示1 11.上面例子DOWNSTREAM_READ_DURATION 部分C56:R:0,0,96H中：0 表示OS接收開始的時間戳，以及接收用時ms，如果耗時較長需要考慮調整內核參數提升網絡

10、接收性能。96 表示本次接收到的數據字節數H 表示本地接收到的數據經過HTTP解碼器作為HTTP 頭部進行解碼。Envoy內HTTP添加部分：1271-96=1175字節2.如果觀察到日志中只有頭部而沒有數據部分，并且整個接收字節數較大，那么可以推斷存在較大的 HTTP 頭部。在這種情況下，可能會觸發一些 HTTP 服務器處理框架中的 HTTP 頭部長度校驗限制。管理員可以將這個問題反饋給開發，建議他們將某些頭部參數移動到數據部分。通過將一部分頭部參數放入數據部分，可以減少整體頭部的長度，從而避免觸發服務器處理框架的限制。判斷Envoy工作線程數量及各個線程處理新連接情況是否均衡：使用命令：a

11、wk print$29 4.log|sort|uniq-c 統計每個線程處理請求的數量了解各個線程處理連接是否均衡：成果成果展示展示2 2Envoy啟動參數：concurrency參數啟動4個工作線程單行日志：1.在 Istio 1.8 版本之前，存在在多線程環境下，outbound 方向的 Envoy 可能出現每個線程處理連接數差異較大的情況的問題，這可能導致端到端處理的平均時延不均衡。2.運維人員可判斷是否需要啟用連接均衡選項來提升吞吐。從而在多線程環境下更均衡地分配連接，提高系統性能并改善響應時間。判斷是否單個消息太大導致TCP分片，或HTTP響應頭和數據部分之間產生延遲：a.由于HTT

12、P請求及響應消息較大，導致出現同一個HTTP消息出現分片：成果成果展示展示3 3上面例子中：1.Envoy 的處理過程中，HTTP 頭部和數據部分為獨立回調，并且每個回調在完成后會單獨發送到 L4 連接的發送緩沖區中，當多個客戶端頻繁發送請求時，可能會導致 HTTP 消息的頭部和數據部分被分別發送，增加某HTTP 消息時延。2.通過分析分片日志，可以觀察到同一個 HTTP 消息的每個分片的接收時間，以及在服務器端發送響應時是否分開發送HTTP 頭部和數據部分，增加了客戶端的端到端處理時延。3.對于這種情況，可以考慮以下優化措施：減小請求端單個HTTP請求的發送的數據量大小。優化服務器端的處理邏

13、輯，以減少處理時間，確保 HTTP 頭部和數據部分能夠盡快被一起發送給客戶端。b.HTTP響應頭部與數據部分存在延時19ms：判斷Envoy之間是否啟動了TLS，以及是否執行了連接復用1.在線上配置過程中，如網格默認沒有啟用 mTLS，導致新增的服務沒有配置 mTLS，從而導致明文傳輸，增加了安全風險?？梢酝ㄟ^監控 Envoy 日志來發現此類情況。2.在下面的日志中（例如2023-11-28T01:43:00.757Z），可以找到以下信息：DOWNSTREAM_READ_DURATION中：C676:R:0,0,1167H,D,E，表示客戶端發起的請求是明文內容，其中的 R 表示明文請求。UP

14、STREAM_WRITE_DURATION中：C677C677:S:0,0.2336d中，C677C677表示上游連接池在收到客戶請求后新創建了一個 C677 連接，并且實際使用的也是 C677 連接。S 表示該連接使用了 TLS。另外在 Istio 1.8 版本之前，存在一個問題，即創建的上游連接并不一定是實際請求所使用的連接。這可能導致消息接收端的錯亂。您也可以通過上面提到的日志信息中連接ID來判斷。3.在接下來的2023-11-28T01:43:09.310Z日志中：UPSTREAM_WRITE_DURATION中：C0C677:S:0,0,2336d中，表示此時沒有創建新的上游連接，而

15、是重用了已有的 C677 連接?？梢耘袛嘣谀扯螘r間內有多少活躍的上游連接被重用。根據重用情況，可以決定是否需要調整連接池連接參數，擴大或縮減連接池內的活動連接容量。這樣可以優化連接池的性能和資源利用情況。成果成果展示展示4 判斷是否由于連接緩沖區水位大小導致接收關閉：a.上游接收響應觸發連接流控日志：成果成果展示展示5 5b.上游接收響應水位恢復后日志：1.Envoy 每個連接都可以配置緩存的水位大小。默認情況下，低水位線為512K，高水位線1M。當前連接內的請求未完成處理時，如果新的請求數據量超過了緩存水位，將會觸發水位關閉。一旦待處理的數據發送完畢，水位將恢復。2.下游連接和上游連接是獨立

16、的連接，它們分別具有各自的緩存配置。這意味著在處理下游請求時使用的緩存配置可能與處理上游請求時使用的緩存配置不同3.從上面的例子中可以看出：（42）線程上游連接日志UPSTREAM_READ_DURATION顯示在0,0,11137H,D,E!1時接收服務端響應時，由于上游發送處理較慢無法發送到后端服務時，觸發水位關閉，連續關閉次數為1。在（42）線程的下一個請求處理中，上游連接日志UPSTREAM_READ_DURATION顯示C114C44:S:0,0,11345d”“C44:S:0,0,11133H+5,D,E!1時，在經過5ms（對應前一條日志關閉時間)后水位在重新開放，因此上游發送可

17、以在時繼續發送數據。此時可以判斷出是由于Envoy上游連接水位被限制導致服務端接收數據變慢。管理員可以配置下游監聽器或上游Cluster的perConnectionBufferLimitBytes參數控制連接水位。根因推測為下游寫response較慢導致上游的讀出現了水位限制判斷Envoy插件執行時間：用例：增加根據頭部x-delay參數進行延時的lua插件：成果成果展示展示6 6訪問日志：使用命令：curl-v-Hx-delay:9 http:/http-server-service.default:9000訪問服務根據以上日志：1.下游接收DOWNSTREAM_READ_DURATION時

18、間點到上游發送UPSTREAM_WRITE_DURATION時間點之間有9s9s的時間差，排除Envoy基本處理流程耗時外，相差較大的時間可以猜測為耗時的HTTP插件引入。2.接下來幫助管理員排查是否由于lua或耗時的用戶自定義插件引入時延問題。非時延類問題非時延類問題有萬分之一的概率，在WAF上看到502報錯：分析方法分析方法：1.在WAF及ingressgateway側分別抓包，發現都有FIN報文，Envoy主動關閉連接。結論結論：1.Istio 1.3老版本默認開啟協議嗅探，可自動檢測客戶端是否開啟TLS協議，并會根據客戶端發送的第一個Client Hello報文判斷協議種類。默認參數p

19、rotocolDetectionTimeout：10ms。2.如果在嗅探配置時間內未收到客戶端報文，Envoy會主動斷開連接。Istio在1.3之后版本默認關閉了協議嗅探功能。3.kubectl edit cm istio-nistio-system可將protocolDetectionTimeout修改為”0s”關閉協議嗅探.2.繼續抓包，分析正常報文與異常報文區別，502異常報文的ACK報文與客戶端Client Hello報文時間間隔超過10ms，而正常ACK報文與Client Hello報文間隔小于10ms。非時延類問題非時延類問題上傳較大圖片，網關偶現413報錯：分析方法分析方法：1.

20、使用tcpdump在ingressgateway抓包，結合報錯信息”request data too large watermark exceeded”，初步判斷和buffer limit相關。結論結論：1.對maxRequestBytes參數配置1MB閾值后，測試傳輸超過1MB的圖片時，報錯基本穩定重現。2.分析代碼發現，處理請求decode階段，會對buffer limit做檢查，如果請求數據量高于maxRequestBytes，則報錯413.3.解決方法：通過envoyfilter為listener下發maxRequestBytes參數配置。如下：2.分析Envoy代碼，發現相關參數為m

21、axRequestBytes和per_connection_buffer_limit_bytes。且經過分析per_connection_buffer_limit_bytes不會對請求造成中斷，只會影響請求處理速度。非時延類問題非時延類問題修改Listener配置，導致長連接斷開：現象現象：Istio 1.8修改EnvoyFilter內容，45s后websocket連接會斷開，雖然客戶有重試，但大量連接請求對后端造成壓力。結論結論：1.分析Envoy代碼得知，Envoy采用Listener-filterChain配置結構，同時接收的客戶端連接將同時保存與此filterChain關系。2.當ap

22、ply新EnvoyFilter時，LDS將調用addOrUpdateListener添加新的Listener，并根據當前Listener是否支持inPlace判斷是否支持原地替換。3.如果不支持，則調用startDrainSequence啟動老Listener下線流程，并在到達Drain時間后，調用removeFilterChains關閉此Listener-filterChain關聯的所有活動連接。4.此斷開連接的底層邏輯是：由于連接上配置的過濾器內容都是在接收連接時確定的，如果不斷開，則Listener上已有連接的執行邏輯可能與新建立的連接不一致。分析方法分析方法：1.進行重現發現此問題可以

23、穩定復現。2.對比使用EnvoyFIlter前后的Envoy dump文件配置內容，并主要關注受影響的Listener的配置變化。1.通過增強 Envoy 的運維功能，可以將線上時延類問題的定位范圍縮小定位范圍縮小到原來的1/10。2.此運維增強日志擴展了Envoy AccessLog，可以在線上業務在線上業務正常運行時實時記錄和分析日志。成果展示成果展示1.引入了服務網格Envoy作為透明代理，其透明攔截機制與未加入網格時對比在用戶鏈路中產生一些不確不確定定因素。2.時延類問題是比較難以定位難以定位的，如在問題發生后重新搭建環境進行重現，這樣往往就失去了先機。3.日志增強功能不僅是對Acce

24、ssLog本身的增強，關鍵狀態以最精簡以最精簡的形式體現出來。案例復盤與總結案例復盤與總結1.在使用服務網格產品時，用戶通常會遇到Sidecar資源消耗較大和網格規模受限規模受限的問題，這會影響客戶購買的集群資源的利用率和單個網格應用的部署規模。2.在進行NodeProxy節點級模式探索時，遇到如金融用戶或游戲用戶需求：，其中有些服務需要保證其更更高的服務優先級高的服務優先級。網格數據面演進：案例網格數據面演進：案例背景背景 Envoy代理邏輯復雜，隨著網格規模的增加，網格內的配置占用的內存也會增加。并且隨配置配置同步通信同步通信量的量的增加增加大規模網格下很難保持穩定運行。容器自動調度機制，

25、同一節點上可能有不同優先級不同優先級用戶。很難規劃很難規劃NodeProxy節點的內存和CPU參數。NodeProxy需要在每個節點上運行完整的代理，同樣會占用一定的節點占用一定的節點內存。希望盡可能地確保用戶購買的資源不受影響資源不受影響，并且能夠在流量增減時進行可控的L7彈性擴縮容。問題與挑戰問題與挑戰1.ASM產品：從Sidecar到節點模式NodeProxy，并向下一代L4/L7L4/L7分離分離的kmesh卸載模式的演進路線。2.提供根據服務元數據進行L4優先級和QoSQoS能力能力問題。3.ASM采用了共享節點內控制面連接，降低降低每個節點對控制面的連接數，這些能力也適用于L4/L

26、7分離場景。4.在下一代L4/L7分離架構中，為了提高L4L4處理性能處理性能和實現更靈活的靈活的L7L7彈性彈性能力，ASM采用了每節點L4內核卸載加L7彈性部署的方式。破題思路破題思路 網格數據面隨集群增加的內存占用情況比較：測試測試環境環境：Istio 1.8.4-r3,k8s 1.1916 核|32 GB|Sit3.4xlarge.2核心核心實踐：實踐：NodeProxyNodeProxy節點模式與節點模式與SidecarSidecar模式對比模式對比網格規模網格規?？偪係idecarSidecar內存占用內存占用GBGB總總NodeProxyNodeProxy內存占用內存占用GBGB

27、內存下降比例內存下降比例30pods/200svcs30*0.04=1.24*0.08=0.32 1-(0.32/1.2)=73%50 pods/200svcs50*0.04=24*0.08=0.3284%100pods/200svcs100*0.04=44*0.08=0.3292%100pods/500svcs100*0.08=84*0.19=0.7691%100pods/1000svcs100*0.14=144*0.24=0.9693%100pods/1500svcs100*0.18=184*0.3=1.293%分析分析：Envoy內存占用的增長在Sidecar模式下會因為每Pod注入而被

28、放大。但是在NodeProxy模式下則可以忽略。隨著網格內Pod和服務數量的上升，NodeProxy對內存占用下降可以達到達到70%70%以上。以上。1.解決每每PodPod內存占用。2.支持元數據元數據進行靈活的L4負載均衡。3.節點內控制面連接共享控制面連接共享。4.NodeProxy之間共享共享TCPTCP連接。5.支持節點節點內服務優先訪問策略優先訪問策略。6.數據面升級控制老版本緩慢下線緩慢下線NodeProxyNodeProxy模式模式NodeProxyNodeProxy節點模式優化節點模式優化方案方案：核心核心實踐：實踐：ASMASM網格數據面的演進路線網格數據面的演進路線Nod

29、eProxyNodeProxy模式模式SidecarSidecar模式模式L4/L7L4/L7分離模式分離模式1.1.固定固定L7代理，占用較大用戶購買資源。2.每個請求需要拷貝用戶拷貝用戶完整數據。3.需要兩側都為兩側都為NodeProxyNodeProxy部署，但需要控制面參與。NodeProxyNodeProxy問題：問題：1.L4內核卸載兼容兼容現有 iptables 配置規則。同時減減少少拷貝數據到用戶態開銷。2.L4攔截區分快慢路徑快慢路徑。3.支持除Istio外第三方第三方安全認證中心。4.部分 L7 能力可卸載可卸載，從而提高性能。5.支持多種異構異構基礎基礎設施的互聯互通場景

30、，可集成多種容器CNI。6.支持L7本地及拉遠兩種模式，可提供全托管全托管的數據面。7.提供了對已加入網格的服務進行動態繞過動態繞過的能力。L4/L7L4/L7彈性分離的架構優勢：彈性分離的架構優勢：核心核心實踐：實踐：ASMASM網格數據面網格數據面L4/L7L4/L7架構優勢架構優勢 有負載情況下，網格數據面L4代理性能及資源占用情況：核心核心實踐：實踐：L4/L7L4/L7分離與分離與SidecarSidecar模式性能及資源對比模式性能及資源對比連接數連接數L4L4內存占用內存占用MBMBL4 CPUL4 CPU占用占用平均時延平均時延msmsP90P90時延時延msmsP99P99時

31、延時延msmsQPSQPS64連接（未加入網格）/1.1022.9655.8445803864連接（ztunnel）16.5109.7%1.7413.1965.4223674764連接（kmesh L4）121210%10%1.0471.0472.9495.716104161041測試測試環境環境：Istio 1.19,Istio 1.19,k8s k8s 1.271.27分析分析：kmesh相比未加入網格的直連情況性能持平（甚至從測試結果看略優），相比ambient的四層處理，CPU占用降低90%90%，平均時延僅后者的60%60%，QPS超過后者6060%無負載情況下，網格數據面隨集群增加

32、的內存占用情況：網格規模網格規模單個單個SidecarSidecarZtunnelZtunnelWaypointWaypointKmesh L4Kmesh L4空載56M13M55M11M200 pods/100 svcs74M14M78M12M1000 pods/500 svcs147M18M157M16M5000 pods/2500 svcs514M38M496M33M2.5w pods/1.25w svcs2.1G112M1.31.8G（不穩定）96M10w pods/5w svcs7.6G150M不穩定130M分析：分析：1 1：雖然L4/L7分離后，每個Waypoint代理占用內存與

33、單個Sidecar相當，但由于可以被共享，并且彈性擴容，整體集群內網格固定內存消耗減固定內存消耗減少少。2 2：節點內固定占用的網格L4部分內存隨網格規模增加較少，增加較少，轉發穩定并與用戶態L4相比降低10%1510%15內存占用。APPnode OSsidecarAPPsidecarAPPsidecarAPPsidecarAPPsidecarAPPsidecarAPPsidecarAPPsidecarAPPsidecarAPPnode OSAPPAPPAPPAPPAPPAPPAPPAPPAPPAPPAPPztunnelztunnelAPPnode OSAPPAPPAPPAPPAPPAPPA

34、PPAPPAPPAPPAPPKmeshK節點內節點內L7L7治理加速：治理加速：基于偽建鏈偽建鏈、延遲建鏈延遲建鏈等技術，內核L4中實現部分L7的治理能力；基于ebpf，在內核協議棧中構筑可編程的L7擴展能力；Kmesh流量編排運行時connectAPPAPPsendmsg延遲建鏈三次握手協議棧發送(sockmap/TLS offload/)recvmsgL4編排(LB/)L7協議解析L7編排(灰度/路由/)L7編排(限流/)userspacekernel偽建鏈核心核心實踐：部分實踐：部分L7L7能力內核卸載能力內核卸載核心核心實踐：實踐：L4/L7L4/L7分離分離數據數據面動態繞過能力面動

35、態繞過能力默認所有流量被默認所有流量被kmesh L4kmesh L4攔截攔截模式一：跳過模式一：跳過kmeshkmesh攔截攔截模式二：跳過所有網格攔截模式二：跳過所有網格攔截1.kmesh L4默認接管所有應用流量所有應用流量2.在Pod創建時注入創建時注入注入少量iptables規則，運行態不增刪。1.1.只繞過只繞過kmeshkmesh 攔截，恢復已有流量路徑。2.幫助判斷是否由是否由kmeshkmesh引入流量治理問題。1.1.繞過所有網格繞過所有網格 攔截，恢復Kubernetes流量。2.幫助判斷是否由網格是否由網格引入流量治理問題。3.3.逃生通道逃生通道!1.服務可達、時延增

36、加、內存占用增加等問題是否由網格引入定界難定界難。2.一旦啟用網格，修改代理模式重啟，影響業務影響業務。3.動態修改iptables規則，有時間窗口，性能低，網絡不穩定有時間窗口，性能低，網絡不穩定。用戶不敢切換用戶不敢切換或升級網格！或升級網格！運運維維增強增強方面方面：1.在問題定位過程中歸納總結經驗、提煉可下沉的技術積累、構建產品的基礎能力、持續迭代和改進。數據面模型發展數據面模型發展：1.需要詳細了解數據面的運作原理，包括線程，連接，處理流程等。2.歸納數據面各個部分的職責，以及相關性。3.了解操作系統的能力和最新的功能提升，在設計上做到彈性化，共享化，并縮短路徑。4.擁抱開源，通過社

37、區不斷完善產品：*前面的優化項已經在kmesh開源之中。案例案例啟示（總）啟示（總）問題總結問題總結-方法積累方法積累-能力下沉能力下沉-持續迭代持續迭代梳理流程梳理流程-明晰職責明晰職責-優化設計優化設計-擁抱開源擁抱開源1.在運維方面，kmesh 將繼續擴展現有的線上運維增強能力。通過結合 L4/L7 帶來的內核觀測能力和現有的 L7 觀測能力，以便能夠實現更快速、更精確的定位線上時延、訪問可達性等問題。2.在 L4/L7 數據面分離方面，kmesh 將致力于實現統一注冊中心的功能，更平滑數據面升級能力，同時完善產品使用體驗，這將為傳統微服務調用和 Serverless 提供更一致的治理體驗。下一步下一步kmeshkmesh項目地址：項目地址：https:/ 信 官 方 公 眾 號：壹 佰 案 例微 信 官 方 公 眾 號：壹 佰 案 例關 注 查 看 更 多 年 度 實 踐 案 例關 注 查 看 更 多 年 度 實 踐 案 例