APIGateway（APIGW/API網關）宿接，顧名思義馆揉，是出現(xiàn)在系統(tǒng)邊界上的一個面向API的、串行集中式的強管控服務撤缴，這里的邊界是企業(yè)IT系統(tǒng)的邊界饿悬，主要起到隔離外部訪問與內部系統(tǒng)的作用令蛉。在微服務概念的流行之前，API網關的實體就已經誕生了狡恬，例如銀行珠叔、證券等領域常見的前置機系統(tǒng)，它也是解決訪問認證弟劲、報文轉換祷安、訪問統(tǒng)計等問題的。
API網關的流行兔乞，源于近幾年來汇鞭，移動應用與企業(yè)間互聯(lián)需求的興起凉唐。移動應用、企業(yè)互聯(lián)霍骄，使得后臺服務支持的對象台囱，從以前單一的Web應用，擴展到多種使用場景腕巡，且每種使用場景對后臺服務的要求都不盡相同玄坦。這不僅增加了后臺服務的響應量血筑，還增加了后臺服務的復雜性绘沉。隨著微服務架構概念的提出，API網關成為了微服務架構的一個標配組件豺总。
一：網關的幾種使用場景
1车伞、面向WebApp
這類場景，在物理形態(tài)上類似前后端分離喻喳，此時的WebApp已經不是全功能的WebApp另玖，而是根據(jù)場景定制、場景化的App表伦。
2谦去、面向MobileApp
這類場景，移動App是后端Service的使用者蹦哼，此時的APIGW還需要承擔一部分MDM（此處是指移動設備管理鳄哭，不是主數(shù)據(jù)管理）的職能。
3纲熏、面向PartnerOpenAPI
這類場景妆丘，主要為了滿足業(yè)務形態(tài)對外開放，與企業(yè)外部合作伙伴建立生態(tài)圈局劲，此時的APIGW需要增加配額勺拣、流控、令牌等一系列安全管控功能鱼填。
4药有、面向PartnerExternalAPI
這類場景，業(yè)界提的比較少苹丸，很多時候系統(tǒng)的建設愤惰，都是為了滿足企業(yè)自身業(yè)務的需要，實現(xiàn)對企業(yè)自有業(yè)務的映射谈跛。當互聯(lián)網形態(tài)逐漸影響傳統(tǒng)企業(yè)時羊苟，很多系統(tǒng)都會為了導入流量或者內容，依賴外部合作伙伴的能力感憾，一些典型的例子就是使用「合作方賬號登錄」蜡励、「使用第三方支付平臺支付」等等令花，這些對于企業(yè)內部來說，都是一些外部能力凉倚。此時的APIGW就需要在邊界上兼都，為企業(yè)內部Service統(tǒng)一調用外部的API做統(tǒng)一的認證、（多租戶形式的）授權稽寒、以及訪問控制扮碧。
在我們講的微服務架構下的API網關，一般指的是前三類使用場景杏糙。即慎王，主要是把企業(yè)內部的API能力，暴露給其他應用或合作伙伴使用宏侍。網關層作為客戶端與服務端的一層擋板赖淤，主要起到了三大類作用：
- 第一類作用是隔離作用，作為企業(yè)系統(tǒng)邊界谅河，隔離外網系統(tǒng)與內網系統(tǒng)咱旱。
- 第二類作用是解耦作用，通過解耦绷耍，使得微服務系統(tǒng)的各方能夠獨立吐限、自由、高效褂始、靈活地調整诸典，而不用擔心給其他方面帶來影響。
- 第三類作用是腳手架作用病袄，提供了一個地點搂赋，方便通過擴展機制對請求進行一系列加工和處理。
二：網關的好處
（1）網關層對外部和內部進行了隔離益缠，保障了后臺服務的安全性脑奠。
（2）對外訪問控制由網絡層面轉換成了運維層面，減少變更的流程和錯誤成本
（3）減少客戶端與服務的耦合幅慌，服務可以獨立發(fā)展宋欺。通過網關層來做映射。
（4）通過網關層聚合胰伍，減少外部訪問的頻次齿诞，提升訪問效率。
（5）節(jié)約后端服務開發(fā)成本骂租，減少上線風險祷杈。
（6）為服務熔斷，灰度發(fā)布渗饮，線上測試提供簡單方案但汞。
（7）便于擴展宿刮。
三：API網關需要考慮的因素
1、安全性問題
企業(yè)在把服務暴露給外部使用時私蕾，首先要確保服務使用的安全僵缺，防止外部的惡意訪問對公司業(yè)務的影響，特別是涉及交易方面的服務踩叭，更是要全面考慮安全性磕潮。為確保安全，需要考慮在通訊鏈路的建立容贝、通訊數(shù)據(jù)的加密自脯、數(shù)據(jù)的完整性、不可抵賴性等方面嗤疯。
2冤今、性能問題
作為企業(yè)API的入口，所有的請求都會經過API網關進行轉發(fā)茂缚，可想而知，對API網關的訪問壓力是巨大的屋谭，有的網站甚至達到每分鐘上千萬的訪問量脚囊。特別是在一些互聯(lián)網企業(yè)，海量的移動終端每時每刻都需要與后端的服務進行交互桐磁，如果不能保證網關的高性能悔耘，企業(yè)在網關層需要投入大量的設備和成本。曾在一家互聯(lián)網公司發(fā)生過我擂，由于網關性能問題衬以，網關的機器數(shù)量，需要與后臺服務器的數(shù)量保持同步增長校摩。這種情況顯然是企業(yè)服務忍受的看峻。
3、高可用問題
API網關作為邏輯上的單點衙吩，一旦發(fā)生問題互妓，將造成企業(yè)服務的不可用，對企業(yè)來說可能造成的致命的影響坤塞。計算短時間的不可用冯勉，也會給企業(yè)帶來直接的經濟損失。所以摹芙，如何保證API網關的7*24小時的穩(wěn)定運行灼狰，網關的自動伸縮、API的熱更新等問題浮禾，都是企業(yè)級的網關需要考慮的交胚。
4坛悉、擴展性問題
前面說到，企業(yè)網關提供了一個腳手架承绸，一些非功能性的問題裸影，例如日志、安全军熏、負載均衡策略轩猩、鑒權等。這些插件會隨著企業(yè)業(yè)務規(guī)模等的變化進行不斷的強化與調整荡澎。這就需要網關層提供這樣一種機制均践，使得可以靈活地進行這些調整和變化，而不用頻繁對網關層進行改動摩幔，確保網關層的穩(wěn)定性彤委。
5、API高效運維的問題
API在上線或衡、發(fā)布過程中焦影，都需要涉及到網關層的配合，例如封断，需要網關層知道API發(fā)布的地址斯辰，API的接口形式、報文格式坡疼，也需要網關層對后臺API進行封裝彬呻。在API調整后，需要作出相應的修改柄瑰。所以闸氮，API網關設計時，需要明確網關層與服務層的職責切分與協(xié)作模式教沾，使得API的管理蒲跨、發(fā)布更加高效。
6详囤、API全生命周期的管理
API服務的全生命周期财骨，包括服務的開發(fā)、測試藏姐、上線發(fā)布隆箩；服務使用的申請、開通羔杨；服務分類分級別的管理捌臊、服務使用情況的監(jiān)控、計費等等兜材。
一個企業(yè)可能會暴露成百上千個API理澎，日常也會經常進行API的發(fā)布逞力、升級、改造糠爬、下架等操作寇荧。對不同的服務，不同的訪問者执隧，需要提供不同的服務訪問策略揩抡。有的商業(yè)API公司，還需要對API的使用進行付費镀琉。所以峦嗤，與API網關配套的，需要一套完善的自助系統(tǒng)屋摔，提供給服務的提供者烁设、管理者、使用者钓试，來對服務的發(fā)布装黑、使用、和運營亚侠。
四：業(yè)界常用的API網關方案
1：Nginx+Lua
基本功能：
（1）靜態(tài)web資源服務器曹体，能夠緩存打開的文件描述符
（2）支持http/imap/pop3/smtp的反向代理；支持緩存硝烂、負載均衡
（3）支持fastcgi(fpm)
（4）模塊化，非DSO機制铜幽，支持過濾器zip壓縮滞谢，SSI以及圖像大小調整
（5）支持SSL
Nginx的擴展功能：
（1）基于名稱和IP的虛擬主機
（2）支持keepalive的保持機制
（3）支持平滑升級
（4）定制訪問日志，支持使用日志緩存區(qū)提高日志存儲性能
（5）支持urlrewrite
（6）支持路徑別名（root或alias指定）
（7）支持基于IP以及用戶的訪問控制
（8）支持傳輸速率限制除抛，并發(fā)限制
性能和高可用性上：
Nginx性能極高狮杨，Nginx先天的事件驅動型設計、全異步的網絡I/O處理機制到忽、極少的進程間切換以及許多優(yōu)化設計橄教，都使得Nginx天生善于處理高并發(fā)壓力下的互聯(lián)網請求。Nginx的穩(wěn)定性也在各大網站得到驗證喘漏。官方提供的常用模塊都非常穩(wěn)定护蝶，每個worker進程相對獨立，master進程在1個worker進程出錯時可以快速“拉起”新的worker子進程提供服務翩迈。支持熱部署持灰，可以不停機更新配置文件、更新日志文件负饲、更新服務器程序版本堤魁。
擴展性上：
Nginx的設計極具擴展性喂链，它完全是由多個不同功能、不同層次妥泉、不同類型且耦合度極低的模塊組成椭微。因此，當對某一個模塊修復Bug或進行升級時盲链，可以專注于模塊自身蝇率，無須在意其他
易用性上：
Nginx使用最自由的BSD許可協(xié)議，允許用戶在自己的項目中直接使用或修改Nginx源碼匈仗，有大量的插件可以利用瓢剿。但是，Nginx模塊需要用C開發(fā)悠轩，而且必須符合一系列復雜的規(guī)則间狂。雖然通過第三方模塊，可以支持Nginx與Perl火架、Lua等腳本語言集成工作鉴象，但對使用者的要求還是很高。
2：SpringCloudZuul
基本功能
- 驗證與安全保障:識別面向各類資源的驗證要求并拒絕那些與要求不符的請求何鸡。
- 審查與監(jiān)控:在邊緣位置追蹤有意義數(shù)據(jù)及統(tǒng)計結果纺弊，從而為我們帶來準確的生產狀態(tài)結論。
- 動態(tài)路由:以動態(tài)方式根據(jù)需要將請求路由至不同后端集群處骡男。
- 壓力測試:逐漸增加指向集群的負載流量淆游，從而計算性能水平。
- 負載分配:為每一種負載類型分配對應容量隔盛，并棄用超出限定值的請求犹菱。
- 靜態(tài)響應處理:在邊緣位置直接建立部分響應，從而避免其流入內部集群吮炕。
- Netflix公司還利用Zuul的功能通過金絲雀版本實現(xiàn)精確路由與壓力測試腊脱。
雖然提供的功能還算豐富，但都比較弱龙亲，很難滿足高要求的場景陕凹。
性能和高可用性:
Zuul處理每個請求的方式是針對每個請求是用一個線程來處理。通常情況下鳄炉，為了提高性能杜耙，所有請求會被放到處理隊列中，從線程池中選取空閑線程來處理該請求迎膜。2016年底泥技，Netflix將它們的網關服務Zuul進行了升級，全新的Zuul2將HTTP請求的處理方式從同步變成了異步，以提升其處理性能珊豹。除了Netflix公司簸呈，目前Zuul在企業(yè)中用的還比較少，性能和穩(wěn)定性方面還有待進一步觀察店茶。
擴展性上
從Zuul的架構圖上可以看出蜕便，Zuul更像是一個過濾器框架，其自身的路由贩幻、日志轿腺、反向代理、ddos預防等功能都是通過過濾器實現(xiàn)的丛楚。提供了PRE族壳、ROUTING、POST和ERROR四個擴展點趣些，可以很容易的添加自定義的過濾器仿荆。
易用性上
Zuul的搭建非常簡便，使用和配置也很簡單坏平。Zuul的開源社區(qū)比較活躍拢操，一直在更新狀態(tài)，但版本不算太穩(wěn)定舶替，在使用的過程中令境，還有一些坑要踩。例如重定向問題顾瞪、異常處理問題舔庶，還沒有解決的很好，需要自己重寫一些filter陈醒。
3.MashapeKong
Kong的一個非常誘人的地方就是提供了大量的插件來擴展應用栖茉，通過設置不同的插件可以為服務提供各種增強的功能。Kong默認插件插件包括：
- 身份認證：Kong提供了BasicAuthentication孵延、Keyauthentication、OAuth2.0authentication亲配、HMACauthentication尘应、JWT、LDAPauthentication認證實現(xiàn)吼虎。
- 安全：ACL（訪問控制）犬钢、CORS（跨域資源共享）、動態(tài)SSL思灰、IP限制玷犹、爬蟲檢測實現(xiàn)。
- 流量控制：請求限流（基于請求計數(shù)限流）洒疚、上游響應限流（根據(jù)upstream響應計數(shù)限流）歹颓、請求大小限制坯屿。限流支持本地、Redis和集群限流模式巍扛。
- 分析監(jiān)控：Galileo（記錄請求和響應數(shù)據(jù)领跛，實現(xiàn)API分析）、Datadog（記錄APIMetric如請求次數(shù)撤奸、請求大小吠昭、響應狀態(tài)和延遲，可視化APIMetric）胧瓜、Runscope（記錄請求和響應數(shù)據(jù)矢棚，實現(xiàn)API性能測試和監(jiān)控）。
- 轉換：請求轉換府喳、響應轉換
Kong本身也是基于Nginx的蒲肋，所以在性能和穩(wěn)定性上都沒有問題。Kong作為一款商業(yè)軟件劫拢，在Nginx上做了很擴展工作肉津，而且還有很多付費的商業(yè)插件。Kong本身也有付費的企業(yè)版舱沧，其中包括技術支持妹沙、使用培訓服務以及API分析插件。
從對上面三種方案的比較中可以看到熟吏，SpringCloudZuul非常適合創(chuàng)業(yè)初期的團隊距糖，快速搭建一個“基本可用”的API網關。Nginx適合有較強研發(fā)團隊牵寺，自主開發(fā)企業(yè)自己的API網關悍引。Kong適合于沒有自身研發(fā)團隊，但需要擁有企業(yè)級API網關能力的公司帽氓。
五：如何設計一個好的企業(yè)級API網關產品
1：功能需求
- API生命周期管理功能：
覆蓋API的定義趣斤、測試、發(fā)布的整個生命周期管理黎休，便捷的日常管理浓领、版本管理，支持熱升級和快速回滾 - 開發(fā)和使用支持功能：
提供頁面調試工具势腮，自動生成API文檔和SDK联贩，大大降低人力成本。 - 安全防護功能：
API請求到達網關需要經過嚴格的身份認證捎拯、權限認證泪幌，才能到達后端服務。支持算法簽名，支持SSL加密祸泪。 - 流量控制功能：
可控制單位時間內API允許被調用次數(shù)吗浩。用來保護企業(yè)的后端服務，實現(xiàn)業(yè)務分級和用戶分級浴滴。支持對API流控拓萌，您可以根據(jù)API的重要程度來配置不同流控，從而保障重要業(yè)務的穩(wěn)定運行升略；支持用戶微王、應用和例外流控，您可以根據(jù)用戶的重要性來配置不同流控品嚣，從而可以保證大用戶的權益炕倘；流控粒度：分鐘、小時翰撑、天罩旋。 - 請求管理功能：
可根據(jù)配置進行參數(shù)類型、參數(shù)值（范圍眶诈、枚舉涨醋、正則、JsonSchema）的校驗逝撬，減少后端對非法請求浴骂、無效請求的資源消耗和處理成本∠艹保可以在API網關定義參數(shù)映射規(guī)則溯警，網關通過映射規(guī)則將后端服務通過映射翻譯成任何形式，以滿足不同用戶的不同需求狡相，從而避免功能重復開發(fā)梯轻。 - 監(jiān)控告警功能：
提供實時、可視化的API監(jiān)控尽棕，包括：調用量喳挑、調用方式、響應時間滔悉、錯誤率蟀悦，讓您能夠清楚的了解API的運行狀況和用戶的行為習慣。
支持自定義報警規(guī)則氧敢，來針對異常情況進行報警儒旬，降低故障處理時間惰许。
提供可訂閱的數(shù)據(jù)分析報表和智能分析。
2：高性能設計
傳統(tǒng)的基于線程的并發(fā)模型（Thread-basedconcurrency）吠谢，為每一個請求分配一個線程或進程。這種模型編程簡單唯袄，可以將處理一個完整請求的代碼編寫在一個代碼路徑中弯屈。這種模型的弊端是，隨著線程(進程)數(shù)的上升恋拷，操作系統(tǒng)在這些線程(進程)之間的頻繁切換资厉，將急劇降低系統(tǒng)的性能。
3：高可用設計
- 無狀態(tài)設計原則蔬顾。
網關層為保證高可以宴偿，易于伸縮，快速啟動诀豁，需要設計成無狀態(tài)的窄刘。用戶的狀態(tài)數(shù)據(jù)我們通常使用session對象來封裝，網關層要設計成無狀態(tài)的舷胜，也就是說娩践，不能由網關來負責session的維護。那由誰來維護session相關的信息呢烹骨？我們是采用cookie+session服務器的方式;- a)用戶在登錄頁完成登錄操作后翻伺，服務器會生成一個登錄session信息，保存起來沮焕，設置個失效時間吨岭，并設置到用戶的cookie里
- b)用戶后續(xù)的每次請求里會帶著這個cookie信息，服務端會對這個cookie信息進行校驗遇汞，通過了就認為是合法用戶未妹，執(zhí)行請求操作
- 優(yōu)雅下線原則
當需要撤掉一臺網關服務的時候，不是直接結束網關進程空入，而是先關閉監(jiān)聽套接字络它，但是繼續(xù)為當前連接的客戶提供服務，所有客戶端的服務完成后歪赢，在把進程關閉化戳。 - Slowstart特性
當網關監(jiān)聽到有一臺新的服務注冊上來時，考慮到有些服務啟動后埋凯，剛開始會有許多初始化的工作点楼，此時服務對請求的響應速度是比較慢的。如果一開始就給這臺服務分配太多的壓力白对，有可能導致服務瞬間被壓垮掠廓。為了避免這種情況，網關層需要考慮支持SlowStart特性甩恼。即蟀瞧，經過一段時間沉颂，逐漸把壓力增加到預設的值。 - 擴展性設計
我們知道悦污，網關對請求的處理铸屉，可以分為三個階段：接受請求、路由并轉發(fā)請求切端、接受服務的返回數(shù)據(jù)并返回給請求者彻坛，除此之外，還有一種情況是處理錯誤踏枣。所以我們也可以在這四個地方添加擴展點昌屉。- （1）接受到請求后
- （2）定位到一個服務，并準備轉發(fā)之前
- （3）接受到服務的返回數(shù)據(jù)椰于，返回給客戶端之前
- （4）當服務調用失敗后
攔截器的處理順序怠益，可以分為兩大類：一類為網關平臺自帶的攔截器，例如安全校驗瘾婿、日志記錄等蜻牢；一類為網關層邏輯開發(fā)的，例如格式轉換等偏陪。一般來說抢呆，網關先執(zhí)行網關平臺自帶的攔截器，再執(zhí)行為了業(yè)務邏輯編寫的攔截器笛谦。當然抱虐，網關也需要提供一種機制，可以較容易地調整攔截器的執(zhí)行順序饥脑。最簡單的一種方法恳邀，就是給每個攔截器定義一個優(yōu)先級，網關按優(yōu)先級順序依次調用各攔截器灶轰。
對網關層來說谣沸，它接收和處理的數(shù)據(jù)都是Request對象，網關層在接收到請求后笋颤，把請求封裝為Request對象乳附，為了讓后續(xù)的filter能夠獲得這個對象，可以考慮把Request對象保存在線程變量中伴澄。
有些攔截器赋除，例如一些調試日志的攔截器，通常情況下都是關閉的非凌，只有在出現(xiàn)問題的時候才需要打開举农。為了保證網關的高可用，網關層必須具備在線啟用或關閉攔截器的能力敞嗡。一般并蝗，網關需要提供restful接口方式祭犯，來關閉和啟用一個攔截器。類似這樣的命令：PUT/apigateway/v1/filters/filterName?enable=value
- 5）API管理與動態(tài)發(fā)布設計
對服務管理來說滚停，分為前端服務管理與后端服務管理。前端服務指的是網關層暴露給客戶端使用的服務API粥惧，后端服務指的是服務層提供的業(yè)務服務API键畴。一個服務暴露給客戶端使用，除了網關層和服務層提供服務的代碼外突雪，還需要配置前端服務與后端服務的映射關系起惕。
網關層API調用服務層API，有多種方式咏删。例如惹想，可以由按照服務層API的服務契約，生成一段客戶端代碼督函，發(fā)布給網關層使用嘀粱。這種方式的弊端是，網關層代碼依賴于服務層代碼辰狡，服務層頻繁修改和調整接口時锋叨，導致網關層的代碼很難維護。
可以通過配置前后端服務映射的方式宛篇，解耦網關層對服務層的依賴娃磺。當服務層的API（例如服務名、參數(shù)名等）發(fā)生變化時叫倍，只需調整映射關系偷卧，無需對網關層的代碼進行調整。網關層按照映射吆倦，自動裝配服務層API所需要的數(shù)據(jù)格式听诸。這樣，網關層團隊與服務層團隊可以相互不受干擾地開發(fā)各自的服務逼庞。
總結：API網關作為企業(yè)能力開放的一個門戶蛇更，除了具備基本的請求轉發(fā)、協(xié)議轉換赛糟、路由等功能派任，以及高性能和高穩(wěn)定性外，還需具備良好的擴展性璧南，已便于網關能力的不斷增強掌逛。在網關實施過程中，要規(guī)劃好網關層與服務層的交互方式司倚，盡量使得網關層與服務層解耦豆混，便于各個團隊工作的獨立性篓像。
轉自普元云。
