楊 帆

(歐特克（中國）軟件研發(fā)有限公司，上海 200127)

0 引言

隨著互聯(lián)網(wǎng)時(shí)代的到來，云計(jì)算技術(shù)和物聯(lián)網(wǎng)技術(shù)快速發(fā)展，互聯(lián)網(wǎng)應(yīng)用提供商的硬件資源與軟件資源越來越多地以服務(wù)的形式提供給用戶[1]。2014年學(xué)者M(jìn)artin Fowler正式提出微服務(wù)架構(gòu)的概念[2]：微服務(wù)架構(gòu)以一套微小的服務(wù)的方式來開發(fā)和部署一個(gè)單獨(dú)的應(yīng)用，這些微小的服務(wù)根據(jù)業(yè)務(wù)功能來劃分，通過自動(dòng)化部署機(jī)制獨(dú)立部署運(yùn)行在自己的進(jìn)程中，微服務(wù)之間使用輕量級(jí)通信機(jī)制來進(jìn)行通信。一個(gè)典型的微服務(wù)架構(gòu)應(yīng)該包括客戶端、微服務(wù)網(wǎng)關(guān)、服務(wù)發(fā)現(xiàn)、微服務(wù)原子層、數(shù)據(jù)庫、部署平臺(tái)等模塊，根據(jù)不同應(yīng)用類型及服務(wù)規(guī)模，可以增加負(fù)載均衡 、權(quán)限認(rèn)證、服務(wù)熔斷、日志監(jiān)控等模塊，來滿足服務(wù)的非功能性需求。企業(yè)紛紛邁向微服務(wù)架構(gòu)的典型原因是業(yè)務(wù)的復(fù)雜性、可擴(kuò)展性[3]。而 Spring Cloud是目前微服務(wù)架構(gòu)領(lǐng)域的翹楚，也是一個(gè)全家桶式的技術(shù)棧，包含了很多組件，例如Eureka、Ribbon、Feign、Hystrix、Zuul這幾個(gè)組件。首先Spring Cloud是基于Spring Boot實(shí)現(xiàn)的云應(yīng)用開發(fā)工具，它為基于JVM的云應(yīng)用開發(fā)中涉及的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、全局鎖、決策競(jìng)選、分布式會(huì)話和集群狀態(tài)管理等操作提供了一種簡(jiǎn)單的開發(fā)框架。

圖1 微服務(wù)系統(tǒng)架構(gòu)Fig.1 micr oservices system architecture

而在互聯(lián)網(wǎng)企業(yè)快速迭代的開放和發(fā)布活動(dòng)中伴隨業(yè)務(wù)的增加，微服務(wù)的子系統(tǒng)會(huì)變得越來越多，并伴隨著子系統(tǒng)間的業(yè)務(wù)調(diào)用路徑也會(huì)越來越復(fù)雜。隨之而來我們面臨著多版本子系統(tǒng)的訪問路徑控制、黑白名單和流量切換，微服務(wù)本身的多系統(tǒng)間的全路徑檢測(cè)、問題定位和 log收集，以及各個(gè)子系統(tǒng)的平滑的上下線發(fā)布和切換等問題。而我們通過開發(fā)出泳道系統(tǒng)來進(jìn)行各系統(tǒng)間實(shí)時(shí)流量控制、多版本訪問路徑選擇等來解決各微服務(wù)間的問題。

1 微服務(wù)架構(gòu)所面臨的問題

微服務(wù)系統(tǒng)中每個(gè)服務(wù)代表著一個(gè)小的業(yè)務(wù)能力[4]，而每個(gè)服務(wù)之間通過 API調(diào)用[5]。所以由于本身就存在多服務(wù)互相調(diào)用的特性，這就使得它存在著跨進(jìn)程之間的事務(wù)、大量的異步處理、多個(gè)微服務(wù)之間相互發(fā)現(xiàn)選擇以及網(wǎng)絡(luò)延遲、容錯(cuò)、消息序列化等問題。而隨著公司的成長(zhǎng)和業(yè)務(wù)的拓展，各個(gè)系統(tǒng)會(huì)進(jìn)行快速的多次迭代。這就會(huì)造成子系統(tǒng)的增加以及子系統(tǒng)的多版本共存等問題的出現(xiàn)。

而通過構(gòu)建Spring Cloud系統(tǒng)構(gòu)架，通過對(duì)Eureka、Ribbon、Feign、Hystrix、Zuul這幾個(gè)系統(tǒng)和組件的使用，可以解決一些如子系統(tǒng)發(fā)現(xiàn)[6]，各子系統(tǒng)間訪問路由、負(fù)載等問題。但是這些還遠(yuǎn)遠(yuǎn)不夠，還面臨著如下問題的挑戰(zhàn)：

（1）對(duì)多版本的子系統(tǒng)支持

（2）多版本的訪問路徑控制

（3）多版本的黑白名單和流量切換

（4）多系統(tǒng)間的全路徑檢測(cè)，問題定位和log收集各個(gè)子系統(tǒng)的平滑的上下線發(fā)布和切換。

2 解決方案和具體要求

為了解決微服務(wù)系統(tǒng)中的多版本子系統(tǒng)一系列問題，目前有兩種可行的解決方案：

（1）物理隔絕獨(dú)立部署。就是根據(jù)需要的支持的各個(gè)版本子系統(tǒng)獨(dú)立部署一整套微服務(wù)系統(tǒng)，但是可以根據(jù)并發(fā)量減少部署的子系統(tǒng)個(gè)數(shù)。在最外層網(wǎng)關(guān)根據(jù)需求發(fā)出的版本號(hào)選擇對(duì)應(yīng)的獨(dú)立系統(tǒng)[7]。

優(yōu)點(diǎn)：不會(huì)對(duì)系統(tǒng)的開發(fā)有任何影響，系統(tǒng)獨(dú)立流量切換和控制也相對(duì)容易，系統(tǒng)的集成測(cè)試相對(duì)友好，也便于開發(fā)人員發(fā)現(xiàn)問題，修改錯(cuò)誤，對(duì)訪問控制也相對(duì)容易。

缺點(diǎn)：實(shí)施成本高昂，如果根據(jù)一個(gè)子系統(tǒng)版本一套獨(dú)立部署，需要把所有的其他子系統(tǒng)全部單獨(dú)部署一遍，會(huì)把一些訪問量較少的服務(wù)也單獨(dú)再部署一個(gè)，而且如某些版本本身訪問數(shù)量較少也需要一整套系統(tǒng)的支持，這就造成資源浪費(fèi)和分配不均，會(huì)擠占高訪問率版本系統(tǒng)的所占資源。

（2）通過軟件自動(dòng)選擇可以訪問的子系統(tǒng)。所有的子系統(tǒng)都配置自身的版本信息并且能夠自己識(shí)別和選擇需要訪問的下一個(gè)系統(tǒng)的版本[8]。

優(yōu)點(diǎn)：系統(tǒng)上下線靈活，不會(huì)擠占高訪問率版本系統(tǒng)的所占資源。實(shí)施成本相對(duì)較低，對(duì)運(yùn)維占用也相對(duì)較少。

缺點(diǎn)：可能會(huì)對(duì)開發(fā)和測(cè)試產(chǎn)生較大的影響，可能會(huì)對(duì)已有系統(tǒng)造成代碼侵入問題，對(duì)于系統(tǒng)查錯(cuò)提告了難度。

對(duì)大多數(shù)處于創(chuàng)業(yè)期的互聯(lián)網(wǎng)企業(yè)來說系統(tǒng)資源都是有限的，如何提升系統(tǒng)資源的最大利用率都是核心的問題。所以選擇第二種方案是大多數(shù)創(chuàng)業(yè)期的互聯(lián)網(wǎng)企業(yè)最佳選擇。而如何規(guī)避第二種方案所帶來的缺點(diǎn)則是對(duì)系統(tǒng)架構(gòu)師的考驗(yàn)了。

為了對(duì)于已有系統(tǒng)的影響最小化也列出了如下的要求：

（1）能夠?qū)θ窂竭M(jìn)行追蹤

（2）對(duì)已有系統(tǒng)的各個(gè)子系統(tǒng)沒有硬性的代碼侵入

（3）可以自由發(fā)布

（4）方便收集所有子系統(tǒng)的log記錄

（5）不需要對(duì)已有系統(tǒng)進(jìn)行重構(gòu)和改造

3 泳道架構(gòu)的設(shè)計(jì)和實(shí)施細(xì)節(jié)

為了應(yīng)對(duì)以上問題，我們主要通過開發(fā)泳道架構(gòu)系統(tǒng)來解決。而泳道架構(gòu)系統(tǒng)的設(shè)計(jì)思路是通過軟件讓各個(gè)子系統(tǒng)能夠自己選擇可以訪問的其他子系統(tǒng)。而在這當(dāng)中需要對(duì)各個(gè)子系統(tǒng)最小化的代碼侵入，對(duì)全鏈路能夠有效的進(jìn)行跟蹤和查找。而且能夠適用于消息隊(duì)列（MQ）和job調(diào)用甚至數(shù)據(jù)庫的存儲(chǔ)。為了滿足以上要求，泳道架構(gòu)系統(tǒng)通過為了讓各個(gè)子系統(tǒng)引入 jar包來讓各個(gè)子系統(tǒng)能根據(jù)版本信息和設(shè)置的閾值自動(dòng)選擇它可以訪問的其他子系統(tǒng)，并能夠在所有的訪問請(qǐng)求中帶上唯一的trace Id，而且讓這個(gè)Id一直保存在所有的需要調(diào)用的子系統(tǒng)中。并且泳道架構(gòu)系統(tǒng)還通過新開發(fā)的新服務(wù)來為所有子系統(tǒng)配置版本信息，控制各個(gè)子系統(tǒng)流量，設(shè)置用戶訪問控制名單和系統(tǒng)訪問控制名單。

實(shí)現(xiàn)細(xì)節(jié)：

首先Spring Cloud的Eureka已經(jīng)提供了微服務(wù)的注冊(cè)和發(fā)現(xiàn)服務(wù)，可以通過對(duì)子系統(tǒng)的配置修改將各個(gè)子系統(tǒng)版本信息通過注冊(cè)服務(wù)發(fā)送給Eureka，而其他子系統(tǒng)則可以通過Eureka來獲得需要訪問的子系統(tǒng)的版本信息[9-10]。

統(tǒng)計(jì)得2001—2016年春季暴雨雨日共11 d,通過影響系統(tǒng)的分析發(fā)現(xiàn)(表1),在11次過程中,有8次暴雨都伴隨有低空切變和地面倒槽的存在;高空槽,低空急流,地面冷空氣也是重要的影響系統(tǒng);春季是冷空氣較為活躍的季節(jié),有4次過程是高空有槽東移或急流存在,中層配合切變或低空急流,而地面先為倒槽控制,之后冷空氣南下影響,冷暖空氣交匯導(dǎo)致暴雨的發(fā)生。另外東北冷渦也是非常重要的影響系統(tǒng),有4次暴雨與之有關(guān)。

其次在類似Spring Boot風(fēng)格的基于簡(jiǎn)易配置的微服務(wù)[9]中開發(fā)一個(gè)被所有子系統(tǒng)引用的jar包來完成trace Id的訪問透?jìng)鳎蛷腅ureka獲取所有子系統(tǒng)的版本配置信息從而來進(jìn)行訪問路徑選擇和計(jì)算。

持續(xù)改進(jìn)方案

泳道系統(tǒng)第一版：

所有版本信息通過Eureka來進(jìn)行存儲(chǔ)，而版本信息都是各個(gè)子系統(tǒng)存儲(chǔ)于自己的配置文件內(nèi)。這樣可以對(duì)訪問進(jìn)行版本訪問選擇控制，但是也無法進(jìn)行主動(dòng)的流量控制。

圖2 基于API的微服務(wù)調(diào)用Fig.2 API-Based microservices calling process

圖3 利用Erueka的微服務(wù)的注冊(cè)和訪問實(shí)現(xiàn)的1.0的服務(wù)調(diào)用Fig.3 version 1.0 microservices calling process base on Erueka’s registration and access

用戶的訪問進(jìn)入網(wǎng)關(guān)并帶有用戶的信息如用戶APP的版本信息和用戶ID等。網(wǎng)關(guān)根據(jù)此用戶的信息生成該用戶此次訪問的Trace Id，并從注冊(cè)的Eureka獲取可以訪問的應(yīng)用A的所有實(shí)例信息。再根據(jù)訪問的要求去選擇相對(duì)應(yīng)的應(yīng)用A的具體實(shí)例。例如：用戶A是要訪問1.0版本的應(yīng)用，網(wǎng)關(guān)從Eureka處獲取到3個(gè)可以訪問的應(yīng)用A實(shí)例，然后根據(jù)1.0的版本號(hào)選出其中2個(gè)可以使用的具體實(shí)例，最后選擇其中一個(gè)發(fā)出訪問并帶上生成的此次的Trace Id。應(yīng)用A v1.0的其中一個(gè)實(shí)例收到這個(gè)訪問發(fā)現(xiàn)它需要調(diào)用應(yīng)用B。應(yīng)用A從Eureka處獲取到應(yīng)用B沒有版本的具體要求，所以不需選擇就可以發(fā)生請(qǐng)求給應(yīng)用B，但是該請(qǐng)求還是會(huì)帶上網(wǎng)關(guān)生成的Trace Id和應(yīng)用的版本需求。而在應(yīng)用B收到訪問請(qǐng)求在發(fā)現(xiàn)需要調(diào)用應(yīng)用C時(shí)，它也會(huì)從Eureka處請(qǐng)求應(yīng)用C的具體信息，然后根據(jù)訪問所需求的版本要求選擇應(yīng)用C支持v1.0的具體實(shí)例，返送訪問請(qǐng)求。

泳道系統(tǒng)第二版：

引入 Zookeeper服務(wù)把各個(gè)子系統(tǒng)版本配置信息在上線時(shí)同步注冊(cè)到 Zookeeper上，再開發(fā)一個(gè)獨(dú)立系統(tǒng)對(duì)Zookeeper信息進(jìn)行管理。

由于添加了兩個(gè)新的服務(wù) Zookeeper和泳道控制應(yīng)用，所以所有的服務(wù)在Eureka注冊(cè)時(shí)同時(shí)會(huì)把自己的版本信息也注冊(cè)到 Zookeeper上。而泳道控制應(yīng)用就能實(shí)時(shí)觀察和控制其中每一個(gè)應(yīng)用實(shí)例的訪問。其中的訪問流程跟第一版大體一致，但是在選擇該服務(wù)可以訪問的下一個(gè)服務(wù)的實(shí)例時(shí)，則不是光通過Eureka來獲取全部信息。而是先通過Eureka拿到全部可以訪問的下一個(gè)應(yīng)用實(shí)例，然后再從 Zookeeper上去獲取具體的訪問規(guī)則，如可以訪問的版本信息，訪問的黑白名單，然后過濾從Eureka獲取的應(yīng)用實(shí)例，選取符合以上規(guī)則的具體幾個(gè)實(shí)例，最后還能再根據(jù)實(shí)例的流量訪問規(guī)則來選取其中一個(gè)實(shí)例來訪問。例如還是用戶A發(fā)出的訪問v1.0的請(qǐng)求，再網(wǎng)關(guān)處跟上一版一樣生產(chǎn)對(duì)應(yīng)的 Trace Id，從 Eureka獲取應(yīng)用A的v1.0和v1.5的全部3個(gè)實(shí)例，然后再讀取 Zookeeper上的訪問版本規(guī)則和黑白名單，篩選出應(yīng)用A的v1.0的2個(gè)實(shí)例，然后再根據(jù)2個(gè)實(shí)例的流量控制的百分比選出最后訪問的那一個(gè)實(shí)例。

計(jì)算流量的方式如下：

應(yīng)用A的v1.0實(shí)例1的流量為40%，

應(yīng)用A的v1.0實(shí)例2的流量為60%。

獲取一個(gè)100以內(nèi)的隨機(jī)數(shù)，如果隨機(jī)數(shù)小于等于40，選擇應(yīng)用A的v1.0實(shí)例1，反之則選擇應(yīng)用A的v1.0實(shí)例2.

泳道系統(tǒng)第三版：

去掉Zookeeper，把版本控制信息和流量調(diào)節(jié)信息控制系統(tǒng)前移。把信息存儲(chǔ)于進(jìn)入網(wǎng)關(guān)，根據(jù)訪問控制把需要的子系統(tǒng)的訪問版本控制信息跟 trace Id一起封裝于訪問信息內(nèi)來進(jìn)行全系統(tǒng)透?jìng)鳌?/p>

圖5 以網(wǎng)關(guān)注入信息3.0的服務(wù)調(diào)用Fig.5 version 3.0 microservices calling process of gateway information injection

第三個(gè)版本跟第一版很像，只是在網(wǎng)關(guān)上添加了一個(gè)泳道控制應(yīng)用。它的所有功能跟第二版比一點(diǎn)也沒有減少，只是減少了系統(tǒng)的復(fù)雜度，去掉了Zookeeper，避免了可能會(huì)由于Zookeeper產(chǎn)生的問題（如非必要勿增實(shí)體）。全部的訪問規(guī)則跟第二版基本一致，但是不再從 Zookeeper獲取訪問規(guī)則，黑白名單和流量控制信息了。而是這些信息直接存儲(chǔ)在網(wǎng)關(guān)上，而網(wǎng)關(guān)則是把所有這些信息和Trace Id一樣存儲(chǔ)在每個(gè)分發(fā)出去的訪問需求上，而具體的應(yīng)用實(shí)例在做訪問選擇時(shí)，不再從別的服務(wù)上獲取訪問信息和規(guī)則，直接從訪問信息中獲取，這樣減少了網(wǎng)路負(fù)擔(dān)和服務(wù)直接的訪問頻次。

4 結(jié)論

通過泳道架構(gòu)系統(tǒng)我們不需要對(duì)所有子系統(tǒng)進(jìn)行代碼侵入的情況下，只通過引入jar就能實(shí)現(xiàn)子系統(tǒng)間的訪問選擇，黑白名單控制和訪問流量調(diào)節(jié)。以此為基礎(chǔ)可以實(shí)現(xiàn)A/B測(cè)試和藍(lán)綠部署、金絲雀發(fā)布，以及灰度發(fā)布、流量切分。