Service Mesh 實踐之避坑指南
Service Mesh已經(jīng)成為微服務(wù)領(lǐng)域的熱門議題，同時也被廣泛視為云原生應(yīng)用程序的指導(dǎo)性架構(gòu)。Service Mesh環(huán)境在理論上能夠增強微服務(wù)通信的流量管理與安全水平，提供關(guān)于應(yīng)用程序運行狀態(tài)的全面情況，但在實踐層面卻往往難于管理、過分復(fù)雜。為了避免掉坑，我們必須采取一系列步驟簡化這個過程。
確定重要事項、規(guī)劃探索旅程
在踏上Service Mesh旅程之前，我們首先需要確定最重要的事項，并由此規(guī)劃探索道路。
對多數(shù)企業(yè)而言，在微服務(wù)之間建立零信任通信已經(jīng)成為一種當(dāng)務(wù)之急，但不同企業(yè)的需求往往不盡相同，有的企業(yè)希望Service Mesh提供高級流量管理功能，有的企業(yè)或希望通過邊車代理強化可觀察性。但無論企業(yè)有哪些需求，都必須首先確定優(yōu)先級，并在起步之前獲得開發(fā)人員、SRE工程師與安全運營（SecOps）團隊的理解與支持，集中精力完成工作。不要指望整個流程能夠一蹴而就，否則Service Mesh的實現(xiàn)之路必然陷入困境。
一旦確定了正確的目標(biāo)優(yōu)先次序，我們即可為Service Mesh旅程建立一份路線圖。作為前進的指引，這份路線圖應(yīng)該列出實施舉措的具體次序，并確定各個步驟該如何與IT及業(yè)務(wù)目標(biāo)保持一致。例如，我們可以對希望增強的可觀察性方向做出排序，用以加快問題解決速度，并改善應(yīng)用程序的正常運行時間，借此超越預(yù)定的流量管理目標(biāo)。通過這種排名，可以專注于解決Service Mesh應(yīng)當(dāng)實現(xiàn)的目標(biāo)、獲取與之對應(yīng)的回報。
明智選擇Service Mesh解決方案
目前市面上存在多種Service Mesh控制平面，不同解決方案之間總有優(yōu)劣差異。在選擇Service Mesh時，請首先保證其能夠支持企業(yè)的運行環(huán)境。如果企業(yè)內(nèi)已經(jīng)部署有Mesos等系統(tǒng)、內(nèi)部專有/遺留架構(gòu)或者特定公有云平臺，請確保選擇的Service Mesh能夠與之兼容。
其次，確定部署哪一種Service Mesh控制平面。雖然各類Service Mesh控制平面都提供相似的基礎(chǔ)功能，但不同方案在功能與成熟度方面總有區(qū)別。要確定Service Mesh的控制平面是否適合企業(yè)的用例，并研究如何設(shè)計整個技術(shù)堆棧。在這些方面，Istio整體表現(xiàn)更好。例如，Istio在服務(wù)雙向TLS方面占據(jù)領(lǐng)先地位，而其他Service Mesh的微服務(wù)零信任實現(xiàn)能力仍然有待提高。
第三，評估企業(yè)的現(xiàn)有技能與資源能夠從容管理多少復(fù)雜性因素。在添加功能時，隨著Service Mesh規(guī)模與集群數(shù)量的增長，整個體系會變得越來越復(fù)雜。我們往往會低估發(fā)展過程中的復(fù)雜度水平，實際上我們很難預(yù)測未來會發(fā)生什么，因此必須設(shè)定極限并留有緩沖。
在選擇Service Mesh時，請關(guān)注這幾個“必要因素”——可觀察性、安全性與流量管理、組織內(nèi)已經(jīng)具備的技能、選擇最佳Service Mesh架構(gòu)等等。另外請詢問自己，企業(yè)是否真的需要為每個pod提供邊車代理，或者是否需要滿足Citrix® Service Mesh lite等替代或變種架構(gòu)的需求。
為意外與復(fù)雜性制定規(guī)劃
無論如何嚴密制定計劃，企業(yè)在實現(xiàn)Service Mesh時總會遇到意外。但這并不是說計劃無用——計劃得越是完善，企業(yè)在應(yīng)對意外時才會更從容。
代理并不是那么透明
有時候，代理的透明度可能相當(dāng)差。一般來說，當(dāng)微服務(wù)嘗試調(diào)用某些并不存在、或者暫時負載壓力較大的資源時，就會引發(fā)超時。但代理的存在會扭曲應(yīng)用超時，導(dǎo)致每項微服務(wù)都誤以為其請求已經(jīng)被即時接收。為此，企業(yè)必須認真調(diào)整應(yīng)用程序中的超時機制。
另外，代理對于HTTP流量同樣不夠透明。很多代理會將HTTP標(biāo)頭轉(zhuǎn)換為小寫形式以保持合規(guī)性、一致性并降低資源消耗。實際上，HTTP/2規(guī)范要求標(biāo)頭必須小寫。如果企業(yè)的應(yīng)用程序仍然通過大小寫來區(qū)分HTTP標(biāo)頭，那么代理的介入很可能破壞其基本功能。請確保代理通信造成的細微差別不致破壞您的應(yīng)用程序，同時著手調(diào)整代理或應(yīng)用程序本體以匹配生態(tài)系統(tǒng)的實際特性。
早測試、勤測試
我們無法預(yù)測未來，也不可能預(yù)見哪些組件會出問題。Service Mesh是一種復(fù)雜的分布式系統(tǒng)，包含大量活動部件，其中每個部件都有可能發(fā)生故障。如果應(yīng)用程序出現(xiàn)問題，我們面對的就是應(yīng)用程序本體、連帶工具乃至其他故障源。為此，大家務(wù)必要逐步實施、持續(xù)監(jiān)控并保證頻繁測試。
為此，企業(yè)需要建立起完備的可觀察性堆棧，具體涵蓋日志記錄、指標(biāo)、分布式跟蹤與服務(wù)圖。分布式跟蹤與服務(wù)圖又是服務(wù)可觀察性中的關(guān)鍵要素。分布式跟蹤能夠監(jiān)控流經(jīng)微服務(wù)架構(gòu)的請求流，通過各個微服務(wù)躍點建立起延遲映射，借此幫助企業(yè)快速解決延遲問題。服務(wù)圖則是各微服務(wù)之間依賴關(guān)系以及運行狀態(tài)的動態(tài)圖形表達，能夠以簡便方式實現(xiàn)環(huán)境可視化并幫助企業(yè)發(fā)現(xiàn)一切問題。
另外需要注意的是，請務(wù)必堅持部署持續(xù)測試，引導(dǎo)項目始終處于正軌之上。大家不妨考慮建立一項端到端24/7全天候測試服務(wù)，用于持續(xù)測試您的微服務(wù)體系。
為大量修訂工作做好準(zhǔn)備
今天的小作坊，明天可能發(fā)展成大企業(yè)，我們必須提前做好準(zhǔn)備。企業(yè)可能需要調(diào)整默認的CPU與內(nèi)存分配機制，盡可能降低資源消耗。同樣的，一旦開始部署Service Mesh，修訂需求就將如潮水般涌來。如果沒有完善的計劃，持續(xù)運作的應(yīng)用程序?qū)⒑芸焐壋鰺o數(shù)個邊車代理，萬萬不可打無把握之仗。
智慧是汲取自錯誤的教訓(xùn)，但真正的智慧應(yīng)該是從他人的錯誤中吸取教訓(xùn)。Service Mesh在安全性、高級流量管理乃至可觀察性方面做出了堅實的承諾，但具體實現(xiàn)卻往往復(fù)雜萬分。請認真規(guī)劃、做好準(zhǔn)備，盡可能走出自己的一條順暢、甚至充滿成就感的探索道路。
