伴隨著買單俠業(yè)務的快速發(fā)展，能夠支持獨立開發(fā)、獨立部署、獨立擴展的微服務在秦蒼得到了廣泛應用和蓬勃發(fā)展，短短3年左右時間，已經(jīng)發(fā)展到了300+個微服務，并且還在快速增長中。

研發(fā)逐漸意識到伴隨著微服務規(guī)?；脑鲩L，必需要重視微服務的基礎設施建設(API網(wǎng)關、服務注冊中心、調用鏈跟蹤等)才能保持開發(fā)效率和產(chǎn)品的質量。

API網(wǎng)關作為訪問微服務的大門, 是訪問后臺服務的入口，作為最常用的基礎服務之一，其重要性不言而喻。在買單俠微服務的發(fā)展道路上，經(jīng)過了以下摸索發(fā)展階段，希望能給規(guī)?；瘧梦⒎盏墓コ仟{們更多參考和啟發(fā)。

原始時代-沒有API網(wǎng)關的數(shù)百微服務

最初在沒有API網(wǎng)關的日子，我們部署在阿里云上的服務全部使用阿里云的負載均衡SLB直接進行通信。不同的服務不同的環(huán)境配置不同的SLB地址，運維維護的配置文件存在著大量的SLB地址，稍不留意配置錯誤，就會影響發(fā)布上線。

客戶端直接和各個服務直接交互，客戶端和服務端有強耦合。服務端的波動會直接影響到客戶端。

各個服務也是任意調用，公司服務調用的拓撲圖，其實是一個混亂、混沌的蜘蛛網(wǎng)狀圖。對數(shù)百個這樣微服務而言，沒有隔離、沒有把控，不僅容易引起問題，而且各個服務的通用需求認證、監(jiān)控、轉換等功能需要多次實現(xiàn)，無法重用。

青銅時代-面向服務的網(wǎng)關Spring Cloud Zuul

痛則思變，買單俠的微服務需要一個入口，就是API網(wǎng)關，幫助解耦客戶端和具體后端微服務，它在微服務架構中很像面向對象設計模式中的Facade模式封裝內部系統(tǒng)的架構，并且提供API給各個客戶端作為服務入口。

由于買單俠微服務技術路線采用Spring Cloud,基于Netflix開源的基礎組件搭建基礎設施，例如服務注冊中心Eureka,在API網(wǎng)關選項中，考慮和Eureka、Ribbon等的兼容，Zuul成了我們的不二選擇。

作為API網(wǎng)關，Zuul能根據(jù)簡單配置就能完成PATH和URL的路由映射轉發(fā)。

Zuul提供了一個技術框架從請求抵達(pre)，請求路由(route)到請求結束(post)以及請求出錯(error)各個階段Zuul都有專門類型的過濾器filter及示例，參見下圖。開發(fā)可以在請求路由轉發(fā)過程中的各個階段實現(xiàn)自己的過濾器完成邏輯控制。

Zuul可以定時掃描指定目錄下用戶自己實現(xiàn)的groovy過濾器，通過groovy類加載器動態(tài)加載，從而在不用重啟API網(wǎng)關下達到動態(tài)添加、更新過濾器。

由于買單俠的微服務使用了基于Spring Cloud Netflix的Eureka作為服務注冊發(fā)現(xiàn)，Zuul也能作為Eureka Client從Eureka Server自動發(fā)現(xiàn)注冊在上面的服務。

這樣服務名可以作為發(fā)往網(wǎng)關請求的RootPath，比如業(yè)務線定義了一個API： /user 給手機端，以前得在Zuul添加mapping, /user --> /serviceName/user, 添加時需要改APIGateway的配置，改完需要重啟。

現(xiàn)在，只要暴露給手機端是/demo-service/user, demo-service是服務名，經(jīng)過Zuul時不用任何配置，它會根據(jù)eureka的服務名自動routing到demo-service, 然后調用user,所以serviceName 可以作為RootPath。無需額外配置，非常方便。

在產(chǎn)品線入口，買單俠開始引入Zuul作為API網(wǎng)關作為API門戶管理轉發(fā)請求到后端服務，并支持了請求校驗和跨域功能。走出了原始時代的混沌。

白銀時代-支持灰度發(fā)布的服務分組入口Zuul

Zuul開始幫助我們解耦了客戶端和具體后端微服務，但對于上百微服務的規(guī)?；芾硖魬?zhàn)一直存在，我們希望能達到微服務的分組和系統(tǒng)化管理。

比如一條產(chǎn)品線，可能會有直銷商城、賬務、審核、基礎應用服務(字典服務)等業(yè)務系統(tǒng)(分組的服務)。而每個分組，會期望在請求抵達自己業(yè)務系統(tǒng)中做一些通用操作。

在這種背景下，我們期望Zuul成為服務分組后各個業(yè)務系統(tǒng)自己的入口服務。為此，我們改造了我們服務發(fā)現(xiàn)的調用方式。

類型調用方式

服務分組內服務發(fā)現(xiàn)直接調用

跨服務分組的服務發(fā)現(xiàn)調用發(fā)給Zuul，再由Zuul轉發(fā)到具體服務

服務分組內的服務每個服務注冊到Eureka的metadata中專門有一項說明自己服務分組內的入口API網(wǎng)關Zuul的服務ID。然后服務調用時，先發(fā)現(xiàn)對應服務的Zuul是否和自己本身分組的Zuul服務ID一樣，是就直接調用，否則請求自動發(fā)往對應服務Zuul，然后路由轉發(fā)到對應服務。

Zuul可以自治化管理自己業(yè)務系統(tǒng)。比如我們要對一個業(yè)務系統(tǒng)中的部分服務做灰度發(fā)布。那么只需要更改直銷商城業(yè)務系統(tǒng)API網(wǎng)關。

所以我們在Zuul里實現(xiàn)了灰度發(fā)布的策略管理，可以選擇權重策略，白名單策略，用戶區(qū)域策略等對用戶進行自定義路由分流。

比如白名單策略，Zuul可以根據(jù)請求里的header信息，例如用戶token來判斷是否白名單中用戶路由到指定服務，這樣發(fā)布系統(tǒng)時，可以在舊服務在線情況下，發(fā)布新版本服務。讓我們的QA作為白名單策略中用戶路由到新版本服務系統(tǒng)中進行測試。測試通過后再切換流量到新版本服務，關閉老服務。

另外，買單俠微服務部署開始應用docker技術解決快速部署并達到跨環(huán)境標準一致。上百微服務不可能一次性遷移到容器環(huán)境，我們采取了分業(yè)務系統(tǒng)，按照服務分組逐步遷移的方式。這里的一個挑戰(zhàn)是服務容器化后，基于overlay網(wǎng)絡，有了獨立于阿里云ECS機器的容器IP，現(xiàn)在注冊到Eureka的就是容器IP。

在同一個集群內，即容器化的服務間基于容器IP是可以相互訪問，但是集群外，即非容器化的服務根據(jù)容器IP是沒法訪問容器化的服務，網(wǎng)絡是不同的。

阿里云容器平臺推薦的遷移方案是給每個容器化服務綁定SLB(server load balance)一個靜態(tài)IP地址來實現(xiàn)容器集群外服務訪問容器服務。但是對于上百規(guī)模的微服務，每個服務配置SLB是巨大的工程，特別我們還有QA,Staging,Production三套環(huán)境，工作量翻了三倍。

API網(wǎng)關Zuul在這里繼續(xù)扮演了極其重要的角色，簡化解決了我們的這個遷移問題。我們僅僅把API網(wǎng)關Zuul作為每個服務分組的代理入口綁定了SLB，并且把這個靜態(tài)IP作為Zuul的hostname注冊到Eureka。服務分組外的服務對容器內服務1的訪問包括下面幾步：

1. 先獲取到該服務1注冊到Eureka的metadata,得到服務分組入口Zuul service ID。從Eureka中查到Zuul注冊的hostname即SLB靜態(tài)IP地址。

2. 按照SLB發(fā)送請求給Zuul,請求路徑中攜帶服務1的serviced.

3. Zuul根據(jù)serviceId自動路由到服務1。

由此可見，Zuul作為每個服務分組的入口在買單俠微服務體系中作用巨大，解決了灰度發(fā)布、容器遷移等一系列關鍵問題，并將繼續(xù)扮演舉足輕重的角色。

黃金時代-面向終端用戶的出入口網(wǎng)關Nginx

當眾多服務分組有了自己的入口Zuul,在產(chǎn)品線面向用戶的入口處網(wǎng)關又發(fā)現(xiàn)了一種尷尬情況。

原來有一個直接面向用戶的Zuul將用戶請求轉發(fā)給后臺服務,現(xiàn)在還有一個管理服務分組的入口網(wǎng)關，將服務分組外的后臺請求轉發(fā)給組內服務。

出現(xiàn)了兩個入口!

同時，Zuul由于啟用了Spring Boot Actuator,暴露了Log, Trace, Dump等敏感Endpoint,在安全方面引起了我們的擔心顧慮。并且基于服務注冊發(fā)現(xiàn)，理論上你知道serviceId可以把任意請求轉發(fā)給對應服務。

面向終端用戶，Zuul是最合適的入口選擇嗎?

并且在我們性能壓力測試下，Zuul雖然適合編程實現(xiàn)業(yè)務邏輯，本身的性能并不占優(yōu)，特別更改配置重啟服務通常要2分鐘左右非常慢。通常要部署多個Zuul容器保證高可用，還是有一定資源消耗。

對于終端用戶，隱藏內部服務細節(jié)，并提供高性能的轉發(fā)服務，Nginx其實是非常不錯的選擇。并在我們產(chǎn)品線開始推廣使用。并且在一條產(chǎn)品線上可被多個業(yè)務系統(tǒng)(服務分組)共享使用，比如直銷商城和直銷客戶，從而提高資源利用率。

解決了入口問題，出口其實也是非常需要引起重視的。

我們的微服務會有一些對外渠道，比如資金源需要訪問不同的資金渠道，支付需要訪問不同的支付渠道，不同渠道往往有不同的安全性要求，例如僅僅允許運行IP白名單的服務訪問，需要特定證書。之前訪問這些渠道都是由具體服務自己直接負責。

當業(yè)務規(guī)模，服務規(guī)模增大，對外出口的訪問管理也容易引起混亂，對統(tǒng)一出口的需求變得強烈。

容器部署讓統(tǒng)一出口成為必要需求，因為容器會在集群內機器上隨機部署，具有隨機IP，而給容器集群內所有機器配置白名單，裝證書并不現(xiàn)實。

我們需要統(tǒng)一的API出口網(wǎng)關，在這里我們可以統(tǒng)一管理證書，提供固定IP。實際上就是一個代理幫助我們轉發(fā)請求到外部渠道服務。

Nginx再次以優(yōu)異表現(xiàn)勝任了我們的需求，擔當我們的出口API網(wǎng)關，我們親切地稱呼它outlets。

每臺Nginx代理固定在一臺ECS上，提供ECS固定IP給外部數(shù)據(jù)提供商。Nginx啟動速度快，并能動態(tài)加載配置，平滑升級。容器可以訪問出口API網(wǎng)關來代理訪問外部依賴服務。

白金時代-接入層網(wǎng)關探索升級從Nginx到Kong

在我們使用Nginx作為出入口網(wǎng)關過程中，我們也關注到基于Nginx的Kong。作為接入層網(wǎng)關，Kong繼承Nginx的優(yōu)異性能表現(xiàn)并且體現(xiàn)了更多的擴展性和網(wǎng)關管理功能。

基于OpenResty,所有對Kong的配置操作都通過REST API完成并且即時生效。

由于Kong基于Nginx，很多基本配置都可以映射到Nginx。

Kong一個非常吸引人的特色是它的豐富插件，有認證，安全，限流，監(jiān)控，轉換，日志等多種類型插件，能輕松配置完成訪問控制，黑白名單設置，限流，跨域等等功能。

當然，由于Kong的靈活性，對于Kong的權限管理和使用流程上還有待規(guī)范。

不久我們可預期各條產(chǎn)品線不僅具有對外的接入層網(wǎng)關Kong,在這里可以基于Kong的插件實現(xiàn)業(yè)務無關的出入口基本管理，而且在它后面是由獨立Zuul作為入口的各個業(yè)務系統(tǒng)，開發(fā)可以利用Zuul實現(xiàn)自己業(yè)務相關的入口控制管理。

總結

買單俠微服務的API網(wǎng)關演化之路著重分享了買單俠微服務體系中，API網(wǎng)關建設從無到有，從少到多，從單一到多元化的演進過程，下表總結了目前我們主要采用的網(wǎng)關技術方案。

在保障基本路由轉發(fā)外，API網(wǎng)關更在買單俠的微服務治理中扮演重要角色，隨著規(guī)?；芾砗蜆I(yè)務需求，其在服務分組管控、灰度發(fā)布、熔斷監(jiān)控、容器化遷移、統(tǒng)一出入口管理等場景都有深入實踐，并且還在不斷演進發(fā)展中。

作者簡介

林丹，現(xiàn)任上海秦蒼(買單俠)信息科技有限公司基礎架構部架構師，畢業(yè)于哈爾濱工業(yè)大學軟件工程專業(yè)，加入秦蒼之前，曾在Autodesk、Blackboard公司任職。專注于SpringCloud、Docker、云計算、SaaS Performance、持續(xù)交付等相關領域，積累了豐富的互聯(lián)網(wǎng)架構設計經(jīng)驗。目前主要負責微服務基礎設施、Docker及CI/CD、前端等相關工作。