版权声明：作者：jiankunking 出处：http://blog.csdn.net/jiankunking 本文版权归作者和CSDN共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。 https://blog.csdn.net/xunzaosiyecao/article/details/85238110
一、什么是API Gateway
一个比较普遍的定义如下：
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
从定义中可以归纳出一下几个核心点：
- 服务调用的统一入口
- AuthN（Authentication is establishing the your identity.）
- AuthZ （Authorization is establishing your privileges.）
- 监控（请求延迟、异常数、审计日志、访问日志）
- 高可用
- 白名单、黑名单
- 限流
- 熔断
- 服务发现
- 协议支持
- …
二、具体实现方案
先说RC（Replication Controller）是什么？
RC保证在同一时间能够运行指定数量的Pod副本，保证Pod总是可用。如果实际Pod数量比指定的多就结束掉多余的，如果实际数量比指定的少就启动缺少的。当Pod失败、被删除或被终结时RC会自动创建新的Pod来保证副本数量。所以即使只有一个Pod也应该使用RC来进行管理。
三、如何开发适合自己的API Gateway？
其实，这个问题也可以拓展为如何开发适应自己业务的某系统，个人感觉应该从以下几点考虑：
- 自己的业务系统需要什么样的功能？
- 业界中该类系统都是如何实现的？
- 自己的基础设施情况（主要是PaaS及中间件）如何？
- 综合1、2考虑，在满足业务需求的前提下，往远了考虑，往简单了实现（既满足目前的功能，又方便以后拓展）。
回到API Gateway这个话题，那就需要考虑一下，自己的业务系统是否需要以上列出的所有功能点？如果不是或者目前不是，那我应该先实现哪一部分？
其中，作为一个Gateway，以下几点应该是基础功能：
- 服务调用的统一入口
- AuthN（Authentication is establishing the your identity.）
- AuthZ （Authorization is establishing your privileges.）
- 监控（请求延迟、异常数、审计日志、访问日志）
- 高可用
剩下的功能实现就要看业务需要及时间了。
如果系统本身的访问量不大，那么限流、熔断是否就可以先不实现？
为什么需要关注自己的基础设施情况（主要是PaaS及中间件）？
比如基础设施中已提供Kubernetes集群服务，那么毫无疑问的高可用方案，应该选择RC方案。如果没有Kubernetes集群服务，那么高可用就需要考虑别的方案了。
监控部分可以参考：《ELK+Prometheus 构建实时日志 检索 监控 告警平台》
个人微信公众号：
