摘要：微服務(wù)基礎(chǔ)層主要是為容器提供計(jì)算存儲(chǔ)網(wǎng)絡(luò)等基礎(chǔ)資源。微服務(wù)訪問(wèn)層，目前服務(wù)對(duì)外暴露訪問(wèn)主要以綁定或是負(fù)載均衡方式。除此之外，內(nèi)置的負(fù)載均衡是基于實(shí)現(xiàn)的，支持。私有云場(chǎng)景中，很多行業(yè)用戶在內(nèi)部都使用硬件負(fù)載均衡來(lái)暴露服務(wù)訪問(wèn)地址。

站在微服務(wù)的角度看容器的基礎(chǔ)設(shè)施服務(wù)可以分為三層：

微服務(wù)基礎(chǔ)層

微服務(wù)構(gòu)建層

微服務(wù)訪問(wèn)層

Rancher的服務(wù)發(fā)現(xiàn)就是基于rancher-dns來(lái)實(shí)現(xiàn)，創(chuàng)建的stack&service都會(huì)生成相應(yīng)的DNS記錄，用戶可以通過(guò)相應(yīng)的規(guī)則進(jìn)行訪問(wèn)，這樣在微服務(wù)之間就可以無(wú)需知曉各自的IP地址，直接用服務(wù)名進(jìn)行連接即可。

微服務(wù)基礎(chǔ)層主要是為容器提供計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等基礎(chǔ)資源。主機(jī)計(jì)算資源主要是對(duì)docker-machine封裝來(lái)提供相關(guān)服務(wù)；容器存儲(chǔ)通過(guò)Convoy組件來(lái)接入，目前對(duì)NFS協(xié)議的存儲(chǔ)適配性最佳；容器之間的網(wǎng)絡(luò)通過(guò)rancher-net組件實(shí)現(xiàn)，目前支持ipsec overlay，在Rancher1.2版本會(huì)支持CNI標(biāo)準(zhǔn)的網(wǎng)絡(luò)插件。

微服務(wù)構(gòu)建層，除了有微服務(wù)本身主體程序，還需要有一些額外的輔助工具來(lái)完善對(duì)應(yīng)微服務(wù)的架構(gòu)體系。rancher-dns來(lái)實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)機(jī)制；rancher-metadata可以靈活動(dòng)態(tài)向微服務(wù)所在容器中注入一些配置數(shù)據(jù)；healthcheck來(lái)保證微服務(wù)的高可用；同時(shí)我們還需要有微服務(wù)打包的工具，保證微服務(wù)可以在任意環(huán)境拉起運(yùn)行。

微服務(wù)訪問(wèn)層，目前服務(wù)對(duì)外暴露訪問(wèn)主要以DNS綁定或是負(fù)載均衡VIP方式。Rancher提供external-dns、external-lb框架可以讓高級(jí)用戶hack自身的場(chǎng)景需求，external-dns除了支持公共的DNS服務(wù)（如route53），還支持內(nèi)部DNS服務(wù)器（如bind9），而external-lb目前支持F5設(shè)備。除此之外，Rancher內(nèi)置的負(fù)載均衡是基于Haproxy實(shí)現(xiàn)的，支持L4-L7。

本次分享，我將會(huì)以概念介紹原理講解并穿插一些實(shí)際案例這樣的方式進(jìn)行分享。

Rancher的元數(shù)據(jù)服務(wù)rancher-metadata靈活性非常大，比較復(fù)雜的微服務(wù)架構(gòu)可以通過(guò)metadata實(shí)現(xiàn)一定程度的解耦，尤其是confd+metadata會(huì)有意想不到妙用，這部分內(nèi)容可以參考 http://niusmallnan.github.io/...

Rancher的healthcheck基于Haproxy實(shí)現(xiàn)，支持TCP/HTTP，當(dāng)unhealthy觸發(fā)時(shí)按照預(yù)先設(shè)置的策略執(zhí)行：

什么也不做

按照scale的容器數(shù)量重建

保證至少x個(gè)healthy的容器數(shù)量

當(dāng)針對(duì)某個(gè)service創(chuàng)建healthcheck策略后，service中容器所在的agent節(jié)點(diǎn)上會(huì)啟動(dòng)Haproxy服務(wù)，同時(shí)把healthcheck的配置轉(zhuǎn)化為Haproxy的配置。如圖中所示添加了backend，其對(duì)應(yīng)的ip就是container的ip。此外還要將Haproxy的stats scket暴露出來(lái)，以便讀取backend的狀態(tài)信息。

我們可以在外部程序中與Haproxy sock通信，可以獲取相關(guān)backend的狀態(tài)信息，由于我們?cè)贖aproxy中設(shè)置check機(jī)制，所以backend的狀態(tài)是會(huì)自動(dòng)更新的。

Rancher Agent上運(yùn)行的host-api組件通過(guò)Haproxy sock來(lái)讀取backend狀態(tài)信息，同時(shí)通過(guò)rancher event機(jī)制把狀態(tài)信息push給rancher-server，rancher-server根據(jù)之前設(shè)置的healthcheck策略，來(lái)控制相關(guān)的rancher agent執(zhí)行container recreate操作。

如果微服務(wù)本身是自帶服務(wù)端口（TCP/HTTP），那么healthcheck規(guī)則很好設(shè)置，只要正常填寫表單項(xiàng)就可以。但實(shí)際應(yīng)用中有些微服務(wù)并不會(huì)有端口暴露，它可能只是一個(gè)與DB交互的程序，這時(shí)我們會(huì)考慮讓服務(wù)本身不要有大的代碼改造，所以就需要用一些小工具來(lái)輔助一下。

微服務(wù)的訪問(wèn)入口，除了我們熟知的LB方式，還可以通過(guò)綁定DNS來(lái)實(shí)現(xiàn)，尤其是在私有云場(chǎng)景下，內(nèi)部DNS的使用其實(shí)比單純使用LB暴露IP+Port方式更加簡(jiǎn)潔，因?yàn)檫@樣無(wú)需考慮微服務(wù)的容器漂移導(dǎo)致的服務(wù)IP出現(xiàn)變化。

Rancher提供了一個(gè)external-dns框架 https://github.com/rancher/ex...，它可以實(shí)現(xiàn)service的服務(wù)地址轉(zhuǎn)換成DNS的記錄。

私有云場(chǎng)景中，很多行業(yè)用戶在內(nèi)部都使用F5硬件負(fù)載均衡來(lái)暴露服務(wù)訪問(wèn)地址。微服務(wù)的改造我們盡量控制在程序架構(gòu)層面，而原有的網(wǎng)絡(luò)結(jié)構(gòu)盡量不要改變，那么就會(huì)引來(lái)一個(gè)微服務(wù)場(chǎng)景如何整合F5設(shè)備的問(wèn)題。

我們以一個(gè)應(yīng)用場(chǎng)景為例，生產(chǎn)環(huán)境系統(tǒng)中有4個(gè)微服務(wù)暴露端口分別是9070、9071、9072、9073，出于容災(zāi)恢復(fù)的考慮需要部署兩套環(huán)境主環(huán)境和備環(huán)境，每個(gè)環(huán)境三臺(tái)主機(jī)，所有的數(shù)據(jù)庫(kù)層均放在非容器環(huán)境中，所有服務(wù)最終通過(guò)F5來(lái)暴露訪問(wèn)。

基于Rancher來(lái)實(shí)現(xiàn)這種應(yīng)用場(chǎng)景：創(chuàng)建兩個(gè)environment分屬主環(huán)境和備環(huán)境，由于是不同的ENV，所以這兩個(gè)環(huán)境是從計(jì)算存儲(chǔ)網(wǎng)絡(luò)層面都是隔離的。每個(gè)環(huán)境中創(chuàng)建一個(gè)stack，stack下創(chuàng)建4個(gè)service，service加上global=true的label，保證每臺(tái)host上都運(yùn)行該service，同時(shí)通過(guò)portmap把service的服務(wù)端口直接暴露在host上，外部的F5設(shè)備則將VIP配置到這些HostIP+Port上。

關(guān)鍵的F5設(shè)置，我們要考慮最好能夠動(dòng)態(tài)設(shè)置。Rancher提供了一個(gè)external-lb框架 https://github.com/rancher/ex...來(lái)解決此問(wèn)題，F(xiàn)5的驅(qū)動(dòng)亦位列其中，同樣也是通過(guò)rancher-metadata組件來(lái)獲取微服務(wù)的IP+Port信息。

浮動(dòng)IP本是Iaas的產(chǎn)物，而Caas仍處在不斷演變的過(guò)程中，企業(yè)內(nèi)部的網(wǎng)絡(luò)結(jié)構(gòu)仍然需要浮動(dòng)IP的機(jī)制。最主要的場(chǎng)景就是防火墻的規(guī)則設(shè)置，通常其規(guī)則都是針對(duì)某個(gè)IP，而這個(gè)IP就意味著無(wú)論后端的服務(wù)怎么變換，它要求IP是不能變化的，否則就要不停的修改防火墻規(guī)則，這是企業(yè)運(yùn)維人員最無(wú)法接受的。

本質(zhì)上我們需要解決微服務(wù)相關(guān)的容器發(fā)生漂移之后，其對(duì)外暴露的IP仍然保持不變。

Rancher的合作伙伴睿云智合提出過(guò)一個(gè)浮動(dòng)IP的解決方案，是一個(gè)很不錯(cuò)的思路。

當(dāng)然我們也可以利用Cattle自有機(jī)制來(lái)變通地搞定這個(gè)問(wèn)題。

微服務(wù)的訪問(wèn)入口使用內(nèi)置的rancher-lb方式，可以通過(guò)label scheduling方式，讓rancher-lb的容器只落在固定主機(jī)上，相關(guān)的防火墻只要配置固定的主機(jī)IP即可。

最后，我們來(lái)一起看一下，比較合適的通用的微服務(wù)部署結(jié)構(gòu)。

這里面使用sidekick容器來(lái)分離主服務(wù)的功能，配置文件和日志分別由不同的容器來(lái)處理，同時(shí)保證整體性，可以完整擴(kuò)容和克隆。配置文件統(tǒng)一放在 convoy連接的NFS存儲(chǔ)中，保證配置文件的一致性。logging容器會(huì)把日志統(tǒng)一發(fā)送到ELK日志系統(tǒng)中，便于集中查詢和管理。保證服務(wù)的可用性，healthcheck必不可少。外部則使用內(nèi)置的Rancher LB來(lái)暴露訪問(wèn)。

Q：convoy插件的現(xiàn)在有支持ceph或者gluster的catalog么？

A：gluster的catalog 之前有，但是一直有些問(wèn)題，現(xiàn)在已經(jīng)被移除了。convoy目前還不支持ceph。

Q：最后一個(gè)架構(gòu)里面，是把日志存到一個(gè)volume，然后應(yīng)用和日志服務(wù)，同時(shí)掛載的意思么？

A：日志就是通過(guò)logging容器發(fā)送到ELK中收集起來(lái)。

Q：直接用log插件發(fā)的么？

A：log driver只能把標(biāo)準(zhǔn)輸入輸出發(fā)送出去，而圖中的架構(gòu)更適合傳統(tǒng)的寫日志文件形式，把日志文件的內(nèi)容發(fā)送到elk中。

Q：具體的操作是不是日志存在一個(gè)sidekick 容易中，讓后讓logging容器來(lái)解析和發(fā)送？

A：是這樣的。

Q：這樣這個(gè)volume 需要mount 本地目錄上去么？還是就已一個(gè)container的形式存在？

A：一個(gè)container足矣。

Q：現(xiàn)在convoy是不是暫時(shí)沒(méi)有其他方案把一個(gè)集群的本地host的磁盤利用起來(lái)？

A：Rancher有一個(gè)longhorn是你說(shuō)的場(chǎng)景，還在迭代中。