ServiceMesh實踐之如何避坑

這篇文章主要講解了“Service Mesh實踐之如何避坑”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Service Mesh實踐之如何避坑”吧！

創(chuàng)新互聯(lián)成都網(wǎng)站建設按需策劃設計，是成都網(wǎng)站推廣公司,為成都輕質(zhì)隔墻板提供網(wǎng)站建設服務,有成熟的網(wǎng)站定制合作流程，提供網(wǎng)站定制設計服務：原型圖制作、網(wǎng)站創(chuàng)意設計、前端HTML5制作、后臺程序開發(fā)等。成都網(wǎng)站設計熱線：028-86922220

Service Mesh已經(jīng)成為微服務領域的熱門議題，同時也被廣泛視為云原生應用程序的指導性架構(gòu)。Service  Mesh環(huán)境在理論上能夠增強微服務通信的流量管理與安全水平，提供關(guān)于應用程序運行狀態(tài)的全面情況，但在實踐層面卻往往難于管理、過分復雜。為了避免掉坑，我們必須采取一系列步驟簡化這個過程。

確定重要事項、規(guī)劃探索旅程

在踏上Service Mesh旅程之前，我們首先需要確定最重要的事項，并由此規(guī)劃探索道路。

對多數(shù)企業(yè)而言，在微服務之間建立零信任通信已經(jīng)成為一種當務之急，但不同組織的需求往往不盡相同。也許您希望Service  Mesh提供高級流量管理功能，也許希望通過邊車代理強化可觀察性。

無論您有哪些需求，都必須首先確定優(yōu)先級，并在起步之前獲得開發(fā)人員、SRE工程師與安全運營(SecOps)團隊的理解與支持，集中精力完成工作。請注意，不要指望整個流程能夠一蹴而就，否則Service  Mesh的實現(xiàn)之路必然陷入困境。

一旦確定了正確的目標優(yōu)先次序，我們即可為Service  Mesh旅程建立一份路線圖。作為前進的指引，這份路線圖應該列出實施舉措的具體次序，并確定各個步驟該如何與IT及業(yè)務目標保持一致。例如，您可以對希望增強的可觀察性方向做出排序，用以加快問題解決速度，并改善應用程序的正常運行時間，借此超越預定的流量管理目標。通過這種排名，您可以專注于解決Service  Mesh應當實現(xiàn)的目標、獲取與之對應的回報。

明智選擇Service Mesh解決方案

目前市面上存在多種Service Mesh控制平面，不同解決方案之間總有優(yōu)劣差異。在選擇Service  Mesh時，請首先保證其能夠支持您的運行環(huán)境。如果您已經(jīng)部署有Mesos等系統(tǒng)、內(nèi)部專有/遺留架構(gòu)或者特定公有云平臺，請確保選擇的Service  Mesh能夠與之兼容。

其次，確定部署哪一種Service Mesh控制平面。雖然各類Service  Mesh控制平面都提供相似的基礎功能，但不同方案在功能與成熟度方面總有區(qū)別。要確定Service  Mesh的控制平面是否適合您的用例，并研究如何設計整個技術(shù)堆棧。在這些方面，Istio整體表現(xiàn)更好。例如，Istio在服務雙向TLS方面占據(jù)領先地位，而其他Service  Mesh的微服務零信任實現(xiàn)能力仍然有待提高。

第三，評估您的現(xiàn)有技能與資源能夠從容管理多少復雜性因素。在添加功能時，隨著Service  Mesh規(guī)模與集群數(shù)量的增長，整個體系會變得越來越復雜。請注意，我們往往會低估發(fā)展過程中的復雜度水平，實際上我們很難預測未來會發(fā)生什么，因此必須設定極限并留有緩沖。

在選擇Service Mesh時，請關(guān)注幾項“必要因素”：可觀察性、安全性與流量管理、組織內(nèi)已經(jīng)具備的技能、選擇最佳Service  Mesh架構(gòu)等等。另外請詢問自己，您是否真的需要為每個pod提供邊車代理，或者是否需要滿足Citrix® Service Mesh  lite等替代或變種架構(gòu)的需求。

為意外與復雜性制定規(guī)劃

無論如何嚴密制定計劃，您在實現(xiàn)Service Mesh時總會遇到意外。但這并不是說計劃無用——計劃得越是完善，您在應對意外時才會更從容。

代理并不是那么透明

有時候，代理的透明度可能相當差。一般來說，當微服務嘗試調(diào)用某些并不存在、或者暫時負載壓力較大的資源時，就會引發(fā)超時。但代理的存在會扭曲應用超時，導致每項微服務都誤以為其請求已經(jīng)被即時接收。為此，我們必須認真調(diào)整應用程序中的超時機制。

另外，代理對于HTTP流量同樣不夠透明。很多代理會將HTTP標頭轉(zhuǎn)換為小寫形式以保持合規(guī)性、一致性并降低資源消耗。實際上，HTTP/2規(guī)范要求標頭必須小寫。如果您的應用程序仍然通過大小寫來區(qū)分HTTP標頭，那么代理的介入很可能破壞其基本功能。請確保代理通信造成的細微差別不致破壞您的應用程序，同時著手調(diào)整代理或應用程序本體以匹配生態(tài)系統(tǒng)的實際特性。

早測試、勤測試

我們無法預測未來，也不可能預見哪些組件會出問題。Service  Mesh是一種復雜的分布式系統(tǒng)，包含大量活動部件，其中每個部件都有可能發(fā)生故障。如果應用程序出現(xiàn)問題，我們面對的就是應用程序本體、連帶工具乃至其他故障源。為此，大家務必要逐步實施、持續(xù)監(jiān)控并保證頻繁測試。

為此，您需要建立起完備的可觀察性堆棧，具體涵蓋日志記錄、指標、分布式跟蹤與服務圖。分布式跟蹤與服務圖又是服務可觀察性中的關(guān)鍵要素。分布式跟蹤能夠監(jiān)控流經(jīng)微服務架構(gòu)的請求流，通過各個微服務躍點建立起延遲映射，借此幫助您快速解決延遲問題。服務圖則是各微服務之間依賴關(guān)系以及運行狀態(tài)的動態(tài)圖形表達，能夠以簡便方式實現(xiàn)環(huán)境可視化并幫助您發(fā)現(xiàn)一切問題。

另外需要注意的是，請務必堅持部署持續(xù)測試，引導項目始終處于正軌之上。大家不妨考慮建立一項端到端24/7全天候測試服務，用于持續(xù)測試您的微服務體系。

為大量修訂工作做好準備

今天的小作坊，明天可能發(fā)展成大企業(yè)，我們必須提前做好準備。您可能需要調(diào)整默認的CPU與內(nèi)存分配機制，盡可能降低資源消耗。同樣的，一旦開始部署Service  Mesh，修訂需求就將如潮水般涌來。如果沒有完善的計劃，持續(xù)運作的應用程序?qū)⒑芸焐壋鰺o數(shù)個邊車代理，萬萬不可打無把握之仗。

智慧是汲取自錯誤的教訓，但真正的智慧應該是從他人的錯誤中吸取教訓。Service  Mesh在安全性、高級流量管理乃至可觀察性方面做出了堅實的承諾，但具體實現(xiàn)卻往往復雜萬分。請認真規(guī)劃、做好準備，盡可能走出自己的一條順暢、甚至充滿成就感的探索道路。

感謝各位的閱讀，以上就是“Service Mesh實踐之如何避坑”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對Service Mesh實踐之如何避坑這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！

分享文章：ServiceMesh實踐之如何避坑
分享鏈接：http://muchs.cn/article40/jejjeo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供響應式網(wǎng)站、做網(wǎng)站、Google、品牌網(wǎng)站制作、電子商務、外貿(mào)建站

廣告

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