版权声明:作者: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 构建实时日志 检索 监控 告警平台》
个人微信公众号: