如何進(jìn)行容器SDN技術(shù)與微服務(wù)架構(gòu)實(shí)踐

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)如何進(jìn)行容器SDN技術(shù)與微服務(wù)架構(gòu)實(shí)踐 ，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

關(guān)于SDN和容器

作為近年來(lái)比較熱的一個(gè)概念，眾所周知SDN是Software Defined Network的縮寫，即軟件定義網(wǎng)絡(luò)。但不同的人對(duì)SDN有不同的理解。在廣義上，只要是你通過(guò)軟件實(shí)現(xiàn)了一個(gè)東西，然后那個(gè)東西能夠靈活地去達(dá)到網(wǎng)絡(luò)上面的部署和伸縮，這就可以被認(rèn)為是SDN。在后文中會(huì)對(duì)Flannel、Calico、Weave這三個(gè)解決方案進(jìn)行分析，并從控制層和轉(zhuǎn)發(fā)層來(lái)著重探討它們的技術(shù)實(shí)現(xiàn)，雖然它們并沒(méi)有宣稱自己是SDN的解決方案。

由于容器技術(shù)給傳統(tǒng)的虛擬化網(wǎng)絡(luò)提出了一些新的挑戰(zhàn)，所以圍繞Docker產(chǎn)生了很多不同的網(wǎng)絡(luò)解決方案，以彌補(bǔ)Docker在這些方面的不足。

圍繞容器的開(kāi)源的SDN解決方案

Docker自己的網(wǎng)絡(luò)方案比較簡(jiǎn)單，就是每個(gè)宿主機(jī)上會(huì)跑一個(gè)非常純粹的Linux Bridge，這個(gè)Bridge可以認(rèn)為是一個(gè)二層的交換機(jī)，但它的能力有限，只能做一些簡(jiǎn)單的學(xué)習(xí)和轉(zhuǎn)發(fā)。然后出來(lái)的流量，出網(wǎng)橋的流量會(huì)走IPTABLES，做NAT的地址轉(zhuǎn)換，然后靠路由轉(zhuǎn)發(fā)去做一個(gè)宿主之間的通信。但是當(dāng)真正用它的網(wǎng)絡(luò)模型部署一個(gè)比較復(fù)雜的業(yè)務(wù)時(shí)，會(huì)存在很多問(wèn)題，比如容器重啟之后IP就變了；或者是由于每臺(tái)宿主機(jī)會(huì)分配固定的網(wǎng)段，因此同一個(gè)容器遷到不同宿主機(jī)時(shí)，它的IP可能會(huì)發(fā)生變化，因?yàn)樗窃诓煌木W(wǎng)段；同時(shí)，NAT的存在會(huì)造成兩端在通訊時(shí)看到對(duì)方的地址是不真實(shí)的，因?yàn)樗籒AT過(guò)；并且NAT本身也是有性能損耗等。這些問(wèn)題都對(duì)使用Docker自己的網(wǎng)絡(luò)方案造成了障礙。

Flannel

圖1

Flannel是CoreOS團(tuán)隊(duì)針對(duì)Kubernetes設(shè)計(jì)的一個(gè)覆蓋網(wǎng)絡(luò)（Overlay Network）工具，如圖1所示。它們的控制平面其實(shí)很簡(jiǎn)單，如圖2所示。

圖2

每個(gè)機(jī)器上面的Flannel進(jìn)程會(huì)監(jiān)聽(tīng)ETCD，向ETCD申請(qǐng)每個(gè)節(jié)點(diǎn)可用的IP地址段，并且從ETCD拿到其他所有宿主機(jī)的網(wǎng)段信息，這樣它就可以做一些路由。對(duì)于它的轉(zhuǎn)發(fā)平面（圖3）——轉(zhuǎn)發(fā)平面主要表現(xiàn)數(shù)據(jù)流的流向——它在Docker進(jìn)來(lái)的網(wǎng)橋基礎(chǔ)之上，又創(chuàng)建了一個(gè)新的叫VXLAN的設(shè)備（圖4），VXLAN是一個(gè)隧道的方案，它可以把一個(gè)二層的包，前面加一個(gè)包頭，然后再把整個(gè)包作為物理網(wǎng)絡(luò)的一個(gè)包，去物理網(wǎng)絡(luò)里面去路由，流轉(zhuǎn)。

圖3

圖4

為什么會(huì)要有這個(gè)東西呢？因?yàn)橥ǔＬ摂M網(wǎng)絡(luò)的IP和MAC在物理的網(wǎng)絡(luò)其實(shí)是不認(rèn)識(shí)的。因?yàn)樽R(shí)別IP需要物理網(wǎng)絡(luò)支持，這個(gè)其實(shí)是個(gè)隧道的方案。

總結(jié)一下Flannel方案，可以看出它并沒(méi)有實(shí)現(xiàn)隔離，并且它也是按照網(wǎng)段做IP分配，即一個(gè)容器從一臺(tái)主機(jī)遷到另外一臺(tái)主機(jī)的時(shí)候，它的地址一定會(huì)變化。

Calico

圖5

Calico的思路比較新，如圖5所示。它把每個(gè)操作系統(tǒng)的協(xié)議棧認(rèn)為是一個(gè)路由器，然后把所有的容器認(rèn)為是連在這個(gè)路由器上的網(wǎng)絡(luò)終端，在路由器之間跑標(biāo)準(zhǔn)的路由協(xié)議——BGP的協(xié)議，然后讓它們自己去學(xué)習(xí)這個(gè)網(wǎng)絡(luò)拓?fù)湓撊绾无D(zhuǎn)發(fā)。所以Calico方案其實(shí)是一個(gè)純?nèi)龑拥姆桨?，也就是說(shuō)讓每臺(tái)機(jī)器的協(xié)議棧的三層去確保兩個(gè)容器，跨主機(jī)容器之間的三層連通性。對(duì)于控制平面（圖6），它每個(gè)節(jié)點(diǎn)上會(huì)運(yùn)行兩個(gè)主要的程序，一個(gè)是它自己的叫Felix，左邊那個(gè)，它會(huì)監(jiān)聽(tīng)ECTD中心的存儲(chǔ)，從它獲取事件，比如說(shuō)用戶在這臺(tái)機(jī)器上加了一個(gè)IP，或者是分配了一個(gè)容器等。接著會(huì)在這臺(tái)機(jī)器上創(chuàng)建出一個(gè)容器，并將其網(wǎng)卡、IP、MAC都設(shè)置好，然后在內(nèi)核的路由表里面寫一條，注明這個(gè)IP應(yīng)該到這張網(wǎng)卡。綠色部分是一個(gè)標(biāo)準(zhǔn)的路由程序，它會(huì)從內(nèi)核里面獲取哪一些IP的路由發(fā)生了變化，然后通過(guò)標(biāo)準(zhǔn)BGP的路由協(xié)議擴(kuò)散到整個(gè)其他的宿主機(jī)上，讓外界都知道這個(gè)IP在這里，你們路由的時(shí)候得到這里來(lái)。

圖6

關(guān)于Calico這里討論一個(gè)問(wèn)題，因?yàn)樗艿氖羌內(nèi)龑拥膮f(xié)議，所以其實(shí)它對(duì)物理架構(gòu)有一定的侵入性。Calico官方稱，你可以跑在一個(gè)大二層的網(wǎng)絡(luò)里面。所謂大二層就是沒(méi)有任何三層的網(wǎng)關(guān)，所有的機(jī)器、宿主機(jī)、物理機(jī)在二層是可達(dá)的。這個(gè)方案其實(shí)有一定的弊端，事實(shí)上在很多有經(jīng)驗(yàn)的網(wǎng)絡(luò)工程師眼里，一個(gè)大二層其實(shí)是一個(gè)單一的故障率，也就是說(shuō)任何一個(gè)都會(huì)有一定的硬件風(fēng)險(xiǎn)會(huì)讓整個(gè)大二層癱瘓。

另外，Calico跑在了一個(gè)三層網(wǎng)關(guān)的物理網(wǎng)絡(luò)上時(shí)，它需要把所有機(jī)器上的路由協(xié)議和整個(gè)物理網(wǎng)絡(luò)里面的路由器的三層路全部用BGP打通。這其實(shí)會(huì)帶來(lái)一個(gè)問(wèn)題，這里的容器數(shù)量可能是成千上萬(wàn)的，然后你讓所有物理的路由學(xué)習(xí)到這些知識(shí)，其實(shí)會(huì)給物理集群里的BGP路由帶來(lái)一定的壓力，這個(gè)壓力我雖然沒(méi)有測(cè)過(guò)，但據(jù)專業(yè)的網(wǎng)絡(luò)工程師告知，當(dāng)網(wǎng)絡(luò)端點(diǎn)數(shù)達(dá)到足夠大的時(shí)候，它自我學(xué)習(xí)和發(fā)現(xiàn)拓?fù)湟约笆諗康倪^(guò)程是需要很多的資源和時(shí)間的。

轉(zhuǎn)發(fā)平面（圖7）是Calico的優(yōu)點(diǎn)。因?yàn)樗羌內(nèi)龑拥霓D(zhuǎn)發(fā)，中間沒(méi)有任何的NAT，沒(méi)有任何的overlay，所以它的轉(zhuǎn)發(fā)效率可能是所有方案中最高的，因?yàn)樗陌苯幼咴鶷CP/IP的協(xié)議棧，它的隔離也因?yàn)檫@個(gè)棧而變得好做。因?yàn)門CP/IP的協(xié)議棧提供了一整套的防火墻的規(guī)則，所以它可以通過(guò)IPTABLES的規(guī)則達(dá)到比較復(fù)雜的隔離邏輯。

圖7

Weave

圖8

Weave方案比較有趣，如圖8所示。首先它會(huì)在每臺(tái)機(jī)器上跑一個(gè)自己寫的Router程序起到路由器的作用，然后在路由器之間建立一個(gè)全打通的PC連接，接著在這張TCP的連接網(wǎng)里面互相跑路由協(xié)議，形成一個(gè)控制平面（圖9）?？梢钥闯?，它的控制平面和Calico一致，而轉(zhuǎn)發(fā)平面（圖10）則是走隧道的，這一點(diǎn)和Flannel一致，所以Weave被認(rèn)為是結(jié)合了Flannel和Calico這兩個(gè)方案的特點(diǎn)。

圖9

圖10

圖11所示是它的服務(wù)發(fā)現(xiàn)與負(fù)載均衡的一個(gè)簡(jiǎn)單的方案，它在每個(gè)容器會(huì)起兩個(gè)網(wǎng)卡，一個(gè)網(wǎng)卡連著自己起的可以跟其他宿主機(jī)聯(lián)通的網(wǎng)橋；另一個(gè)網(wǎng)卡綁在原生Docker的一個(gè)網(wǎng)橋上，并在這個(gè)網(wǎng)橋上監(jiān)聽(tīng)一個(gè)DNS的服務(wù)，這個(gè)DNS實(shí)際上嵌在Router里面，即它可以從Router里學(xué)習(xí)到一些服務(wù)的后端的一些配置。所以這時(shí)容器如果發(fā)起DNS查詢，實(shí)際上會(huì)被路由導(dǎo)到宿主機(jī)上，DNS Server上，然后DNS server做一些響應(yīng)。它們官方負(fù)載均衡也是靠這個(gè)，但是這其實(shí)是一個(gè)短板，因?yàn)槲覀兏蛴谒膶踊蛘呤瞧邔痈?xì)的負(fù)載均衡。

在隔離方面，Weave的方案比較粗糙，只是子網(wǎng)級(jí)的隔離（圖12）。比如說(shuō)有兩個(gè)容器都處在10.0.1-24網(wǎng)段，那么它會(huì)在所有的容器里面加一條路由說(shuō)該網(wǎng)段會(huì)走左邊的網(wǎng)橋出去，但是所有非此網(wǎng)段的流量會(huì)走Docker0，這個(gè)時(shí)候Docker0和其他是不聯(lián)通的，所以它就達(dá)到一個(gè)隔離的效果。

圖11

圖12

三個(gè)方案總結(jié)

總結(jié)一下：

1. Flannel僅僅作為單租戶的容器互聯(lián)方案還是很不錯(cuò)的，但需要額外的組件去實(shí)現(xiàn)更高級(jí)的功能，例如服務(wù)發(fā)現(xiàn)與負(fù)載均衡。

2. Calico有著良好的性能和隔離策略，但其基于三層轉(zhuǎn)發(fā)的原理對(duì)物理架構(gòu)可能會(huì)有一定的要求和侵入性。

3. Weave自帶DNS，一定程度上能解決服務(wù)發(fā)現(xiàn)，但因隔離功能有限，若作為多租戶的聯(lián)通方案還稍加欠缺。

4. 另外，Calico和Weave都使用了路由協(xié)議作為控制面，而自主路由學(xué)習(xí)在大規(guī)模網(wǎng)絡(luò)端點(diǎn)下的表現(xiàn)其實(shí)是未經(jīng)驗(yàn)證的，曾咨詢過(guò)相關(guān)的網(wǎng)絡(luò)工程師，大規(guī)模端點(diǎn)的拓?fù)溆?jì)算和收斂往往需要一定的時(shí)間和計(jì)算資源。

七牛的具體實(shí)踐

業(yè)務(wù)需求

七牛實(shí)際上一直在擁抱容器帶來(lái)的變革，擁抱新型的微服務(wù)架構(gòu)理念。所以構(gòu)建了一套容器平臺(tái)，這么做的目的，一方面想推進(jìn)通過(guò)將已有業(yè)務(wù)容器化簡(jiǎn)化研發(fā)和上線流程，另一方面也想通過(guò)這個(gè)方式去滿足用戶的一些計(jì)算需求，畢竟計(jì)算和數(shù)據(jù)離得越近越好。

所以我們業(yè)務(wù)上對(duì)網(wǎng)絡(luò)的需求是：

1. 首先一點(diǎn)，是能夠運(yùn)行在底層異構(gòu)的基礎(chǔ)網(wǎng)絡(luò)上，這一點(diǎn)對(duì)于推進(jìn)已有業(yè)務(wù)的容器化來(lái)說(shuō)是很重要的，否則會(huì)涉及到基礎(chǔ)網(wǎng)絡(luò)的大規(guī)模變更，這是無(wú)法接受的。

2. 我們?cè)噲D構(gòu)造一個(gè)對(duì)容器遷移友好的網(wǎng)絡(luò)結(jié)構(gòu)，允許容器在必要情況下發(fā)生調(diào)度。

3. 我們認(rèn)為服務(wù)發(fā)現(xiàn)和負(fù)載均衡對(duì)業(yè)務(wù)來(lái)說(shuō)是個(gè)基礎(chǔ)而普適的需求，尤其是在倡導(dǎo)微服務(wù)架構(gòu)的今天，一個(gè)設(shè)計(jì)良好的組件應(yīng)該是可水平伸縮的，因此對(duì)于組件的調(diào)用方，服務(wù)發(fā)現(xiàn)和負(fù)載均衡是非常必要的功能。當(dāng)然有人會(huì)說(shuō)這個(gè)功能和網(wǎng)絡(luò)層無(wú)關(guān)，而應(yīng)由應(yīng)用層去實(shí)現(xiàn)，這個(gè)說(shuō)法挺有道理，但后面我會(huì)講到由網(wǎng)絡(luò)層直接支持這兩個(gè)功能的好處。

4. 為了滿足七牛本身已有的一些對(duì)隔離有要求的服務(wù)，并滿足上層更豐富的權(quán)限模型和業(yè)務(wù)邏輯，我們?cè)噲D將隔離性做的更加靈活。

在這幾個(gè)需求的驅(qū)動(dòng)下，我們最終嘗試跳出傳統(tǒng)網(wǎng)絡(luò)模型的束縛，嘗試去構(gòu)造一個(gè)更加扁平而受控的網(wǎng)絡(luò)結(jié)構(gòu)。

轉(zhuǎn)發(fā)平面

首先，在轉(zhuǎn)發(fā)層面，為了包容異構(gòu)的基礎(chǔ)網(wǎng)絡(luò)，我們選擇了使用Open vSwitch構(gòu)造L2 overlay模型，通過(guò)在OVS之間聯(lián)通vxlan隧道來(lái)實(shí)現(xiàn)虛擬網(wǎng)絡(luò)的二層互通。如圖13所示。但隧道通常是有計(jì)算成本的，隧道需要對(duì)虛擬二層幀進(jìn)行頻繁解封包動(dòng)作，而通用的cpu其實(shí)并不擅長(zhǎng)這些。我們通過(guò)將vxlan的計(jì)算量offload到硬件網(wǎng)卡上，從而將一張萬(wàn)兆網(wǎng)卡的帶寬利用率從40%提升到95%左右。

選擇overlay的另一個(gè)理由是，據(jù)我們目前所了解到，當(dāng)下硬件的設(shè)備廠商在對(duì)SDN的支持上通常更偏向于overlay模型。

圖13

控制平面

而在控制層面，我們思考了容器和傳統(tǒng)虛機(jī)的一些不同：

前面提到，微服務(wù)架構(gòu)下，每個(gè)容器的職責(zé)相對(duì)虛機(jī)來(lái)說(shuō)更加細(xì)化和固定，而這會(huì)造成容器與容器間的依賴關(guān)系也相對(duì)固定。那么每臺(tái)宿主機(jī)上的容器可能產(chǎn)生的outbound其實(shí)也是可推演的。如果進(jìn)一步想的話，其實(shí)推演出來(lái)的理論范圍通常會(huì)遠(yuǎn)大于容器實(shí)際產(chǎn)生的 outbound。所以我們嘗試使用被動(dòng)的方式實(shí)現(xiàn)控制指令的注入。因此我們引入了OpenFlow作為控制面的協(xié)議。OpenFlow作為目前SDN 控制平面的協(xié)議標(biāo)準(zhǔn)，它有著很強(qiáng)的表達(dá)能力。從包匹配的角度看，它幾乎可匹配包頭中的任意字段，并支持多種流老化策略。此外，擴(kuò)展性也很好，支持第三方的 Vendor 協(xié)議，可以實(shí)現(xiàn)標(biāo)準(zhǔn)協(xié)議中無(wú)法提供的功能OpenFlow可以按Table組織流表，并可在表間跳轉(zhuǎn)（這一點(diǎn)其實(shí)和IPTABLES很像，但OpenFlow的語(yǔ)義會(huì)更加豐富）。配合OpenFlow的這種Table組織方式，可以實(shí)現(xiàn)相對(duì)復(fù)雜的處理邏輯。如圖14所示。

圖14

選擇了OpenFlow，我們的控制平面會(huì)顯得很中規(guī)中矩，也就是邏輯上的集中式控制，沒(méi)有weave/calico的P2P那么炫酷。在這樣的結(jié)構(gòu)下，當(dāng)ovs遇到未知報(bào)文時(shí)，會(huì)主動(dòng)提交包信息給Controller，Controller會(huì)根據(jù)包信息判斷后，給ovs下發(fā)合適的流表規(guī)則。為了實(shí)現(xiàn)負(fù)載均衡和高可用，我們給每組ovs配置多個(gè)Controller。如圖15所示。

例如:

1. 對(duì)于非法流量Controller會(huì)讓ovs簡(jiǎn)單丟棄，并在將來(lái)一段時(shí)間內(nèi)不要再詢問(wèn)。

2. 對(duì)于合法流量，Controller會(huì)告訴ovs如何路由這個(gè)包并最終到達(dá)正確的目的地。

圖15

服務(wù)發(fā)現(xiàn)和負(fù)載均衡

關(guān)于服務(wù)發(fā)現(xiàn)和負(fù)載均衡，我們提供了以下幾個(gè)對(duì)象模型：

1. Container，容器實(shí)例，多個(gè)Container構(gòu)成一個(gè)Pod（實(shí)體）。

2. Pod，每個(gè)Pod共享一個(gè)網(wǎng)絡(luò)棧，IP地址和端口空間（實(shí)體）。

3. Service，多個(gè)相同Pod副本構(gòu)成一個(gè)Service，擁有一個(gè)Service IP（邏輯）。

4. 安全組，多個(gè)Service構(gòu)成一個(gè)安全組（邏輯）。

其中，可動(dòng)態(tài)伸縮的關(guān)系是一個(gè)Service與其后端Pod的映射，這一步是靠平臺(tái)的自動(dòng)服務(wù)發(fā)現(xiàn)來(lái)完成。只要發(fā)起對(duì)Service IP的訪問(wèn)，那么Service本身就會(huì)完成服務(wù)發(fā)現(xiàn)和負(fù)載均衡的功能。后端Pod如果發(fā)生變動(dòng)，調(diào)用方完全無(wú)需感知。

從實(shí)現(xiàn)上來(lái)說(shuō)，我們將這個(gè)功能實(shí)現(xiàn)到了每個(gè)宿主機(jī)上，每個(gè)宿主機(jī)上的這個(gè)組件會(huì)直接代理本機(jī)產(chǎn)生的Service流量，這樣可以避免額外的內(nèi)網(wǎng)流量開(kāi)銷。

功能上，我們實(shí)現(xiàn)了IP級(jí)的負(fù)載均衡，什么意思，就是每個(gè)Service IP的可訪問(wèn)端口與后端Pod實(shí)際監(jiān)聽(tīng)的端口是一致的，比如后端Pod監(jiān)聽(tīng)了12345，那么直接訪問(wèn)Service IP的12345端口，即可直接訪問(wèn)，而無(wú)需額外的端口配置。

這里對(duì)比一下常見(jiàn)的幾種負(fù)載均衡：

1. 比DNS均衡更加精細(xì)。

2. 比端口級(jí)的負(fù)載均衡器更容易使用，對(duì)業(yè)務(wù)入侵更小。

另外，7層的負(fù)載均衡實(shí)際上有很大的想象空間，我們實(shí)現(xiàn)了大部分Nginx的常用配置，使用者可以靈活配置。業(yè)務(wù)甚至還可以指定后端進(jìn)行訪問(wèn)。

安全組

在隔離層面，我們?cè)谶壿嬌蟿澐至税踩M，多個(gè)service組成一個(gè)安全組，安全組之間可以實(shí)現(xiàn)靈活的訪問(wèn)控制。相同安全組內(nèi)的容器可以互相不受限制的訪問(wèn)。其中最常見(jiàn)的一個(gè)功能是，將安全組A中的某些特定的Service Export給另一組安全組B。Export后，安全組B內(nèi)的容器則可以訪問(wèn)這些導(dǎo)出的Service，而不能訪問(wèn)A中的其他Service。如圖16所示。

圖16

介紹完了我們網(wǎng)絡(luò)的基礎(chǔ)功能，這里通過(guò)分析兩個(gè)七牛的實(shí)際案例來(lái)說(shuō)明這樣的結(jié)構(gòu)是如何推動(dòng)業(yè)務(wù)的架構(gòu)演變的。

案例分析1——七牛文件處理FOP架構(gòu)演變

第一個(gè)是七牛的文件處理架構(gòu)（File OPeration），如圖17所示。文件處理功能一直是七牛非常創(chuàng)新、也是很核心的一個(gè)功能，用戶在上傳了一個(gè)文件后，通過(guò)簡(jiǎn)單地在資源url中添加一些參數(shù)，就能直接下載到按參數(shù)處理后的文件，例如你可以在一個(gè)視頻文件的url中添加一些參數(shù)，最終下載到一張?jiān)谝曨l某一幀上打了水印并旋轉(zhuǎn)90度并裁剪成40×40大小的圖片。

圖17

而支撐這樣一個(gè)業(yè)務(wù)的架構(gòu)，在早期是非常笨拙的。圖17左側(cè)是業(yè)務(wù)的入口，右側(cè)是實(shí)際進(jìn)行計(jì)算的各種worker集群，里面包含了圖片處理，視頻處理，文檔處理等各種處理實(shí)例。

1. 集群信息寫死在入口配置中，后端配置變更不夠靈活。

2. 業(yè)務(wù)入口成為流量穿透的組件（業(yè)務(wù)的指令流與數(shù)據(jù)流混雜在一起）。

3. 突發(fā)請(qǐng)求情況下，應(yīng)對(duì)可能不及時(shí)。

后面負(fù)責(zé)文件處理的同事將架構(gòu)進(jìn)化成了這樣（如圖18）。

1. 增加Discovery組件，用于集群中worker信息的自動(dòng)發(fā)現(xiàn)，每個(gè)worker被添加進(jìn)集群都會(huì)主動(dòng)注冊(cè)自己。

2. 業(yè)務(wù)入口從Discovery獲取集群信息，完成對(duì)請(qǐng)求的負(fù)載均衡。

3. 每個(gè)計(jì)算節(jié)點(diǎn)上新增Agent組件，用于向Discovery組件上報(bào)心跳和節(jié)點(diǎn)信息，并緩存處理后的結(jié)果數(shù)據(jù)（將數(shù)據(jù)流從入口分離），另外也負(fù)責(zé)節(jié)點(diǎn)內(nèi)的請(qǐng)求負(fù)載均衡（實(shí)例可能會(huì)有多個(gè)）。

4. 此時(shí)業(yè)務(wù)入口只需負(fù)責(zé)分發(fā)指令流，但仍然需要對(duì)請(qǐng)求做節(jié)點(diǎn)級(jí)別的負(fù)載均衡。

圖18

圖19描述的是文件處理架構(gòu)遷移到容器平臺(tái)后的早期結(jié)構(gòu)，較遷移之前有如下變更。

1. 每個(gè)Agent對(duì)應(yīng)一個(gè)計(jì)算worker，并按工種獨(dú)立成Service，比如Image Service，Video Service。

2. 取消業(yè)務(wù)的Discovery服務(wù)，轉(zhuǎn)由平臺(tái)自身的服務(wù)發(fā)現(xiàn)功能。

3. 每個(gè)Agent的功能退化：

• 無(wú)需和Discovery維護(hù)心跳，也不在需要上報(bào)節(jié)點(diǎn)信息。

• 由于后端只有一個(gè)worker，因此也不需要有節(jié)點(diǎn)內(nèi)的負(fù)載均衡邏輯。

4. 業(yè)務(wù)入口無(wú)需負(fù)載均衡，只需無(wú)腦地請(qǐng)求容器平臺(tái)提供的入口地址即可。

圖19

圖20是遷移后發(fā)生的另一次演變，實(shí)際上上一個(gè)階段中，每個(gè)Agent仍然和計(jì)算實(shí)例綁定在一起，而這么做其實(shí)只是為了方便業(yè)務(wù)的無(wú)痛遷移，因?yàn)锳gent本身的代碼會(huì)有一些邏輯上的假設(shè)。

這張圖中，我們進(jìn)一步分離了Agent和worker，Agent獨(dú)立成一個(gè)Service，所有的worker 按工種獨(dú)立成Service，這么分離的目的在于，Agent是可能會(huì)有文件內(nèi)容緩存、屬于有狀態(tài)的服務(wù)，而所有的worker是真正干活、無(wú)狀態(tài)的服務(wù)。分離之后的好處在于，worker的數(shù)量可以隨時(shí)調(diào)整和伸縮，而不影響Agent中攜帶的狀態(tài)。

好處：

1. 可以看到，相比于最早的架構(gòu)，業(yè)務(wù)方只需集中精力開(kāi)發(fā)業(yè)務(wù)本身，而無(wú)需重復(fù)造輪子，實(shí)現(xiàn)各種復(fù)雜的服務(wù)發(fā)現(xiàn)和各種負(fù)載均衡的代碼。

2. 另外，自從部署到容器平臺(tái)之后，平臺(tái)的調(diào)度器會(huì)自動(dòng)更具節(jié)點(diǎn)的資源消耗狀況做實(shí)例的遷移，這樣使得計(jì)算集群中每個(gè)節(jié)點(diǎn)的資源消耗更加均衡。

案例分析2——用戶自定義文件處理UFOP架構(gòu)演變

另一個(gè)案例是七牛的用戶自定義文件處理。

用戶自定義文件處理（User-defined File OPeration，UFOP）是七牛提供的用于運(yùn)行用戶上傳的文件處理程序的框架。他的作用實(shí)際上和前面介紹的是一致的，只是允許用戶自定義他的計(jì)算實(shí)例。例如七?，F(xiàn)有的鑒黃服務(wù)，就是一個(gè)第三方的worker，可以用于識(shí)別出一個(gè)圖片是否包含黃色內(nèi)容。而正是由于引入了用戶的程序，所以UFOP在架構(gòu)上和官方的 FOP的不同在于，UFOP對(duì)隔離有要求。

圖20是原本UFOP的架構(gòu)，事實(shí)上，這里已經(jīng)使用了容器技術(shù)進(jìn)行資源上的隔離，所有的容器通過(guò)Docker Expose將端口映射到物理機(jī)，然后通過(guò)一個(gè)集中式的注冊(cè)服務(wù)，將地址和端口信息注冊(cè)到一個(gè)中心服務(wù)，然后入口分發(fā)服務(wù)通過(guò)這個(gè)中心服務(wù)獲取集群信息做請(qǐng)求的負(fù)載均衡。

而在網(wǎng)絡(luò)的隔離上，由于Docker自身的弱隔離性，這個(gè)架構(gòu)中選擇了禁止所有的容器間通信，而只允許入口過(guò)來(lái)的流量。這個(gè)隔離尺度一定程度上限制了用戶自定義程序的靈活性。

圖20

而在遷移到容器平臺(tái)后，由于有靈活的安全組控制，不同用戶上傳的處理程序天然就是隔離的，而用戶可以創(chuàng)建多種職責(zé)不同的Service來(lái)完成更復(fù)雜的處理邏輯。如圖21所示。

另外，遷移后的程序?qū)碛型暾亩丝诳臻g，進(jìn)一步放開(kāi)了用戶自定義處理程序的靈活性。

圖21

上述就是小編為大家分享的如何進(jìn)行容器SDN技術(shù)與微服務(wù)架構(gòu)實(shí)踐 了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。