摘要：個推針對服務場景，基于和搭建了微服務框架，提高了開發(fā)效率。三容器化在微服務落地實踐時我們選擇了，下面將詳細介紹個推基于的實踐。

2016年伊始Docker無比興盛，如今Kubernetes萬人矚目。在這個無比需要創(chuàng)新與速度的時代，由容器、微服務、DevOps構成的云原生席卷整個IT界。個推針對Web服務場景，基于OpenResty和Node.js搭建了微服務框架，提高了開發(fā)效率。在微服務的基礎上，我們結合Docker實現(xiàn)了容器化，并采用Consul進行服務注冊及發(fā)現(xiàn)。同時，面對日漸增多的微服務和配置，我們采用了Kubernetes來實現(xiàn)容器編排。

-微服務框架-

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

-微服務客戶端與服務端通信方式-

客戶端與服務端通信有2種方式，第一種是客戶端直接與各個微服務進行通信，這樣的架構有4個缺點：

（1）多次服務請求，效率低；

（2）對外暴露服務接口；

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

（4）客戶端代碼復雜，服務端升級困難。

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

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

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

（3）統(tǒng)一鑒權，流控，防攻擊。

但在該架構下，網(wǎng)關也有可能成為系統(tǒng)瓶頸。

-服務注冊與發(fā)現(xiàn)方式-

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

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

-服務分層-

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

具體實現(xiàn)過程
下圖為個推統(tǒng)一的服務框架，每個微服務都是運行于這個框架之下，WebLua集成在OpenResty上，對流量進行代理，WebNode和Javams分別是Node和Java服務的微服務架構。

-統(tǒng)一的服務框架-

首先是WebLua

-WebLua微服務框架-

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

-WebNode微服務框架-

上圖是我們Node服務的微服務框架-WebNode，最早基于Express和co實現(xiàn)，近期個推完成了基于Koa2.0升級的框架。我們的業(yè)務主要是由Node.js和TypeScript進行開發(fā)，我們對業(yè)務進行拆分，獨立出一個個功能模塊，每個獨立的功能模塊多帶帶開發(fā)成一個APP，一個或多個APP一起安裝于WebNode框架之下，作為一個微服務統(tǒng)一對外服務。WebNode框架的實現(xiàn)和WebLua類似，也提供了插槽，方便APP進行安裝和組合。

Javams 是個推為了針對高并發(fā)場景下快速構建微服務而研發(fā)的框架，在 Spring Boot 的基礎上，包含了RPC框架、Trace、緩存、健康檢查等組件，提供一站式服務。

在微服務架構中一個重要角色就是API網(wǎng)關，下面來做介紹。

-使用API網(wǎng)關前后對比-

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

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

-API網(wǎng)關的整體架構-

從上面的API Gateway架構圖中可以看到，網(wǎng)關安裝諸多插件，每個插件會在請求的一個或多個階段發(fā)揮作用。插件配置會在Consul上更新，實時生效，插件規(guī)則可靈活配置。在操作中，我們為插件開發(fā)者提供了更多自由選擇，開發(fā)者可以自己定義格式。

在微服務落地實踐時我們選擇了Docker，下面將詳細介紹個推基于Docker的實踐。

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

-個推鏡像體系-

個推鏡像體系是以Centos為基礎系統(tǒng)鏡像，安裝OpenResty，Node.js，jdk，由此得到環(huán)境鏡像；在這個基礎上安裝微服務框架，獲得Gorp鏡像，再在這個Gorp的基礎上安裝具體應用服務，得到應用服務鏡像。

-API網(wǎng)關中服務注冊和配置更新過程-

在API網(wǎng)關中，服務注冊通過Consul-agent來實現(xiàn)，配置更新通過Consul-Template實現(xiàn)。Consul-Template主要更新3類配置，包括：

Services：代理的所有微服務的服務地址；

Products：簡言之即請求到微服務的映射表，如左上所示，所有請求都有統(tǒng)一個規(guī)范，從Host中可以獲取Prod，從URI中可以獲取APP，這2個信息可將請求動態(tài)路由到具體服務；

Nging-Conf：產(chǎn)品的Nginx配置。

-應用服務的服務注冊和配置更新過程-

應用服務容器，服務注冊的方式跟API網(wǎng)關一致。首先，服務通過容器內(nèi)部運行的Consul agent將服務注冊到Consul上，其次通過Consul-Template來監(jiān)測觀察 Consul上配置的變化，并更新配置文件。

OpenResty或者WebNode配置的更新是直接覆蓋相應的配置文件，然后重啟對應的服務。

-Docker集群-

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

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

一開始，我們將容器向Kubernetes集群遷移時，沒做任何改變，只是采用Pod將所有的服務體系在Kubernetes集群跑起來。但隨著深入使用Kubernetes，我們對微服務做了一些改變。

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

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

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

-服務部署方式-

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

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

（1）微服務化后配置文件多而分散。

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

（3）在很多不同環(huán)境中，相同的配置項暴露給測試和運維。

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

（5）基于Consul的Web UI無法對非法的輸入進行校驗。

針對這些問題我們做了以下調整：

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

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

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

-配置中心流程圖-

-日志服務框架-

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

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

-個推微服務架構-

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

上述是個推基于Docker和Kubernetes的整個微服務實踐過程，我們在實踐微服務過程中做了九件重要的事情，即設計實現(xiàn)了自己的微服務框架、完成微服務的容器化部署、自研API網(wǎng)關、基于Consul服務注冊和配置管理、使用Kubernetes對容器進行編排、基于Service和Kube-DNS對服務注冊和發(fā)現(xiàn)體系進行改造、搭建了自己的配置中心、優(yōu)化日志服務和實現(xiàn)了Zipkin鏈路追蹤。