隨著云計(jì)算業(yè)務(wù)的快速發(fā)展，國內(nèi)外云計(jì)算企業(yè)的專利之爭也愈發(fā)激烈。在云計(jì)算這樣的技術(shù)領(lǐng)域，專利儲(chǔ)備往往代表著企業(yè)最新的技術(shù)實(shí)力。華云數(shù)據(jù)本期“智匯華云”專欄將針對“淺談微服務(wù)架構(gòu)之服務(wù)發(fā)現(xiàn)”技術(shù)，與大家共同分享云計(jì)算領(lǐng)域的最新技術(shù)。
由于業(yè)務(wù)量大幅增長，華云數(shù)據(jù)決定對業(yè)務(wù)增長導(dǎo)致不斷臃腫的單體應(yīng)用進(jìn)行重構(gòu)，重構(gòu)后的應(yīng)用選擇微服務(wù)架構(gòu)。微服務(wù)架構(gòu)最大的優(yōu)勢是語言的開放性，可以根據(jù)業(yè)務(wù)場景選擇最合適的語言。另外對于不止一個(gè)技術(shù)棧的公司組織架構(gòu)，也能帶來很好的融合協(xié)作機(jī)會(huì)。華云數(shù)據(jù)的主要技術(shù)棧是JAVA，PHP。JAVA自不必多說，其微服務(wù)框架spring cloud對微服務(wù)有非常全面且完善的一條龍支持，簡直是微服務(wù)架構(gòu)開發(fā)的利器，而PHP則有所欠缺，特別是在服務(wù)治理部分。比如在做服務(wù)注冊、發(fā)現(xiàn)的時(shí)候比較痛苦。
我們的方案
1、為什么要使用服務(wù)發(fā)現(xiàn)
下圖1 ，是一個(gè)簡單的高可用架構(gòu)圖，我們看到集群組部署有3個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)分別部署有一個(gè)服務(wù)A。在它前面有負(fù)載均衡，以nginx做負(fù)載均衡為例，我們會(huì)在配置文件手動(dòng)配置上這3個(gè)節(jié)點(diǎn)的服務(wù)A的地址，根據(jù)負(fù)載策略做轉(zhuǎn)發(fā)。
圖1
這是傳統(tǒng)上比較常用的方式。服務(wù)的地址是固定不變的。那么如果服務(wù)的地址彈性伸縮，是可變的又如何呢?如下圖2。
圖2
與傳統(tǒng)方式不同的是，服務(wù)的地址是彈性伸縮，是可變的。這種彈性帶來最大的好處是服務(wù)可以根據(jù)流量、根據(jù)CPU、內(nèi)存等開銷，依據(jù)一定的策略，橫向擴(kuò)展或減少服務(wù)實(shí)例。除了能支撐大量的峰值訪問，還能帶來非常大的成本節(jié)約。另外特別說下，docker及其衍生出來的Kubernates之類的軟件或解決方案，使得這種資源調(diào)度，彈性伸縮，架構(gòu)監(jiān)控等有了很好的基礎(chǔ)層保證。回過頭來說，既然服務(wù)地址可變，那么人工配置的方式肯定不行，我們需要一種自動(dòng)發(fā)現(xiàn)服務(wù)地址變更的機(jī)制。
2、服務(wù)發(fā)現(xiàn)的機(jī)制及發(fā)現(xiàn)方式
這種機(jī)制即服務(wù)發(fā)現(xiàn)，也是微服務(wù)架構(gòu)最常使用的技術(shù)棧。如下圖 3，我們引入一個(gè)注冊中心。服務(wù)實(shí)例在啟動(dòng)的時(shí)候自動(dòng)把地址注冊到注冊中心，在訪問相應(yīng)服務(wù)的時(shí)候，先通過注冊中心拿到待訪問服務(wù)實(shí)例的地址，然后依據(jù)一定的策略訪問即可。
圖3
好處主要有兩點(diǎn)：
1、解決上述說的服務(wù)地址變化的問題;
2、注冊中心能夠監(jiān)測相應(yīng)服務(wù)的狀態(tài)，有了它，我們就能知道微服務(wù)架構(gòu)中有多少個(gè)服務(wù)，版本是什么，每個(gè)服務(wù)的實(shí)例數(shù)有多少，狀態(tài)如何。
服務(wù)發(fā)現(xiàn)有兩種方式：
2.1服務(wù)端發(fā)現(xiàn)
1)服務(wù)實(shí)例啟動(dòng)時(shí)自動(dòng)發(fā)布地址到注冊中心。
2)客戶端/服務(wù)端在調(diào)用某個(gè)服務(wù)時(shí)，帶著服務(wù)名調(diào)用負(fù)載均衡器，負(fù)載均衡器接收到請求，從注冊中心拿到服務(wù)地址(有多個(gè))，根據(jù)負(fù)載策略訪問某一個(gè)特定的服務(wù)。
這種方式最大的好處就是由服務(wù)端實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)及負(fù)載，客戶端完全不用做額外的事情，非常推薦使用此方式。如下圖4。
圖4
2.2客戶端發(fā)現(xiàn)
從下圖5可以看到，跟服務(wù)端發(fā)現(xiàn)不同的地方是，待訪問服務(wù)的地址由客戶端從注冊中心獲取，并且客戶端需要實(shí)現(xiàn)負(fù)載(比如待訪問的服務(wù)地址有3個(gè)，那么客戶端需要依據(jù)一定的負(fù)載策略，找出其中一個(gè)地址進(jìn)行訪問)。
圖5
這種方式最大的特點(diǎn)就是靈活，客戶端或者微服務(wù)可以根據(jù)自己的業(yè)務(wù)場景選擇最佳的負(fù)載策略，但是缺點(diǎn)也是顯而易見的，客戶端或微服務(wù)需要考慮負(fù)載。這在JAVA沒問題，它的spring cloud框架很強(qiáng)大，可以支持，不過PHP及其它語言就會(huì)很痛苦，所以個(gè)人推薦使用服務(wù)端發(fā)現(xiàn)的方式。
如下圖6方式，服務(wù)端發(fā)現(xiàn)可使用consul template+nginx
圖6
3、工具介紹及總結(jié)
Netflix OSS 是典型的客戶端發(fā)現(xiàn)范例;Netflix Eureka 是服務(wù)注冊表，Netflix Ribbon是IPC客戶端，與Eureka一起實(shí)現(xiàn)CLB。對docker無明確支持
Consul 是典型的服務(wù)端發(fā)現(xiàn)范例;通過consul template監(jiān)聽consul中服務(wù)地址的變動(dòng)，自動(dòng)生成或更新nginx.conf，并生效配置。對docker有很好的支持
微服務(wù)架構(gòu)的性質(zhì)決定了它的復(fù)雜性，存在成百上千個(gè)微服務(wù)，而每個(gè)微服務(wù)又可能分布在多個(gè)不同節(jié)點(diǎn)，所以全棧監(jiān)控很重要，而服務(wù)發(fā)現(xiàn)則是其中很重要的一環(huán)。通過它，我們就知道整個(gè)系統(tǒng)有多少個(gè)微服務(wù)，版本是什么，每個(gè)服務(wù)的實(shí)例數(shù)有多少，狀態(tài)如何。而這些又是一個(gè)完整自動(dòng)化運(yùn)維架構(gòu)的基礎(chǔ)，發(fā)揮微服務(wù)架構(gòu)最大的價(jià)值非常重要，大大減少運(yùn)維人員在部署、問題排查上冗余工作，大幅提升工作效率。
申請創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！
