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

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

API網關作為訪問微服務的大門, 是訪問后臺服務的入口，作為最常用的基礎服務之一，其重要性不言而喻。在買單俠微服務的發展道路上，經過了以下摸索發展階段，希望能給規模化應用微服務的攻城獅們更多參考和啟發。

原始時代-沒有API網關的數百微服務

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

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

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

青銅時代-面向服務的網關Spring Cloud Zuul

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

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

作為API網關，Zuul能根據簡單配置就能完成PATH和URL的路由映射轉發。

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

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

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

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

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

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

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

Zuul開始幫助我們解耦了客戶端和具體后端微服務，但對于上百微服務的規模化管理挑戰一直存在，我們希望能達到微服務的分組和系統化管理。

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

在這種背景下，我們期望Zuul成為服務分組后各個業務系統自己的入口服務。為此，我們改造了我們服務發現的調用方式。

類型調用方式

服務分組內服務發現直接調用

跨服務分組的服務發現調用發給Zuul，再由Zuul轉發到具體服務

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

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

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

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

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

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

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

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

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

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

3. Zuul根據serviceId自動路由到服務1。

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

黃金時代-面向終端用戶的出入口網關Nginx

當眾多服務分組有了自己的入口Zuul,在產品線面向用戶的入口處網關又發現了一種尷尬情況。

原來有一個直接面向用戶的Zuul將用戶請求轉發給后臺服務,現在還有一個管理服務分組的入口網關，將服務分組外的后臺請求轉發給組內服務。

出現了兩個入口!

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

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

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

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

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

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

當業務規模，服務規模增大，對外出口的訪問管理也容易引起混亂，對統一出口的需求變得強烈。

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

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

Nginx再次以優異表現勝任了我們的需求，擔當我們的出口API網關，我們親切地稱呼它outlets。

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

白金時代-接入層網關探索升級從Nginx到Kong

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

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

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

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

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

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

總結

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

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

作者簡介

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