於7月23日在舊金山舉行的谷歌cloud next 2018大會宣布了istio v1.0服務網格的發布日程表。期間，我們看到，這個開源平台的1.0正式版旨在簡化「已部署服務網路的建立，借助負載均衡、服務到服務的身份驗證、監控等，而不需要修改任何服務**」。該版本的主要新特性包括跨集群mesh支援、細粒度流量控制以及在乙個mesh中增量推出mutual tls的能力。
\\ istio是乙個開源平台，可以有效充當envoy**資料平面的控制平面。雖然看上去是谷歌在主導這個專案，但許多其他的組織也在積極貢獻，包括lyft（envoy**的建立者）、ibm、pivotal、思科、紅帽和vmware。
\\ istio控制平面的架構包括用於控制和使用策略的mixer、用於流量管理的pilot和用於身份和證書管理的citadel。通過使用sidecar模式，envoy資料平面和包含在mesh中的服務部署在一起。然後，所有服務到服務的通訊都是通過envoy sidecars攔截，控制平面指定的策略在這裡執行，遙測資料在這裡收集。
istio架構（來自istio文件）
\\ istio 1.0的發布公告指出，該版本比之前的0.8版本增加了多項新特性，此外，istio團隊已經「把許多已有的特性標記為beta，表明它們已經生產就緒」（雖然在這個語境中，twitter上的人們對於「beta」的意思還存在一些爭議）。目前，把istio安裝到kubernetes集群的推薦方法是通過官方的helm chart，雖然文件中還提供了其他選項。對於使用docker和hashicorp consul的系統，也有安裝指南（雖然未經測試，但也有乙份hashicorp nomad安裝指南）。
\\ 現在，多個kubernetes集群可以加到乙個mesh中了，這促成了「跨集群通訊和一致性策略執行」。該特性處於beta階段，安裝說明提醒說，「生產環境可能需要額外的步驟或者更複雜的部署選項。」還有乙個開啟的問題（istio issue #4822），重啟控制平面集群中的任何istio服務pod都會導致遠端集群連線斷開。
\\ networking api是本次發布中的另外乙個beta特性，它可以對通過mesh的流量進行細粒度的控制。文件指出，使用gateways顯式建模入口和出口關注點使操作人員可以「控制網路拓撲，滿足網路邊緣的安全訪問要求」。
\\ 現在，mutual tls（mtls）可以在乙個mesh中增量推出，而不要求所有istio託管的服務一次性公升級。istio身份驗證策略提供了「permissive」模式，可以克服有些服務沒有envoy sidecar支援mtls通訊的問題。一旦啟用這個模式，服務就可以接收http和mutual tls流量了。遷移完成後，為了保證mesh中所有通訊都使用tls，需要刪除permissive模式。
\\ istio mixer現在支援程序外介面卡，使得開發人員可以建立「grpc介面卡」或者「暴露grpc介面的後端」，提供mixer功能，如日誌、監控、定額、acl控制等。發布說明指出，雖然程序外介面卡特性目前還在積極開發中，但在未來的版本中，它會成為擴充套件mixer的預設方式，簡化介面卡的構建。
\\ 控**務訪問的身份驗證策略現在完全在envoy本地判斷，提公升了效能和可靠性。雖然文件中沒有詳細說明，但據推測，這裡對集中式的mixer和每個服務的envoy**之間的資料最終一致性做了一些權衡。關於這一點，文件「mixer和spof迷思」提供了更多的見解。
\\ 發布說明還指出，整個istio社群都在效能和可靠性上付出了巨大的努力，包括連續回歸測試、大規模環境模擬及完成bug修復。這些測試的其他結果會「在未來幾周內詳細分享」。
\\ 官方部落格「istio 1.0發布」指出，多個組織在探索istio的使用，包括ebay、auto trader uk、descartes labs、hp fitstation、juspay、namely、pubnub和trulia。谷歌在公告中指出，「至少有十幾家公司在生產環境中執行istio，其中有幾家在gcp上執行」，其中還援引了auto trader uk基礎設施交付負責人karl stoney**istio如何幫助他們加速向容器和公有雲遷移的一段話：
\\
\\\auto trader uk不僅從私有雲遷移到了公有雲，還從虛擬機器遷移到了kubernetes。istio提供的控制和視覺化水平幫助我們極大降低了這項艱鉅任務的風險。
\
在7月23日的谷歌cloud next大會上，谷歌還宣布了managed istio的alpha版本。這是開源istio的乙個部署，作為雲服務平台的一部分，可以在kubernetes引擎集群上自動安裝和公升級。pivotal也在他們的cloud foundry平台中新增了istio支援，也已提供mtls支援，入口、額外的服務到服務支援以及應用程式安全策略也將很快提供。pivotal istio部落格也談到「重要的抽象」和「最好的技術是人看不到的技術」，並提醒開發人員，在構建旨在為交付業務價值提供支援的軟體和平台時要避免弄錯重點：
\\
\\\開發人員可能會很自然地嘗試同時使用istio和kubernetes，但是，這種額外的操作負擔是要付出代價的。除非你的核心業務是構建和**平台，否則就是在浪費時間和金錢。你最優秀、最聰明的工程師應該增加獨一無二的業務價值，而不是把開源元件連線起來。
\
還有其他一些公司在為istio生態系統做貢獻。可觀測性提供商datadog、solarwinds、sysdig、google stackdriver和amazon cloudwatch已經編寫了外掛程式把istio整合到他們的產品。tigera、cilium和styra已經構建了策略執行和網路功能擴充套件。紅帽還構建了乙個基於web的ui驅動工具kiali，實現服務網格管理和可觀測性。cloud foundry正基於istio構建其下一代流量路由棧，最近宣布的knative無伺服器專案也在做同樣的事，而apigee宣布，他們計畫在其api管理解決方案中使用它。
\\檢視英文原文：istio v1.0 service mesh released with features 「ready for production use」
\\
Istio 服務網格
istio是乙個完全開源的服務網格，作為透明的一層接入到現有的分布式應用程式裡。它也是乙個平台，擁有可以整合任何日誌 遙測和策略系統的 api 介面。istio 多樣化的特性使您能夠成功且高效地執行分布式微服務架構，並提供保護 連線和監控微服務的統一方法。服務網格用來描述組成這些應用程式的微服務網路...
服務網格 前路漫漫
隨著越來越多的公司採用微服務架構，istio linkerd和cilium等服務網格也越來越受關注。服務網格提供了非常有吸引力的特性 全堆疊可觀測性 透明的安全性 系統彈性等。但是，服務網格真的是雲原生應用程式的正確解決方案嗎？本文將討論服務網格在什麼情況下是有意義的，以及什麼時候不應該使用服務網格...
服務網格 Istio和AWS App Mesh
在談論它之前，讓我們先看一下網格到底是什麼 服務網格是微服務體系結構的基礎結構層。它處理服務之間的通訊問題，使該通訊更加可見 或 可觀察 且易於管理。更具體地說，它可以處理諸如服務發現，路由和負載平衡，安全性 例如，加密，tls，身份驗證，授權 之類的事情，並提供錯誤處理 例如重試和斷路 上面提到的...