Author | helight
This article is reprinted with permission arrogant and micro data service application (ID: helight_tech)
This blog is about the API Gateway and Service Grid. Although in 2020, and around this topic is still a lot of confusion. The reason I chose to write this topic, in order to help bring real specific explanation will help clarify the differences and overlap where and when to use which way. If I feel a clear explanation, or do not recognize what I said, or also to ask me to drink a beer (or both), please feel free to contact me (my twwiter: @christianposta).
作者介绍1:作者目前在 Solo.io 工作，主要就是微服务相关的工作。关于微服务大家都有各自的见解。作者在 Solo.io 就是为了实践微服务，并且推向市场，这也是验证各种微服务理论的最佳方式。
作者介绍2:作者同时也是[Istio in Action”](https://www.manning.com/books/istio-in-action)一书的作者，这本书中介绍他重点投入的服务网格技术。这篇文章中的服务网格技术也主要是是从 Istio 的角度来的，但是也会讲更普遍的服务网格技术。
Why another blog on this topic? Other articles related to this topic
On the subject of writing a series of articles, such as: "API gateway is responsible for north-south traffic, service grid is responsible for things flow", "API gateway management business function, and the communication between the service grid management services and services", " from a functional point of view which is the API should do, which is to serve the grid should do "and" service grid API gateway and contrast. "
我在后面也计划逐步翻译这个系列的文章。
From the moment this area still has a lot of local people puzzled.
我还是想看到一些关于不同实现之间取舍的严肃规范的讨论。例如服务网格和 API 网关之间的职责/说明还是有重叠的地方。人们在选择时感到困惑和不知所措。
— Andrew Clay Shafer 雷启理 (@littleidea) June 12, 2019
What's the confusion what puzzles
About a year ago I wrote an article about the API gateway authenticates the crisis, mainly to assess differences API management, Kubernetes Ingresses and API Gateway (related definitions) at. In the last article, I tried to explain how to deal with this as a service grid balance, but the lack of a detailed comparison of these technologies, sufficient to justify the use of that technology when or will lack. I also strongly suggest that you read about the article, considered that the first part of this topic, the article is the second part.
I think the confusion is mainly the following reasons:
-
The technique used is coincident (various agents)
-
On the ability to have overlap (flow control, routing, metrics collection, security / policy enforcement, etc.)
-
Replace with API management service grid idea
-
Error ability to understand the service grid
-
Some services have their own grid gateway
Finally, one of the most easily confusing.
If the service grid just deal with things flow (within the boundary), then why do some service grid technology to achieve another one for the north and south traffic Ingress (it is also part of the grid) gateway it? Typical it is Istio. Take a look at stio Ingress the document gateway how to say:
网关是在网格边界上的一个负载均衡器，处理进入网格或者出网格去的 `HTTP/TCP` 连接。
Our HTTP API is not it? If you use a Istio gateway to send HTTP requests to the cluster / grid (this is the gateway from Envoy Proxy the project built), this is not enough of it?
Assumptions assumptions
Later in this article we mentioned the service refer to the grid Istio and Istio gateway. Select the envisaged scenario because it is a scene that best demonstrate overlap and confusion. There are also other services Grid gateway, but some have no clear gateway.
Where they overlap which places a coincidence?
First is the ability to serve on the grid and the grid API we want to identify what areas of the overlap. They all handle application traffic, so it should not overlap part of the unexpected. Here are some of the listed capacity coincide:
-
Telemetry collection
-
Distributed Track
-
Service Discovery
-
Load Balancing
-
TLS terminate / originate
-
JWT verification
-
Request vomit
-
Traffic segmentation
-
Canary released
-
Traffic shadow (bad translation, the goal is to replicate traffic out to the other services)
-
Limit frequency
These functions will overlap, so you use one or all or a have not used it?
Where they diverge where there are not the same?
Service Grid is running on a layer lower than the API Gateway, and run on a single service architecture. Service grid to service clients more information call: architecture topology-dependent (load balancing client service discovery, request routing), telemetry flexible mechanisms (timeouts, retry, fuse) that should be implemented, should be collected (metric track), as well as security process application (mTLS, RBAC). All of these details are usually achieved by providing sidecar process (consider Envoy), although they can also do not need to be. I do look at the ServiceMeshCon Speech: Evolution service grid data plane.
In this article, API Identity Crisis:
服务网格的目标是针对普遍的任何服务/应用程序在L7透明地解决这些问题【上面列出的那些问题】。换句话说，就是服务网格希望是融入到服务中（而不是实际在服务代码中写代码）。
Bottom line: service grid to provide more details about the architecture of the rest of realization of service / client.
API Gateway is another way to provide services: the details of blows and separated achieved. API Gateway provides a centralized abstract, for all the services of an application architecture for it as a whole, through a proxy designated API to solve the border issue system.
Whether or not the presence of the grid services, the API is present on the gateway applications / services layer, it provides an abstraction layer other systems to access internal system. Looks a bit like a gathering API, API abstraction and expose them to go, this exposure is different from the implementation of the API, and add more complex zero-trust security policies based on user edge. Questions on application architecture and its internal boundary question is not the same, so there must be such a thing occur API gateway to handle this part of the problem.
Border issues and challenges between the service and the service is not the same
On the micro-Service / cloud-native architecture of the border, API Gateway provides three major capabilities, the ability to service the extent of these three grid solution is not the same.
-
Boundary decoupling decoupling border
-
Tight control over data are allowed to be strictly controlled in and out of data into and out
-
Bridging security trust domains bridging domain security trust
Next, a detailed look:
Boundary decoupling decoupling border
API Gateway's core function is to give the outside world the client to provide a stable API interface. From Chris Richardson wrote a book micro-service model, we can be API 网关模式 interpreted as:
明确简化对一组 API/微服务的调用
给指定的使用者，客户端或者消费者模拟一个应用程序的一组 API
这里关键是 API 网关，应用 API 网关之后，它会变成了客户端访问应用程序体系 API 的一个单一入口点
API Gateway API gateway certification referred to in an article in the crisis realized examples:
-
Solo.io Gloo
-
Spring Cloud Gateway
-
Netflix Zuul
-
IBM-Strongloop Loopback/Microgateway
From a functional point of view, API gateway to support what features it? So what is the real business needs of the API gateway is it? And these needs are not well supported by the Service Grid:
-
Request / Response Conversion
-
Protocol conversion applications, such as: REST / SOAP / XSLT
-
Custom response to the error / speed limit
-
Direct response
-
Precise control api / proxy pipeline
-
API 组合/分组
下面来逐个看。
Request / response transformation 请求/相应转换
暴露 API 给外部是 API 网关的功能之一，你可能想隐藏 API 的真实实现而只暴露接口出去。这可能是多种方式的组合，包括改变请求的形式、删除/添加头、把头加入到正文中或是反之。这就提供了一种很好的客户端和服务端的解耦方式：无论服务端对 API 做了改变或是客户端无法随之更新，有了 API 网关，就在这一层可以做一些适配和转换。
Application protocol transformations 应用程序协议转换
许多企业投身于这些技术像基于 HTTP 的 XML 通信、SOAP、或者基于 HTTP 的 JSON 通信。他们可能希望通过更紧靠、特定于客户端的 API 使用这些技术，并继续具有互操作性。此外，服务提供商可能希望采用新的 RPC 机制（像 gRPC）或者流式协议（像 rSocket）。
Error / Rate limit custom responses 自定义对错误/限速的响应
转换来自上游服务的请求是 API 网关的一项关键能力，但是定制来自网关的响应也是很关键的。采用了 API 网关的虚拟 API 来处理请求/响应/错误的客户端，也希望在网关这边能够自定义它的响应内容，以便适配这种协议模式。
Direct responses 直接响应
当客户端（可信的或者恶意的）请求一个不可用的资源，或者因为某些原因受阻止而无法返回上游，最好是可以终止代理，并且返回一个预设的响应。
精确控制 api/proxy 流水线
没有一边倒的代理。一个 API 网关应该有改变功能（比如限频，认证，路由，转换等）应用顺序的能力，并在出现问题时提供调试方法。
API composition API 组合
在多个服务上暴露一个组合功能，通常需要把多个 API 组合成一个 API。像 GraphQL 就可以满足这类需求。
如你所见，在服务提供者和客户端之间提供一个强大的解耦层，涉及的东西远不止是允许 HTTP 流量进入集群。
严格控制进出服务的请求
API 网关的另外一个重要的功能是管理哪些数据/请求可以进入应用程序体系，哪些数据/响应可以流出去。这意味着网关需要深入理解进入系统的请求或出去的请求。例如，一个普通的场景就是 WEB 应用程序防火墙阻止 SQL 注入攻击。另外就是防止数据丢失技术来防止请求中返回 SSN 或者 PII，因为这些规范或者标准的要求：PCI-DSS/HIPPA/GDPR。网关是实现这些策略的天然场所。
SSN：在美国，社会安全号码（Social Security number，SSN）是发给公民、永久居民、临时（工作）居民的一组九位数字号码，是依据美国社会安全法案（Social Security Act）205条C2中社会安全卡的记载。这组数字由联邦政府社会安全局针对个人发行。社会安全号码主要的目的是为了追踪个人的赋税资料，但近年来已经成为实际上（De facto）的国民辨识号码。
PII：个人验证信息（PII，personally identifiable information）是有关一个人的任何数据，这些数据能帮助识别这个人，如姓名、指纹或其他生物特征资料、电子邮件地址、住址、电话号码或社会安全号码。个人验证信息的一个子集是个人识别财务信息（PIFI，personally identifiable financial information）。
PCI-DSS：全称Payment Card Industry (PCI) Data Security Standard,第三方支付行业(支付卡行业PCI DSS)数据安全标准
HIPPA：HIPAA全称为：Health Insurance Portability and Accountability
GDPR：《通用数据保护条例》（General Data Protection Regulation，简称GDPR）为欧洲联盟的条例，前身是欧盟在1995年制定的《计算机数据保护法》。
同样，定义和执行这些功能并不像只允许 HTTP 流量进入集群那么简单。
自定义安全/桥接信任域
API 网关提供的最后一个主要功能就是边界安全。这包括验证外部应用体系的用户和服务提供身份信息和范围策略，这样可以限制访问指定服务和业务功能。这也和前面一段介绍的功能有关系。
一个通用的例子是可以和 OAuth/SSO 认证流绑定，包括 Open ID Connect。对这些标准的挑战在于网关有可能没有完全实现这些功能，或者是实现的不正确。API 网关需要一种方式能够灵活的适配这些环境，同时还要提供自定义能力。
在很多企业都已经有身份/信任/授权机制，所以 API 网关的很大一部分就是能够为这些后端能力进行本地化集成。虽然新的像 SPIFEE 标准已经出现了，但是企业还是需要一段时间来研究使用，在这段时间内 API 网关还是一个强需求（甚至在下一代的应用程序架构中都可能是）。同样，你可以撇一眼上面的内容，这部分也上面提到的转换/解耦有点关系。
说明：SPIFFE（Secure Production Identity Framework For Everyone）以特制的X.509证书形式为现代生产环境中的每个工作负载提供安全标识。SPIFFE消除了对应用程序级身份验证和复杂网络级ACL配置的需求。SPIFFE标准是许多CNCF参与者和其他相关方，聚集在一起提出的共同方法，使便服务彼此呈现和授权他们的身份。SPIFFE仍处于早期实施阶段，尚未准备好进行生产部署 - 您可以通过贡献来提供帮助。SPIFFE和SPIRE的工作由Scytale的员工协调。
网站/代码：https://spiffe.io/ https://github.com/spiffe
如何着手采用一种/另一种/两者/两者都不采用
我之前的一篇博客中，我已经列出了一些采用 API 网关和服务网格的挑战点，并且关于如何选择给了一些建议。
再次重申：从系统服务边界开始。这是架构系统中比较熟悉的一部分。选择最合适的也是要考虑的。自从我们引入云基础设施和云本机应用程序体系结构以来，预设的场景就变了。例如，如果你选择使用 Kubernetes，则强烈建议考虑使用它的生态中的技术来从头构建应用程序网络。比如签出 Evnoy Proxy 对其进行二次修改开发。例如，在 Solo.io，我们就利用 Envoy 构建了一个叫 Gloo 的开源项目来解决这类问题。
你需要服务网格吗？如果你在云平台上部署，在系统中有多种语言/框架的实现需要，并且使用微服务架构构建，那么你需要服务网格。有很多选择的。在我之前的博客中讨论并做过各种比较，比如最近 OSCON 上的演讲，可以随时联系我寻求对你最合适的指导。
收尾
API 网关在一些功能点上和服务网格是重合的。它们在使用的一些技术上也有重合（比如 Envoy）。但是它们的定位是有不同的，所以理解这些可以让你在部署微服务系统的时候少很多痛苦，让你在架构使用过程中发现一些意想不到的场景和用法。
原文：https://blog.christianposta.com/microservices/do-i-need-an-api-gateway-if-i-have-a-service-mesh/
