微服務2.0時代：Spring Cloud Netflix與 Kubernetes＆Istio比較

第1集：微服務的誕生
回到起源，我們必須回到2015年初，當時“微服務”的概念在西班牙開始變得強勁。微服務的第一個開發堆疊被髮布，也就是取得了相對普及的Netflix堆疊，在第一2015年3月釋出。
今天它仍然是雲端計算的所有解決方案包括Spring中最受關注和最受歡迎的：

另外兩個解決方案（Consul和Zookeeper）使用了與Netflix堆疊的不同元件，Netflix元件包括Zuul ，Ribbon 和Hystrix 。 最初，該架構由以下部分組成：

• 配置伺服器：外部化配置伺服器，允許我們集中生態系統的所有配置。它不是Netflix的一部分（因為Netflix使用的是Archaius），但它是由Spring開發的。
• Eureka ：伺服器，用於註冊微服務和有關它們的後設資料。
• Ribbon：用於在客戶端中平衡請求的庫。它與Eureka通訊以獲得每個微服務的可用例項的暫存器。
• Hystrix ：使用斷路器模式進行級聯錯誤管理的庫。
• Zuul ：將作為API閘道器/邊緣服務的伺服器，作為微服務生態系統的入口點。

第2集：建立
自2015年問世以來，微服務架構迅速變得非常重要，並且隨著時間的推移而逐漸增加。在雲解決方案成功的推動下，作為他們的主要架構解決方案，兩者都在這裡相輔相成。
與任何取得成功的架構或工具一樣，一系列應用程式和其他庫涵蓋了最初未被考慮的功能區域。這就是請求的可追溯性，這是分散式系統中的一種常見需求，它最初沒有超出手動實現的解決方案。

這些和其他需求反映在完成我們生態系統的新庫包中，其中一些是：

• Sleuth：庫允許我們根據標頭的組合在不同的應用程式/微服務之間分佈可請求的請求。
• Zipkin ：儲存臨時資料的伺服器，引用分散式請求進行相關性和延遲研究。
• Contract合同：庫允許我們實施消費者驅動的合同模式，以增加我們的更改不會導致任何API條件中斷的信心。

第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儲存庫的各個分支和/或標籤。

第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測試。
• 執行狀況檢查和負載平衡：控制健康例項並使用不同的可用演算法進行平衡。
• 管理超時和斷路：我們可以配置不同服務的超時以及斷路，重試的配置......
• 故障注入：為了測試我們應用程式的彈性，我們可以插入兩種型別的故障：延遲和取消請求。
• 配額管理：允許您設定呼叫限制。
• 安全性：各種服務之間的安全通訊，基於驗證通訊兩部分的角色的訪問，白名單和黑名單......
• 監控和記錄：記錄，捕獲服務網格指標，分散式可追溯性......