昨天寫了一篇<微服務(wù)的時(shí)間和成本去哪兒了>，有人在底下留言：

　　我的回答是：

　　"微服務(wù)可以不用服務(wù)發(fā)現(xiàn)和負(fù)載均衡嗎？它是微服務(wù)一個(gè)核心組件。怎么能說沒有關(guān)系？"

　　我覺得有必要來思考和總結(jié)一下服務(wù)發(fā)現(xiàn)技術(shù)是如何演進(jìn)的。于是周末一通閱讀和消化，希望能掰開揉碎在這里講一下服務(wù)發(fā)現(xiàn)技術(shù)的演進(jìn)歷史。

催生的背景

　　為了提升研發(fā)效能，賦能業(yè)務(wù)規(guī)?；瘎?chuàng)新。不管是一線互聯(lián)網(wǎng)企業(yè)還是傳統(tǒng)互聯(lián)網(wǎng)企業(yè)，將單塊架構(gòu)解耦成微服務(wù)架構(gòu)，已經(jīng)成為企業(yè)目前數(shù)字化轉(zhuǎn)型的一個(gè)大趨勢(shì)。

　　

　　微服務(wù)架構(gòu)下的服務(wù)少則幾個(gè)，幾十個(gè)，多則上百個(gè)，每個(gè)服務(wù)一般都以集群HA的方式進(jìn)行部署。

　　這個(gè)時(shí)候就出現(xiàn)了兩個(gè)問題：

• 一個(gè)是服務(wù)發(fā)現(xiàn)，也就是服務(wù)的消費(fèi)方Consumer如何找到服務(wù)的提供方Provider。

• 另外一個(gè)是負(fù)載均衡，服務(wù)消費(fèi)方如何以負(fù)載策略去訪問服務(wù)當(dāng)中的服務(wù)提供方的實(shí)例。

　　

?通用解決思路~代理(proxy)

　　在服務(wù)發(fā)現(xiàn)演進(jìn)過程中，先后出現(xiàn)了三代服務(wù)發(fā)現(xiàn)解決方案。這三代的核心都是代理，只不過代理在架構(gòu)中出現(xiàn)的位置是不同的。通過在消費(fèi)方和提供方中間增加一層代理，由代理來處理服務(wù)發(fā)現(xiàn)和負(fù)載均衡等功能，消費(fèi)方通過代理間接去訪問服務(wù)實(shí)例。

　　

三代服務(wù)發(fā)現(xiàn)方案

第一代：傳統(tǒng)集中式代理　　

　　

• 該方案比較簡單，在消費(fèi)和提供方中間部署一層代理服務(wù)。

• 常用的集中制代理有硬件負(fù)載均衡器，比如F5/A10；或者軟件的負(fù)載均衡器，比如Nginx，HAPROXY。也可以是軟硬結(jié)合，比如前面是F5，后面是Nginx，這種方法兼顧了配置的靈活性，因?yàn)镹gix比F5更容易配置。

• 這種配置需要引入DNS服務(wù)域名進(jìn)行配合，每個(gè)服務(wù)都要申請(qǐng)注冊(cè)域名，并且每個(gè)域名都要在代理上配置域名和服務(wù)IP的映射關(guān)系。

• DNS和代理的配置一般由運(yùn)維人員手工完成。

　　

• 國內(nèi)外的公司采用這種方式的有ebay，攜程，拍拍貸。

• 缺點(diǎn)是手工配置，效率不高也缺乏靈活性，對(duì)開發(fā)人員不友好。

第二代：客戶端嵌入式代理

　　隨著微服務(wù)和云技術(shù)的興起，企業(yè)對(duì)服務(wù)發(fā)現(xiàn)的效率和靈活性提出了更高的要求，于是出現(xiàn)了第二代方案。

• 該方案將服務(wù)發(fā)現(xiàn)和負(fù)載均衡以客戶庫Library的形式嵌入到應(yīng)用或服務(wù)程序中。

• 該方案需要獨(dú)立的服務(wù)注冊(cè)中心配合，服務(wù)啟動(dòng)的時(shí)候?qū)⒎?wù)自動(dòng)注冊(cè)到中心，并且定期的報(bào)心跳進(jìn)行保活?？蛻舳送ㄟ^服務(wù)注冊(cè)中心發(fā)現(xiàn)服務(wù)的ip列表，通過某種負(fù)載均衡策略選擇某個(gè)服務(wù)進(jìn)行調(diào)用，這種對(duì)開發(fā)人員比較友好，可以做到開發(fā)自助，不需要太多的運(yùn)維介入。

　　這種做法也是很多互聯(lián)網(wǎng)公司的一個(gè)主流，相應(yīng)的開源也很多。比如：

• eureka就是一個(gè)注冊(cè)中心，配套ribbon客戶端代理。

• dubbo和近期開源的nacos

• consul+ribbon

　　

?　　缺點(diǎn)：

• 客戶端依賴語言棧，不同的語言需要開發(fā)不同的客戶端，在微服務(wù)下可能出現(xiàn)的多語言問題，顯然開發(fā)成本太高。

• 另外嵌入式代理也給客戶端增加了復(fù)雜性

第三代：主機(jī)獨(dú)立進(jìn)程方案。

　　隨著容器和云原生技術(shù)的興起，業(yè)界開始探索第三代的解決方案。

　　

　　主機(jī)獨(dú)立進(jìn)程方案是上面兩種方案的折中，代理既不集中部署，也不嵌入在客戶的應(yīng)用程序當(dāng)中，而是作為獨(dú)立的進(jìn)程部署在每個(gè)主機(jī)上，這個(gè)主機(jī)可以是物理的或者虛擬的。一個(gè)主機(jī)上的多個(gè)消費(fèi)者可以共享這個(gè)代理，實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡。

　　第三代結(jié)構(gòu)和第二代是類似的，也需要引入服務(wù)注冊(cè)中心進(jìn)行配合，三代之間只不過代理的位置發(fā)生了變化。

　　這個(gè)方案目前有個(gè)更時(shí)髦的稱謂叫ServiceMesh。

　　

?　　開源產(chǎn)品：Envoy，Linkerd，Istio對(duì)應(yīng)到服務(wù)注冊(cè)中心，當(dāng)然K8S也內(nèi)置支持服務(wù)發(fā)現(xiàn)機(jī)制，也是屬于第三代的主機(jī)獨(dú)立進(jìn)程方案。

K8S服務(wù)發(fā)現(xiàn)機(jī)制

　　考慮到K8S在業(yè)界比較火，而且內(nèi)部服務(wù)發(fā)現(xiàn)機(jī)制比較復(fù)雜，這里獨(dú)立出來就進(jìn)行剖析。

　　

　　如上圖所示，在K8S中一個(gè)服務(wù)是由一組Pod構(gòu)成的服務(wù)集群。

• Pod是K8S當(dāng)中最基本的調(diào)度單位，它相當(dāng)于K8S集群當(dāng)中虛擬機(jī)的概念。

• 每個(gè)Pod都有一個(gè)PodIP，并且相互之間是通過PodIP相互訪問，但是服務(wù)的PodIP在K8S當(dāng)中是不固定的，可能會(huì)變(包括預(yù)期和非預(yù)期)。

• 為了屏蔽這種變化，K8S引入了服務(wù)Service這個(gè)概念，一方面實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡，另一方面屏蔽PodIP可能的變更。

• 在服務(wù)發(fā)布的時(shí)候，K8S會(huì)為每個(gè)服務(wù)分配一個(gè)虛擬的ClusterIP

　　

　　在K8S的worker節(jié)點(diǎn)上，有kubelet和kube-proxy，其中后者是實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)的關(guān)鍵，上面是簡化的服務(wù)發(fā)現(xiàn)流程。

服務(wù)注冊(cè)階段：

其中kubelet負(fù)責(zé)啟動(dòng)Pod服務(wù)實(shí)例--->

啟動(dòng)完成后kubelet會(huì)把Pod的IP列表注冊(cè)到Master節(jié)點(diǎn)上-->

最后通過服務(wù)Service的發(fā)布，K8S會(huì)為服務(wù)分配相應(yīng)的ClusterIP，相關(guān)信息也會(huì)記錄在Master上。

服務(wù)發(fā)現(xiàn)階段：

• kube-proxy會(huì)發(fā)現(xiàn)clusterIP和podIP列表之間的映射關(guān)系，并且修改本地iptables的轉(zhuǎn)發(fā)規(guī)則，進(jìn)行負(fù)載均衡和轉(zhuǎn)發(fā)到對(duì)應(yīng)的PodIP

• 當(dāng)有消費(fèi)者Pod要訪問某個(gè)目標(biāo)服務(wù)實(shí)例Pod的時(shí)候，通過ClusterIP發(fā)起調(diào)用，這個(gè)ClusterIP會(huì)被本地的Iptables機(jī)制截獲，然后進(jìn)行負(fù)載均衡，轉(zhuǎn)發(fā)到指定的Pod實(shí)例。

• 實(shí)際消費(fèi)這Pod也是通過服務(wù)名進(jìn)行訪問ClusterIP，因?yàn)镃lusterIP本身也會(huì)變，為了屏蔽變化，K8S還引入了kubeDNS這個(gè)概念，它通過master可以發(fā)現(xiàn)服務(wù)名和ClusterIP之間的映射關(guān)系。這樣消費(fèi)者Pod通過kubeDNS間接的發(fā)現(xiàn)服務(wù)的ClusterIP。

?比較總結(jié)和選型

　　

　　三種方案各有利弊，沒有絕對(duì)的好壞。他們都有大規(guī)模的成功落地的案例。架構(gòu)師需要在理解這些方案優(yōu)劣的基礎(chǔ)上，根據(jù)企業(yè)的實(shí)際上下文，綜合考量，做出技術(shù)選型。

總結(jié)

以上是生活随笔為你收集整理的服务发现技术是如何演进出来的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。