一、什么是API Gateway
一个比较普遍的定义如下：
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
从定义中可以归纳出一下几个核心点：
- 服务调用的统一入口
- AuthN（Authentication is establishing the your identity.）
- AuthZ （Authorization is establishing your privileges.）
- 监控（请求延迟、异常数、审计日志、访问日志）
- 高可用
- 白名单、黑名单
- 限流
- 熔断
- 服务发现
- 协议支持 （协议转换）
- …
二、具体实现方案
介绍几个概念：
1、先说RC（Replication Controller）是什么？
RC保证在同一时间能够运行指定数量的Pod副本，保证Pod总是可用。如果实际Pod数量比指定的多就结束掉多余的，如果实际数量比指定的少就启动缺少的。当Pod失败、被删除或被终结时RC会自动创建新的Pod来保证副本数量。所以即使只有一个Pod也应该使用RC来进行管理。
2、HPA
Horizontal Pod Autoscaling，简称HPA，是Kubernetes中实现POD水平自动伸缩的功能。为什么要水平而不叫垂直, 那是因为自动扩展主要分为两种:
- 水平扩展(scale out)，针对于实例数目的增减
- 垂直扩展(scal up)，即单个实例可以使用的资源的增减, 比如增加cpu和增大内存
而HPA属于前者。它可以根据CPU使用率或应用自定义metrics自动扩展Pod数量(支持 replication controller、deployment 和 replica set)
HPA是kubernetes里面pod弹性伸缩的实现,它能根据设置的监控阀值进行pod的弹性扩缩容，目前默认HPA只能支持cpu和内存的阀值检测扩缩容，但也可以通过custom metric api 调用prometheus实现自定义metric 来更加灵活的监控指标实现弹性伸缩。
三、如何开发适合自己的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 构建实时日志 检索 监控 告警平台》
个人微信公众号：
