基于分布式微服務系統的跨主機通信問題及其解決方案

周兵

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

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

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

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

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

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

1 分布式微服務

1.1 什么是微服務

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

1.2 單體式架構系統

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

1.3 分布式架構系統

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

1.4 分布式微服務架構

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

2 微服務與Docker容器

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

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

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

3 跨主機網絡通信問題

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

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

3.1 VXLAN封包模式

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

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

3.2 路由模式

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

3.3 兩種模式優缺點比較

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

4 分布式微服務架構系統的跨主機網絡通信解決方案與實施

4.1 案例說明

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

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

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

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

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

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

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 創建Docker Swarm集群

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

創建Docker Swarm集群命令：

docker swarm init --advertise-addr

將其他Docker主機節點加入Swarm集群中：

docker swarm join ＼

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

192.168.99.100：2377

查看集群所有服務器節點：

docker node ls

至此，Docker Swarm集群創建完畢。

4.4 構建Overlay network

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

創建指定子網的Overlay跨主機網絡，也可不指定子網IP，由系統自動指定：

docker network create ＼

--driver overlay ＼

--subnet 10.0.9.0/24 ＼

--gateway 10.0.9.99 ＼

my-network

4.5 在跨主機的網絡上部署一個服務

docker service create ＼

--replicas 3 ＼

--name my-web ＼

--network my-network ＼

nginx

選項--replicas為微服務應用重復部署的數量。其他管理命令：

docker service ls 查看集群列表

docker service ps lvs 查看集群下所有節點狀態

docker service rm lvs 刪除集群

docker service inspect --pretty lvs 集群屬性

docker service scale lvs=4 #擴容集群節點數量

4.6 驗證測試

首先進入容器內部：

docker exec -ti 容器id /bin/bash

使用ping命令測試：

ping 容器name

5 結論

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

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

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

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

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

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

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

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

參考文獻：

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

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

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

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

【通聯編輯：代影】