API 网关与南北向安全设计

互联网技术发展到今天，各大企业的应用系统架构早已从初级的单体架构、分层架构进化成更具有拓展性、易于管理的分布式架构或微服务架构。近些年，随着云厂商的崛起，Serverless 架构也逐渐被推广开来。无论是哪种架构，内外部通信的技术都大量地依赖 API 来实现。当内部组件越来越多，对外提供的业务功能越来越模块化后，给日常的技术管理带来更多的问题。

1、非业务功能模块的重复或冗余

为了保障信息系统的可管理性和易用性，在建设过程中通常会增加一些额外的功能模块，比如系统监控。系统监控功能与业务是无关的，有没有系统监控只要业务功能完善，用户都可以使用系统或平台，添加系统监控功能是为了便于系统管理人员和系统运维人员更好地监控系统的运作状态，及时、尽早地发现系统中可能存在的问题，并根据监控信息做出相应的调整。而安全机制也类似，尤其是当每一个业务组件或服务、微服务都去实现这些安全机制时，安全功能的重复建设就会凸显出来。

2、多端、多协议的兼容性问题复杂

企业对外提供的业务功能面向不同的用户群体，网络环境和客户端设备各不相同，比如移动 App 应用程序、H5 应用程序、普通的 Web 应用程序、小程序、IoT 设备等，为了兼顾多端的使用，接口实现变得更加复杂。同时，因为系统建设的时期不同，存在多种不同技术实现的应用，在接口技术上也不尽相同，比如 SOAP API、RESTful API、RPC 服务等。这些问题的解决，在系统架构上需要一个组件来进行不同协议间的转换和接口管理。

3、业务功能合并和边界防护

当系统架构在模块化拆分之后，业务上或第三方合作厂商在使用这些接口时，往往一次性需要调用多个接口才能完成一个业务所需要的功能。同时，模块化拆分之后使得面向外部暴露的攻击面变大，也难以管理。

为了解决这些问题，在架构中引入 API 网关成为首选的解决方案。一个典型的 API 网关产品至少包含统一接入、协议适配、流量控制、安全防护等基本功能，网关负责各种类型 API 的统一接入，并将不同的请求协议转换成内部 API 可理解的接口协议，再通过身份鉴别、访问控制、限流、降级、熔断等措施，对确认放行的请求经过路由策略进行转发，共同保护网关的整体稳定性。

使用 API 网关后，在整个架构上，API 网关对外部提供统一的 API 调用入口，并在系统边界为内部的可调用 API 提供保护。API 网关就像所有后端服务的大门，当前端请求过来之后，首先经过 API 网关的身份认证、访问控制、流量控制等安全控制措施，API 网关确认通过后，再向后端服务转发请求。API 网关本身提供的数据转换、负载均衡、消息加密等功能降低了各个后端组件或模块技术实现的复杂度，屏蔽了后端服务在技术上的复杂性和差异性。

对于客户端接入来说，原来需要对接不同的后端服务或组件，现在只需要对接 API 网关即可，在使用流程上更为方便、简洁，用户体验也更好。

目前市场上，API 网关可供选择的产品很多，既有开源产品也有商业产品，比如 Kong、Zuul、Tky、Apigee 等。