隨著云計算業(yè)務的快速發(fā)展，國內(nèi)外云計算企業(yè)的專利之爭也愈發(fā)激烈。在云計算這樣的技術(shù)領(lǐng)域，專利儲備往往代表著企業(yè)最新的技術(shù)實力。華云數(shù)據(jù)本期“智匯華云”專欄將針對“淺談微服務架構(gòu)之服務發(fā)現(xiàn)”技術(shù)，與大家共同分享云計算領(lǐng)域的最新技術(shù)。

由于業(yè)務量大幅增長，華云數(shù)據(jù)決定對業(yè)務增長導致不斷臃腫的單體應用進行重構(gòu)，重構(gòu)后的應用選擇微服務架構(gòu)。微服務架構(gòu)最大的優(yōu)勢是語言的開放性，可以根據(jù)業(yè)務場景選擇最合適的語言。另外對于不止一個技術(shù)棧的公司組織架構(gòu)，也能帶來很好的融合協(xié)作機會。華云數(shù)據(jù)的主要技術(shù)棧是JAVA，PHP。JAVA自不必多說，其微服務框架spring cloud對微服務有非常全面且完善的一條龍支持，簡直是微服務架構(gòu)開發(fā)的利器，而PHP則有所欠缺，特別是在服務治理部分。比如在做服務注冊、發(fā)現(xiàn)的時候比較痛苦。

我們的方案

1、為什么要使用服務發(fā)現(xiàn)

下圖1 ，是一個簡單的高可用架構(gòu)圖，我們看到集群組部署有3個節(jié)點，每個節(jié)點分別部署有一個服務A。在它前面有負載均衡，以nginx做負載均衡為例，我們會在配置文件手動配置上這3個節(jié)點的服務A的地址，根據(jù)負載策略做轉(zhuǎn)發(fā)。

圖1

這是傳統(tǒng)上比較常用的方式。服務的地址是固定不變的。那么如果服務的地址彈性伸縮，是可變的又如何呢?如下圖2。

圖2

與傳統(tǒng)方式不同的是，服務的地址是彈性伸縮，是可變的。這種彈性帶來最大的好處是服務可以根據(jù)流量、根據(jù)CPU、內(nèi)存等開銷，依據(jù)一定的策略，橫向擴展或減少服務實例。除了能支撐大量的峰值訪問，還能帶來非常大的成本節(jié)約。另外特別說下，docker及其衍生出來的Kubernates之類的軟件或解決方案，使得這種資源調(diào)度，彈性伸縮，架構(gòu)監(jiān)控等有了很好的基礎(chǔ)層保證?；剡^頭來說，既然服務地址可變，那么人工配置的方式肯定不行，我們需要一種自動發(fā)現(xiàn)服務地址變更的機制。

2、服務發(fā)現(xiàn)的機制及發(fā)現(xiàn)方式

這種機制即服務發(fā)現(xiàn)，也是微服務架構(gòu)最常使用的技術(shù)棧。如下圖 3，我們引入一個注冊中心。服務實例在啟動的時候自動把地址注冊到注冊中心，在訪問相應服務的時候，先通過注冊中心拿到待訪問服務實例的地址，然后依據(jù)一定的策略訪問即可。

圖3

好處主要有兩點：

1、解決上述說的服務地址變化的問題;

2、注冊中心能夠監(jiān)測相應服務的狀態(tài)，有了它，我們就能知道微服務架構(gòu)中有多少個服務，版本是什么，每個服務的實例數(shù)有多少，狀態(tài)如何。

服務發(fā)現(xiàn)有兩種方式：

2.1服務端發(fā)現(xiàn)

1)服務實例啟動時自動發(fā)布地址到注冊中心。

2)客戶端/服務端在調(diào)用某個服務時，帶著服務名調(diào)用負載均衡器，負載均衡器接收到請求，從注冊中心拿到服務地址(有多個)，根據(jù)負載策略訪問某一個特定的服務。

這種方式最大的好處就是由服務端實現(xiàn)服務發(fā)現(xiàn)及負載，客戶端完全不用做額外的事情，非常推薦使用此方式。如下圖4。

圖4

2.2客戶端發(fā)現(xiàn)

從下圖5可以看到，跟服務端發(fā)現(xiàn)不同的地方是，待訪問服務的地址由客戶端從注冊中心獲取，并且客戶端需要實現(xiàn)負載(比如待訪問的服務地址有3個，那么客戶端需要依據(jù)一定的負載策略，找出其中一個地址進行訪問)。

圖5

這種方式最大的特點就是靈活，客戶端或者微服務可以根據(jù)自己的業(yè)務場景選擇最佳的負載策略，但是缺點也是顯而易見的，客戶端或微服務需要考慮負載。這在JAVA沒問題，它的spring cloud框架很強大，可以支持，不過PHP及其它語言就會很痛苦，所以個人推薦使用服務端發(fā)現(xiàn)的方式。

如下圖6方式，服務端發(fā)現(xiàn)可使用consul template+nginx

圖6

3、工具介紹及總結(jié)

Netflix OSS 是典型的客戶端發(fā)現(xiàn)范例;Netflix Eureka 是服務注冊表，Netflix Ribbon是IPC客戶端，與Eureka一起實現(xiàn)CLB。對docker無明確支持

Consul 是典型的服務端發(fā)現(xiàn)范例;通過consul template監(jiān)聽consul中服務地址的變動，自動生成或更新nginx.conf，并生效配置。對docker有很好的支持

微服務架構(gòu)的性質(zhì)決定了它的復雜性，存在成百上千個微服務，而每個微服務又可能分布在多個不同節(jié)點，所以全棧監(jiān)控很重要，而服務發(fā)現(xiàn)則是其中很重要的一環(huán)。通過它，我們就知道整個系統(tǒng)有多少個微服務，版本是什么，每個服務的實例數(shù)有多少，狀態(tài)如何。而這些又是一個完整自動化運維架構(gòu)的基礎(chǔ)，發(fā)揮微服務架構(gòu)最大的價值非常重要，大大減少運維人員在部署、問題排查上冗余工作，大幅提升工作效率。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。