容器技術(shù)越來越成熟，應(yīng)用領(lǐng)域也越來越廣，容器的應(yīng)用促進(jìn)了微服務(wù)的快速發(fā)展，也使旨在提升效率和融合開發(fā)運(yùn)維的DevOps迅速落地。容器、微服務(wù)、DevOps就像孿生兄弟，相互依存，相互融合和發(fā)展。隨著容器平臺的建設(shè)落地，微服務(wù)越來越火，越來越多的公司已經(jīng)開始采用或者正在考慮采用微服務(wù)架構(gòu)。但微服務(wù)架構(gòu)應(yīng)用通常是分布式的，一個(gè)業(yè)務(wù)應(yīng)用通常是由眾多的微服務(wù)編排而成，服務(wù)之間的調(diào)用、通信、安全認(rèn)證、訪問控制、負(fù)載均衡、限流限額等需求也帶來了運(yùn)維的復(fù)雜性，實(shí)現(xiàn)微服務(wù)治理是個(gè)不小的難題。如果再把微服務(wù)部署于容器云平臺，則會更加復(fù)雜。目前也有不少的廠商或者公司嘗試開發(fā)微服務(wù)治理平臺，不管基于gRPC或者Istio等，都不是一個(gè)成熟的方案。基于我們銀河證券容器云平臺建設(shè)和微服務(wù)管理治理的實(shí)踐研究，我們提出了使用成熟的API網(wǎng)關(guān)產(chǎn)品來實(shí)現(xiàn)容器云平臺微服務(wù)治理的方案，更快、更便利的實(shí)現(xiàn)微服務(wù)的治理，特別對于傳統(tǒng)行業(yè)IT技術(shù)實(shí)力相對有限的情況下，避免投入大量的人力財(cái)力去做基礎(chǔ)平臺的研發(fā)，更可避免項(xiàng)目失敗所導(dǎo)致的時(shí)間、發(fā)展機(jī)遇的錯(cuò)失。

微服務(wù)治理當(dāng)前面臨的問題

微服務(wù)化帶來了很多好處，比如通過將復(fù)雜單體系統(tǒng)切分為若干個(gè)微服務(wù)來分解和降低耦合性，而且每個(gè)微服務(wù)功能單一，實(shí)現(xiàn)快捷，使得這些微服務(wù)易于被小型的開發(fā)團(tuán)隊(duì)所理解和維護(hù)，相對于單體系統(tǒng)降低了復(fù)雜度。然而微服務(wù)也帶來了很多挑戰(zhàn)，微服務(wù)架構(gòu)是分布式架構(gòu)，單個(gè)微服務(wù)簡單，眾多的微服務(wù)分布式應(yīng)用的復(fù)雜性難以回避，眾多微服務(wù)之間的通信、微服務(wù)事務(wù)處理、微服務(wù)的拆分、服務(wù)注冊、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、路由、監(jiān)控、AB測試、金絲雀發(fā)布、限流、訪問控制等等都帶來了挑戰(zhàn)。特別微服務(wù)部署于容器云平臺，基于當(dāng)前現(xiàn)狀如何治理好微服務(wù)是一個(gè)棘手的具有挑戰(zhàn)性的問題。

1. 常用方案的不足

服務(wù)治理的問題由來已久，服務(wù)治理也是一個(gè)很大的話題。在SOA ESB的時(shí)代就有很多探討，微服務(wù)化盛行之后顯得尤為重要。目前比較流行的微服務(wù)開發(fā)框架是SpringCloud，國內(nèi)也有用Dubbo的，但Dubbo遠(yuǎn)遠(yuǎn)達(dá)不到實(shí)際的要求。SpringCloud雖然提供了很多組件，但都是半成品，作為開發(fā)人員還有很多工作需要做，最終服務(wù)組件的質(zhì)量往往取決于開發(fā)人員的能力，不同開發(fā)人員所實(shí)現(xiàn)的微服務(wù)可能千差萬別；其次，SpringCloud對代碼有侵入性，如果以后要更換開發(fā)框架，需要重寫很多東西，甚至可能不得不推倒重來，代價(jià)高昂；再者，Java語言的特異性，如果要采用其他開發(fā)語言如Go/Python等開發(fā)的微服務(wù)或者不全是Java微服務(wù)，SpringCloud可能就無能為力，無法統(tǒng)一管控。微服務(wù)治理更是難以實(shí)現(xiàn)。

2. 服務(wù)網(wǎng)格（Service Mesh）的不成熟

Service Mesh服務(wù)網(wǎng)格目前是很火熱的存在。很多人鼓吹其為第二代微服務(wù)，不過在我們看來更多是概念炒作，Service Mesh服務(wù)網(wǎng)格描述的是微服務(wù)網(wǎng)絡(luò)，所實(shí)現(xiàn)的是服務(wù)治理能力而不是微服務(wù)。其定義是一個(gè)用來連接、保護(hù)、控制和觀察微服務(wù)的工具。Service Mesh 服務(wù)網(wǎng)格的核心思想就是“流量代理”，通過一個(gè)個(gè)SideCar“代理（Envoy）” 來為微服務(wù)轉(zhuǎn)發(fā)和接收所有流量，而不用去修改微服務(wù)代碼，通過控制這些SideCar代理，就可以實(shí)現(xiàn)微服務(wù)連接、訪問控制、注冊發(fā)現(xiàn)、安全認(rèn)證、負(fù)載均衡、限流熔斷、監(jiān)控等等一系列服務(wù)治理相關(guān)功能，使微服務(wù)的代碼不再需要去實(shí)現(xiàn)服務(wù)治理邏輯，簡化了開發(fā)并提高了敏捷效率。說到底其是服務(wù)治理工具，談不上第二代微服務(wù)。
作為Service Mesh的一種實(shí)現(xiàn)，Istio 1.0剛剛GA（General Availability）,雖然鼓吹說可以上生產(chǎn)，但依然需要時(shí)間和實(shí)踐的檢驗(yàn)。服務(wù)網(wǎng)格會隨著微服務(wù)數(shù)量的增加而成倍的增加復(fù)雜度，這也是需要進(jìn)一步檢驗(yàn)的方面。

3. 微服務(wù)治理的復(fù)雜性

微服務(wù)架構(gòu)一定程度上是為了解決伸縮性問題、運(yùn)行效率問題和開發(fā)效率問題。

單體應(yīng)用功能是集中式的，難以滿足伸縮性、也就是擴(kuò)展要求。微服務(wù)是分布式的，伸縮性是其最重要價(jià)值所在；

單體應(yīng)用隨著功能的累積，越來越難以更新和維護(hù)，而微服務(wù)專注于只提供一種功能，可以橫向和縱向兩個(gè)維度伸縮，開發(fā)簡單，開發(fā)速度也會大幅提升，與其他微服務(wù)共同編排組成一個(gè)或多各業(yè)務(wù)應(yīng)用系統(tǒng)，形成微服務(wù)生態(tài)系統(tǒng)；

單體應(yīng)用包含了所有的功能，這些功能往往是緊耦合的，缺乏彈性，運(yùn)行效率往往也不高，微服務(wù)則獨(dú)立自治而輕量，運(yùn)行簡單而快捷。把一個(gè)單體應(yīng)用拆分為微服務(wù)往往是處于伸縮性和效率方面的考慮。每個(gè)微服務(wù)的效率提升帶來整個(gè)業(yè)務(wù)應(yīng)用的效率提升。但隨著微服務(wù)量的增加，比如何管理好這些微服務(wù)并使其高效則并不容易。

另外其彈性伸縮要求非常適合容器云平臺的彈性伸縮特性，因此往往和容器平臺結(jié)合，部署于容器云平臺，這也更增加了微服務(wù)治理的難度，涉及的東西越多，復(fù)雜性越大，需要考慮如何更好的利用容器平臺的優(yōu)點(diǎn)來簡化復(fù)雜性。

以微服務(wù)架構(gòu)實(shí)現(xiàn)的業(yè)務(wù)應(yīng)用，通常是分布式的，有眾多的微服務(wù)組件，彼此有依賴性。一個(gè)微服務(wù)簡單，但有眾多的微服務(wù)相互關(guān)聯(lián)就復(fù)雜化了，每個(gè)業(yè)務(wù)應(yīng)用可能有多個(gè)服務(wù)編排而成，每個(gè)服務(wù)又可能部署不同數(shù)量的服務(wù)實(shí)例。單體應(yīng)用不存在的微服務(wù)治理問題也由于微服務(wù)生態(tài)系統(tǒng)中眾多的微服務(wù)和微服務(wù)實(shí)例，以及承載微服務(wù)的基礎(chǔ)設(shè)施容器云平臺，隨著微服務(wù)量的增加而使其運(yùn)營和運(yùn)維復(fù)雜化，使微服務(wù)治理復(fù)雜化。

4. 敏捷性需求

引入任何一個(gè)產(chǎn)品或者一種技術(shù)或者一種方法，目的都是為了快速的解決面臨的問題，也就是要求敏捷性。新產(chǎn)品新技術(shù)新方法如果無法作到敏捷，也就失去了采用其的重要價(jià)值。采用微服務(wù)一個(gè)重要的原因也效率問題。在應(yīng)用微服務(wù)提高開發(fā)效率和運(yùn)行效率的同時(shí)，不能帶來服務(wù)治理等的復(fù)雜化。雖然微服務(wù)分布式架構(gòu)和部署于容器云平臺增加了運(yùn)維的復(fù)雜性，復(fù)雜性同時(shí)帶來了風(fēng)險(xiǎn)，但復(fù)雜性并非我們設(shè)計(jì)的初衷，風(fēng)險(xiǎn)更不是我們想要的。化繁為簡、簡化運(yùn)維、控制風(fēng)險(xiǎn)、提高效率、實(shí)現(xiàn)敏捷是基礎(chǔ)的要求。
常用的開發(fā)框架都是半成品，需要很多的工作量，如果能實(shí)現(xiàn)通過規(guī)則或策略配置就可以實(shí)現(xiàn)微服務(wù)的大部分治理能力，比用SpringCloud等去實(shí)現(xiàn)要敏捷的多。微服務(wù)實(shí)現(xiàn)關(guān)注的應(yīng)是業(yè)務(wù)邏輯，不應(yīng)該去關(guān)注服務(wù)治理的問題。所有非業(yè)務(wù)邏輯的功能盡可能的交給服務(wù)治理層來實(shí)現(xiàn)，這樣才能具有敏捷性。所謂術(shù)業(yè)有專攻，做到因?yàn)閷I(yè)，所以敏捷！

5. 安全挑戰(zhàn)

速度和敏捷不應(yīng)該損害安全性，任何時(shí)候安全都是第一位的。安全也是微服務(wù)可用性的一個(gè)重要指標(biāo)。如果客戶端直接以非安全和非管理的方式連接和調(diào)用實(shí)現(xiàn)的后端微服務(wù)，那是存在嚴(yán)重的安全隱患的。要訪問這些后端的微服務(wù)需要以受管理的方式訪問，不能無序，需要保證安全。
微服務(wù)生態(tài)系統(tǒng)擁有眾多的組件微服務(wù)，這些組件服務(wù)相互依存，微服務(wù)與微服務(wù)生態(tài)就像一個(gè)人之于人類社會，接觸面越大、關(guān)系網(wǎng)越復(fù)雜、接觸量越多，安全挑戰(zhàn)就越大。

要保證安全，就像人類一樣筑座城池，把自己保護(hù)起來。但完全保護(hù)起來不跟外面接觸也不行，需要開個(gè)城門，建個(gè)關(guān)口，實(shí)現(xiàn)對外交流。每個(gè)城池就是一個(gè)微服務(wù)，城門就是API，在城門口實(shí)現(xiàn)進(jìn)出安全檢查、管控，就類似于我們說的微服務(wù)API網(wǎng)關(guān)。一個(gè)國家可能有很多座城池，是一個(gè)小生態(tài)，要保護(hù)整個(gè)國家可能需要建立起一條長城，對外交流也是開個(gè)關(guān)口，這就實(shí)現(xiàn)了統(tǒng)一的微服務(wù)安全管控。多個(gè)國家形成一個(gè)大生態(tài)，就是整個(gè)微服務(wù)生態(tài)系統(tǒng)，通過API網(wǎng)關(guān)來實(shí)現(xiàn)安全管控。

6. 服務(wù)接口標(biāo)準(zhǔn)化要求

微服務(wù)架構(gòu)的挑戰(zhàn)是實(shí)現(xiàn)服務(wù)的標(biāo)準(zhǔn)化，以及保證服務(wù)的可靠性和可用性。車同轍、書同文、量同器、貨同幣。微服務(wù)實(shí)現(xiàn)可以是不同的語言、不同的協(xié)議、不同的名稱、不同的字段類型等，這些微服務(wù)之間如果要交互，就面臨著眾多的轉(zhuǎn)換問題，類似于曾經(jīng)的系統(tǒng)集成問題，所以后來出現(xiàn)了ESB，但ESB并沒有從根本上解決問題。所以不管微服務(wù)是怎么實(shí)現(xiàn)的，微服務(wù)接口API需要標(biāo)準(zhǔn)化。
一種實(shí)現(xiàn)方式是在微服務(wù)前面加個(gè)Adapter適配器，由Adapter來實(shí)現(xiàn)轉(zhuǎn)換。對微服務(wù)來說它有了API網(wǎng)關(guān)，其可以承擔(dān)其Adapter的職責(zé)，因此API網(wǎng)關(guān)層是可以提供標(biāo)準(zhǔn)化的接口的。

7. 擴(kuò)展性、負(fù)載均衡、路由、限流等需求

成功的可伸縮微服務(wù)生態(tài)系統(tǒng)需要完善且穩(wěn)定的基礎(chǔ)設(shè)施的支撐。微服務(wù)的彈性擴(kuò)展性通常是基于完善的容器云平臺基礎(chǔ)設(shè)施服務(wù)。彈性并不是我們說起來這么簡單。微服務(wù)的彈性依賴于基礎(chǔ)資源的彈性，依賴于資源調(diào)度的能力，依賴于服務(wù)伸縮的策略等。微服務(wù)的彈性伸縮可以基于容器平臺的彈性伸縮能力，但伸縮策略并不是固定的，不同場景需要配置不同的伸縮策略，特別是在收縮時(shí)，需要保證業(yè)務(wù)請求已經(jīng)被處理完成且不會有新的業(yè)務(wù)請求到來。這就需要靠負(fù)載均衡路由策略等實(shí)現(xiàn)。每個(gè)微服務(wù)對于不同的用戶可能會采用不同的服務(wù)策略，提供不同的業(yè)務(wù)流量，這面臨這限流限額等需求。另外在微服務(wù)出現(xiàn)異常情況下，能實(shí)現(xiàn)異常遷移、錯(cuò)誤修復(fù)、容錯(cuò)等，或者達(dá)到某種熔斷閥值暫停服務(wù)。
這些能力固然可以在容器云平臺上和其他工具集成來實(shí)現(xiàn)，但會使整個(gè)平臺運(yùn)維復(fù)雜化。復(fù)雜化不是我們設(shè)計(jì)的初衷，所以需要換個(gè)思路。

微服務(wù)治理思路

SpringCloud等微服務(wù)治理涉及眾多的組件需要自己開發(fā)搭建，這是一個(gè)挺大的工作量。為每個(gè)微服務(wù)都實(shí)現(xiàn)一個(gè)API網(wǎng)關(guān)，來對外提供統(tǒng)一的接口，實(shí)現(xiàn)注冊、轉(zhuǎn)換、路由、限流、負(fù)載均衡等能力又使API網(wǎng)關(guān)職責(zé)過重，使微服務(wù)生態(tài)復(fù)雜化。如果把每個(gè)微服務(wù)的這些非業(yè)務(wù)邏輯能力要求都提取出來，放在一個(gè)公用的API網(wǎng)關(guān)上去實(shí)現(xiàn)，使每個(gè)微服務(wù)專注于其業(yè)務(wù)邏輯的開發(fā)，就會簡化開發(fā)，提升敏捷性。公用的統(tǒng)一的API網(wǎng)關(guān)上實(shí)現(xiàn)微服務(wù)的注冊、轉(zhuǎn)換、路由、流控等，映射為一個(gè)標(biāo)準(zhǔn)的API對外提供服務(wù)。這樣既滿足了微服務(wù)開發(fā)敏捷性的要求，也是簡化微服務(wù)治理的需求。微服務(wù)所有的安全認(rèn)證、訪問控制等從微服務(wù)本身剝離出來，通過統(tǒng)一的API網(wǎng)關(guān)組件定義策略配置來實(shí)現(xiàn)微服務(wù)的安全管控和服務(wù)治理能力。

我們希望微服務(wù)不會隨著量的增加而帶來運(yùn)維和治理的復(fù)雜性，也希望能快捷的接入不同協(xié)議不同格式不同類型的微服務(wù)業(yè)務(wù)應(yīng)用和業(yè)務(wù)服務(wù)，這就可能需要一個(gè)統(tǒng)一的層次來完成這些能力，而不用每個(gè)微服務(wù)都實(shí)現(xiàn)一個(gè)sidecar Gateway；也可以容易的使用新技術(shù)替代舊技術(shù)。這就是統(tǒng)一的API網(wǎng)關(guān)服務(wù)。如果我們滿足了這些要求，微服務(wù)架構(gòu)將會帶來敏捷、可靠和高可用，提升效率，并減少風(fēng)險(xiǎn)。

API網(wǎng)關(guān)

實(shí)施微服務(wù)可能不可或缺的一個(gè)很重要的組件就是服務(wù)網(wǎng)關(guān)。網(wǎng)關(guān)，顧名思義，網(wǎng)絡(luò)關(guān)口，擔(dān)負(fù)著安全檢查、認(rèn)證授權(quán)、路由分發(fā)、流量控制、熔斷保護(hù)等重要的職責(zé)。API網(wǎng)關(guān)，那就是API的網(wǎng)絡(luò)關(guān)口、通道，是整個(gè)微服務(wù)平臺的咽喉，API請求應(yīng)答必經(jīng)之路。為了利用容器云彈性伸縮等特性，結(jié)合微服務(wù)的優(yōu)點(diǎn)，部署微服務(wù)于容器云平臺，則API網(wǎng)關(guān)的實(shí)施部署則會顯得更復(fù)雜些。
API網(wǎng)關(guān)（API Gateway）是一個(gè)服務(wù)器，是調(diào)用服務(wù)的唯一節(jié)點(diǎn)和請求應(yīng)答出入口。API Gateway封裝內(nèi)部系統(tǒng)的架構(gòu)，并且提供API給各個(gè)客戶端。通常情況下它還需要實(shí)現(xiàn)其他功能，如認(rèn)證授權(quán)、訪問控制、路由、負(fù)載均衡、緩存、日志、限流限額、轉(zhuǎn)換、映射、過濾、熔斷、注冊、服務(wù)編排、API管理、監(jiān)控、統(tǒng)計(jì)分析等等。
從API網(wǎng)關(guān)的能力來看，我們可以理解其重要性。一夫當(dāng)關(guān)，萬夫莫開。其不但是整個(gè)服務(wù)系統(tǒng)的安全屏障，也承擔(dān)著很多服務(wù)治理的能力。所以實(shí)現(xiàn)或者選擇一個(gè)好的API網(wǎng)關(guān)，是建設(shè)容器云和微服務(wù)體系中一個(gè)至關(guān)重要的事項(xiàng)。這也決定了API網(wǎng)關(guān)的部署，要盡可能的減少接觸面。
微服務(wù)對外可以提供統(tǒng)一的接口API，可以在API網(wǎng)關(guān)層通過對API的治理實(shí)現(xiàn)對微服務(wù)的治理。

API網(wǎng)關(guān)在微服務(wù)治理中的價(jià)值

很多人對于微服務(wù)API網(wǎng)關(guān)也都有比較深入的介紹。一個(gè)重要的原因是微服務(wù)通信、微服務(wù)重構(gòu)、協(xié)議轉(zhuǎn)換等的需要，API網(wǎng)關(guān)還可以提供更多能力實(shí)現(xiàn)微服務(wù)治理。

1. API網(wǎng)關(guān)提供了一個(gè)穩(wěn)定可重用接口層

API網(wǎng)關(guān)首先隔離了內(nèi)部和外部服務(wù)，所有外部服務(wù)通過API網(wǎng)關(guān)所暴露的標(biāo)準(zhǔn)API訪問內(nèi)部服務(wù)，提供了相對穩(wěn)定的API接口，隱藏了服務(wù)的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，保障后臺服務(wù)的安全性。
這方面有眾多的應(yīng)用場景：
（1）. 一個(gè)服務(wù)可以在API網(wǎng)關(guān)映射為不同的API接口，相當(dāng)于提供了多種的服務(wù)能力。也就是提供了接口便利的重用能力。
一個(gè)后臺服務(wù)通過API網(wǎng)關(guān)可以映射為多個(gè)不同的API接口，以滿足不同的客戶端調(diào)用需求，比如有個(gè)服務(wù)實(shí)現(xiàn)了按照業(yè)務(wù)類型查詢業(yè)務(wù)數(shù)據(jù)，可能某個(gè)客戶就是特定的業(yè)務(wù)類型，在API網(wǎng)關(guān)就可以映射一個(gè)API，使用固定的業(yè)務(wù)類型值，服務(wù)于特定用戶。

不同API可以滿足不同SLA需求，節(jié)約后端開發(fā)成本。
（2）.只要API不變，對應(yīng)的服務(wù)只要是兼容性的更新，都不影響客戶端對該API的調(diào)用，提供了接口的穩(wěn)定性。

API相對穩(wěn)定，API實(shí)現(xiàn)是不固定的，Client /Server都可能是不固定的，但API層是穩(wěn)定的。API（Application Programming Interface，應(yīng)用編程接口）則提供了一個(gè)穩(wěn)定的接口層。接口的實(shí)現(xiàn)可以變，只要接口不變，調(diào)用接口的應(yīng)用就不需要改變。
同時(shí)對外訪問控制由網(wǎng)絡(luò)層面轉(zhuǎn)換成網(wǎng)關(guān)應(yīng)用層面，減少變更流程和錯(cuò)誤成本
（3）.不同服務(wù)定義為不同的API，非兼容更新的服務(wù)定義不同的API。不影響原來的接口版本。

（4）.隔離內(nèi)部和外部服務(wù)，隱藏了服務(wù)實(shí)現(xiàn)細(xì)節(jié)。業(yè)務(wù)應(yīng)用只需要關(guān)注API，不管API對應(yīng)的服務(wù)是什么，由誰提供。

實(shí)現(xiàn)內(nèi)外隔離，隱藏了服務(wù)的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，保障后臺服務(wù)的安全性。也降低客戶端和服務(wù)的耦合度，阻斷服務(wù)依賴，服務(wù)獨(dú)立運(yùn)行，通過網(wǎng)關(guān)層實(shí)現(xiàn)按服務(wù)映射，服務(wù)編排，縮減外部調(diào)用頻次，提升訪問效率。
隔離內(nèi)外部服務(wù)，也為微服務(wù)的擴(kuò)展提供了便利，在應(yīng)用層面可以利用容器的伸縮特性實(shí)現(xiàn)應(yīng)用服務(wù)實(shí)例的自動(dòng)彈性伸縮，實(shí)現(xiàn)應(yīng)用服務(wù)的高可用。

2. API網(wǎng)關(guān)是平臺的安全屏障

API網(wǎng)關(guān)提供安全和保護(hù)能力，阻止客戶端應(yīng)用以非安全和非管理的方式直接訪問API，保護(hù)開放的應(yīng)用。這是API網(wǎng)關(guān)最重要的能力之一。隔離內(nèi)外服務(wù)也就減少對外暴露的服務(wù)可能，以增加系統(tǒng)安全性。在API接口層實(shí)現(xiàn)授權(quán)認(rèn)證、訪問控制、防范威脅和OWASP漏洞、防御性緩存、通過SSO和統(tǒng)一身份管理來等來提高安全性，為應(yīng)用程序、移動(dòng)和IoT提供端到端的安全機(jī)制。也可能需要在API網(wǎng)關(guān)實(shí)現(xiàn)流量控制、限額、過濾、熔斷、服務(wù)優(yōu)先級控制、超時(shí)處理、負(fù)載均衡等機(jī)制來保護(hù)應(yīng)用服務(wù)的安全。
安全第一，就像我們的社會交通一樣，第一要保證安全的條件下快速通過。這也是在實(shí)現(xiàn)或選擇API網(wǎng)關(guān)時(shí)首先要考慮的問題。
安全涉及的問題也比較多，API網(wǎng)關(guān)層通常要實(shí)現(xiàn)身份統(tǒng)一認(rèn)證，可對接統(tǒng)一認(rèn)證中心、權(quán)限中心，實(shí)現(xiàn)授權(quán)認(rèn)證、訪問控制等功能。為了最小化延遲，API網(wǎng)關(guān)層邏輯要盡可能的薄。安全的前提下實(shí)現(xiàn)快速通過。不能堵塞，所以需要盡可能的減少延遲。另外考慮采用安全傳輸，防止數(shù)據(jù)包被其他人篡改、偽造，防止非公共數(shù)據(jù)被其他人竊聽。可能還需要考慮服務(wù)基礎(chǔ)設(shè)施安全以及第三方應(yīng)用/內(nèi)容安全。

API網(wǎng)關(guān)是微服務(wù)平臺的安全屏障。不管私有服務(wù)或者開放服務(wù)，其安全性都是一個(gè)時(shí)刻都需要認(rèn)真面對的課題。

3. 敏捷-簡化開發(fā)

在API網(wǎng)關(guān)層實(shí)現(xiàn)這些安全機(jī)制，不但提高安全性，也簡化了應(yīng)用服務(wù)的開發(fā)。使開發(fā)人員專注于業(yè)務(wù)應(yīng)用、業(yè)務(wù)服務(wù)的研發(fā)，不再考慮基礎(chǔ)能力基礎(chǔ)組件，提升開發(fā)部署的效率，從而提升收益率。
將安全、訪問控制等非業(yè)務(wù)邏輯功能從微服務(wù)中分離出來，也使微服務(wù)的設(shè)計(jì)和實(shí)現(xiàn)簡化。使微服務(wù)更輕盈，更敏捷。
通過對 API服務(wù)的分類分級，簡化和控制開發(fā)人員對數(shù)據(jù)和服務(wù)的訪問；服務(wù)的開放和共享，可以構(gòu)建更大范圍內(nèi)的協(xié)作和開發(fā)人員生態(tài)體系。加快業(yè)務(wù)服務(wù)業(yè)務(wù)應(yīng)用的交付。

4. 標(biāo)準(zhǔn)化接口，統(tǒng)一入口

API網(wǎng)關(guān)提供統(tǒng)一對外接口以實(shí)現(xiàn)開放性、標(biāo)準(zhǔn)化和規(guī)范化。當(dāng)實(shí)現(xiàn)新的業(yè)務(wù)應(yīng)用時(shí)或者需要集成不同系統(tǒng)或者服務(wù)之間的功能，調(diào)用不同服務(wù)提供的能力時(shí)，利用API網(wǎng)關(guān)可以讓用戶在不感知服務(wù)邊緣的情況下，利用統(tǒng)一的接口編排組裝服務(wù)。對于一個(gè)公司內(nèi)部不同的服務(wù)，由于歷史原因提供的接口可能有不小的差異，通過API網(wǎng)關(guān)可以消除這種差異，統(tǒng)一對外提供標(biāo)準(zhǔn)化的接口，比如Restful接口。 當(dāng)內(nèi)部服務(wù)更新時(shí)，也可以通過API網(wǎng)關(guān)進(jìn)行適配轉(zhuǎn)換，對客戶端透明，不需要調(diào)用方進(jìn)行調(diào)整。
標(biāo)準(zhǔn)化是微服務(wù)化面對的一個(gè)很大挑戰(zhàn)。雖然我們也強(qiáng)調(diào)微服務(wù)的價(jià)值在于重構(gòu)，但重構(gòu)需要很長的路要走，剛開始可能需要類似于ESB的集成，首先實(shí)現(xiàn)互連互通，資源共享。但ESB服務(wù)往往比較重，無法滿足低延遲的要求，所以還需要逐步的重構(gòu)業(yè)務(wù)應(yīng)用。不同微服務(wù)的開發(fā)語言、協(xié)議、接口類型等可能不一樣，所以需要API網(wǎng)關(guān)來實(shí)現(xiàn)轉(zhuǎn)換，提供統(tǒng)一的標(biāo)準(zhǔn)化API對外開放，最為統(tǒng)一的入口。

5. 監(jiān)控分析，明確各部分工作業(yè)績

日志監(jiān)控等能力也是API網(wǎng)關(guān)的重要能力之一。通過對API訪問日志和運(yùn)行監(jiān)控?cái)?shù)據(jù)的統(tǒng)計(jì)分析，可以了解業(yè)務(wù)服務(wù)的調(diào)用情況、調(diào)用趨勢、運(yùn)行情況等等。一方面是業(yè)務(wù)服務(wù)評價(jià)的指標(biāo)，另一方面也是助力智能決策的數(shù)據(jù)來源。哪些API服務(wù)調(diào)用的多，哪些API服務(wù)調(diào)用的少，哪個(gè)客戶調(diào)用的多，以及高峰流量時(shí)刻、平均流量、響應(yīng)時(shí)間等等都是需要監(jiān)控和統(tǒng)計(jì)分析的。這些數(shù)據(jù)將有助于我們對提供API的服務(wù)進(jìn)行運(yùn)維運(yùn)營或重構(gòu)，有助于我們做出合理決策。更為智能決策提供必須的數(shù)據(jù)支持。也是服務(wù)開發(fā)和擁有者的業(yè)績參考。

使用API網(wǎng)關(guān)實(shí)現(xiàn)微服務(wù)治理

微服務(wù)治理涉及的方面很多，但大體上包含微服務(wù)生命周期管理、微服務(wù)注冊發(fā)現(xiàn)、微服務(wù)日志監(jiān)控、微服務(wù)安全、微服務(wù)訪問控制、微服務(wù)編排、微服務(wù)負(fù)載擴(kuò)展、微服務(wù)流量控制、容錯(cuò)熔斷等。這其中的大部分能力都可以在API網(wǎng)關(guān)層來實(shí)現(xiàn)，同時(shí)可以結(jié)合容器云平臺來實(shí)現(xiàn)完善的微服務(wù)治理能力。
從API網(wǎng)關(guān)的定位和能力來看，我們主要可以在網(wǎng)關(guān)層實(shí)現(xiàn)微服務(wù)的安全認(rèn)證及訪問控制（包括路由、轉(zhuǎn)換、流量控制等），同時(shí)API網(wǎng)關(guān)也提供注冊發(fā)現(xiàn)、日志監(jiān)控、服務(wù)編排、負(fù)載均衡等能力。利用這些能力，可以便利的實(shí)現(xiàn)微服務(wù)的治理，天然融合，無需再開發(fā)或部署一套微服務(wù)治理平臺，也不用為不同平臺之間的集成花費(fèi)人力財(cái)力和珍貴的時(shí)間。
目前API網(wǎng)關(guān)產(chǎn)品眾多，商用的產(chǎn)品功能相對完善，可以很好的滿足微服務(wù)治理的需求。