【本人禿頂程序員】微服務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 ......

歡迎你們加入：963,，,944,,,895，免費分享Spring框架、Mybatis框架SpringBoot框架、SpringMVC框架、SpringCloud微服務、Dubbo框架、Redis緩存、RabbitMq消息、JVM調優、Tomcat容器、MySQL數據庫教學視頻及架構學習思惟導圖

寫在最後：

禿頂程序員的不易，看到這裏，點了關注吧！ 點關注，不迷路，持續更新！！！