看微服務(wù)核心技術(shù)如何演變

在云計(jì)算時(shí)代有三大利器—容器技術(shù)、devops、微服務(wù)，容器技術(shù)如docker、kubernetes幫助我們以最小成本快速部署應(yīng)用程序。devops則是研發(fā)運(yùn)維一體化思想，從管理和技術(shù)上推進(jìn)產(chǎn)品的快速迭代。

微服務(wù)則是互聯(lián)網(wǎng)架構(gòu)經(jīng)歷了從單體架構(gòu)—>集群架構(gòu)—>分布式架構(gòu)的產(chǎn)物，每一次的技術(shù)架構(gòu)升級(jí)背后是新的設(shè)計(jì)理念，用以解決數(shù)據(jù)和業(yè)務(wù)復(fù)雜度增加帶來的技術(shù)問題。

而今天我們要介紹的便是微服務(wù)架構(gòu)的核心技術(shù)的辛酸演變史～

微服務(wù)架構(gòu)的設(shè)計(jì)思想包括服務(wù)原子化、獨(dú)立進(jìn)程、輕量級(jí)通信、獨(dú)立部署、基于業(yè)務(wù)能力，典型的微服務(wù)架構(gòu)如下所示。

將業(yè)務(wù)拆分成了服務(wù)A、服務(wù)B、服務(wù)C，對(duì)于服務(wù)的管理使用服務(wù)配置中心，對(duì)于服務(wù)與服務(wù)之間的發(fā)現(xiàn)使用服務(wù)注冊(cè)中心，對(duì)于服務(wù)如何與客戶端通信采用服務(wù)網(wǎng)關(guān)來實(shí)現(xiàn)身份認(rèn)證、路由等內(nèi)容，其中微服務(wù)的核心技術(shù)無疑是服務(wù)發(fā)現(xiàn)與負(fù)載均衡。試想我們把原來的單體式架構(gòu)從1個(gè)服務(wù)拆分成微服務(wù)（比如10個(gè)），這個(gè)時(shí)候運(yùn)維人員在系統(tǒng)中配置10個(gè)微服務(wù)的名稱，再指定這10個(gè)微服務(wù)的上下游關(guān)系（即如何從一個(gè)微服務(wù)到另外一個(gè)微服務(wù)），這個(gè)還是相對(duì)容易的。

再試想如果把1個(gè)服務(wù)拆分成100個(gè)微服務(wù)，這時(shí)候需要給100個(gè)微服務(wù)命名，還要定義好不同的微服務(wù)之間如何找尋到其它的微服務(wù)，以后如果是某個(gè)微服務(wù)掛掉了或者下線了，還需要去找到這個(gè)微服務(wù)以及解除它所帶來的與其它服務(wù)之間的聯(lián)系，這時(shí)候就有點(diǎn)挑戰(zhàn)了。

再再試想如果把1個(gè)服務(wù)拆分成1000個(gè)微服務(wù)，要定義這1000個(gè)微服務(wù)的名稱，還要定義這1000個(gè)微服務(wù)之間的道路，有個(gè)微服務(wù)掛掉了還得找到它并且解除與它相關(guān)的服務(wù)聯(lián)系，這時(shí)候就是tobe or to die，that’sa question；所以微服務(wù)的核心技術(shù)是服務(wù)發(fā)現(xiàn)與負(fù)載均衡，你服不服？

那么微服務(wù)架構(gòu)是如何來解決服務(wù)之間的配置與發(fā)現(xiàn)問題呢？從服務(wù)演變成微服務(wù)的規(guī)模（1—>10—>100—>1000）以及不同互聯(lián)網(wǎng)公司的現(xiàn)況也有三個(gè)階段的解決方案：

階段1 從1—>10的proxy方案

這個(gè)階段，微服務(wù)的數(shù)量還比較少，不需要關(guān)注微服務(wù)的名稱，采用的解決方案是使用代理proxy—DNS解析&F5硬件負(fù)載均衡&Nginx服務(wù)端負(fù)載均衡。使用DNS建立域名與IP地址之間的映射關(guān)系，使用負(fù)載均衡技術(shù)將客戶端請(qǐng)求根據(jù)配置策略引到不同的微服務(wù)上提供服務(wù)。

階段2 從10—>100的客戶端嵌入式代理

這是目前大部分互聯(lián)網(wǎng)公司的做法，將代理（包括服務(wù)發(fā)現(xiàn)和負(fù)載均衡邏輯）以客戶庫的形式嵌入在服務(wù)中，再結(jié)合單獨(dú)的服務(wù)注冊(cè)中心組件進(jìn)行配合使用，服務(wù)啟動(dòng)時(shí)自動(dòng)到注冊(cè)中心registry進(jìn)行注冊(cè)，并通過定期的心跳請(qǐng)求與registry保持聯(lián)系，而服務(wù)的調(diào)用方（consumer）通過與registry請(qǐng)求獲取服務(wù)地址并放在負(fù)載均衡軟件中。

當(dāng)下比較流行的Spring cloud框架便是這種設(shè)計(jì)模式，使用eureka來做注冊(cè)中心，使用ribbon來進(jìn)行客戶端代理做負(fù)載均衡。

服務(wù)注冊(cè)中心的邏輯流轉(zhuǎn)圖如下所示，服務(wù)A與服務(wù)B在啟動(dòng)時(shí)向服務(wù)注冊(cè)中心上報(bào)自己提供的服務(wù)和IP地址，服務(wù)C告訴服務(wù)注冊(cè)中心自己需要的服務(wù)，獲取服務(wù)地址后進(jìn)行服務(wù)A、服務(wù)B的調(diào)用，同理服務(wù)A與服務(wù)B的調(diào)用也按此進(jìn)行。

服務(wù)配置中心是解決微服務(wù)數(shù)量超過一定程度時(shí)候的問題，因?yàn)樵诿總€(gè)服務(wù)里分別維護(hù)一個(gè)服務(wù)的配置問題，實(shí)在太難了。

通過在配置中心存儲(chǔ)服務(wù)的名字和IP地址，每次發(fā)生服務(wù)調(diào)用時(shí)從該配置中心進(jìn)行獲取，如果服務(wù)的IP地址有所變更，直接更新配置中心即可。

階段3 從100—>1000的service mesh方案

因?yàn)榉桨?是使用負(fù)載均衡來進(jìn)行代理，如果負(fù)載均衡的服務(wù)器掛掉了，那么整個(gè)業(yè)務(wù)就掛掉了，隨著微服務(wù)數(shù)量的增加會(huì)產(chǎn)生問題。

方案2則是客戶端負(fù)載，嵌入了服務(wù)負(fù)載均衡的SDK后，比較難以維護(hù)整個(gè)負(fù)載均衡，加上無法支持多語言，也比較麻煩。這時(shí)候產(chǎn)生的service mesh服務(wù)網(wǎng)格方案便可解決如上的問題。

service mesh服務(wù)網(wǎng)格的核心設(shè)計(jì)思想是sidecar邊車模式（像下圖戰(zhàn)爭時(shí)期摩托車的設(shè)計(jì)一般，主位置是戰(zhàn)斗員，附位置是幫助主駕駛提供彈藥等工作），在每個(gè)微服務(wù)（主進(jìn)程）啟動(dòng)的時(shí)候同時(shí)再啟動(dòng)一個(gè)進(jìn)程，為主進(jìn)程提供支持，并共享生命周期。

在整個(gè)業(yè)務(wù)運(yùn)行的過程中，附進(jìn)程處理服務(wù)之間的通信、服務(wù)注冊(cè)、負(fù)載均衡、認(rèn)證鑒權(quán)、熔斷限流、上報(bào)日志、監(jiān)控的任務(wù)，把階段2的服務(wù)注冊(cè)eureka、服務(wù)網(wǎng)關(guān)zuul、服務(wù)配置中心如etcl的活全干了。目前業(yè)內(nèi)也有些不錯(cuò)的servicemesh落地方案，如linkerd、istio等。

服務(wù)A和服務(wù)B只負(fù)責(zé)業(yè)務(wù)邏輯的處理，而所有的服務(wù)發(fā)現(xiàn)、負(fù)載均衡等工作全由單獨(dú)的進(jìn)程sidecar來進(jìn)行。

因?yàn)槭菃为?dú)的進(jìn)程，所以對(duì)于所有的開發(fā)語言都能支持，只需要主進(jìn)程能與附進(jìn)程保持通信即可。對(duì)于這些sidecar的管理都集中在控制面板controlplane，實(shí)現(xiàn)了集中治理，保障了微服務(wù)的高可靠性。

如果從服務(wù)視角來看，整個(gè)業(yè)務(wù)服務(wù)劃分成微服務(wù)后就如下圖所示，綠色表示微服務(wù)的業(yè)務(wù)邏輯處理，藍(lán)色代表sidecar進(jìn)程處于微服務(wù)之間的通信與負(fù)載均衡，它們鏈接起來后就像網(wǎng)格一樣，這也是服務(wù)網(wǎng)格servicemesh的由來～

其實(shí)在我們的生活中也有類似的場(chǎng)景，在北京地鐵剛開通運(yùn)行時(shí)，每個(gè)換乘站都會(huì)有售票員，根據(jù)用戶要到達(dá)的地方進(jìn)行對(duì)應(yīng)地鐵票的售賣，這時(shí)候的售票員就像微服務(wù)第一階段的proxy，將用戶指引到目的地。

但是隨著地鐵出行越來越方便，大家也越來越喜歡地鐵出行了，地鐵的人流量開始增長，這時(shí)候售票員逐漸的忙不過來了，此時(shí)地鐵站的配置升級(jí)為工作人員+自動(dòng)售票機(jī)，自動(dòng)售票機(jī)呈現(xiàn)了整個(gè)北京地鐵圖情況，用戶根據(jù)自己的出行情況選擇目的地，這時(shí)候的自動(dòng)售票機(jī)就像微服務(wù)第二階段的客戶端嵌入式代理一樣，用戶自己選擇目的地。

而到現(xiàn)在，隨著互聯(lián)網(wǎng)和經(jīng)濟(jì)的快速發(fā)展，北京各地鐵口已升級(jí)為全自動(dòng)售票機(jī)，再也沒有人工售票窗口了，用戶在自動(dòng)售票機(jī)根據(jù)自己的出行情況選擇目的地即可。

如果站在整個(gè)北京市地鐵的宏觀上看，每個(gè)地鐵站全配置自動(dòng)售票機(jī)，地鐵站即我們的微服務(wù)，售票機(jī)即sidecar，整個(gè)配合形成了subwaymesh，在微服務(wù)里即servicemesh～

servicemesh無疑是當(dāng)下微服務(wù)技術(shù)的最好詮釋，它屏蔽了分布式系統(tǒng)的復(fù)雜性，解決了服務(wù)之間復(fù)雜的發(fā)現(xiàn)與調(diào)用過程，讓開發(fā)團(tuán)隊(duì)可專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)，聚焦真正的價(jià)值提供。

就像北京地鐵全升級(jí)為自動(dòng)售票機(jī)一樣，屏蔽了來自全國各地人群語言不一致的復(fù)雜性，解決了購買地鐵票繁瑣的收錢找零充值過程，讓地鐵服務(wù)真正便捷的方便用戶。