自微服務(wù)架構(gòu)開始興起已近三年多了，早期的Spring Cloud Netflix架構(gòu)已經(jīng)成熟，并已被Spring Cloud整合到解決通常云問題的新解決方案中，例如，Sleuth，Zipkin，Contract等就是這種情況。

但是現(xiàn)在架構(gòu)趨向于朝著不同的方向發(fā)展。在這篇文章中，我們將分析迄今為止微服務(wù)架構(gòu)的路徑以及未來將伴隨我們的工具和技術(shù)。

微服務(wù)的誕生

回到起源，我們必須回到2015年初，當(dāng)時(shí)“微服務(wù)”的概念在西班牙開始變得強(qiáng)勁。微服務(wù)的第一個(gè)開發(fā)堆棧被發(fā)布，也就是取得了相對(duì)普及的Netflix堆棧，在第一2015年3月發(fā)布。

今天它仍然是云計(jì)算的所有解決方案包括Spring中最受關(guān)注和最受歡迎的：

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

配置服務(wù)器：外部化配置服務(wù)器，允許我們集中生態(tài)系統(tǒng)的所有配置。它不是Netflix的一部分（因?yàn)镹etflix使用的是Archaius），但它是由Spring開發(fā)的。

• Eureka ：服務(wù)器，用于注冊(cè)微服務(wù)和有關(guān)它們的元數(shù)據(jù)。

• Ribbon：用于在客戶端中平衡請(qǐng)求的庫(kù)。它與Eureka通信以獲得每個(gè)微服務(wù)的可用實(shí)例的寄存器。

• Hystrix ：使用斷路器模式進(jìn)行級(jí)聯(lián)錯(cuò)誤管理的庫(kù)。

• Zuul ：將作為API網(wǎng)關(guān)/邊緣服務(wù)的服務(wù)器，作為微服務(wù)生態(tài)系統(tǒng)的入口點(diǎn)。

如果現(xiàn)在我們看慣了單體巨石架構(gòu)，這組架構(gòu)似乎變大了，但是解決了分布式架構(gòu)的主要需求：注冊(cè)，集中配置，負(fù)載平衡，抵御失敗...

在部署邏輯上，與微服務(wù)的使用相關(guān)聯(lián)，我們使用容器解決方案進(jìn)行部署，在這種情況下，我們都知道并且是市場(chǎng)上最受歡迎的解決方案：Docker。

另一個(gè)問題是容器編排解決方案。我們是一個(gè)少數(shù)早期采用的OpenShift 3，紅帽解決方案基于Kubernetes，這是在推出2015年6月。

但實(shí)際情況是，當(dāng)時(shí)已經(jīng)有各種容器編排解決方案。當(dāng)然，沒有一個(gè)是非常成熟的，它們?cè)谑袌?chǎng)上也沒有多少占有率。

微服務(wù)的建立

自2015年問世以來，微服務(wù)架構(gòu)迅速變得非常重要，并且隨著時(shí)間的推移而逐漸增加。在云解決方案成功的推動(dòng)下，作為他們的主要架構(gòu)解決方案，兩者都在這里相輔相成。

與任何取得成功的架構(gòu)或工具一樣，一系列應(yīng)用程序和其他庫(kù)涵蓋了最初未被考慮的功能區(qū)域。這就是請(qǐng)求的可追溯性，這是分布式系統(tǒng)中的一種常見需求，它最初沒有超出手動(dòng)實(shí)現(xiàn)的解決方案。

這些和其他需求反映在完成我們生態(tài)系統(tǒng)的新庫(kù)包中，其中一些是：

Sleuth：庫(kù)允許我們根據(jù)標(biāo)頭的組合在不同的應(yīng)用程序/微服務(wù)之間分布可請(qǐng)求的請(qǐng)求。 Zipkin ：存儲(chǔ)臨時(shí)數(shù)據(jù)的服務(wù)器，引用分布式請(qǐng)求進(jìn)行相關(guān)性和延遲研究。 Contract合同：庫(kù)允許我們實(shí)施消費(fèi)者驅(qū)動(dòng)的合同模式，以增加我們的更改不會(huì)導(dǎo)致任何API條件中斷的信心。 此外，演變也隨之而來，不僅僅是一部分了，他們開始為其他功能定義標(biāo)準(zhǔn)堆棧，比如對(duì)記錄和監(jiān)控至關(guān)重要的組件也開始涌現(xiàn)出來。

這時(shí)，用于記錄監(jiān)控這些用途的工具比如（Elasticsearch - Logstash或FluentD - Kibana）成為了這些新的架構(gòu)中不可或缺的部分，增加了它的受歡迎程度。

通過所有這些新工具/庫(kù)包，我們享受了一個(gè)更完整的生態(tài)系統(tǒng)，同時(shí)比現(xiàn)在更加復(fù)雜，它實(shí)際上涵蓋了我們所擁有的所有需求。

另一方面，在微服務(wù)架構(gòu)設(shè)計(jì)中出現(xiàn)了非堵塞的通信需要，當(dāng)時(shí)在沒有一個(gè)純粹的完整性解決辦法的情況下使用Vert.x，后來Spring 5的React提供了支持。

Kubernetes的崛起

正如我們之前評(píng)論的那樣，當(dāng)這些新架構(gòu)出現(xiàn)時(shí)，市場(chǎng)上確實(shí)沒有很多容器編排解決方案。

Kubernetes，Openshift，Docker Swarm，都在2015年的1.0.0版本中出現(xiàn)，2016年的Mesos ...... 在市場(chǎng)上沒有主導(dǎo)解決方案。

隨著時(shí)間的推移，我們看起來似乎是一個(gè)明顯的支配者，那就是Kubernetes，或者基于Kubernetes的Openshift的解決方案。

正因如此，我們已經(jīng)可以發(fā)現(xiàn)管理解決方案Kubernetes 實(shí)現(xiàn)在不同的平臺(tái)：谷歌的Kubernetes引擎，亞馬遜AWS EKS等。

同樣，在帖子開頭討論的一些功能，例如由Ribbon，Eureka和Config Server執(zhí)行的負(fù)載平衡，注冊(cè)，集中配置也可由PaaS提供。那么為什么要使用Spring Cloud Netflix提供的這些功能呢？

這是幾個(gè)客戶經(jīng)常詢問我們的問題。答案很簡(jiǎn)單：在該架構(gòu)的初始階段，市場(chǎng)上沒有建立編排解決方案。

在軟件架構(gòu)中包含這些部分（Eureka，Ribbon ......）使其更加便攜。由于這些服務(wù)包含在工件本身中，因此可以在不同的云解決方案之間移動(dòng)應(yīng)用程序，而無需擔(dān)心這些橫向服務(wù)的耗盡。

同樣，Spring Cloud Netflix提供的解決方案比云解決方案通常提供的解決方案具有更強(qiáng)大的功能。這些是一些額外的功能，提供：

Ribbon 除了允許我們實(shí)現(xiàn)自己的平衡算法之外，還提供不同的平衡算法，這比包含PaaS的典型Round Robin或Random提供了更多的靈活性。 Eureka允許我們 在注冊(cè)表中包含和查閱有關(guān)實(shí)例的其他信息：網(wǎng)址，元數(shù)據(jù)......在PaaS解決方案中，我們通常無法選擇合并到注冊(cè)表中的信息。 Config Server為我們提供了一個(gè)分層的屬性系統(tǒng)，允許我們查閱git存儲(chǔ)庫(kù)的各個(gè)分支和/或標(biāo)簽。 我們擁有一個(gè)具有所有這些可能性的架構(gòu)，但我們沒有充分利用它們，這通常發(fā)生在大多數(shù)客戶端中：它們不需要這種高級(jí)架構(gòu)功能，因?yàn)樗麄冋J(rèn)為可以通過PaaS實(shí)現(xiàn)這些功能。

今天，Kubernetes云解決方案是在市場(chǎng)上占主導(dǎo)地位的PaaS，如果我們想想PaaS理念，那它的目的就是：從較低級(jí)別的功能/資源中抽象出來，以便應(yīng)用程序可以專注于業(yè)務(wù)邏輯。所有這些功能都很清楚，它們不屬于業(yè)務(wù)范圍。

這讓我們分離我們的應(yīng)用程序，也就是我們的業(yè)務(wù)邏輯，這使得系統(tǒng)的各個(gè)層之間更明確的分離性質(zhì)。

這些是Kubernetes可以吸收的Spring Cloud Netflix的結(jié)構(gòu)特征有：

1.注冊(cè)，負(fù)載平衡和健康檢查（eureka和Ribbon）

Kubernetes系統(tǒng)中會(huì)出現(xiàn)的一個(gè)新Pod裝載一個(gè)微服務(wù)，但與Eureka + Ribbon組合不同，負(fù)載平衡不是在客戶端完成的，因此在Kubernetes中應(yīng)用程序不必知道服務(wù)的所有現(xiàn)有實(shí)例（這是通過Eureka客戶端完成的）。

在pod中的應(yīng)用程序知道的是Kubernetes 服務(wù)層，這是一個(gè)凝聚服務(wù)實(shí)例的抽象。通過這種方式，客戶端調(diào)用這個(gè)服務(wù)層，該服務(wù)層將維護(hù)一個(gè)恒定的地址，并且該地址將執(zhí)行特定目標(biāo)實(shí)例的平衡。

Kubernetes還將負(fù)責(zé)定期進(jìn)行健康檢查，以檢查實(shí)例的健康狀況，反過來在Eureka的情況下，是由實(shí)例通知服務(wù)器是否具有正確的可用性。

2.集中配置（配置服務(wù)器）

由于Kubernetes的最新版本有可用的configmaps。這些允許我們將屬性作為環(huán)境變量單獨(dú)存儲(chǔ)為屬性文件（本地或遠(yuǎn)程）。

但是，Kubernetes仍然有一些功能無法覆蓋Spring Cloud Netflix所做的功能，這將無法讓我們完全分離。這些功能是級(jí)聯(lián)錯(cuò)誤管理，網(wǎng)關(guān)API，請(qǐng)求可追溯性......這就是我們進(jìn)入微服務(wù)架構(gòu)的下一個(gè)重要步驟。

新寵的誕生

如果我們考慮微服務(wù)架構(gòu)中給我們帶來最多問題的那部分，大多數(shù)人都同意這些問題都與網(wǎng)絡(luò)有關(guān)。具體而言，一切都與延遲，遠(yuǎn)程調(diào)用失敗的管理，平衡，請(qǐng)求的可追溯性，對(duì)不存在的實(shí)例的調(diào)用或下降有關(guān)...

這些情況下的責(zé)任分為不同的層次。例如，PaaS（或注冊(cè)服務(wù)）負(fù)責(zé)向我們提供健康實(shí)例列表。Hystrix負(fù)責(zé)管理外部呼叫以控制超時(shí)和管理故障情況......

在這個(gè)灰色區(qū)域，嵌套在應(yīng)用層和PaaS之間，在出現(xiàn)更多問題的時(shí)刻，我們將在這里找到微服務(wù)架構(gòu)的新革命。

Istio

Istio是一種服務(wù)網(wǎng)絡(luò)解決方案，基于Google在執(zhí)行大規(guī)模服務(wù)方面的經(jīng)驗(yàn)和良好實(shí)踐。它與IBM和Lift共同開發(fā)，于2017年5月作為Opensource發(fā)布，他們計(jì)劃每個(gè)月發(fā)布一個(gè)版本。

對(duì)于那些不熟悉服務(wù)網(wǎng)格概念的人來說，這里的定義似乎是最好的：

“服務(wù)網(wǎng)格是一個(gè)專用的基礎(chǔ)設(shè)施層，用于使服務(wù)到服務(wù)通信安全，快速和可靠。如果您正在構(gòu)建云本機(jī)應(yīng)用程序，則需要一個(gè)服務(wù)網(wǎng)格“，Blog Buoyant：什么是服務(wù)網(wǎng)格？為什么我需要一個(gè)呢？

Service Mesh是一個(gè)在去年開始大量涌現(xiàn)的概念。這方面的證據(jù)就是Paypal或Ticketmaster這樣擁有大量流量的大公司已經(jīng)在使用它，而且Envoy和Linkerd已經(jīng)是Cloud Native Computing Foundation的一部分。

在討論為什么微服務(wù)世界將要發(fā)生這些大的變化之前，讓我們看看它將如何實(shí)現(xiàn)。

Istio是一種工具，可以收集我們?cè)谄湎聦樱≒aaS）和緊接上方（應(yīng)用程序）中放置的功能，以負(fù)責(zé)管理與網(wǎng)絡(luò)通信相關(guān)的所有內(nèi)容。

實(shí)際上，Istio并沒有引入新的功能，而是將現(xiàn)有的功能移動(dòng)到將要放置的中間層。

為此，它所做的是在我們的應(yīng)用程序旁邊放置一個(gè)代理，它將攔截它們的所有網(wǎng)絡(luò)通信，管理它們以提供可靠性，彈性和安全性。

在我們的應(yīng)用程序旁邊放置此代理稱為sidecar-proxy邊車代理模式。在Kubernetes中，在我們的應(yīng)用程序的容器部署的pod中，部署了一個(gè)帶有這種代理的附加容器，如下圖所示：

Istio 默認(rèn)使用Envoy 作為sidecar-proxy，它將伴隨我們所有的微服務(wù)。還可以將Linkerd用于數(shù)據(jù)平面。

Istio在我們的應(yīng)用程序的單獨(dú)容器中運(yùn)行的事實(shí)導(dǎo)致服務(wù)網(wǎng)格本身和應(yīng)用程序之間的更大分離。

此外，在從Ribbon和Hystrix等庫(kù)中實(shí)現(xiàn)收集功能時(shí)，它可以完全免除應(yīng)用程序?qū)軜?gòu)復(fù)雜性的管理。

在處理與網(wǎng)絡(luò)通信相關(guān)的所有事情時(shí)，Istio為我們提供了大量功能，其中包括：

• 路由請(qǐng)求：我們可以根據(jù)不同的標(biāo)準(zhǔn)，如源應(yīng)用程序，目的，應(yīng)用程序版本，請(qǐng)求頭路由請(qǐng)求......此外，我們可以按百分比獲得的流量或重復(fù)什么可以讓我們金絲雀部署和A / B測(cè)試。

• 運(yùn)行狀況檢查和負(fù)載平衡：控制健康實(shí)例并使用不同的可用算法進(jìn)行平衡。

• 管理超時(shí)和斷路：我們可以配置不同服務(wù)的超時(shí)以及斷路，重試的配置......

• 故障注入：為了測(cè)試我們應(yīng)用程序的彈性，我們可以插入兩種類型的故障：延遲和取消請(qǐng)求。

• 配額管理：允許您設(shè)置呼叫限制。

• 安全性：各種服務(wù)之間的安全通信，基于驗(yàn)證通信兩部分的角色的訪問，白名單和黑名單......

• 監(jiān)控和記錄：記錄，捕獲服務(wù)網(wǎng)格指標(biāo)，分布式可追溯性...... 它可以部署在不同的基礎(chǔ)架構(gòu)上：Kubernetes，基于Eureka或Consul注冊(cè)的環(huán)境以及很快在CloudFoundry和Mesos中注冊(cè)的環(huán)境。

如果我們仔細(xì)研究它的功能，我們會(huì)發(fā)現(xiàn)它收集了Netflix套件的許多職責(zé)：斷路和Hystrix超時(shí)管理，負(fù)載平衡Ribbon區(qū)請(qǐng)求......

此外，Istio與Spring Cloud已經(jīng)使用的一些解決方案集成在一起，就像Zipkin的情況一樣，它可以在使用Eureka作為記錄的環(huán)境中工作。

它還與市場(chǎng)上的其他現(xiàn)有解決方案集成，用于公制存儲(chǔ)，日志記錄，配額管理......例如Prometheus，F(xiàn)luentD，Redis ......

結(jié)束語

最后感謝大家的觀看，以上文章為個(gè)人觀點(diǎn)，如果對(duì)你有幫助，記得關(guān)注點(diǎn)贊轉(zhuǎn)發(fā)支持！