本文最初發布于 Christian Posta 的個人博客，經原作者授權由 InfoQ 中文站翻譯并分享。
在過去五年，我投入大量精力來幫助企業踏上云原生之旅。很大程度上，對團隊（最終是組織）基于軟件的技術交付速度進行現代化提升受到人員、過程和最終技術決策的影響。當應用程序的架構（由于各種人員 / 流程 / 技術因素）成為修改和“加快速度”的瓶頸時，微服務方法可能會合適，但也不是唯一的方法。
我曾在以前的文章中提到，許多團隊都無法完美地實現它，讓微服務運行需要克服一些“困難”。同時，我還提到一些長遠來看可能對你工作有益的技術。我甚至還寫了一本關于這個主題的書。
開始的時候，最好是遠離微服務，不過現在，許多組織已經遠遠過了這個階段。
你已經走上了微服務之路
如果你真的走上了微服務之路，那么當其不奏效時，不管是對自己還是對公司都要實事求是。改變路線可能才是產品成功的正確步驟。
如果微服務不奏效，要勇于承認
盡管出發點是好的，在你出于正當的理由開始使用微服務后，返回單體架構仍然可能是正確的選擇。如果你做出決策時的假設或上下文發生了變化，那么回到單體架構也“沒關系”。
在 Istio 社區（為微服務通信構建服務網格），控制平面的實現將逐漸從微服務方法轉變為更趨向于單體的方法。在2019 年KubeConNA 的Istio 大會上，谷歌API 基礎架構首席工程師和架構師 Louis Ryan 發表了演講，詳細描述了這樣做的動機，并在設計文檔中介紹了大致的情況。從Istio 1.5 開始，我們應該就可以看到 istiod方法的效果， 以前分配給各種微服務部署的功能將被合并到一個守護進程中。
Istio 用于幫助解決由微服務 / 云架構引入的應用程序網絡難題，那么 Istio 本身為什么要遠離微服務架構呢？最直接的答案是：
事實證明，微服務方法非常復雜，但沒有提供預期的價值或目標。相反，它違背了這些目標。
對于 Istio 項目來說，單體架構似乎能更好地實現這些目標。下面，我們將做進一步地分析。
Istio 以微服務的方式實現
Istio 是一個開源的服務網格，其架構與其他服務網格的實現類似，包括一個控制平面和一個數據平面。數據平面由與每個應用程序實例共存并位于請求路徑中的代理組成。控制平面位于請求路徑之外，用于管理和控制數據平面的行為。
過去，Istio 的控制平面被實現為可單獨部署的服務，它們的用途如下：
- Pilot —— 核心數據平面配置（xDS）服務器
- Galley —— 配置監控、驗證、轉發
- Injector —— 負責自動注入數據平面并設置引導程序
- Citadel —— 證書簽名、Secret 生成、CA 集成
- Telemetry —— 一種“混合器”組件，負責將遙測數據聚合到各種后端
- Policy —— 一個請求路徑“混合器”組件，負責執行策略
這些服務將根據一組操作人員定義的配置，共同提供和管理數據平面。
微服務的好處
微服務可以減少系統更改時的分歧，提升組織速度。在微服務架構中，每個服務可能都是獨立運營的（每個服務都有自己的團隊），并且有獨立于其他服務的發布節奏 / 生命周期。這將使開發人員和運營人員可以并行不悖，而不需要進行鎖定 / 同步 / 協調（這些可能會減慢部署和特性更改的速度），提升了更改速度。
服務可能會被進一步分解的另一個原因是它的使用模式和可伸縮性。舉個簡單的例子，一個具有大量讀寫操作的服務可以從讀寫操作分離中受益，因為讀操作可能會消耗更多的內存（可能需要比較多的緩存空間才能提供超快的讀取速度），而寫操作可能會消耗更多的存儲或網絡。你能在可以獨立伸縮的機器 / 配額上優化服務的讀操作部分（內存更大），然后在其他具有 SSD 或經過優化的 EBS/SAN 的機器上優化服務的寫操作部分。
以下是其他可能讓你將應用分解成服務的原因：
- 安全問題
- 領域劃分
- 不同的語言優化
- 服務的重要性
采用微服務架構的首要代價是復雜性。當你從一個東西（單體）變成一堆相互通信的小東西（針對特定問題進行了優化）時，顯著增加了架構和運行這些東西所需的基礎設施的復雜性。
如果你實現了微服務的好處，那么這可能是一個必要的代價。如果沒有，你最好評估一下你的假設，并改變路線。這就是 Istio 現在的情況。
改變路線
首先，要了解的是誰在開發和運營你的服務架構。在 Istio 社區，項目中不同的組件由不同的社區工作組負責。另一方面，下載和操作 Istio 的人并不是這樣劃分的。事實上，根據到目前為止的觀察，Istio 控制平面是由同一組人（甚至是一個人）操作的。在某種程度上，如果 Istio 控制平面的一組微服務作為一個較大的 SaaS 運行，那么它會工作得很好，但在目前的使用中，情況似乎并非如此。
其次，要了解的是發布是如何完成的？服務可以獨立發布嗎？Istio 的答案是“理論上是”，但實際上似乎不是這樣。Istio 的新版本發布時，需要升級 / 部署所有控制面組件。
最后，在 Istio 的情況下，你可能會問，“對于各種不同的組件，難道沒有不同的伸縮變量和安全考慮嗎？”老實說，并沒有。下面這段話節選自 Istio istiod的設計文檔 ：
然而，對于現在的大多數 Istio 組件來說，情況并非如此——控制平面的成本主要由一個特性（服務于 XDS）決定。相比之下，其他控制平面特性都有邊際成本，因此，分離的價值不大。
出于安全考慮，控制平面的所有服務都有相同的權限等級：
現狀并非如此，Mutating Webhook、Envoy Bootstrap 和 Pilot 的權限在許多方面與 Citadel 相似，因此，對它們進行攻擊造成的傷害幾乎相同。
正如 Istiod 設計文檔的所言：“復雜性是萬惡之源，否則：我怎么能學會不再憂慮并愛上單體”。
istiod是一個單體，它支持以前版本的所有功能，并且顯著降低了復雜性。請注意，以前組成控制平面的服務在項目中仍然是作為子模塊實現（包括邊界和契約等），但操作體驗得到改善。操作人員現在只需要考慮運行和升級單個二進制文件，而不再是一批二進制文件。
對于 Istio 來說，采用單體控制平面，可以大大降低復雜性，而這種復雜性之前并沒有為我們帶來足夠的回報：
- 只有一個服務需要部署，安裝 / 升級變得簡單了
- 配置復雜性降低了，因為不再需要通過配置編排服務
- 問題調式更容易了（只需要在一個地方查找問題，而不是多個地方）
- 提高了效率，降低了數據傳輸開銷、共享緩存，等等
想了解更多信息，請參閱 Istiod 的設計文檔。
另外，你可以觀看我做的istiod方法演示，它應該會出現在 Istio 1.5 中。請注意，該演示使用了 Istio 的 super alpha 版本，所以還不是很完美。
小結
我很高興看到 Istio 社區繼續改進 Istio 的可用性和可操作性。Istio 控制平面的單體部署對這個項目很有意義。這對你的項目有意義嗎？如果是這樣，你會考慮嗎？你是否也會像這樣計算自己的微服務架構（和相關基礎設施）的價值與復雜性比，從而確定變換方法的時間呢？
