為微服務構建服務網格的Istio自身卻走向微服務的反面單體架構 – Christian Posta

事實證明，微服務方法的複雜性無法實現其預期的價值或目標。相反，它違背了這些目標。
對於Istio專案，似乎採用單體架構可以更好地實現這些目標。讓我們仔細看看。

Istio在應用微服務中定位
Istio是一個開源服務網格，其結構類似於具有控制平面和資料平面的其他服務網格實現。資料平面由與每個應用程式例項一起存在並位於請求路徑中的代理組成。控制平面位於請求路徑之外，用於管理和控制資料平面的行為。
從歷史上看，Istio的控制平面是作為可單獨部署的服務實現的，該服務執行以下操作：

• Pilot -核心資料平面配置（xDS）伺服器
• Galley -配置監視，驗證，轉發
• Injector -負責自動注入資料平面並設定載入程式
• Citadel -證書籤名，秘密生成，與CA整合等
• Telemetry -一個“混合器”元件，負責將遙測資料聚合和聯合到各種後端
• Policy -負責執行策略的請求路徑“混合器”元件

微服務的好處
微服務可以透過減少對系統進行更改的摩擦來使組織更快地前進。使用微服務架構，每個服務可能會獨立執行（每個服務都由自己的團隊），並且具有獨立於其他人的自己的釋出節奏/生命週期。這將使開發人員和操作員可以並行移動，從而更快地移動，而無需進行更改的鎖定/同步/協調，這可以減慢部署和功能的更改。
可能進一步細分服務的另一個原因是其使用模式和擴充套件屬性。舉一個簡單的例子，具有大量讀取和寫入操作的服務可能會受益於將讀取與寫入分開，因為讀取可能會佔用更多的記憶體（可能需要更多的快取空間才能使讀取速度更快），而寫入可能會佔用更多的儲存空間或網路。您可以在機器/配額上最佳化服務的讀取部分，以使其能夠獨立擴充套件（更多記憶體），然後在具有SSD或最佳化的EBS / SAN等的其他機器上使服務的寫入部分。
您可能將應用拆分為服務的其他一些原因：

• 安全問題
• 域分組
• 不同的語言最佳化
• 服務的重要性

糾正過程
首先要了解的是誰在開發和操作您的服務體系結構。在Istio社群中，專案中有不同的組成部分，可以在不同的社群工作組中看到。另一方面，下載和操作Istio安裝的角色並不那麼容易構建。實際上，到目前為止，觀察到的是一個小組（甚至一個人）操作Istio控制平面。在某些方面，如果將Istio控制平面作為一組微服務，則可以在較大的SaaS上執行，但效果很好，但是在當前採用的情況下似乎並非如此。
要了解的第二件事就是如何完成釋出，服務可以獨立釋出嗎？在實踐中，Istio的答案在理論上是“肯定的”，事實並非如此。當釋出新版本的Istio時，您需要升級/部署所有控制皮膚元件。
最後，在Istio案例中，您可以問“在各個元件中是否還存在其他不同的縮放變數和安全問題？”而誠實的答案將意識到實際上並沒有。直接從Istio設計文件中獲取istiod：

最後，在Istio案例中，您可以問“在各個元件中是否還存在其他不同的縮放變數和安全問題？”而誠實的答案將意識到實際上並沒有。直接從Istio設計文件中獲取istiod：

正如Istiod設計文件中的潛臺詞所言：“複雜性是萬惡之源，或者：我如何學會不再擔心和愛單體monolith”。

istiod是單體整體monlith的化身，它以更低的複雜度支援了以前發行版的所有功能。請注意，組成先前控制平面的服務仍被實現為專案內的子模組（帶有邊界和合同等），但是操作經驗得到了改善。運維人員現在需要擔心執行和升級單個二進位制檔案還是它們的集合。
對於Istio進入單體控制平面，可以減少大量的複雜性，而這些複雜性永遠不會完全得到回報：

• 僅需一項可部署服務，安裝/升級變得更加容易
• 由於不再需要用於協調服務的配置，因此降低了配置複雜性
• 更容易除錯問題（在一個地方還是所有地方看看）
• 提高效率/減少傳輸，共享快取等的開銷

結論
我很高興看到Istio社群繼續改善其可用性和可操作性特徵。對Istio控制平面進行整體部署對於該專案非常有意義。這對您的專案有意義嗎？如果這樣做，您會考慮嗎？您是否以一種能夠確定更改方法的時間的方式來衡量微服務體系結構（和相關基礎架構）的價值/複雜度比率？