作者张超，API7 Cloud 产品负责人，Apache APISIX PMC 成员。
原文链接
一、多云和混合云
现在微服务曾经成为最风行的一种软件架构，人们通过本人对业务的了解，和迷信办法（比方畛域驱动设计的实践）的加持将组织对外提供的产品拆分为一个个微服务，同时依照微服务的架构调整组织架构（逆康威定律）来开展业务的迭代。
以往组织习惯于自建数据中心来部署自家的产品，这些数据中心可能构建在买断或者是租赁的机房中，组织须要对机房的设施进行简单的治理，包含交换机、服务器、磁盘、机柜等这些硬件设施，以及应答因为机房掉电、机柜温度过高、服务器解体等带来的故障。应答这些要问题往往会破费大量的人力财力，同时达不到很好的成果，使得本人产品的 SLA（服务等级约定）往往无奈达到对客户的承诺，从而造成抵偿。
随着云的衰亡，人们越来越习惯于将本人的业务部署到私有云之上，私有云帮忙用户屏蔽了硬件的细节，工程师再也不必关怀基础设施的搭建和保护问题，而是能够把本人的精力尽可能得放到业务的部署、保护和开发之上。然而，除了享受云带来的便当以外，云的衰亡和应用也给用户带来了其余的一些问题：
- __被“锁定”__，当深度应用了云上某产品后，导致业务无奈轻易迁徙到其余的云，或者是从云上来到。这种状况特地产生在应用云提供的 PaaS 或者 SaaS 产品，而后与本人的业务产生了强绑定。通常因为在选购产品时，业务正处于高速倒退的阶段，决策人往往疏忽了应用云产品所带来的捆绑效应。
- __可用性问题__，大家都懂得“不要把鸡蛋放在一个篮子里”的情理，而后在业务上升期时，组织思考的是疾速上线产品，占据市场，对于基建的思考往往是有余的，在这样的状况下，如果产生云某某区域机房掉电、光缆被挖断等问题，就会对业务造成影响。
于是当初人们越来越习惯于同时应用多种私有云或者除了应用云以外，额定再搭建公有云的形式，来躲避上述提到的问题。这就是咱们常说的“多云”和“混合云”。
“多云”指的是同时应用多种私有云，将业务镜像地、或者异构地部署到这些云上，同时尽可能采纳规范服务（防止厂商锁定）。因为应用了多种云，当某个云呈现不可用的状况下，它对业务的影响可能被放大，甚至通过 DNS 批改解析等形式，启用备份的云，从而确保业务的连续性。“混合云”指的是组织除了应用了一个或者多个私有云以外，还领有自建的公有云（或者数据中心），在此场景下，局部业务可能部署在公有云，其余的可能都曾经上私有云，或者所有业务都在云上，而公有云负责管理和监控。__总之，在采纳了“多云”或者“混合云”这样的模式后，在晋升服务可用性的同时，软件部署形式的灵活性也大大晋升。__
然而，在利用“多云”和“混合云”后，如何高效、简略的治理云上的微服务，则变得更加辣手。这当中比拟经典的要属 API 的治理了，现在大量的微服务都抉择应用 API 这一形式来进行交互，当微服务部署之后，它们提供的 API 须要可能被裸露到内部，以便和内部的调用方连贯，从而提供服务。
二、多云、混合云场景下 API 治理的需要
咱们晓得对于治理微服务 API 而言，一款好的 API 网关是必不可少的，API 网关可能平安、高效地将微服务 API 裸露进来，然而，采纳“多云“，“混合云”这样的模式后，对于 API 网关的需要不仅仅局限在 API 网关本身的性能是否满足业务的需要了，具体来说，咱们须要思考：
是否反对多集群治理
正如前文所述，在采纳“多云”或者“混合云”，后，每个云或者公有数据中心所部署的业务可能存在着比拟大的差别，因而用户须要在这些云上别离部署一套套的 API 网关集群，且可想而知这些网关集群的配置、证书、API 密钥等可能不尽相同。如果用户抉择应用的网关不反对多集群的治理，可能会对 API 的治理造成很大的麻烦，尤其是在业务扩张期，API 网关集群规模越来越大，数量越来越多的时候。
在这种状况下，一款反对多集群治理的 API 网关产品 便能极大地升高管理员的治理老本。
- 用户领有一个对立的控制台，并且在该控制台中可抉择以后须要配置和查看的集群，并且能够依据理论业务的部署状况，上线或者下线一个网关集群。
- 用户能够管制台上查看所有这些 API 网关集群的运行状态，包含常见的 QPS、提早、网关集群 CPU 和内存占用率等。
是否反对合作
因为业务的疾速倒退，少数几个 API 网关管理员可能无奈承当起保护全副 API 网关集群的重任，同时思考到大部分的网关配置，比方增加路由、为路由配置插件等，能够由开发者自行处理，不须要全副由管理员经手。因而，是否反对“合作”对于治理来说，也变得重要起来。具体来说，管理员能够邀请组织内的其余成员退出到该 API 网关集群的治理中，同时应用 RBAC 之类的策略为大家调配不同的权限，比方为管理员设置 Organization Admin 的角色（能够执行任意操作），为一般开发者设置为 Service Admin 的角色（仅可保护少数几个服务和路由），进而在实现合作的根底上确保操作平安，并且在员工到职或者呈现岗位变动时，及时回收账号或者批改权限。
试想如果不反对合作，那么大概率一个组织内的成员会共享一个账号，这种用法在初期可能具备肯定的便利性，然而工夫一长它的潜在危害就会裸露进去，比方某员工在到职后可能仍然能够登录并进行配置，甚至一些不怀好意的员工可能会抉择删除全副数据，这对于组织对外的产品和服务来说是灾难性的。而且在进行复盘时，管理员甚至无奈将具体的操作和具体某个成员关联起来，因为大家共享同一账号（即使是保有审计日志的状况下）。
是否可运行在任何基础设施上
随着容器化和容器编排的技术越来越成熟，以往很多运行在虚拟机之上的微服务都纷纷转投了 Kubernetes 的怀抱，这就意味着，用户可能会抉择应用 Kubernetes、传统的虚拟机、甚至是物理机（比方在本人的公有数据中心里）。如果用户抉择的 API 网关产品在性能上十分丰盛，可能满足业务需要，然而又受限于底层基础设施，或者不足成熟的装置工具，这样会让用户处于两难的地步，要么放弃应用，要么自行进行二次开发从而使得该 API 网关取得运行在某个基础设施之上的能力。无论如何，这都会带来应用上的老本。
三、抉择
联合上文所述，在“多云”和“混合云”的场景下，如何抉择 API 网关则变得极其重要，这里列举了几种常见的抉择，用户应该依据他们的理论场景和倒退的思考来进行剖析。
不同云不同计划
通常来说每一家私有云厂商都会提供其内置的 API 网关解决方案，用户能够依据现有产品的开发规格对云上的 API 网关计划进行选型。
长处如下：
- 应用老本极低，无需部署，无需保护
- 通常反对按需付费，晚期应用可能只须要极低的费用
毛病是：
- 往往不同云的 API 网关应用形式互相不兼容，实现同一种配置须要经验不同的门路
- 各家的产品性能不对称，比方 A 厂商可能反对 mTLS，而 B 厂商不反对
- “混合云”场景下，可能须要再抉择一款开源的或者商业化的 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 服务进行评估：
- 这个 SaaS 服务是否能满足当初以及将来一段时间的应用需要？
- 这个 SaaS 服务厂商是否业余诚信？他们领有哪些用户案例？
- 这个 SaaS 服务是否合规，合乎 GDPR，领有 SOC2 审计报告？
- 这个 SaaS 服务是否有明确的 SLA 条款？
- 这个 SaaS 服务是如何免费的？用户是否能够预估将来一年或者几年的收入？
齐全自研
如果开源的 API 网关解决方案无奈满足用户的理论场景，用户可能抉择思考齐全自研专属于他们的 API 网关产品，但这往往费时费力，且网关自身的稳定性也是一个重大问题。研发一个 API 网关尽管不像实现一个关系型数据库或者浏览器那么难，但也不是久而久之就能够实现的，因而齐全自研能够认为是“最坏的策略”。往往只能作为最初的抉择。
四、总结
在云原生的大环境下，在“多云”和“混合云”的场景下进行 API 的治理将会成为每一个组织倒退时将面临的一个问题，甚至在没有采纳“多云”和“混合云”之前就应该开始防患未然。只管本文给出了几种不同的抉择，然而须要谨记的是，它们之中没有“银弹”，用户应该依据业务的理论状况和倒退方向抉择一个“目前看来最合适的计划”。