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/