coolfiry

在這篇文章中將我們一起來探討當前的API網關的作用。 

一、API網關的用處

API網關我的分析中會用到以下三種場景。 

1. Open API。 企業需要將自身數據、能力等作為開發平臺向外開放，通常會以rest的方式向外提供，最好的例子就是淘寶開放平臺、騰訊公司的QQ開放平臺、微信開放平臺。 Open API開放平臺必然涉及到客戶應用的接入、API權限的管理、調用次數管理等，必然會有一個統一的入口進行管理，這正是API網關可以發揮作用的時候。
2. 微服務網關。微服務的概念最早在2012年提出，在Martin Fowler的大力推廣下，微服務在2014年后得到了大力發展。 在微服務架構中，有一個組件可以說是必不可少的，那就是微服務網關，微服務網關處理了負載均衡，緩存，路由，訪問控制，服務代理，監控，日志等。API網關在微服務架構中正是以微服務網關的身份存在。 
3. API服務管理平臺。上述的微服務架構對企業來說有可能實施上是困難的，企業有很多遺留系統，要全部抽取為微服務器改動太大，對企業來說成本太高。但是由于不同系統間存在大量的API服務互相調用，因此需要對系統間服務調用進行管理，清晰地看到各系統調用關系，對系統間調用進行監控等。 API網關可以解決這些問題，我們可以認為如果沒有大規模的實施微服務架構，那么對企業來說微服務網關就是企業的API服務管理平臺。

二、API網關在企業整體架構中的地位

一個企業隨著信息系統復雜度的提高，必然出現外部合作伙伴應用、企業自身的公網應用、企業內網應用等，在架構上應該將這三種應用區別開，三種應用的安排級別、訪問方式也不一樣。 因此在我的設計中將這三種應用分別用不同的網關進行API管理，分別是：API網關（OpenAPI合伙伙伴應用）、API網關（內部應用）、API網關（內部公網應用）。

三、企業中在如何應用API網關

1、對于OpenAPI使用的API網關來說，一般合作伙伴要以應用的形式接入到OpenAPI平臺，合作伙伴需要到 OpenAPI平臺申請應用。 因此在OpenAPI網關之外，需要有一個面向合作伙伴的使用的平臺用于合作伙伴，這就要求OpenAPI網關需要提供API給這個用戶平臺進行訪問。 如下架構:

當然如果是在簡單的場景下，可能并不需要提供一個面向合作伙伴的門戶，只需要由公司的運營人員直接添加合作伙伴應用id/密鑰等，這種情況下也就不需要合作伙伴門戶子系統。 

2、對于內網的API網關，在起到的作用上來說可以認為是微服務網關，也可以認為是內網的API服務治理平臺。 當企業將所有的應用使用微服務的架構管理起來，那么API網關就起到了微服務網關的作用。 而當企業只是將系統與系統之間的調用使用rest api的方式進行訪問時使用API網關對調用進行管理，那么API網關起到的就是API服務治理的作用。 架構參考如下：

3、對于公司內部公網應用（如APP、公司的網站），如果管理上比較細致，在架構上是可能由獨立的API網關來處理這部分內部公網應用，如果想比較簡單的處理，也可以是使用面向合作伙伴的API網關。 如果使用獨立的API網關，有以下的好處：

• 面向合作伙伴和面向公司主體業務的優先級不一樣，不同的API網關可以做到業務影響的隔離。
• 內部API使用的管理流程和面向合作伙伴的管理流程可能不一樣。
• 內部的API在功能擴展等方面的需求一般會大于OpenAPI對于功能的要求。

基于以上的分析，如果公司有能力，那么還是建議分開使用合作伙伴OPEN API網關和內部公網應用網關。

四、API網關有哪些競爭方案

1、對于Open API平臺的API網關，我分析只能選擇API網關作為解決方案，業界沒有發現比較好的可以用來作為Open API平臺的入口的其他方案。 

2、對于作為微服務網關的API網關，業界的選擇可以選擇的解決方案比較多，也取決于微服務器的實現方案，有一些微服務架構的實現方案是不需要微服務網關的。

• Service Mesh，這是新興的基于無API網關的架構，通過在客戶端上的代理完成屏蔽網絡層的訪問，這樣達到對應用層最小的改動，當前Service Mesh的產品還正在開發中，并沒有非常成熟可直接應用的產品。 發展最迅速的產品是Istio。 建議大家密切關注相關產品的研發、業務使用進展。

• 基于duboo架構，在這個架構中通常是不需要網關的，是由客戶端直接訪問服務提供方，由注冊中心向客戶端返回服務方的地址。

五、API網關解決方案

私有云開源解決方案如下：

• Kong kong是基于Nginx+Lua進行二次開發的方案， https://konghq.com/
• Netflix Zuul，zuul是spring cloud的一個推薦組件，https://github.com/Netflix/zuul
• orange,這個開源程序是國人開發的， http://orange.sumory.com/

公有云解決方案：

• Amazon API Gateway，https://aws.amazon.com/cn/api-gateway/
• 阿里云API網關，https://www.aliyun.com/product/apigateway/
• 騰訊云API網關， https://cloud.tencent.com/product/apigateway

自開發解決方案：

• 基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于這個方案
• 基于Netty、非阻塞IO模型。 通過網上搜索可以看到國內的宜人貸等一些公司是基于這種方案，是一種成熟的方案。
• 基于Node.js的方案。 這種方案是應用了Node.js天生的非阻塞的特性。
• 基于java Servlet的方案。 zuul基于的就是這種方案，這種方案的效率不高，這也是zuul總是被詬病的原因。

六、企業怎么選擇API網關

如果是要選擇一款已有的API網關，那么需要從以下幾個方面去考慮。 

1、性能與可用性
如果一旦采用了API網關，那么API網關就會作為企業應用核心，因此性能和可用性是必須要求的。

• 從性能上來說，需要讓網關增加的時間消耗越短越好，個人覺得需要10ms以下。 系統需要采用非阻塞的IO，如epoll，NIO等。網關和各種依賴的交互也需要是非阻塞的，這樣才能保證整體系統的高可用性，如：Node.js的響應式編程和基于java體現的RxJava和Future。
• 網關必須支持集群部署，任務一臺服務器的crash都應該不影響整體系統的可用性。
• 多套網關應該支持同一管理平臺和同一監控中心。 如： 一個企業的OpenAPI網關和內部應用的多個系統群的不同的微服務網關可以在同一監控中心進行監控。

2、可擴展性、可維護性
一款產品總有不能滿足生產需求的地方，因此需求思考產品在如何進行二次開發和維護，是否方便公司團隊接手維護產品。 
3、需求匹配度
需要評估各API網關在需求上是否能滿足，如： 如果是OpenAPI平臺需要使用API網關，那么需要看API網關在合作伙伴應用接入、合作伙伴門戶集成、訪問次數限額等OpenAPI核心需求上去思考產品是否能滿足要求。 如果是微服務網關，那么要從微服務的運維、監控、管理等方面去思考產品是否足夠強大。
4、是否開源？公司是否有自開發的能力？
現有的開源產品如kong，zuul，orange都有基礎的API網關的核心功能，這些開源產品大多離很好的使用有一定的距離，如：沒有提供管理功能的UI界面、監控功能弱小，不支持OpenAPI平臺，沒有公司運營與運維的功能等。 當然開源產品能獲取源代碼，如果公司有比較強的研發能力，能hold住這些開源產品，經過二次開發kong、zuul應該還是適應一些公司，不過需求注意以下一些點：

• kong是基于ngnix+lua的，從公司的角度比較難于找到能去維護這種架構產品的人。 需求評估當前公司是否有這個能力去維護這個產品。
• zuul因為架構的原因在高并發的情況下性能不高，同時需要去基于研究整合開源的適配zuul的監控和管理系統。
• orange由于沒有被大量使用，同時是國內個人在開源，在可持續性和社區資源上不夠豐富，出了問題后可能不容易找到人問。

另外kong提供企業版本的API網關，當然也是基于ngnix+lua的，企業版本可以購買他們的技術支持、培訓等服務、以及擁有界面的管理、監控等功能。

5、公有云還是私有云
現在的亞馬遜、阿里、騰訊云都在提供基礎公有云的API網關，當然這些網關的基礎功能肯定是沒有問題，但是二次開發，擴展功能、監控功能可能就不能滿足部分用戶的定制需求了。另外很多企業因為自身信息安全的原因，不能使用外網公有網的API網關服務，這樣就只有選擇私有云的方案了。 
在需求上如果基于公有云的API網關只能做到由內部人員為外網人員申請應用，無法做到定制的合作伙伴門戶，這也不適合于部分企業的需求。 
如果作為微服務網關，大多數情況下是希望網關服務器和服務提供方服務器是要在內網的，在這里情況下也只有私有云的API網關才能滿足需求。 

綜合上面的分析，基礎公有云的API網關只有滿足一部分簡單客戶的需求，對于很多企業來說私有云的API網關才是正確的選擇。

文章作者介紹：
來自于小豹科技的架構師-專注于軟件研發基于平臺性軟件的研發，目前我正在研發一款基于Netty、響應式架構的插件式的API網關，希望能對行業帶來一些改變。 我希望與對OpenAPI、微服務、API網關、Service Mesh等感興趣的朋友多交流。 有興趣的朋友請加我的QQ群244054462。

在Java版發表這篇文章，似乎有點把矛頭指向Java了。其實不是，GC是所有新一代語言共有的特征，
Python, Eiffel，C#，Roby等無一例外地都使用了GC機制。但既然Java中的GC最為著名，所以天塌
下來自然應該抗著。

這篇短文源于comp.lang.java.programmer跟comp.lang.c++上發生的一場大辯論，支持C++和Java
的兩派不同勢力展開了新世紀第一場沖突，跟貼發言超過350，兩派都有名角壓陣。C++陣營的擂主是
Pete Becker，ACM會員，Dinkumware Ltd. 的技術副總監。此君精通C++和Java，開發過兩種語言的
核心類庫，但是卻對C++狂熱之極，而對于Java頗不以為然。平時談到Java的時候還好，一旦有人膽
敢用Java來批判C++，立刻忍不住火爆脾氣跳將出來，以堅韌不拔的毅力和大無畏精神與對手周旋，
舌戰群儒，哪怕只剩下一個人也要血戰到底。這等奇人當真少見！我真奇怪他整天泡在usenet上，
不用工作么？他的老板P.J. Plauger如此寬宏大量？Java陣營主角是一個網名Razzi的兄弟，另外有
Sun公司大名鼎鼎的Peter van der Linden助陣，妙語連珠，寸土必爭，加上人多勢眾，一度占據優勢。
C++陣營里大拿雖然很多，但是大多數沒有Pete那么多閑工夫，例如Greg Comeau，Comeau公司老板，
每次來個只言片語，實在幫不了Pete多大忙。但是自從C++陣營中冒出一個無名小子，網名Courage(勇氣)，
發動對Java GC機制的批判，形勢為之一變。C++陣營眼下處于全攻之勢，Java陣營疲于防守，只能
招架說：“你們沒有證據，沒有統計資料”，形勢很被動。

垃圾收集(GC)不是一直被Java fans用來炫耀，引以為傲的優點么？怎么成了弱點了？我大惑不解，定睛
一看，才覺得此中頗有道理。

首先，Java Swing庫存在大量資源泄漏問題，這一點SUN非常清楚，稱之為bugs，正在極力修正。但是看來
這里的問題恐怕不僅是庫編寫者的疏忽，可能根源在于深層的機制，未必能夠輕易解決，搞不好要傷筋動骨。
不過這個問題不是那么根本，C++陣營覺得如果抓住對方的弱點攻擊，就算是占了上風也沒什么說服力。誰
沒有缺點呢？于是反其道而行之，猛烈攻擊Java陣營覺得最得意的東西，Java的GC機制本身。

首先來想一想，memory leak到底意味著什么。在C++中，new出來的對象沒有delete，這就導致了memory
leak。但是C++早就有了克服這一問題的辦法——smart pointer。通過使用標準庫里設計精致的auto_ptr
以及各種STL容器，還有例如boost庫(差不多是個準標準庫了)中的四個smart pointers，C++程序員只要
花上一個星期的時間學習最新的資料，就可以拍著胸脯說：“我寫的程序沒有memory leak!”。

相比之下，Java似乎更優秀，因為從一開始你就不用考慮什么特殊的機制，大膽地往前new，自有GC替你
收拾殘局。Java的GC實際上是JVM中的一個獨立線程，采用不同的算法策略來收集heap中那些不再有
reference指向的垃圾對象所占用的內存。但是，通常情況下，GC線程的優先級比較低，只有在當前程序
空閑的時候才會被調度，收集垃圾。當然，如果JVM感到內存緊張了，JVM會主動調用GC來收集垃圾，獲取
更多的內存。請注意，Java的GC工作的時機是：1. 當前程序不忙，有空閑時間。2. 空閑內存不足。
現在我們考慮一種常見的情況，程序在緊張運行之中，沒喲空閑時間給GC來運行，同時機器內存很大，
JVM也沒有感到內存不足，結果是什么？對了，GC形同虛設，得不到調用。于是，內存被不斷吞噬，而那些
早已經用不著的垃圾對象仍在在寶貴的內存里睡大覺。例如：

class BadGc {

    public void job1() {
        String garbage = "I am a garbage, and just sleeping in your precious memory, " +
                  "how do you think you can deal with me? Daydreaming! HAHA!!!";
        ....
    }

    public void job2() {...}

    ...
    ...

    public void job1000() {...}

    public static void main(String[] args) {
        bgc = new BadGc();
 bgc.job1();
 bgc.job2();
 ...
 bgc.job1000();
    }
}

運行中，雖然garbage對象在離開job1()之后，就再也沒有用了。但是因為程序忙，內存還夠用，所以GC得
不到調度，garbage始終不會被回收，直到程序運行到bgc.job1000()時還躺在內存里嘲笑你。沒轍吧！

好了，我承認這段程序很傻。但是你不要以為這只是理論上的假設，恰恰相反，大多數實用中的Java程序都有
類似的效應。這就是為什么Java程序狂耗內存，而且好像給它多少內存吃都不夠。你花上大筆的銀子把內存
從128升到256，再升到512，結果是，一旦執行復雜任務，內存還是被輕易填滿，而且多出來的這些內存只是
用來裝垃圾，GC還是不給面子地千呼萬喚不出來。等到你的內存終于心力交瘁，GC才姍姍來遲，收拾殘局。而
且GC工作的方式也很不好評價，一種方法是一旦有機會回收內存，就把所有的垃圾都回收。你可以想象，這要
花很長時間(幾百M的垃圾啊！)，如果你這時侯正在壓下開炮的按鈕，GC卻叫了暫定，好了，你等死吧！另一
種方法，得到機會之后，回收一些內存，讓JVM感到內存不那么緊張時就收手。結果呢，內存里始終有大批垃
圾，程序始終在半死不活的蕩著。最后，GC可以每隔一段時間就運行一次，每次只回收一部分垃圾，這是現在
大部分JVM的方式，結果是內存也浪費了，還動不動暫停幾百毫秒。難啊！

反過來看看C++利用smart pointer達成的效果，一旦某對象不再被引用，系統刻不容緩，立刻回收內存。這
通常發生在關鍵任務完成后的清理(cleanup)時期，不會影響關鍵任務的實時性，同時，內存里所有的對象
都是有用的，絕對沒有垃圾空占內存。怎么樣？傳統、樸素的C++是不是更勝一籌？

據統計，目前的Java程序運行期間占用的內存通常為對應C++程序的4-20倍。除了其它的原因，上面所說的是一個
非常主要的因素。我們對memory leak如此憤恨，不就是因為它導致大量的內存垃圾得不到清除嗎？如果有了
GC之后，垃圾比以前還來勢洶洶，那么GC又有什么好處呢？

當然，C++的smart pointer現在會使用的人不多，所以現在的C++程序普遍存在更嚴重的memory leak問題。
但是，如果我奶奶跟舒馬赫比賽車輸掉了，你能夠埋怨那輛車子么？
http://www.594k.com/java/html/y2007m1/12051/