在 3scale，我们一直对构建 API 管理的正确方法持有相当的意见，并且自成立以来我们的核心就是混合架构。因此，随着 Apigee 今天宣布一个具有一些相似之处的架构，我们认为现在是讨论这些选择及其重要性的好时机。
API 管理本质上是关于 API 流量的 控制 和 可见性 。换句话说，它知道流经 API 管道的内容并确保它是：
- A）你想要的流量
- B) 做正确的事
这涉及从安全和身份到性能、正常运行时间和业务目标实现的各种问题。
建筑学
在构建 3scale 时，我们一遍又一遍地看到同样的问题：API 流量应该可以从许多位置、不同的技术堆栈和不同的交付需求交付，但它需要一个一致、统一的管理层。这导致了我们架构的中心租户：
管控与流量交付层分离
这种模式与网络本身一样古老，将控制平面和数据平面分开，但它不同于我们以外的大多数供应商今天构建 API 管理的方式。这些其他方法基本上分为两个阵营：1)“通过我们的云路由所有 API 流量”或 2)“部署大量单独的本地网关，每个网关都有成本”。这两者都会导致单点故障，无法很好地应对规模，最终导致成本过高。
在考虑用于微服务、物联网和许多其他现代挑战的 API 时，将跟踪和控制流量的方式与交付点分开变得更加明显更有意义。控制平面和数据平面应该是分开的，但要相互交谈。
Apigee 宣布 Edge 产品现在具有对新“微网关”组件的预览支持，该组件是其云网关的轻量级版本，可以部署在 Apigee 云系统之外以路由流量。这是迈向混合架构的良好一步，很高兴看到另一家供应商朝着这个方向迈进。
混合架构更进一步
我们认为虽然这是一个有用的步骤，但要释放混合架构的真正价值还有很多。为了说明这一点，下面是 3scale 的架构，它展示了各个部分是如何组合在一起的。
3scale的系统：
- 允许多种流量从 NGINX 或 Varnish 网关传输到全球 CDN，我们自己的 APICast 云代理，一直到轻量级代码插件
- 确保其中每一个都可以自主运行以传输流量，同时与带外核心管理层同步
- 拥有一套完整的 API，使任何希望编写新的流量管理客户端的人都能使用
- 不按节点定价，因此 API 团队可以混合和匹配他们喜欢的尽可能多的不同类型的节点，以最适合他们的流量模式，而不必被迫承担配置不足的风险
这意味着管理可以连接到任何流量流向的地方以提供控制。它还可以保护客户免于锁定到特定的 API 网关。尽管许多人使用我们提供的出色且高度可扩展的 NGINX 驱动的网关，但其他人可能会根据他们的需要选择不同的机制并且可以轻松地做到这一点。
该架构为我们的客户购买：
- 每个网关节点数以千计的 API 事务（通过 NGINX）
- 无限的、完全强化的网关节点
- 与完整 CDNS 的缓存和分发能力集成
- 通过 API 连接自定义流量源的能力
- 极具成本效益的解决方案
因此，很高兴看到该领域的架构创新，但对于提高性能的真正混合架构，我们建议进一步研究，包括：
- 支持包括开源在内的多种流量传递机制
- 确保完整的 API 支持，以便用户可以从任何地方连接到管理层
- 去除每个节点的成本
如果您想查看 3scale ，我们可以为您解锁 API 架构的超能力！ – 注册帐户或通过 sales@3scale.net 联系我们。