過去五年中，我一直幫助企業進行雲原生的實踐。深入體會到，當應用程序架構成爲迭代的瓶頸時，微服務方法多是合適的，但這不是惟一的方法。web
微服務不是「烏托邦式應用程序體系結構」。後端
關於這個主題，我也出了一本書–《Microservices for Java Developers》。緩存
儘管如今許多組織都已實現微服務架構，但遠離微服務有時多是最好的起點。安全
已經走上了微服務的道路
若是你已經走上了微服務之路，在沒法使用微服務架構時請對本身和組織誠實，這會使你的產品更爲成功。服務器
有時仍是會「回到總體」
出於各類考慮，組織使用了微服務，但有時仍是會「回到總體」。微信
在爲微服務通訊構建服務網格的Istio社區，控制平面的實現將逐漸從微服務方法變爲更加單一的方法。谷歌API基礎架構的首席工程師和架構師路易斯·瑞安（Louis Ryan）在2019年KubeConNA的Istio聚會上，詳細介紹了動機並在設計文檔中介紹了該案例。從Istio 1.5（於2020年2月中旬）開始，咱們就能看到該方法的效果，該方法將先前分配給各類微服務部署的功能合併爲一個守護程序istiod。網絡
咱們知道，Istio是用於幫助解決微服務/雲架構所帶來的挑戰，那麼Istio自身爲什麼會脫離微服務架構？最直接的答案是：架構
事實證實，微服務方法的複雜性沒法實現其預期的價值或目標。相反，它違背了這些目標。app
對於Istio項目，「回到總體」能夠更好地實現這些目標。運維
Istio：微服務架構方式（V1.5以前）
Istio是一個開源服務網格，其結構相似於具備控制平面和數據平面的服務網格實現。數據平面：由與每一個應用程序實例一塊兒存在並位於請求路徑中的代理組成。控制平面：位於請求路徑以外，用於管理和控制數據平面的行爲。
從Istio1.5以前版本上看，Istio的控制平面是可做爲單獨部署的服務，該服務執行如下操做：
Pilot -核心數據平面–配置（xDS）服務器
Galley -配置監視，驗證，轉發
Injector -負責自動注入數據平面並設置引導程序
Citadel -證書籤名，密鑰生成，與CA集成等
Telemetry -一個「混合器」組件，負責將遙測數據聚合，並鏈接各類後端
Policy -負責執行策略的請求路徑「混合器」組件
這些服務將由一組運營商定義的配置來驅動，並進行協調來服務和指導數據平面。
微服務的好處
微服務能夠經過減小對總體系統的修改，來使組織快速迭代。在微服務架構下，每一個服務可能會獨立運行（每一個服務都有本身的團隊），而且具備彼此獨立的發佈節奏/生命週期。這將使開發人員和運維人員能夠並行，而無需鎖定/同步/協調來進行更改，從而提升部署和功能更改的速度。
細分服務的另外一個緣由是其使用模式和擴展屬性。舉一個簡單的例子，須要大量讀取和寫入的服務可能會受益於將讀寫分離，由於讀取可能會佔用更多的內存（可能須要更多的緩存空間才能使讀取速度更快），而寫入可能會佔用更多的存儲空間或網絡。你能夠在機器/配額上擴展更多內存優化服務的讀取部分，而後在具備SSD或EBS / SAN等機器上優化服務的寫入部分。
將應用拆分爲微服務的其餘一些緣由：
安全問題
域分組
不一樣的語言優化
服務的重要性
轉到微服務架構時，第一要權衡的是複雜性。當你從一個事物（總體）變爲一堆小事物，微服務彼此通訊時複雜性就會增長。
若是微服務架構帶給你瞭如上的好處，你有必要權衡下。若是沒有，最好從新評估並糾正。這就是Istio目前正在發生的事情。
Istio1.5：從微服務到單一
首先要了解的是誰在開發和操做你的服務體系結構。在Istio社區中，項目中有不一樣的組成部分，能夠在不一樣的社區工做組中看到。若是以較大規模的SaaS運行，則Istio控制平面做爲一組微服務將能夠很好地工做，可是在目前，狀況彷佛並不是如此。
要了解的第二件事是如何完成發佈？服務能夠獨立發佈嗎？在實踐中，Istio的答案在理論上是「確定的」，事實並不是如此。當發佈新版本的Istio時，你須要升級/部署全部控制面板組件。
最後，在Istio案例中，你能夠問：「各個組件是否存在變量和安全問題的不一樣？」 實際上並無。從Istio設計文檔中能夠看到：
Istio1.5以前，控制平面的成本由單個功能（服務XDS）控制。相比較而言，全部其餘控制平面特徵都具備邊際成本，所以分離的價值很小。
爲了安全起見，全部控制平面服務都具備相同的特權級別：
Istio1.5以前，，經過Webhook， Envoy Bootstrap & Pilot 所行使的權力在許多方面與 Citadel 類似
正如Istiod設計文檔中的潛臺詞所言：「複雜性是萬惡之源，或：我如何學會再也不擔憂和喜歡上總體架構」。
istiod是整體的化身，它以較低的複雜度支持了先前發行版的全部功能。請注意，組成Istio1.5以前版本的控制平面的服務仍被實現爲項目內的子模塊，可是操做經驗獲得了改善。運維人員如今須要擔憂運行和升級單個二進制文件仍是它們的集合。
對於Istio進入單一控制平面，能夠減小大量的複雜性，可是複雜性永遠不會徹底消失：
僅經過一項可部署服務，使安裝/升級變得更加容易
因爲再也不須要用於協調服務的配置，所以下降了配置複雜性
更容易調試問題（在一個地方仍是全部地方看看）
提升效率/減小傳輸，共享緩存等的開銷
有關更多詳細信息，請參見Istiod設計文檔。
結論
很高興看到Istio社區繼續改善其可用性和可操做性。對Istio控制平面進行總體部署對於該項目很是有意義。這對你的項目有意義嗎？若是這樣作，你會考慮嗎？你會在何時衡量微服務體系結構的價值與它帶來複雜性的關係，會不會也要「迴歸總體」？
譯者：王延飛
原文連接：https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/
本文分享自微信公衆號 - K8S中文社區（k8schina）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。