API管理平台的部署方式和成功案例

前言

本文仅代表作者的个人观点；

本文的内容仅限于技术探讨，不能作为指导生产环境的素材；

本文主要参考了红帽公司产品技术和手册；

一、3 Scale的几种部署方式

第一种部署方式：

API Manager和API网关公有云托管方式。客户将自己的API后端集成到API网关

第二种部署方式：

混合方式，API Manager在公有云托管，API网关和API后端客户运行到私有云上。

第三种部署方式：

全部在私有云Openshift上部署，包括API Mnagaer和API网关，以及客户后端的API。

第四种部署方式：

在私有云Openshift上部署API Manager和API网关，不运行在Openshift上。

第五种部署方式：

在私有云上部署API Mnagaer和API网关，客户API自行管理。

二、基于不同部署方式的3 Scale使用场景

第一种：所有组件部署到内网：

如果OCP集群部署在内部网络内（它可以访问内部服务，存储等），LB应该负责将外部流量和流量从DMZ路由到OCP集群。

优点：存储和OCP部署在内部网络中，更安全。将OpenShift router部署到单独的OCP node上，性能更高。

缺点：需要将LB单独部署到DMZ中，并允许它访问OpenShift路由器。需要为OCP router分配单独的节点。

第二种：

API Manager既可以部署到DMZ，也可以部署到内部：

部署到DMZ： API网关通过LB中的暴露路由连接到后端和系统。

部署到内部：3scale API网关应用程序，通过SVC连接到后端和系统

第三种：不同的服务暴露给不同的网络。

有的API只需要内部被访问，就无需暴露给DMZ的LB。

第四种：3Scale管理多个API后端。

例如API的有来自于AWS和Azure的。

可以使用API LB来处理将API网关应用程序请求路由到多个端点。

使用具有healthchek支持的高级Round-Robin DNS，并将API网关应用程序指向它。

第五种：访问外部资源

出口流量是指从OpenShift pod到OpenShift之外的外部系统的流量。启用出口流量有两个主要选项：允许从OpenShift物理节点IP访问外部系统（pod对外访问的时候，通过NAT转化为node节点的IP）；或使用egress router。

在企业环境中，出口路由器通常是首选。它们允许从特定pod，一组pod或项目到外部系统或服务的细粒度访问。通过节点IP访问意味着在给定节点上运行的所有pod都可以访问外部系统。

在3Scale中，可以让3 Scale的API Gateway pod使用egress router，来实现pod的出口流量访问。

三、部分成功案例：

https://www.3scale.net/resources/customer-case-studies/

魏新宇

• "大魏分享"运营者、红帽资深解决方案架构师
• 专注开源云计算、容器及自动化运维在金融行业的推广
• 拥有MBA、ITIL V3、Cobit5、C-STAR、TOGAF9.1（鉴定级）等管理认证。
• 拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、AIX、HPUX等技术认证。