基于分布式微服務(wù)系統(tǒng)的跨主機(jī)通信問題及其解決方案

周兵

摘要：傳統(tǒng)單體式架構(gòu)（Monolithic Architecture）的開發(fā)周期長、難維護(hù)、難測試等特征，越來越難適應(yīng)當(dāng)前互聯(lián)網(wǎng)技術(shù)的發(fā)展需求，這也使得企業(yè)難以推進(jìn)技術(shù)更新。隨著移動互聯(lián)網(wǎng)的發(fā)展，企業(yè)被迫將其應(yīng)用遷移至現(xiàn)代化UI界面架構(gòu)以便能兼容移動設(shè)備，這要求企業(yè)能實現(xiàn)應(yīng)用功能的快速上線；此外，從技術(shù)方面看，云計算及互聯(lián)網(wǎng)公司大量開源輕量級技術(shù)不停涌現(xiàn)并日漸成熟，比如：輕量級開發(fā)技術(shù)的出現(xiàn)如Spring Cloud；新的輕量級協(xié)議如RESTful API和輕量級消息機(jī)制；簡化的基礎(chǔ)設(shè)施如操作系統(tǒng)虛擬化如hypervisors；容器化如Docker，基礎(chǔ)設(shè)施即服務(wù)（IaaS）如Kubernetes等； 新的可替代數(shù)據(jù)持久化模型如NoSQL等；標(biāo)準(zhǔn)化代碼管理如Github等等。這一切都催生了新的架構(gòu)設(shè)計風(fēng)格——微服務(wù)架構(gòu)的出現(xiàn)。

微服務(wù)天生就是分布式的，部署在各個主機(jī)上的服務(wù)系統(tǒng)會面臨跨主機(jī)通信問題，如何設(shè)計一個高效、安全又能適應(yīng)分布式微服務(wù)要求的網(wǎng)絡(luò)架構(gòu)，該文具有一定的指導(dǎo)意義。

關(guān)鍵詞：網(wǎng)絡(luò)架構(gòu)；微服務(wù)；分布式；Docker；跨主機(jī)通信

中圖分類號：TP393 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2019）05-0060-03

傳統(tǒng)單體式架構(gòu)（Monolithic Architecture）的開發(fā)周期長、難維護(hù)、難測試等特征，越來越難適應(yīng)當(dāng)前互聯(lián)網(wǎng)技術(shù)的發(fā)展需求，這也使得企業(yè)難以推進(jìn)技術(shù)更新。隨著移動互聯(lián)網(wǎng)的發(fā)展，企業(yè)被迫將其應(yīng)用遷移至現(xiàn)代化UI界面架構(gòu)以便能兼容移動設(shè)備，這要求企業(yè)能實現(xiàn)應(yīng)用功能的快速上線。此外，從技術(shù)方面看，云計算及互聯(lián)網(wǎng)公司大量開源輕量級技術(shù)不停涌現(xiàn)并日漸成熟，比如：輕量級開發(fā)技術(shù)的出現(xiàn)如Spring Cloud；新的輕量級協(xié)議如RESTful API和輕量級消息機(jī)制；簡化的基礎(chǔ)設(shè)施如操作系統(tǒng)虛擬化如hypervisors；容器化如Docker，基礎(chǔ)設(shè)施即服務(wù)（IaaS）如Kubernetes等；新的可替代數(shù)據(jù)持久化模型如NoSQL等；標(biāo)準(zhǔn)化代碼管理如Github等等。這一切都催生了新的架構(gòu)設(shè)計風(fēng)格——微服務(wù)架構(gòu)的出現(xiàn)。

微服務(wù)天生就是分布式的，部署在各個主機(jī)上的服務(wù)系統(tǒng)會面臨跨主機(jī)通信問題，如何設(shè)計一個高效、安全又能適應(yīng)分布式微服務(wù)要求的網(wǎng)絡(luò)架構(gòu)是當(dāng)前面臨的一個普遍問題。

1 分布式微服務(wù)

1.1 什么是微服務(wù)

“微服務(wù)”源于2014年3月Martin Fowler所寫的一篇文章“Microservices”。微服務(wù)軟件架構(gòu)是一種軟件設(shè)計模式，一種互聯(lián)網(wǎng)軟件系統(tǒng)架構(gòu)，它將單體式應(yīng)用劃分成一些小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供服務(wù)。每個服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級的通信機(jī)制互相溝通（通常是基于HTTP的RESTful API）。每個服務(wù)都圍繞著具體的業(yè)務(wù)功能進(jìn)行構(gòu)建開發(fā)，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境或開發(fā)環(huán)境中。在分布式系統(tǒng)中，還要允許服務(wù)可重復(fù)部署。微服務(wù)是一種架構(gòu)風(fēng)格，一個大型的復(fù)雜的軟件應(yīng)用被切分成一個或多個微服務(wù)組成。系統(tǒng)中的各個微服務(wù)可被獨(dú)立部署運(yùn)行，各個微服務(wù)之間是松耦合的，互不依賴。每個微服務(wù)僅關(guān)注于完成一件任務(wù)或者說一個單一的功能，并能很好地完成該任務(wù)。在所有情況下，每個任務(wù)代表著一個小的業(yè)務(wù)功能。

1.2 單體式架構(gòu)系統(tǒng)

傳統(tǒng)的軟件架構(gòu)是一個項目一個應(yīng)用，這個應(yīng)用不能重復(fù)安裝部署，也就是只能安裝在一臺服務(wù)器上，因此無須考慮對應(yīng)用進(jìn)行多服務(wù)器部署，也就不用考慮各節(jié)點之間的網(wǎng)絡(luò)通信問題。這種架構(gòu)的最大特點是安裝部署簡單，但由于不能橫向擴(kuò)展，需要一般需要性能強(qiáng)勁的專業(yè)服務(wù)器設(shè)備。由于采用單服務(wù)器部署，系統(tǒng)將不可避免地會發(fā)生單點故障，單個服務(wù)器發(fā)生故障的時候會波及整個系統(tǒng)或者網(wǎng)絡(luò)，從而導(dǎo)致整個系統(tǒng)或者網(wǎng)絡(luò)的癱瘓。這種架構(gòu)的缺點很明顯，隨著需求和功能增加，系統(tǒng)將越來越大，功能間的依賴會越來越復(fù)雜，難維護(hù)、擴(kuò)展性差、升級困難。

1.3 分布式架構(gòu)系統(tǒng)

分布式系統(tǒng)架構(gòu)是把一組獨(dú)立主機(jī)劃分為邏輯主機(jī)，同時對外提供服務(wù)，對于用戶來說，邏輯主機(jī)和獨(dú)立主機(jī)都是不可見的，就像是一臺主機(jī)在提供服務(wù)一樣。分布式架構(gòu)的優(yōu)勢之一是可以使用廉價硬件（相對于昂貴的專業(yè)服務(wù)器），另一個優(yōu)勢是提高了系統(tǒng)的可靠性，可擴(kuò)展性。主機(jī)越多，CPU、內(nèi)存、存儲資源等也就越多，能夠處理的用戶并發(fā)訪問量也就越大。比如一個大型網(wǎng)站，一般會把一個網(wǎng)站橫向拆分成很多小功能模塊，然后把不同的功能模塊部署到不同的服務(wù)器上，各個功能模塊之間通過遠(yuǎn)程服務(wù)調(diào)用（RPC）等方式進(jìn)行通信，以一個邏輯主機(jī)的形式對外提供服務(wù)。這些拆分的小功能模塊，也就是微服務(wù)的雛形。

1.4 分布式微服務(wù)架構(gòu)

分布式微服務(wù)架構(gòu)本身是一種去中心化的架構(gòu)，即微服務(wù)是跨機(jī)房、可重復(fù)部署的，是跨機(jī)房負(fù)載均衡的，用戶在訪問這個微服務(wù)的時候，為其提供服務(wù)的主機(jī)和機(jī)房是不確定的，并且微服務(wù)隨時可以在任意不同的服務(wù)商或機(jī)房之間遷移和部署。

2 微服務(wù)與Docker容器

Docker使用Google公司推出的Go語言進(jìn)行開發(fā)實現(xiàn)，基于Linux內(nèi)核對進(jìn)程進(jìn)行封裝隔離，屬于操作系統(tǒng)層面的虛擬化技術(shù)。由于隔離的進(jìn)程獨(dú)立于宿主和其他的隔離的進(jìn)程，因此也稱其為容器。

在Docker技術(shù)出現(xiàn)之前，微服務(wù)架構(gòu)是很難實現(xiàn)的。因為微服務(wù)系統(tǒng)需要一套獨(dú)立的執(zhí)行環(huán)境，這套環(huán)境不能對外部有依賴性。同時，執(zhí)行環(huán)境的粒度又必須足夠的小。Docker在容器的基礎(chǔ)上，進(jìn)行了進(jìn)一步的封裝，極大簡化了容器的創(chuàng)建和維護(hù)，粒度足夠小，是一個很優(yōu)秀的微服務(wù)運(yùn)行環(huán)境。

Docker是一種虛擬化技術(shù)，如何使網(wǎng)絡(luò)中的容器們可以相互通信，又能讓容器外部網(wǎng)絡(luò)的用戶訪問這些容器呢？

3 跨主機(jī)網(wǎng)絡(luò)通信問題

沒有跨主機(jī)網(wǎng)絡(luò)時，比如一個應(yīng)用有兩個服務(wù)，兩個服務(wù)不可能部署到同一個機(jī)器上，這樣沒辦法做到高可用，所在的主機(jī)一旦出現(xiàn)故障，主機(jī)上所有的服務(wù)都將無法訪問。如果將服務(wù)部署到兩個主機(jī)上面，但是兩個主機(jī)上面這個容器的IP在主機(jī)外面是看不到的。所以只能把容器的IP轉(zhuǎn)換成了一個宿主機(jī)的一個IP，或者宿主機(jī)的一個訪問端點，才能讓外部的主機(jī)訪問。所以，傳統(tǒng)方案是通過端口映射，把容器的一個端口映射到主機(jī)的一個端口，讓另外一個主機(jī)和這個主機(jī)映射到這個容器上去通信。這樣會帶來一些問題，首先通過端口映射，比如說映射到8090端口，如果還要啟動另一個容器，就需要映射到另外一個端口，因為宿主機(jī)上只有這一個8090端口，不可能共享同一個端口。映射出去之后是宿主機(jī)的一個端口，這樣這個端口就是對外暴露的，安全性需要嚴(yán)格控制。

在Docker1.9之后，增加了跨主機(jī)的網(wǎng)絡(luò)，它就可以直接通過容器的IP去通信，通過這個外部跟它是隔離的，這樣又能做到安全，啟動多個容器，容器的IP端口也是不會沖突的。

3.1 VXLAN封包模式

VXLAN封包模式，比如overlay驅(qū)動，它是用VXLAN的協(xié)議去把容器之間的請求封裝成VXLAN的請求，將鏈路層的以太網(wǎng)包封裝到UDP包中進(jìn)行傳輸。首先舉個例子，從C1去訪問宿主機(jī)上C2的容器，先通過C1發(fā)出這個包之后，它首先進(jìn)行封包，要查找中心化存儲C2是在哪個主機(jī)上的，查到的是這個主機(jī)上，就把這個請求的包封裝成宿主機(jī)之間的包，把這個包送達(dá)到對應(yīng)宿主機(jī)上，再通過一定的約定去解包，最終轉(zhuǎn)發(fā)到另外一個主機(jī)上的一個容器。其缺點是對帶寬的損耗比較大，因為看到這里去封包，它肯定是把這個容器的包上面又加了一層包，這個包上面肯定會有一些自己的占用，一般像封包模式，MTU最終都會小于宿主機(jī)之間的MTU，它還會造成一些資源占用。比如說在這個地方去封包的時候，它可能會占用CPU去做一下封包操作，還會占用CPU去做解包的操作，所以會增加主機(jī)上的負(fù)載，但是它的好處是對基礎(chǔ)設(shè)施要求比較低，它只需要兩個宿主機(jī)之間可以三層互通。

Docker的overlay驅(qū)動也是封包模式的實現(xiàn)，它的封包方式是基于VXLAN。VXLAN內(nèi)部把一個二層的包、鏈路層的一個請求封裝成一個VXLAN的一個包，這里面會有一個約定的信息，比如VXLAN ID，還有一個外部的UDP的頭，最終會把這個包通過UDP發(fā)往對應(yīng)的主機(jī)上面去，對應(yīng)的主機(jī)再做VXLINE的解包。Docker還會做IP的地址管理和網(wǎng)絡(luò)信息同步。

3.2 路由模式

舉例來說，主機(jī)1上的容器想要訪問主機(jī)2的容器，首先這個機(jī)器上是沒有主機(jī)2的IP地址，它出了機(jī)器之后到達(dá)路由器，再通過路由器上的路由表，去把對應(yīng)的請求網(wǎng)端轉(zhuǎn)發(fā)到對應(yīng)的主機(jī)2上面，主機(jī)2上面是有這個容器的IP，所以它就能夠做到這個容器的跨主機(jī)通信。它的好處在于它沒有封包，所以它的性能很好，但是它對于基礎(chǔ)設(shè)施有一些要求，比如我的基礎(chǔ)設(shè)施要支持、能夠配置這個路由表，如果用Linux路由要支持二層的轉(zhuǎn)發(fā)。

3.3 兩種模式優(yōu)缺點比較

總的來說，二層VLAN網(wǎng)絡(luò)需要二層網(wǎng)絡(luò)設(shè)備支持，通用性和靈活性不如Overlay網(wǎng)絡(luò)。相比之下，Overlay網(wǎng)絡(luò)在不改變現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)設(shè)施的前提下，通過某種約定通信協(xié)議，把二層報文封裝在IP報文之上的新的數(shù)據(jù)格式。能夠充分利用成熟的IP路由協(xié)議進(jìn)程數(shù)據(jù)分發(fā)，突破VLAN的數(shù)量限制，并可將廣播流量轉(zhuǎn)化為組播流量，避免廣播數(shù)據(jù)泛濫。因此，Overlay網(wǎng)絡(luò)實際上是目前最適合的Docker容器跨節(jié)點通信方案。

4 分布式微服務(wù)架構(gòu)系統(tǒng)的跨主機(jī)網(wǎng)絡(luò)通信解決方案與實施

4.1 案例說明

n如圖所示，假設(shè)本地局域網(wǎng)段10.159.62.0/24中存在主機(jī)10.159.62.231，10.159.62.232和10.159.62.233互聯(lián)互通；

n每個主機(jī)上都運(yùn)行Docker引擎，通過Docker運(yùn)行若干個Docker容器，例如圖中的Order，Billing等；

n將這3臺主機(jī)建立成為一個Docker Swarm集群；

n創(chuàng)建一個Docker Overlay網(wǎng)絡(luò)（網(wǎng)段10.10.0.0/24），每個主機(jī)上的容器都被加入該overlay網(wǎng)絡(luò)中，通過overlay網(wǎng)絡(luò)實現(xiàn)跨主機(jī)的容器相互通信；

n假設(shè)Console，Terminal和API這三個服務(wù)均需要暴露端口到物理網(wǎng)絡(luò)，因為物理網(wǎng)絡(luò)10.159.62.0/24無法直接訪問overlay網(wǎng)絡(luò)中的容器，需要容器中映射端口到物理網(wǎng)絡(luò)。

noverlay網(wǎng)絡(luò)中的容器默認(rèn)通過與主機(jī)之間的bridge訪問物理網(wǎng)絡(luò)。

4.2 開放Docker Swarm集群所需的主機(jī)端口

Swarm集群的成員主機(jī)都需要開放集群所需的主機(jī)端口：

firewall-cmd --zone=public --add-port=2377/tcp --permanent

firewall-cmd --zone=public --add-port=7946/tcp --permanent

firewall-cmd --zone=public --add-port=7946/udp --permanent

firewall-cmd --zone=public --add-port=4789/tcp --permanent

firewall-cmd --zone=public --add-port=4789/udp --permanent

firewall-cmd –reload

4.3 創(chuàng)建Docker Swarm集群

Docker Swarm是Docker開源組織提供的Docker環(huán)境集群管理工具，它能夠把若干臺Docker主機(jī)的抽象為一個邏輯上的主機(jī)，它也是一種用于統(tǒng)一管理Docker主機(jī)的CLI工具，可用來控制Docker主機(jī)。Swarm調(diào)用的是Docker API標(biāo)準(zhǔn)接口，兼容非集群模式的操作指令，比如通過常規(guī)的docker運(yùn)行命令來啟動容器，Swarm會自動選擇適合的主機(jī)來運(yùn)行相關(guān)容器。也就是說，像Compose編排腳本可以在不經(jīng)任何改動的情況下，直接通過Swarm來實現(xiàn)對集群的管理。

創(chuàng)建Docker Swarm集群命令：

docker swarm init --advertise-addr

將其他Docker主機(jī)節(jié)點加入Swarm集群中：

docker swarm join ＼

--token SWMTKN-1-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c ＼

192.168.99.100：2377

查看集群所有服務(wù)器節(jié)點：

docker node ls

至此，Docker Swarm集群創(chuàng)建完畢。

4.4 構(gòu)建Overlay network

Swarm上默認(rèn)已有一個名為ingress的Overlay網(wǎng)絡(luò)，也可以自定義創(chuàng)建新的Overlay網(wǎng)絡(luò)。Docker提供給我們兩種方式來定義overlay網(wǎng)絡(luò)，在docker1.12之前，我們需要依靠第三方的工具如Consul、Etcd或者ZooKeeper來實現(xiàn)“服務(wù)發(fā)現(xiàn)”和“DNS解析”，從而實現(xiàn)不同主機(jī)之間的多個容器之間的網(wǎng)絡(luò)通信。但是在docker1.12之后，我們可以直接用Docker原生的swarm來實現(xiàn)“服務(wù)發(fā)現(xiàn)”和“DNS解析”。

創(chuàng)建指定子網(wǎng)的Overlay跨主機(jī)網(wǎng)絡(luò)，也可不指定子網(wǎng)IP，由系統(tǒng)自動指定：

docker network create ＼

--driver overlay ＼

--subnet 10.0.9.0/24 ＼

--gateway 10.0.9.99 ＼

my-network

4.5 在跨主機(jī)的網(wǎng)絡(luò)上部署一個服務(wù)

docker service create ＼

--replicas 3 ＼

--name my-web ＼

--network my-network ＼

nginx

選項--replicas為微服務(wù)應(yīng)用重復(fù)部署的數(shù)量。其他管理命令：

docker service ls 查看集群列表

docker service ps lvs 查看集群下所有節(jié)點狀態(tài)

docker service rm lvs 刪除集群

docker service inspect --pretty lvs 集群屬性

docker service scale lvs=4 #擴(kuò)容集群節(jié)點數(shù)量

4.6 驗證測試

首先進(jìn)入容器內(nèi)部：

docker exec -ti 容器id /bin/bash

使用ping命令測試：

ping 容器name

5 結(jié)論

當(dāng)我們開發(fā)好微服務(wù)之后，考慮到靈活快速持續(xù)部署的需要，通常會考慮將其Docker容器化并在Docker環(huán)境下運(yùn)行。由于微服務(wù)個數(shù)通常會較多，把所有微服務(wù)部署在一臺Docker主機(jī)上是不現(xiàn)實的，因此需要考慮到跨主機(jī)通信的問題，對實際部署必然會提出以下幾點要求：

1）微服務(wù)作為一個Docker容器可以在任意主機(jī)上運(yùn)行；

2）同一主機(jī)上可以運(yùn)行多個相同或不同的微服務(wù)；

3）運(yùn)行在同一個主機(jī)上的微服務(wù)之間可以相互通信；

4）運(yùn)行在不同主機(jī)上的微服務(wù)也可以相互通信；

5）每個微服務(wù)的IP地址不受主機(jī)所在本地局域網(wǎng)IP地址段限制，即擁有獨(dú)立網(wǎng)段，避免占用本地IP地址，同時確保容器數(shù)量受限盡量小；

6）每個微服務(wù)容器避免通過端口暴露的方式相互通信，確保不會因端口獨(dú)占而導(dǎo)致無法靈活部署。

綜上所述，采用在Docker Swarm模式下將各微服務(wù)加入同一個overlay network網(wǎng)絡(luò)的方式實現(xiàn)微服務(wù)之間的跨主機(jī)通信是現(xiàn)實可行的方案。

參考文獻(xiàn)：

[1] 王磊.微服務(wù)架構(gòu)與實踐[M].北京：電子工業(yè)出版社，2016.

[2] sam newman.微服務(wù)設(shè)計[M]. 北京：人民郵電出版社，2016.

[3] 王福強(qiáng).springboot揭秘：快速構(gòu)建微服務(wù)體系[M]. 北京：機(jī)械工業(yè)出版社，2016.

[4] 周立.spring cloud與docker微服務(wù)架構(gòu)實戰(zhàn)[M]. 北京：電子工業(yè)出版社，2017.

【通聯(lián)編輯：代影】