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

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

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

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

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

服務網格不會神奇地使應用程式成為雲原生，它僅是支援。基礎架構來幫助管理微服務，而不會解決不良的微服務拓撲。如果域邊界定義不正確，或者服務過於健談，有狀態或不符合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策略。