筆者經(jīng)常聽到的一個問題是：“我真的需要一個服務網(wǎng)格嗎？誠實的回答是“具體情況具體分析”，這取決于收益和成本。但是，在幫助用戶在許多不同的場景中經(jīng)歷了從探索到生產(chǎn)部署的過程之后，筆者很樂意與大家分享在決策過程中需要考慮的因素。
服務網(wǎng)格提供了連接、保護和觀察微服務的一致方式。大多數(shù)服務網(wǎng)格都與編排平臺緊密集成。服務網(wǎng)格需要相關團隊認真學習，這是一個成本，你應該將該成本與可能實現(xiàn)的運維簡化的好處進行權衡。
除了成本和收益，還有什么能決定你是否真的需要一個服務網(wǎng)格？答案是，運行的微服務的數(shù)量，以及緊迫性和時機，都會對你的需求產(chǎn)生影響。
有多少微服務？
如果你正在部署第一個或第二個微服務，筆者認為沒有服務網(wǎng)格也行。你應該首先專注于學習Kubernetes并將無狀態(tài)容器從應用程序中分解出來。你會很自然地慢慢熟悉服務網(wǎng)格可以解決的問題，這將使你在時機成熟時更好地規(guī)劃服務網(wǎng)格的使用。
如果你現(xiàn)有的應用程序架構提供了所需的可觀察性、安全性和彈性，那么你已經(jīng)有了一個很好的起點。對于你來說，問題是何時添加服務網(wǎng)格。我們通?？吹浇M織關注與實用程序代碼相關聯(lián)的工作，以集成每個新的微服務。一旦這項工作變得痛苦，他們就會評估如何使這種集成更加有效。我們提倡使用服務網(wǎng)格來簡化這項工作。
在什么程度上，服務網(wǎng)格的好處明顯大于成本因組織而異。以筆者的經(jīng)驗，團隊通常會意識到，一旦有了5到6個微服務，就需要一個一致的方法。然而，許多用戶在注意到實用程序代碼成本的增加和應用程序之間細微差別的復雜性增加之前，會使用十幾個或更多的微服務。當然，有些組織繼續(xù)擴展，根本不選擇服務網(wǎng)格，而是投資于應用程序庫和工具。另一方面，我們也與那些希望趕在復雜度上升之前引入服務網(wǎng)格的早期客戶合作，在他們擁有6個微服務之前就引入了服務網(wǎng)格。
緊迫性和時機
時機同樣很重要。服務網(wǎng)格的緊迫性取決于組織的挑戰(zhàn)和目標，但也可以由當前的流程或運維狀態(tài)來決定。以下是一些可能會降低或消除使用服務網(wǎng)格的緊迫性的狀態(tài)：
——你的微服務都是由組織中的開發(fā)人員使用一種語言（“monoglot”）編寫的，它們是從一個公共框架構建的。
——你的工程師致力于構建和維護自動構建到每個新微服務中的特定工具。
——你有一個部分或完全單體的架構，其中應用程序邏輯被構建到一個或兩個容器中，而不是幾個容器中。
——在手動集成過程之后，你可以一次發(fā)布或升級所有內容。
——你使用的應用程序協(xié)議不是由現(xiàn)有的服務網(wǎng)格提供的（HTTP、HTTP/2、gRPC）。
另一方面，以下是表明你需要一個服務網(wǎng)格，并且盡早開始評估或采用的信號：
——你使用許多用不同語言編寫的微服務，這些語言可能不遵循通用的架構模式或框架（或者你正在進行語言/框架遷移）。
——你正在整合第三方代碼或與陌生團隊（例如，合作伙伴或并購方）進行交互，并且希望有一個共同的基礎。
——你的組織一直在“重新解決”問題，特別是在實用程序代碼中（筆者最喜歡的示例：證書輪換）。
——你具有跨服務的健壯的安全性、合規(guī)性或可審計性需求。
——你的團隊花在定位或理解問題上的時間比解決問題的時間要多。
這些都意味著，你需要一個服務網(wǎng)格。當應用程序無法向用戶提供高質量的體驗時，你的團隊如何解決它？發(fā)現(xiàn)問題通常是最困難和最昂貴的部分。
接下來呢？
一旦你找到了問題，你能緩解或解決它嗎？如果唯一的解決辦法是開發(fā)新代碼或重建容器，這將是一個痛苦的局面。這就是保持彈性能力獨立于業(yè)務邏輯（如在服務網(wǎng)格中）的好處所在。
如果你熟悉這個局面，那么你可能現(xiàn)在就需要一個服務網(wǎng)格。記住你的成本和收益，并找到以下問題的答案：
——你是不是花太多的時間去找到問題，而不是為用戶開發(fā)和提供價值？
——你的運維和擁有的微服務的數(shù)量是合拍的，還是應該簡化？
——你是否有服務網(wǎng)格可以解決的關鍵問題？
密切關注這些問題的答案將有助于你確定是否以及何時真正需要服務網(wǎng)格。
原文鏈接：
https://thenewstack.io/when-you-do-and-dont-need-a-service-mesh/
