QCon技術(shù)干貨：個(gè)推基于Docker和Kubernetes的微服務(wù)實(shí)踐

2016年伊始，Docker無比興盛，如今Kubernetes萬人矚目。在這個(gè)無比需要?jiǎng)?chuàng)新與速度的時(shí)代，由容器、微服務(wù)、DevOps構(gòu)成的云原生席卷整個(gè)IT界。在近期舉辦的QCon全球軟件開發(fā)大會(huì)上，個(gè)推應(yīng)用平臺(tái)基礎(chǔ)架構(gòu)高級(jí)研發(fā)工程師王志豪，基于他在基礎(chǔ)架構(gòu)方面多年的經(jīng)驗(yàn)，分享了《個(gè)推基于Docker和Kubernetes的微服務(wù)實(shí)踐》。

個(gè)推應(yīng)用平臺(tái)基礎(chǔ)架構(gòu)高級(jí)研發(fā)工程師王志豪

一、微服務(wù)化

微服務(wù)架構(gòu)

微服務(wù)是將單一的應(yīng)用程序拆分成多個(gè)微小的服務(wù)，各個(gè)小服務(wù)之間松耦合，高內(nèi)聚，每個(gè)小的服務(wù)可以單獨(dú)進(jìn)行開發(fā)，不依賴于具體的編程語言，也可以使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)，各個(gè)服務(wù)可以獨(dú)立部署，擁有各自的進(jìn)程，相互之間通過輕量化的機(jī)制進(jìn)行通信(如基于HTTP的API接口)，所有的服務(wù)共同實(shí)現(xiàn)具體的業(yè)務(wù)功能。

客戶端與服務(wù)端通信有2種方式，第一種是客戶端直接與各個(gè)微服務(wù)進(jìn)行通信，這樣的架構(gòu)有4個(gè)缺點(diǎn)：

（1）多次服務(wù)請(qǐng)求，效率低；

（2）對(duì)外暴露服務(wù)接口；

（3）接口協(xié)議無法統(tǒng)一；

（4）客戶端代碼復(fù)雜，服務(wù)端升級(jí)困難。

第二種方式是由API網(wǎng)關(guān)統(tǒng)一代理各個(gè)服務(wù)，對(duì)外提供統(tǒng)一的接口協(xié)議，該架構(gòu)有3 個(gè)優(yōu)勢(shì)：

（1）封裝服務(wù)接口細(xì)節(jié)，減少通信次數(shù)；

（2）統(tǒng)一通信協(xié)議，減少客戶端代碼耦合；

（3）統(tǒng)一鑒權(quán)，流控，防***；

在該架構(gòu)下，網(wǎng)關(guān)也有可能成為系統(tǒng)瓶頸。

相應(yīng)地，這2種架構(gòu)也帶來了2種服務(wù)注冊(cè)發(fā)現(xiàn)的方式，第一種是客戶端通過向服務(wù)的注冊(cè)中心查詢微服務(wù)的地址與其通信，第二種是增加統(tǒng)一的API網(wǎng)關(guān)來查詢。前者會(huì)增加客戶端的復(fù)雜度，開發(fā)成本高，第二種操作會(huì)顯得更加簡(jiǎn)潔，因此我們?cè)趯?shí)踐的時(shí)候選擇了第二種架構(gòu)方式。

微服務(wù)數(shù)量增加以后，服務(wù)之間的調(diào)用關(guān)系易產(chǎn)生耦合，甚至出現(xiàn)循環(huán)調(diào)用的情況，最好的應(yīng)對(duì)方法是對(duì)服務(wù)進(jìn)行分層，即將相互依賴的服務(wù)通過消息隊(duì)列等技術(shù)進(jìn)行異步解耦，減少服務(wù)間的依賴。

服務(wù)分層

微服務(wù)的具體實(shí)踐

1.技術(shù)選型

在實(shí)踐中，我們的API Gateway使用的是OpenResty, OpenResty基于Nginx并擴(kuò)展了對(duì)Lua的支持，可構(gòu)建高并發(fā)的Web服務(wù)。我們通過HTTP接口實(shí)現(xiàn)客戶端通信，數(shù)據(jù)基本封裝成JSON格式，服務(wù)間的通信接口也是基于HTTP，并利用消息隊(duì)列進(jìn)行異步解耦；至于服務(wù)注冊(cè)發(fā)現(xiàn)，我們使用的是Consul；我們選擇了Lua（擴(kuò)展API Gateway的功能），Node.js（用于開發(fā)后端服務(wù)），Java（用于密集計(jì)算和與大數(shù)據(jù)通信的場(chǎng)景）作為主要的開發(fā)語言。

2.具體實(shí)現(xiàn)過程

在實(shí)踐過程中，我們使用Lua開發(fā)了自己的微服務(wù)框架——WebLua，其封裝服務(wù)之間的通信協(xié)議和訪問外部資源（如Mysql、Redis等）的方法和依賴，同時(shí)提供了應(yīng)用插槽。我們可以將每一個(gè)APP看成一個(gè)功能模塊，每個(gè)APP都需要插到WebLua中才能運(yùn)行。WebLua可以方便地將模塊進(jìn)行組合，既可以一個(gè)APP運(yùn)行一個(gè)微服務(wù)，也可以多個(gè)APP一起對(duì)外提供服務(wù)。如此，開發(fā)者只需關(guān)注業(yè)務(wù)APP開發(fā)，很大程度上提高了開發(fā)效率。上圖右側(cè)是具體的代碼目錄結(jié)構(gòu)，每個(gè)APP可分為Action，Page，Data三層，Action層在請(qǐng)求處理前后進(jìn)行攔截，可做某些特殊處理，如請(qǐng)求前進(jìn)行權(quán)限校驗(yàn)等；Page層主要對(duì)請(qǐng)求的參數(shù)進(jìn)行解析和校驗(yàn)；Data層負(fù)責(zé)具體業(yè)務(wù)處理，同時(shí)提供了Shell腳本，可實(shí)現(xiàn)APP打包和部署安裝。

二、 API網(wǎng)關(guān)

在架構(gòu)中一個(gè)重要角色就是API網(wǎng)關(guān)，下面來做一個(gè)介紹。

從上面的對(duì)比圖中可以看到，左側(cè)是沒有API Gateway的，很多的模塊如Auth，Logging等，這些代碼都需要自己去實(shí)現(xiàn)，造成了模塊的重復(fù)建設(shè)，同時(shí)侵入了服務(wù)，功能擴(kuò)展比較困難；右側(cè)的圖是使用了API Gateway之后的架構(gòu)圖，所有通用模塊均在API Gateway實(shí)現(xiàn)，維護(hù)簡(jiǎn)單，一處建設(shè)，各處受益。在這種情況下，對(duì)API Gateway也提出了更高要求——其功能必須可以很方便地?cái)U(kuò)展。

為了實(shí)現(xiàn)這樣的API網(wǎng)關(guān)，我們基于 OpenResty，借鑒了Kong和Orange的插件機(jī)制，通過插件來擴(kuò)展API網(wǎng)關(guān)功能。

從上面的API Gateway架構(gòu)圖中可以看到，網(wǎng)關(guān)安裝諸多插件，每個(gè)插件會(huì)在請(qǐng)求的一個(gè)或多個(gè)階段發(fā)揮作用。插件配置會(huì)在Consul上更新，實(shí)時(shí)生效，插件規(guī)則可靈活配置。在操作中，我們?yōu)椴寮_發(fā)者提供了更多的自由，開發(fā)者可以自己定義格式。

三、容器化

在微服務(wù)落地實(shí)踐時(shí)我們選擇了Docker，下面將詳細(xì)介紹個(gè)推基于Docker的實(shí)踐。

首先網(wǎng)絡(luò)組件選擇的是Calico，服務(wù)注冊(cè)發(fā)現(xiàn)和配置管理選擇的是Consul。Consul-Template可實(shí)時(shí)監(jiān)測(cè)Consul配置和服務(wù)的變化。

個(gè)推鏡像體系是以CentOS為基礎(chǔ)系統(tǒng)鏡像，安裝OpenResty，Nodejs，JDK，由此得到環(huán)境鏡像，再在這個(gè)基礎(chǔ)上安裝微服務(wù)框架，獲得Gorp鏡像。再在這個(gè)基礎(chǔ)上安裝具體應(yīng)用服務(wù)，得到應(yīng)用服務(wù)鏡像。

服務(wù)注冊(cè)發(fā)現(xiàn)和配置更新流程

在API網(wǎng)關(guān)中，服務(wù)注冊(cè)通過Consul-Agent來實(shí)現(xiàn)，配置更新通過Consul-Template實(shí)現(xiàn)。Consul-Template主要更新3類配置，包括：Services：代理的所有微服務(wù)的服務(wù)地址；Products：簡(jiǎn)言之即請(qǐng)求到微服務(wù)的映射表，如左上所示，所有請(qǐng)求都有統(tǒng)一個(gè)規(guī)范，從Host中可以獲取Prod，從URI中可以獲取APP，這 2個(gè)信息可將請(qǐng)求動(dòng)態(tài)路由到具體服務(wù)；Nging-Conf：產(chǎn)品的Nginx配置。

應(yīng)用服務(wù)容器，服務(wù)注冊(cè)的方式跟API網(wǎng)關(guān)一致。首先，服務(wù)通過容器內(nèi)部運(yùn)行的Consul Agent將服務(wù)注冊(cè)到Consul上，其次通過Consul-Template來監(jiān)測(cè)觀察 Consul上配置的變化，并更新配置文件。OpenResty或者WebNode配置的更新是直接覆蓋相應(yīng)的配置文件，然后重啟對(duì)應(yīng)的服務(wù)。

上圖是個(gè)推基于Docker的集群架構(gòu)，從中可看到，Docker集群包括3個(gè)節(jié)點(diǎn)，整個(gè)微服務(wù)分為3層，最上層是API Gateway，中間是業(yè)務(wù)層，最下層是一些多產(chǎn)品公用的基礎(chǔ)的微服務(wù)。

四、Kubernetes實(shí)踐

微服務(wù)雖然有很多好處，但也帶來了很多問題，其中一個(gè)就是運(yùn)維復(fù)雜。以前運(yùn)維只需要面對(duì)一個(gè)單體應(yīng)用即可，現(xiàn)在可能面臨的是幾十甚至上百的微服務(wù)。在這種情況下，我們需要借助Kubernetes來解決問題。Kubernetes是Google開源的一個(gè)容器編排工具，可用于協(xié)助管理容器。

一開始，我們將容器向Kubernetes集群遷移時(shí)，沒做任何改變，只是采用Pod將所有的服務(wù)體系在Kubernetes集群運(yùn)行。但隨著深入使用Kubernetes，我們對(duì)微服務(wù)做了一些改變。

1.首先我們換成用Deployment的方式來部署服務(wù)，Deployment會(huì)保證服務(wù)時(shí)刻有一定的副本存活，提高了服務(wù)穩(wěn)定性。

2.其次，我們使用了Service，它可以代理Pod實(shí)現(xiàn)負(fù)載的均衡。

3. Kube-DNS可以將Service名解析成具體的ClusterIP，并且當(dāng)Service沒有刪除重建時(shí)，其ClusterIP不變，如此DNS解析的緩存就不存在失效問題?；贙ube-DNS和Service的特性，后續(xù)我們改造了服務(wù)注冊(cè)發(fā)現(xiàn)體系。

上圖是我們當(dāng)前的服務(wù)部署方式，Pod用Deployment的方式創(chuàng)建，用Service來進(jìn)行代理。

在實(shí)踐過程中，我們還遇到了另一個(gè)問題，即配置管理問題。

（1）微服務(wù)化后配置文件多而分散；

（2）不同環(huán)境之間有很多不必要的差異，如數(shù)據(jù)庫名；

（3）在很多不同環(huán)境中，相同的配置項(xiàng)暴露給測(cè)試和運(yùn)維；

（4）沒有版本控制，回滾比較麻煩；

（5）基于Consul的Web UI無法對(duì)非法的輸入進(jìn)行校驗(yàn)。

針對(duì)這些問題我們做了以下調(diào)整：

（1） 統(tǒng)一不同環(huán)境間不必要的差異；

（2） 對(duì)配置文件進(jìn)行模板化，只暴露差異部分，同時(shí)可實(shí)現(xiàn)不同配置文件集中配置；

（3）基于Consul開發(fā)配置中心，對(duì)產(chǎn)品配置集中管理；對(duì)輸入進(jìn)行合法性校驗(yàn)；增加版本控制，方便回滾。

配置中心流程圖

關(guān)于日志服務(wù)，我們?cè)趹?yīng)用容器中集成了Fluent-Bit，配置了2個(gè)輸入源，TCP和tail， 輸出也有2個(gè)，一個(gè)是Elasticsearch，所有的日志都會(huì)上傳到ES通過Kibana展示查詢，另一個(gè)是日志審計(jì)服務(wù)，有些需要進(jìn)行審計(jì)的操作日志會(huì)發(fā)送到日志審計(jì)服務(wù)進(jìn)行進(jìn)一步的分析處理。

微服務(wù)數(shù)量增加以后，請(qǐng)求鏈路可能延長(zhǎng)，開發(fā)者在追蹤問題和排查性能瓶頸時(shí)會(huì)很不方便，因此我們引入了Zipkin，其主要用于分布式鏈路追蹤，在API Gateway實(shí)現(xiàn)了一個(gè)插件進(jìn)行Span收集，后端服務(wù)則通過開源的中間件來實(shí)現(xiàn)。

上圖是個(gè)推目前的整體架構(gòu)圖，最底層是K8S集群，上面部署了Kube-DNS，Consul用于服務(wù)注冊(cè)發(fā)現(xiàn)和配置管理，再者是我們分層的微服務(wù)體系，右側(cè)是一些輔助的管理系統(tǒng)。

五、總結(jié)

上述是個(gè)推基于Docker和Kubernetes的整個(gè)微服務(wù)實(shí)踐過程，我們?cè)趯?shí)踐微服務(wù)過程中做了9件重要的事情，簡(jiǎn)化了操作流程，提高了工作效率。個(gè)推設(shè)計(jì)實(shí)現(xiàn)了自己的微服務(wù)框架，完成微服務(wù)的容器化部署，自研API網(wǎng)關(guān)，并基于Consul的服務(wù)注冊(cè)和配置管理，使用Kubernetes對(duì)容器進(jìn)行編排，基于Service和Kube-DNS對(duì)服務(wù)注冊(cè)和發(fā)現(xiàn)體系進(jìn)行改造，搭建了自己的配置中心，優(yōu)化了日志服務(wù)，實(shí)現(xiàn)了Zipkin鏈路追蹤。