微服務2.0時代：Spring Cloud Netflix與 Kubernetes＆Istio比較
自微服務架構開始興起已近三年多了，早期的Spring Cloud Netflix架構已經成熟，並已被Spring Cloud整合到解決通常雲問題的新解決方案中，例如， Sleuth，Zipkin ， Contract 等就是這種情況。
但是現在架構趨向於朝著不同的方向發展。在這篇文章中，我們將分析迄今為止微服務架構的路徑以及未來將伴隨我們的工具和技術。
第1集：微服務的誕生
回到起源，我們必須回到2015年初，當時“微服務”的概念在西班牙開始變得強勁。微服務的第一個開發堆疊被髮布，也就是取得了相對普及的Netflix堆疊，在 第一2015年3月釋出 。
今天它仍然是雲端計算的所有解決方案包括Spring中最受關注和最受歡迎的：
另外兩個解決方案（ Consul 和Zookeeper）使用了與Netflix堆疊的不同元件，Netflix元件包括Zuul ，Ribbon 和Hystrix 。 最初，該架構由以下部分組成：
- 配置伺服器：外部化配置伺服器，允許我們集中生態系統的所有配置。它不是Netflix的一部分（因為Netflix使用的是Archaius），但它是由Spring開發的。
- Eureka ：伺服器，用於註冊微服務和有關它們的元資料。
- Ribbon： 用於在客戶端中平衡請求的庫 。它與Eureka通訊以獲得每個微服務的可用例項的暫存器。
- Hystrix ：使用 斷路器 模式進行級聯錯誤管理的庫。
- Zuul ：將作為API閘道器/邊緣服務的伺服器，作為微服務生態系統的入口點。
如果現在我們看慣了單體巨石架構，這組架構似乎變大了，但是解決了分散式架構的主要需求：註冊，集中配置，負載平衡，抵禦失敗...
在部署邏輯上，與微服務的使用相關聯，我們使用容器解決方案進行部署，在這種情況下，我們都知道並且是市場上最受歡迎的解決方案： Docker 。
另一個問題是容器編排解決方案。我們是一個少數早期採用的 OpenShift 3 ，紅帽解決方案基於Kubernetes，這是在推出 2015年6月 。
但實際情況是，當時已經有各種容器編排解決方案。當然，沒有一個是非常成熟的，它們在市場上也沒有多少佔有率。
第2集：建立
自2015年問世以來，微服務架構迅速變得非常重要，並且隨著時間的推移而逐漸增加。在雲解決方案成功的推動下，作為他們的主要架構解決方案，兩者都在這裡相輔相成。
與任何取得成功的架構或工具一樣，一系列應用程式和其他庫涵蓋了最初未被考慮的功能區域。這就是請求的可追溯性，這是分散式系統中的一種常見需求，它最初沒有超出手動實現的解決方案。
這些和其他需求反映在完成我們生態系統的新庫包中，其中一些是：
- Sleuth：庫允許我們根據標頭的組合在不同的應用程式/微服務之間分佈可請求的請求。
- Zipkin ：儲存臨時資料的伺服器，引用分散式請求進行相關性和延遲研究。
- Contract合同：庫允許我們實施 消費者驅動的合同模式， 以增加我們的更改不會導致任何API條件中斷的信心。
此外，演變也隨之而來，不僅僅是一部分了，他們開始為其他功能定義標準堆疊，比如對記錄和監控至關重要的元件也開始湧現出來。
這時，用於記錄監控這些用途的工具比如（Elasticsearch - Logstash或FluentD - Kibana）成為了這些新的架構中不可或缺的部分，增加了它的受歡迎程度。
通過所有這些新工具/庫包，我們享受了一個更完整的生態系統，同時比現在更加複雜，它實際上涵蓋了我們所擁有的所有需求。
另一方面，在微服務架構設計中出現了非堵塞的通訊需要，當時在沒有一個純粹的完整性解決辦法的情況下使用Vert.x，後來Spring 5的React提供了支援。
第3集：Kubernetes的崛起
正如我們之前評論的那樣，當這些新架構出現時，市場上確實沒有很多容器編排解決方案。
Kubernetes，Openshift，Docker Swarm，都在2015年的1.0.0版本中出現，2016年的Mesos ...... 在市場上沒有主導解決方案。
隨著時間的推移，我們看起來似乎是一個明顯的支配者，那就是Kubernetes，或者基於Kubernetes的 Openshift 的解決方案。
正因如此，我們已經可以發現管理解決方案Kubernetes 實現在不同的平臺：谷歌的 Kubernetes引擎 ，亞馬遜 AWS EKS 等。
同樣，在帖子開頭討論的一些功能，例如由Ribbon，Eureka和Config Server執行的負載平衡，註冊，集中配置也可由PaaS提供。那麼為什麼要使用Spring Cloud Netflix提供的這些功能呢？
這是幾個客戶經常詢問我們的問題。答案很簡單：在該架構的初始階段，市場上沒有建立編排解決方案。
在軟體架構中包含這些部分（Eureka，Ribbon ......）使其更加便攜。由於這些服務包含在工件本身中，因此可以在不同的雲解決方案之間移動應用程式，而無需擔心這些橫向服務的耗盡。
同樣，Spring Cloud Netflix提供的解決方案比雲解決方案通常提供的解決方案具有更強大的功能。這些是一些額外的功能，提供：
- Ribbon 除了允許我們實現自己的平衡演算法之外，還提供不同的平衡演算法，這比包含PaaS的典型Round Robin或Random提供了更多的靈活性。
- Eureka允許我們 在登錄檔中包含和查閱有關例項的其他資訊：網址，元資料......在PaaS解決方案中，我們通常無法選擇合併到登錄檔中的資訊。
- Config Server為我們提供了一個分層的屬性系統，允許我們查閱git儲存庫的各個分支和/或標籤。
我們擁有一個具有所有這些可能性的架構，但我們沒有充分利用它們，這通常發生在大多數客戶端中：它們不需要這種高階架構功能，因為他們認為可以通過PaaS實現這些功能。
今天，Kubernetes雲解決方案是在市場上占主導地位的PaaS，如果我們想想PaaS理念，那它的目的就是：從較低級別的功能/資源中抽象出來，以便應用程式可以專注於業務邏輯。所有這些功能都很清楚，它們不屬於業務範圍。
這讓我們分離我們的應用程式，也就是我們的業務邏輯，這使得系統的各個層之間更明確的分離性質。
這些是Kubernetes可以吸收的Spring Cloud Netflix的結構特徵有：
1.註冊，負載平衡和健康檢查（eureka和Ribbon）
Kubernetes系統中會出現的一個新Pod裝載一個微服務，但與Eureka + Ribbon組合不同，負載平衡不是在客戶端完成的，因此在Kubernetes中應用程式不必知道服務的所有現有例項（這是通過Eureka客戶端完成的）。
在pod中的應用程式知道的是Kubernetes 服務 層，這是一個凝聚服務例項的抽象。通過這種方式，客戶端呼叫這個服務層，該服務層將維護一個恆定的地址，並且該地址將執行特定目標例項的平衡。
Kubernetes還將負責定期進行健康檢查，以檢查例項的健康狀況，反過來在Eureka的情況下，是由例項通知伺服器是否具有正確的可用性。
2.集中配置（配置伺服器）
由於Kubernetes的最新版本有可用的 configmaps 。這些允許我們將屬性作為環境變數單獨儲存為屬性檔案（本地或遠端）。
但是，Kubernetes仍然有一些功能無法覆蓋Spring Cloud Netflix所做的功能，這將無法讓我們完全分離。這些功能是級聯錯誤管理，閘道器API，請求可追溯性......這就是我們進入微服務架構的下一個重要步驟。
第4集：街區新生兒
如果我們考慮微服務架構中給我們帶來最多問題的那部分，大多數人都同意這些問題都與網路有關。具體而言，一切都與延遲，遠端呼叫失敗的管理，平衡，請求的可追溯性，對不存在的例項的呼叫或下降有關...
這些情況下的責任分為不同的層次。例如，PaaS（或註冊服務）負責向我們提供健康例項列表。Hystrix負責管理外部呼叫以控制超時和管理故障情況......
在這個灰色區域，巢狀在應用層和PaaS之間，在出現更多問題的時刻，我們將在這裡找到微服務架構的新革命。
Istio
Istio 是一種服務網路解決方案，基於Google在執行大規模服務方面的經驗和良好實踐。它與IBM和Lift共同開發，於2017年5月作為Opensource釋出，他們計劃每個月釋出一個版本。
對於那些不熟悉服務網格概念的人來說，這裡的定義似乎是最好的：
“服務網格是一個專用的基礎設施層，用於使服務到服務通訊安全，快速和可靠。如果您正在構建雲本機應用程式，則需要一個服務網格“，Blog Buoyant： 什麼是服務網格？為什麼我需要一個呢？
Service Mesh 是一個在去年開始大量 湧現 的概念。這方面的證據就是Paypal或Ticketmaster這樣擁有大量流量的大公司已經在使用它，而且 Envoy 和 Linkerd 已經是 Cloud Native Computing Foundation的一部分 。
在討論為什麼微服務世界將要發生這些大的變化之前，讓我們看看它將如何實現。
Istio是一種工具，可以收集我們在其下層（PaaS）和緊接上方（應用程式）中放置的功能，以負責管理與網路通訊相關的所有內容。
實際上，Istio並沒有引入新的功能，而是將現有的功能移動到將要放置的中間層。
為此，它所做的是在我們的應用程式旁邊放置一個代理，它將攔截它們的所有網路通訊，管理它們以提供可靠性，彈性和安全性。
在我們的應用程式旁邊放置此代理稱為sidecar-proxy邊車代理模式。在Kubernetes中，在我們的應用程式的容器部署的pod中，部署了一個帶有這種代理的附加容器，如下圖所示：
Istio 預設使用Envoy 作為sidecar-proxy，它將伴隨我們所有的微服務。還可以 將Linkerd用於資料平面 。
Istio在我們的應用程式的單獨容器中執行的事實導致服務網格本身和應用程式之間的更大分離 。
此外，在從Ribbon和Hystrix等庫中實現收集功能時，它可以完全免除應用程式對架構複雜性的管理。
在處理與網路通訊相關的所有事情時，Istio為我們提供了大量功能，其中包括：
- 路由請求：我們可以根據不同的標準，如源應用程式，目的，應用程式版本，請求頭路由請求......此外，我們可以按百分比獲得的流量或重複什麼可以讓我們 金絲雀部署 和 A / B測試 。
- 執行狀況檢查和負載平衡：控制健康例項並使用不同的可用演算法進行平衡。
- 管理超時和斷路：我們可以配置不同服務的超時以及斷路，重試的配置......
- 故障注入：為了測試我們應用程式的彈性，我們可以插入兩種型別的故障：延遲和取消請求。
- 配額管理：允許您設定呼叫限制。
- 安全性：各種服務之間的安全通訊，基於驗證通訊兩部分的角色的訪問，白名單和黑名單......
- 監控和記錄：記錄，捕獲服務網格指標，分散式可追溯性......
它可以部署在不同的基礎架構上：Kubernetes，基於Eureka或Consul註冊的環境以及很快在CloudFoundry和Mesos中註冊的環境。
如果我們仔細研究它的功能，我們會發現它收集了Netflix套件的許多職責：斷路和Hystrix超時管理，負載平衡Ribbon區請求......
此外，Istio與Spring Cloud已經使用的一些解決方案整合在一起，就像Zipkin的情況一樣，它可以在使用Eureka作為記錄的環境中工作。
它還與市場上的其他現有解決方案整合，用於公制儲存，日誌記錄，配額管理......例如Prometheus，FluentD，Redis ......