开发api网关需要注意什么

[hello2dj]

为什么需要API GW(微服务场景)

• 简化客户端调用复杂度

  在微服务架构模式下后端服务的实例数一般是动态的，对于客户端而言如何发现这些动态改变的服务实例的访问地址信息

• 数据裁剪以及聚合

  客户端的需求总是多变的，这样更适合做出响应

• 多渠道支持

  针对不同的渠道以及客户端提供不同的api

• 遗留系统的微服务化改造

  通过引入抽象层，逐步使用新的实现替换旧的实现

• 协议转换

  现实有很多协议但对于客户端来说只要知道某几种就可以了

GW 分类

• 面向Web App

  这类场景，在物理形态上类似前后端分离，此时的Web App已经不是全功能的Web App，而是根据场景定制、场景化的App。

• 面向Mobile App

  这类场景，移动App是后端Service的使用者，此时的API GW还需要承担一部分MDM（此处是指移动设备管理，不是主数据管理）的职能。

• 面向Partner OpenAPI

  这类场景，主要为了满足业务形态对外开放，与企业外部合作伙伴建立生态圈，此时的API GW需要增加配额、流控、令牌等一系列安全管控功能。

• 面向Partner ExternalAPI

  这类场景，业界提的比较少，很多时候系统的建设，都是为了满足企业自身业务的需要，实现对企业自有业务的映射。当互联网形态逐渐影响传统企业时，很多系统都会为了导入流量或者内容，依赖外部合作伙伴的能力，一些典型的例子就是使用「合作方账号登录」、「使用第三方支付平台支付」等等，这些对于企业内部来说，都是一些外部能力。此时的API GW就需要在边界上，为企业内部Service 统一调用外部的API做统一的认证、（多租户形式的）授权、以及访问控制。

• 面向IoT SmartDevice

  这类场景，业界就提的更少了，但在传统企业，尤其是工业企业，传感器、物理设备从工业控制协议向IP转换，导致具备信息处理能力的「智能产品」在被客户激活使用直至报废过程中，信息的传输不能再基于VPN或者企业内部专线，导致物理链路上会存在一部分公网链路。此时的API GW所需要满足的，就是不是前三种单向的由外而内的数据流，也不是第四种由内而外的数据流，「内外兼修」的双向数据流，对于企业的系统来说终端设备很多情况下都不是直连网关，而是进过一个「客户侧」的集中网关在和企业的接入网关进行通信。

api GW实现应当

面向运行期

• 对客户端实现身份认证

• 通信会话的秘钥协商，报文的加密与解密

• 日常流控与应急屏蔽

• 内部响应报文的场景化裁剪

• 支持「前正后反模型」的集成框架

• 报文格式的转换

• 业务路由的支撑

• 客户端优先的超时机制

• 全局流水号的生成与应用

• 面向客户端支持HTTP DNS / Direct IP

• 面向开发期

  • 自助的沙盒测试环境

  • 面向客户端友好的 SDK / Library以及示例

  • 能够根据后端代码直接生成客户端业务代码框架

  • 完善的报文描述能力（元数据），支撑配置型的报文裁剪

• 面向运维与运营

  • 支持面向接入方的独立部署与快速水平扩展

  • 面向业务场景或合作伙伴的自助API开通

  • 对外接口性能与线上环境故障定位自助平台

注意事项

后端API粒度

能和原子业务能力找到映射最好，一定要避免「万能接口」的出现。

业务路由的实现和含报文转换的API不停机发布

尽可能的在报文头里面存放业务路由所需要的信息，避免对报文体进行解析。

API GW上线后，面临的很大问题都是后端服务如何自助发布到外部，同时不能重启网关服务，以保障业务的连续。在此过程中，如果涉及到报文格式的转换，那对API网关实现的技术要求比较高。如果让网关完成报文转换，第一种方案，网关需要知道报文的具体格式（也就是报文的元数据，或者是类定义），这部分要支持热更新。第二种方案，需要客户端在报文内另外附加元数据，网关通过运行期加载元数据对报文进行解析在进行报文的转换，这种方案性能不会很好。第三种方案，就是在运行期首次报文转换的时候，根据元数据生成报文转换代码并加载，这种方案对技术实现要求比较高，对网关外围平台支撑力度要求也不低。

列举几个 netflix Zuul(java) kong(缺少报文转换，为了避免业务耦合)

[hello2dj]

这个是在infoQ读到的一篇文章的主要注意点集合