在精彩的軟體容器世界中，當新專案湧現並解決你認為早已解決的問題時，這感覺就像地面在你的腳下不斷地移動。在許多情況下，這些問題很久以前被解決，但現在的雲原生架構正在推動著更大規模的應用程式部署，這就需要新的工具和方法。
微服務就是乙個很好地例子。在此模型下，典型的應用程式或服務將被分解成可以獨立部署的功能模組，這些功能模組能彼此分開擴充套件和維護，並且鏈結在一起時可以提**用或服務的全部功能。
當使用容器來開發微服務時，後一塊可能是棘手的。當它們可能散布在伺服器節點集群中時，並且在它們的例項不斷彈出時，隨後被更新版本替換而下線時，該如何將所有元件部分鏈結起來？在面向服務的架構中（soa），微服務可以被視為進化的繼承者，這種任務類似於企業服務匯流排（ebs）所處理的任務，所以需要的是一種基於雲原生版本的ebs。
這是乙個相對新的開源專案istio旨在填補的工作。它被正式的描述為服務網格，因為它的其中一部分分布在由容器管理的基礎架構中，並且它開始著手於滿足服務發現，負載均衡，訊息路由，遙測和監控，以及必不可少的安全等需求。
istio源自於谷歌和ibm之間的合作，實際上包含了一些現有的元件，特別是由乘車服務公司lyft開發的元件。它以某一種形式存在了至少一年，最終在七月底達到1.0版本的里程碑，這意味著它終於被認為足夠成熟，可以作為生產的一部分基礎架構運作。
ibm研究員兼ibm雲計算首席技術官jason mcgee告訴the next platform，雲原生態系統已基本確定容器作為打包和執行的核心結構，而kubernetes則作為管理容器的編排系統。但mcgee解釋說，還有第三塊拼圖還沒有落地，這就是istio的設計點。
「你如何管理在容器平台上執行的應用程式或服務之間的互動？」mcgee問道。 「如果你正在構建微服務，或者你有一組應用程式，那麼應用程式之間的通訊會產生一大堆有趣的問題。你如何了解誰與誰之間進行對話，如何收集有關應用程式之間通訊的資料，如何保護控制哪些服務可以相互通訊的通訊，以及如何使應用程式安全，尤其是我們今天擁有更多種的動態或分布式架構應用程式，你在公有雲的何處能安放高質量的元件？」
mcgee說他在ibm的團隊幾年前已經開始研究這個問題了，當時他遇到了谷歌的同行並發現他們正走在同一條道路上，但ibm主要關注流量路由，版本控制和a/b測試方面，谷歌則專注於安全和遙測。兩家公司決定合併各自的努力，結果就是istio的產生。
istio由以下元件組成：
envoy，被描述為邊車**，它作為**部署在每個微服務例項旁邊;
mixer，它是乙個核心元件，用於通過envoy**實施策略，並從中收集遙測指標;
pilot，負責配置**;
citadel，是負責頒發證書的集中元件，它也有自己在每個節點的**。
envoy是由lyft開發的元件，被mcgee描述為「一種非常輕量的l4到l7的智慧型路由器」，它捕獲來自與其配對的微服務的所有傳入和傳出通訊，作為一種流量的控制方式，執行策略和收集遙測。pilot是ibm提供的主要元件，可作為部署在基礎架構中的所有envoy**的控制平面。
「如果你想象在乙個服務網格中，你可能有一百個微服務，如果每個都有多個例項，你可能有數百或數千個這些智慧型路由器，你需要一種方法對它們進行全部程式設計，所以istio引入了這個稱為pilot的東西。可以把它想象成程式設計師，所有這些路由器的控制平面。所以你有乙個地方可以通過它來程式設計這個服務網路，然後圍繞資料收集進行遙測，圍繞安全進行證書管理，但從根本上說你可以利用這個智慧型路由層和這個控制平面來管理它。」mcgee解釋道。
istio還有自己的api，允許使用者將其插入現有的後端系統，例如用於日誌記錄和遙測。
根據谷歌的說法，istio的監控功能使使用者能夠測量服務之間的實際流量，例如每秒請求數，錯誤率和延遲，還可以生成依賴關係圖，以便使用者可以看到服務之間如何相互影響。
通過其envoy邊車**，istio還可以在每個服務請求上使用雙向tls身份驗證（mtls），新增傳輸加密並使使用者能夠授權跨基礎架構的每個請求。
istio的目的是，它消除了開發人員擔心例項之間的能否安全通訊，解決了控制哪個例項可以與哪些例項進行通訊，以及提供執行諸如金絲雀部署之類功能等需求。如果是發布新版本的特定微服務的**，最初只更新例項的一部分，直到你對新**執行可靠**到滿意，再更新其他部分。
應該注意的是，其他服務網格平台已經存在，例如開源端的linkerd或conduit，而微軟有一項服務，被稱之為azure service fabric mesh，目前作為其雲平台上的技術預覽。此外，服務網格代表了網路管道上方的抽象層，因此前提是已經為每個容器例項配置了網路介面，ip位址和其他網路屬性。這通常意味著，無論何時建立新的容器例項，部署微服務還將需要乙個單獨的工具來自動配置網路。
然而，ibm希望istio將成為雲原生工具包的標準組成部分，正如kubernetes那樣，kubernetes基於谷歌為自己的內部集群開發的borg和omega技術和其上面的容器層技術。
「從社群的角度來看，我的期望是istio成為架構的預設部分，就像容器和kubernetes已經成為雲原生架構的預設部分一樣。」mcgee說。為此，ibm希望將istio與其公有雲所提供的kubernetes託管服務以及其內部部署的ibm cloud private堆疊整合在一起。
「所以，你現在可以執行istio，我們支援現在平台上執行istio，但期望是在不久的將來，我們將istio內嵌，所以每當使用我們的平台時，istio元件就在那裡，你可以利用它，並且不必負責部署和管理istio本身，只需能夠在應用程式中使用它。」mcgee說。
谷歌已經新增對了istio的支援，儘管只是將其標記為alpha版本，作為託管服務的一部分，該服務在其雲平台上客戶的google kubernetes engine（gke）集群中自動安裝和維護。
istio也獲得了業內其他公司的支援，尤其是red hat，幾年前它重新設計了openshift應用程式平台，以docker容器和kubernetes為基礎。
red hat的istio產品經理brian redbeard harrington表示red hat打算將服務網格整合到openshift中，但red hat希望在正式使用前能看到一些粗糙點的改進，比如支援多租戶技術。
「istio現在的目標是他們所謂的軟多租戶技術，也就是說，我們希望在組織內部可以使用它，以便該組織內的兩個不同的團隊可以使用並信任它，只要沒有乙個組的行為過於惡意，他們就不會影響到彼此的服務。通過我們執行openshift online的方式，我們讓客戶執行我們從未看過的**，並且必須最後安排這兩個客戶並存，這是乙個非常獨特的多租戶挑戰。」harrington解釋道。
「我們需要對這個多租戶有更高的信心; 我們需要對效能和穩定性有更高的信心。 我們還沒有看到任何攪局者，但我們已經看到了可提供很多價值的領域，包括在進行規模測試和一些自動化回歸測試方面，我們還在社群層面貢獻了乙個名為kiali的專案，視覺化的給出了istio的內部運作，這只是我們所提供的產品的一部分。」他補充道。
換句話說，istio是另一種開源工具，可以為那些希望構建雲原生應用程式基礎架構的使用者新增選項選單。像red hat這樣的**商將把它融入他們經過測試和支援的企業平台產品中比如openshift，而其他**商則希望自己混合搭配並構建它。
微軟的Project Tye旨在控制微服務開發
很難使用微服務？借助project tye，microsoft提供了乙個實驗性開發人員工具，旨在使其更易於構建，測試和部署微服務和分布式應用程式。微軟認為，project tye net foundation專案 於5月21日推出，將緩解開發人員在構建與資料庫進行通訊或由相互通訊的多個服務組成的應用...
微服務化之無狀態化與容器化
此文已由作者劉超授權網易雲社群發布。一 為什麼要做無狀態化和容器化 很多應用拆分成微服務，是為了承載高併發，往往乙個程序扛不住這麼大的量，因而需要拆分成多組程序，每組程序承載特定的工作，根據併發的壓力用多個副本公共承擔流量。將乙個程序變成多組程序，每組程序多個副本，需要程式的修改支撐這種分布式的架構...
什麼是DevOps？ 虛擬化 容器 微服務
提到devops這個詞，我相信很多人一定不會陌生。作為乙個熱門的概念，devops近年來頻頻出現在各大技術社群和 的文章中，備受行業大咖的追捧，也吸引了很多吃瓜群眾的圍觀。那麼，devops是什麼呢？有人說它是一種方法，也有人說它是一種工具，還有人說它是一種思想。更有甚者，說它是一種哲學。越說越玄乎...