作者张超，API7 Cloud 产品负责人，Apache APISIX PMC 成员。

原文链接

一、多云和混合云

如今微服务已经成为最流行的一种软件架构，人们通过自己对业务的理解，和科学方法（比如领域驱动设计的理论）的加持将组织对外提供的产品拆分为一个个微服务，同时按照微服务的架构调整组织架构（逆康威定律）来开展业务的迭代。

以往组织习惯于自建数据中心来部署自家的产品，这些数据中心可能构建在买断或者是租赁的机房中，组织需要对机房的设备进行复杂的管理，包括交换机、服务器、磁盘、机柜等这些硬件设施，以及应对因为机房掉电、机柜温度过高、服务器崩溃等带来的故障。应对这些要问题往往会花费大量的人力财力，同时达不到很好的效果，使得自己产品的 SLA（服务等级约定）往往无法达到对客户的承诺，从而造成赔偿。

随着云的兴起，人们越来越习惯于将自己的业务部署到公有云之上，公有云帮助用户屏蔽了硬件的细节，工程师再也不用关心基础设施的搭建和维护问题，而是可以把自己的精力尽可能得放到业务的部署、维护和开发之上。然而，除了享受云带来的便利以外，云的兴起和使用也给用户带来了其他的一些问题：

• 被“锁定”，当深度使用了云上某产品后，导致业务无法轻易迁移到其他的云，或者是从云上离开。这种情况特别发生在使用云提供的 PaaS 或者 SaaS 产品，然后与自己的业务发生了强绑定。通常因为在选购产品时，业务正处于高速发展的阶段，决策人往往忽略了使用云产品所带来的捆绑效应。
• 可用性问题，大家都懂得“不要把鸡蛋放在一个篮子里”的道理，然后在业务上升期时，组织考虑的是快速上线产品，占据市场，对于基建的考虑往往是不足的，在这样的情况下，如果发生云某某区域机房掉电、光缆被挖断等问题，就会对业务造成影响。 于是现在人们越来越习惯于同时使用多种公有云或者除了使用云以外，额外再搭建私有云的方式，来规避上述提到的问题。这就是我们常说的“多云”和“混合云”。

“多云”指的是同时使用多种公有云，将业务镜像地、或者异构地部署到这些云上，同时尽可能采用标准服务（避免厂商锁定）。因为使用了多种云，当某个云出现不可用的情况下，它对业务的影响能够被缩小，甚至通过 DNS 修改解析等方式，启用备份的云，从而确保业务的连续性。“混合云”指的是组织除了使用了一个或者多个公有云以外，还拥有自建的私有云（或者数据中心），在此场景下，部分业务可能部署在私有云，其他的可能都已经上公有云，或者所有业务都在云上，而私有云负责管理和监控。总之，在采用了“多云”或者“混合云”这样的模式后，在提升服务可用性的同时，软件部署方式的灵活性也大大提升。

然而，在应用“多云”和“混合云”后，如何高效、简单的管理云上的微服务，则变得更加棘手。这当中比较经典的要属 API 的管理了，如今大量的微服务都选择使用 API 这一方式来进行交互，当微服务部署之后，它们提供的 API 需要能够被暴露到外部，以便和外部的调用方连接，从而提供服务。

二、多云、混合云场景下 API 管理的需求

我们知道对于管理微服务 API 而言，一款好的 API 网关是必不可少的，API 网关能够安全、高效地将微服务 API 暴露出去，然而，采用“多云“，“混合云”这样的模式后，对于 API 网关的需求不仅仅局限在 API 网关自身的功能是否满足业务的需求了，具体来说，我们需要考虑：

是否支持多集群管理

正如前文所述，在采用“多云”或者“混合云”，后，每个云或者私有数据中心所部署的业务可能存在着比较大的差异，因此用户需要在这些云上分别部署一套套的 API 网关集群，且可想而知这些网关集群的配置、证书、API 密钥等可能不尽相同。如果用户选择使用的网关不支持多集群的管理，可能会对 API 的管理造成很大的麻烦，尤其是在业务扩张期，API 网关集群规模越来越大，数量越来越多的时候。

在这种情况下，一款支持多集群管理的 API 网关产品 便能极大地降低管理员的管理成本。

1. 用户拥有一个统一的控制台，并且在该控制台中可选择当前需要配置和查看的集群，并且可以根据实际业务的部署情况，上线或者下线一个网关集群。
2. 用户可以控制台上查看所有这些 API 网关集群的运行状态，包括常见的 QPS、延迟、网关集群 CPU 和内存占用率等。

是否支持协作

由于业务的快速发展，少数几个 API 网关管理员可能无法承担起维护全部 API 网关集群的重担，同时考虑到大部分的网关配置，比如添加路由、为路由配置插件等，可以由开发者自行处理，不需要全部由管理员经手。因此，是否支持“协作”对于管理来说，也变得重要起来。具体来说，管理员可以邀请组织内的其他成员加入到该 API 网关集群的管理中，同时使用 RBAC 之类的策略为大家分配不同的权限，比如为管理员设置 Organization Admin 的角色（可以执行任意操作），为普通开发者设置为 Service Admin 的角色（仅可维护少数几个服务和路由），进而在实现协作的基础上确保操作安全，并且在员工离职或者出现岗位变动时，及时回收账号或者修改权限。

试想如果不支持协作，那么大概率一个组织内的成员会共享一个账号，这种用法在初期可能具备一定的便利性，但是时间一长它的潜在危害就会暴露出来，比如某员工在离职后可能依然可以登录并进行配置，甚至一些不怀好意的员工可能会选择删除全部数据，这对于组织对外的产品和服务来说是灾难性的。而且在进行复盘时，管理员甚至无法将具体的操作和具体某个成员关联起来，因为大家共享同一账号（即便是保有审计日志的情况下）。

是否可运行在任何基础设施上

随着容器化和容器编排的技术越来越成熟，以往很多运行在虚拟机之上的微服务都纷纷转投了 Kubernetes 的怀抱，这就意味着，用户可能会选择使用 Kubernetes、传统的虚拟机、甚至是物理机（比如在自己的私有数据中心里）。如果用户选择的 API 网关产品在功能上非常丰富，能够满足业务需求，但是又受限于底层基础设施，或者缺乏成熟的安装工具，这样会让用户处于两难的境地，要么放弃使用，要么自行进行二次开发从而使得该 API 网关获得运行在某个基础设施之上的能力。无论如何，这都会带来使用上的成本。

三、选择

结合上文所述，在“多云”和“混合云”的场景下，如何选择 API 网关则变得极其重要，这里列举了几种常见的选择，用户应该根据他们的实际场景和发展的考虑来进行分析。

不同云不同方案

通常来说每一家公有云厂商都会提供其内置的 API 网关解决方案，用户可以根据现有产品的开发规格对云上的 API 网关方案进行选型。

优点如下：

1. 使用成本极低，无需部署，无需维护
2. 通常支持按需付费，早期使用可能只需要极低的费用

缺点是：

1. 往往不同云的 API 网关使用方式相互不兼容，完成同一种配置需要经历不同的路径
2. 各家的产品功能不对称，比如 A 厂商可能支持 mTLS，而 B 厂商不支持
3. “混合云”场景下，可能需要再选择一款开源的或者商业化的 API 网关，部署在用户自己的私有云上

采用该方案时，如果想要获得一致的使用体验，可能需要基于不同的解决方案进行产品化，开发一个配置同步产品，屏蔽底层的细节，这里可能需要用户自行进行调研，分析以及开发（但可能会遇到兼容性问题，功能受限，只能使用几个 API 网关产品的交集功能），且需要考虑同步失败情况。

当然，用户也可以选择手动重复配置每一个云上的 API 网关（如果可以忍受的话）。

使用开源解决方案

考虑到在不同云使用不同方案的缺点，用户也可以考虑使用开源的 API 网关解决方案（如 Apache APISIX, Kong, Tyk, Traefik 等），这样的好处是，你可以在每个云（包括私有数据中心）上使用同一种 API 网关，从而避免了不同解决方案之间的兼容问题。且一个成熟，生态强大的开源的 API 网关可以帮助用户解决很多场景的问题，即便不能覆盖全部的场景，这些 API 网关通常也允许用户通过多种不同的方式进行扩展，比如 Apache APISIX 允许用户通过使用 Go、Java、Python、Lua、WASM 等语言和技术进行扩展。

然而这些开源 API 网关通常采用 Open Core 的开源策略，产品中的核心功能都开源了，但是面向企业级的管理能力，如可视化控制台、多集群管理、审计、SSO 等功能往往是收费的（集成在它们的商业产品中），这就导致如果用户不希望向他们付费，只能选择自研一套管理平台（也称为网关的控制面）来管理这些 API 网关。这可能意味着用户需要为此招聘一名全职的工程师负担起这部分的开发工作。

购买企业级 API 网关 SaaS 服务

如果开源的 API 网关在功能上满足需求，但是因为无法接受自研控制面的成本的话，用户也可以考虑联系这些开源软件的原厂（如 Apache APISIX 背后的原厂 API7.ai，Kong 背后的原厂 Kong inc，以及 Tyk 背后的原厂 Tyk inc 等），这些原厂往往会提供不同的企业级 API 网关产品和支持服务。尤其在“多云”和“混合云”的场景下，这些原厂相继都发布了他们的 SaaS 产品。API 网关的 SaaS 产品往往聚焦在管理侧，提供开箱即用的控制台，而不关心 API 网关实例具体部署在哪里（当然，某些 SaaS 服务也支持托管 API 网关实例，但这往往也会引入其他问题，比如代理 API 时的延迟）。

SaaS 服务通常会为每个租户托管一个用户独享的网关控制面，然后将用户部署的（或者 SaaS 服务托管的）网关实例进行连接（往往会使用 mTLS 等策略确保数据的安全性、隐私性），进而对它们进行管理。虽然购买 SaaS 服务需要花费一定的金钱，但是相比于招聘专职的工程师维护一个 API 网关和它的控制面，这些支出可能会更低。

当然，采购 SaaS 服务需要谨慎，用户确认订单前，应该从下面几个方面对一个 SaaS 服务进行评估：

1. 这个 SaaS 服务是否能满足现在以及未来一段时间的使用需求？
2. 这个 SaaS 服务厂商是否专业诚信？他们拥有哪些用户案例？
3. 这个 SaaS 服务是否合规，符合 GDPR，拥有 SOC2 审计报告？
4. 这个 SaaS 服务是否有明确的 SLA 条款？
5. 这个 SaaS 服务是如何收费的？用户是否可以预估未来一年或者几年的支出？

完全自研

如果开源的 API 网关解决方案无法满足用户的实际场景，用户可能选择考虑完全自研专属于他们的 API 网关产品，但这往往费时费力，且网关本身的稳定性也是一个重大问题。研发一个 API 网关虽然不像实现一个关系型数据库或者浏览器那么难，但也不是一朝一夕就可以完成的，因此完全自研可以认为是“最坏的策略”。往往只能作为最后的选择。

四、总结

在云原生的大环境下，在“多云”和“混合云” 的场景下进行 API 的管理将会成为每一个组织发展时将面临的一个问题，甚至在没有采用“多云”和“混合云”之前就应该开始未雨绸缪。 尽管本文给出了几种不同的选择，但是需要谨记的是，它们之中没有“银弹”，用户应该根据业务的实际情况和发展方向选择一个“目前看来最合适的方案”。