微服務是否真的需要服務網格？

服務網格通常被視作開發服務的靈丹妙藥，但實際上它僅針對特定的操作、安全性和流量政策，而不是所有領域。

随着企業從整體式服務轉移到微服務和雲原生應用程式，確定項目安全且易于實施至關重要，同時也希望能為開發人員騰出時間來進行更重要的工作。服務網格使得無需在微服務内部重新實作基礎架構邏輯（例如，路由，日志記錄等），進而使其真正地靈活地進行更改。

以為服務網格可以解決您所有基礎架構問題？在您進行投資之前，我們建議您深入研究該技術的真實含義，這能幫助您确定服務網格是否适合您的開發周期，或者是否應該繼續使用。

您無需更改微服務中的任何内容即可實作服務網格。雖然服務網格允許企業在不重寫整個代碼的情況下用基礎結構層改造其應用程式，但您仍需要進行一些更改，特别是如果您在建構應用程式時并沒有考慮到雲原生設計方面的考慮。

服務網格不會神奇地使應用程式成為雲原生，它僅是支援。基礎架構來幫助管理微服務，而不會解決不良的微服務拓撲。如果域邊界定義不正确，或者服務過于健談，有狀态或不符合12個因素，那麼最終将遇到比服務網格所能解決的問題更多的問題。

開發人員仍然有責任確定遵循現代雲原生技術，API管理和DevOps CI / CD最佳實踐，首先使用正确的開發原則來建構微服務。抵制重新建構商品基礎架構元件（記錄和監視）并利用商業或商品OSS項目的沖動，而不是讓每個服務團隊以自治的名義從頭開始建構它。

總體而言，服務網格就像在汽車中擁有最好的儀表闆和控件（例如具有“運動”模式）一樣。但是，如果未為其本身建構引擎（即，它正在管理的微服務），則适合利用服務網格。為了獲得最佳結果，微服務設計需要正确完成，這可能意味着您需要修改已經存在的代碼。

事實上，服務網格無法替代您的API管理需求。服務網格以及諸如Kubernetes之類的編排技術都可以替代某些API管理功能，但并不是所有API管理需求。

API網關是API管理和服務網格之間重疊的主要領域，它引入了入口網關的概念。API網關和服務網格均控制安全性（通路控制和身份驗證），流量管理（速率限制和限制）以及路由到API。

這種重疊是許多開發人員都在努力的問題。甚至Google都必須努力解決其Apigee API管理和Istio服務網格之間的問題。

将運作時委托給入口網關，但要通過Istio Mixer擴充卡将所有政策和密鑰管理路由回Apigee。随着時間的推移，随着這些技術的不斷發展，期望更緊密的內建和更多的重疊。

服務網格實作方面缺乏标準化，盡管一些标準化工作取得進展，但一些供應商建立了自己的網格和自以為是的發行版。例如，Microsoft和HashiCorp正在為該行業開發服務網格接口。

使用服務網格，您還冒着雲供應商将您鎖定在其服務網格中的風險。這與服務網格的最初概念背道而馳，服務網格最初的概念是它可以與多雲一起運作，但是希望标準化将使服務網格能夠真正支援多雲環境。

服務網格需要深入了解底層技術才能實作。盡管服務網格最終将使微服務實作變得輕而易舉，但仍然需要對基礎技術（如Kubernetes，Docker，Istio等）有深入的了解。

對于許多公司而言，很難找到并培養合适的技能。沒有正确的知識和專業知識，最終将導緻服務網格實施不佳。服務網格仍然是一項新興技術，它正在不斷發展和快速發展。作為示例，上述混合器擴充卡已被棄用。

從長遠來看，這種“進行中的工作”有可能減慢您的實施速度，特别是當開發人員在努力提供業務價值的同時，難以跟上服務網格所基于的所有技術的最新發展時。

總體而言，服務網格就是要縮短實作價值的時間和簡化開發的過程，就像中間件以前所做的那樣，但是如果不了解它就跳入技術，弊大于利。

比實施最新技術更重要的是，要對微服務，小型服務以及僅通過立面的服務接口公開的主要功能做出務實的決策。不要試圖煮沸海洋。

在許多情況下，企業應該真正關注的是微服務的API管理和有效的API政策。