点击查看目录
首先声明，我在 RedHat 工作，确切得说，是在 3scale 团队开发 3scale API 管理解决方案。最近，在跟我们的客户讨论时有个问题被越来越多的提及：使用了Istio之后，为什么还需要API管理？
为了回答这个问题，我们首先要搞明白服务网格和 API 管理究竟是什么，剧透一下：3scale API Management 和 Istio 可以共存。
让我们聚焦于 3scale API Management 和 Istio Service Mesh（这两者是我比较了解的），我会尽量描述清楚这两个方案的目标是解决哪些问题。
API Management 解决方案是什么？
我们先看一下 Wikipedia 的定义：API管理的过程包括创建和发布Web API、执行调用策略、访问控制、订阅管理、收集和分析调用统计以及报告性能。
这是一个清晰的定义。作为一家已经创建了一系列内部 Service 的公司，我现在希望通过向外部订阅者提供 API 的方式构建业务。当然，我会通过提供一些订阅计划来量化它，包括使用限制、范围，并且可以自动的给客户提供账单。
此外，外部开发者可以很容易地发现我提供的 API，并使用他们的信用卡以自服务的方式注册订阅计划，而这一切，对我的 API 代码来说应该是透明的。
分析过这些需求之后，我们可以把它们归为以下几类：
- 访问控制和安全：控制谁可以访问我的 API，以及以何种方式访问。
- API 契约和流量限制：一位用户在一次订阅的情况下可以调用多少次请求。
- 分析和报告：API 运行情况怎么样？哪些方法被调用的最为频繁？有没有错误？API 调用的趋势是什么？
- 开发者门户，文档：让开发者发现你的 API 并注册订阅计划。
- 账单：提供发票并向开发者收取费用。
API 管理方案是如何做到这些的？这要得益于一个叫做 API Gateway 的组件。
这是一个位于调用流程中间环节的组件，所有客户端请求都会经过它，它能够保护你的 API 端点，并通过与其他 API Management 组件通信来决定是否让一个用户访问的你的 API。
它一般是通过对用户请求进行身份识别和流量控制来实现的。考虑下面这个场景：
- 用户 A 订阅了
Basic Plan。 Basic Plan定义了一些 API 操作（HTTP Method + HTTP path）的限制，例如：Get /products和POST /shipments。- 这些限制可以被定义成每秒/分钟/月等等。
GET /Products可以被限制成每分钟请求 10 次。
在这种情况下，当用户 A 想在 1 分钟内调用 10 次以上时，超出的请求就会因为流量控制而收到 429 状态码。或者身份验证没有通过，用户就会收到 403（Forbidden）状态码。身份识别可以通过 Oauth、请求参数或者 header 来提供。
流量控制是 API Management 的关键部分。这也是 API Gateway 针对最终用户执行业务规则的部分，流量控制可以实现非常复杂的场景，比如基于多条规则或客户端 IP。API Management 之所以强大，在于它可以满足复杂流量控制场景（业务规则）的能力。
因此，我可以大声地说：API Management 不（仅仅）是流量限制。
Service Mesh 是什么？
前面我们讲了 API，却没有提及 Service、Application、Port、Connection、Retry 等等，因为在 API Management 层，我们不需要关心这些。但是现在我们需要了。
API 的背后是什么？多个互相通信的 Service，它们之间的交互组成了一个完整的 API，每个 Service 可能由不同的编程语言实现，并且由同一个庞大组织内的不同地区的不同团队进行维护和操作。这听起来耳熟吗？对，微服务！
一个完整的 API，由多个 Service 共同完成，这听起来很棒，但是随着越来越多的团队为新特性或新需求发布新的 Service，日渐增长的架构运维复杂度问题就会暴露出来：
- 如果 Service 之间的内部调用失败了会发生什么？
- 请求失败发生在哪里？
- 为什么这个 API 端点这么慢？哪个 Service 有问题？
- 这个 Service 真的容易出错，我们可以在出错的时候重试吗？
- 某人总是在每天的同一时刻大量请求这个 Service，我们需要通过流量限制避免它。
- 这个 Service 不可以访问到另一个 Service……
这些问题可以由 Service Mesh 解决，并归为以下类别：
- 弹性：超时、重试、熔断、故障处理、负载均衡。
- 流量限制：基于多个来源的基础设施流量限制。
- 通信路由：根据 path、host、header、cookie base、源 Service……
- 可观测性：指标、日志、分布式追踪。
- 安全：mTLS、RBAC……
所有这些都是以对 Application 透明的方式执行的。
我们来看一下 Istio 是如何工作的：
Istio 使用sidecar 容器模式，通过在同一个 Pod 中运行一个新增的容器实例来扩展核心容器的功能。这个核心容器就是我们的 Application，而 Sidecar 容器，是 Istio 基于 Envoy 的代理。
如上图所示，注入之后，所有的出入 Application 容器的通信，都将被这个代理劫持（使用 IPTables）。
通过这种方式，Istio 就能控制通信，以及向控制平面报告发生了什么。确切来说，是报告给作为遥测和策略引擎的 Mixer。
它们之间的共同点是什么？
我们已经明确了这两种技术，你发现了什么共同点？它们试图解决不同的问题，但是使用的是相同的技术……
这两个方案有一点共同之处：
但是记住这一点很重要，它们的流量限制分别用来处理不同的事务：业务规则和基础设施之间的限制。
因此，它们并不是互斥的，我们应该把它们当做基础设施的不同层面：
- API Management：处理对 API 的访问，基于开发者、订阅计划、Application、账单等等。
- Service Mesh：让你的 API 变得更安全，便于监控，以及弹性能力。
我们如何将 3scale API Management 和 Istio Service Mesh 结合起来？
3scale 是如何将 API Management 的能力添加到 Istio Service Mesh 的？请继续关注我们更多的技术发布，你可以使用我们的API Gateway APIcast或者使用3scale Istio Adapter原生地扩展 Istio。
