正文
在介绍 API 网关的一些文章中，提到了网关层的服务编排能力。从解耦的角度出发，服务的编排不适合在网关层进行。对服务的编排，其实是提供了一种业务能力，如果把服务的编排放在了网关层，实际上是把一部分业务能力放在了网关层，这样一来，服务层、网关层都有一些业务能力，造成团队职责的不清，也不利于业务能力的沉淀。
网关层除了请求的路由、转发外，还需要负责安全、鉴权、限流、监控等。这些功能的实现方式，往往随着业务的变化不断调整。例如权限控制方面，早期可能只需要简单的用户 + 密码方式，后续用户量大了后，可能会使用高性能的第三方解决方案。又例如，针对不同的监控方案，需要记录不同的日志文件。
所以，这些能力不能一开始就固化在网关平台上，而应该是一种可配置的方式，便于修改和替换。这就要求网关层提供一套机制，可以很好地支持这种动态扩展。
这里总结下网关的价值：
-
网关层对外部和内部进行了隔离，保障了后台服务的安全性。
-
对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本
-
减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射。
-
通过网关层聚合，减少外部访问的频次，提升访问效率。
-
节约后端服务开发成本，减少上线风险。
-
为服务熔断，灰度发布，线上测试提供简单方案。
-
便于扩展。
API 网关作为对外提供服务的入口，就像企业服务的大门。一方面，要有足够的能力，应对大量的对外访问，另一方面，还要给对内的服务提供一定的安全保障。
除此之外，企业提供的 API 服务多种多样，API 网关要能够对这些 API 的全生命周期进行便捷的管理，例如服务发布、调整、下架、计费、监控等。
1. 安全性问题
企业在把服务暴露给外部使用时，首先要确保服务使用的安全，防止外部的恶意访问对公司业务的影响，特别是涉及交易方面的服务，更是要全面考虑安全性。为确保安全，需要考虑在通讯链路的建立、通讯数据的加密、数据的完整性、不可抵赖性等方面。
2. 性能问题。
作为企业 API 的入口，所有的请求都会经过 API 网关进行转发，可想而知，对 API 网关的访问压力是巨大的，有的网站甚至达到每分钟上千万的访问量。特别是在一些互联网企业，海量的移动终端每时每刻都需要与后端的服务进行交互，如果不能保证网关的高性能，企业在网关层需要投入大量的设备和成本。曾在一家互联网公司发生过，由于网关性能问题，网关的机器数量，需要与后台服务器的数量保持同步增长。这种情况显然是企业服务忍受的。
3. 高可用问题。
API 网关作为逻辑上的单点，一旦发生问题，将造成企业服务的不可用，对企业来说可能造成的致命的影响。计算短时间的不可用，也会给企业带来直接的经济损失。所以，如何保证 API 网关的 7*24 小时的稳定运行，网关的自动伸缩、API 的热更新等问题，都是企业级的网关需要考虑的。
4. 扩展性问题
前面说到，企业网关提供了一个脚手架，一些非功能性的问题，例如日志、安全、负载均衡策略、鉴权等。这些插件会随着企业业务规模等的变化进行不断的强化与调整。这就需要网关层提供这样一种机制，使得可以灵活地进行这些调整和变化，而不用频繁对网关层进行改动，确保网关层的稳定性。
5. API 高效运维的问题
API 在上线、发布过程中，都需要涉及到网关层的配合，例如，需要网关层知道 API 发布的地址，API 的接口形式、报文格式，也需要网关层对后台 API 进行封装。在 API 调整后，需要作出相应的修改。所以，API 网关设计时，需要明确网关层与服务层的职责切分与协作模式，使得 API 的管理、发布更加高效。
6. API 全生命周期管理的问题
API 服务的全生命周期，包括服务的开发、测试、上线发布；服务使用的申请、开通；服务分类分级别的管理、服务使用情况的监控、计费等等。
一个企业可能会暴露成百上千个 API，日常也会经常进行 API 的发布、升级、改造、下架等操作。对不同的服务，不同的访问者，需要提供不同的服务访问策略。有的商业 API 公司，还需要对 API 的使用进行付费。所以，与 API 网关配套的，
需要一套完善的自助系统
，提供给服务的提供者、管理者、使用者，来对服务的发布、使用、和运营。
业界 API 网关解决方案有很多，包括商业的、开源的。例如 Tyk、Kong、API Umbrella、ApiAxle、Netflix Zuul、WSO2 API Manager、ClydeIO 等。下面介绍三种常见的 API 网关方案。
