周兵

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

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

關鍵詞：網(wǎng)絡架構；微服務；分布式；Docker；跨主機通信

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2019）05-0060-03

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

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

1 分布式微服務

1.1 什么是微服務

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

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

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

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

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

1.4 分布式微服務架構

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

2 微服務與Docker容器

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

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

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

3 跨主機網(wǎng)絡通信問題

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

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

3.1 VXLAN封包模式

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

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

3.2 路由模式

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

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

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

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

4.1 案例說明

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

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

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

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

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

noverlay網(wǎng)絡中的容器默認通過與主機之間的bridge訪問物理網(wǎng)絡。

4.2 開放Docker Swarm集群所需的主機端口

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

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主機的抽象為一個邏輯上的主機，它也是一種用于統(tǒng)一管理Docker主機的CLI工具，可用來控制Docker主機。Swarm調(diào)用的是Docker API標準接口，兼容非集群模式的操作指令，比如通過常規(guī)的docker運行命令來啟動容器，Swarm會自動選擇適合的主機來運行相關容器。也就是說，像Compose編排腳本可以在不經(jīng)任何改動的情況下，直接通過Swarm來實現(xiàn)對集群的管理。

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

docker swarm init --advertise-addr

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

docker swarm join ＼

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

192.168.99.100：2377

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

docker node ls

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

4.4 構建Overlay network

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

創(chuàng)建指定子網(wǎng)的Overlay跨主機網(wǎng)絡，也可不指定子網(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 在跨主機的網(wǎng)絡上部署一個服務

docker service create ＼

--replicas 3 ＼

--name my-web ＼

--network my-network ＼

nginx

選項--replicas為微服務應用重復部署的數(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 #擴容集群節(jié)點數(shù)量

4.6 驗證測試

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

docker exec -ti 容器id /bin/bash

使用ping命令測試：

ping 容器name

5 結論

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

1）微服務作為一個Docker容器可以在任意主機上運行；

2）同一主機上可以運行多個相同或不同的微服務；

3）運行在同一個主機上的微服務之間可以相互通信；

4）運行在不同主機上的微服務也可以相互通信；

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

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

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

參考文獻：

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

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

[3] 王福強.springboot揭秘：快速構建微服務體系[M]. 北京：機械工業(yè)出版社，2016.

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

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