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

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

---

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

覺得服務網格能夠解決您全部基礎架構問題？在您進行投資以前，咱們建議您深刻研究該技術的真實含義，這能幫助您肯定服務網格是否適合您的開發週期，或者是否應該繼續使用。

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

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