啥叫网络监控,啥叫网关

2022-09-01 19:31:57 B股动态

　　序　　

　　最近在考虑重构一个新产品。准备微服务的技术方案，搭建基础架构框架。网关是不可或缺的组件。那么，到底什么是网关呢？　　

　　它有哪些特性或特点使其成为微服务的必备组件？今天，我们就来讨论一下这个问题。希望通过这篇文章，大家能明白为什么要用它。　　

　　进化过程　　

　　传统的单一技术架构，所有的内容，都打包成一个包。为了保证系统的稳定性和安全性，有必要开发一些过滤器和拦截器来过滤和拦截客户端请求，并完成最终请求的转发。如下图所示　　

　　在微技术解决方案下，还需要为每个服务开发过滤器和拦截器来管理请求。但由于服务数量多，客户端形式多样，如果每个服务都开发，会造成很大的代码冗余和开发负担。因此，期望将一些相同的功能提取到一个服务中，并且这将成为一个组件，即当前的网关。　　

　　网关存在的原因：　　

　　在微服务技术框架下，请求管理功能解决了微服务技术框架下的多客户端适配，使用单一门户完成协议适配网关的基本功能。　　

　　在微技术解决方案下，网关必须至少具备图中所示的基本功能。　　

　　统一请求管理作为网关的单点入口，消除了客户端直接连接众多微服务的复杂性，采用单点入口实现路由转发，从而实现了服务调用服务对整个系统的不稳定。然后网关需要进行限流熔断，以维持系统的稳定性和分区容错。对于服务调用环节，网关有责任记录和监控日志以保证整个系统。在监控下，工作系统可能不仅被它自己的客户机调用。很多情况下，系统对外开放能力API，所以网关需要安全认证来保证安全。这些年来，API gateway正在经历一些身份危机。　　

　　它们是集中和共享的资源吗，从而促进API对外部实体的公开和治理？他们是集群的入口哨兵吗，这样他们就可以严格控制哪些用户流量进入或离开集群？还是他们根据自己拥有的客户端类型，使用某种API结合glue更简洁地表达API？当然，房间里的大象和我经常听到的一个问题：“服务网格会让API gateway过时吗？房间里的大象：英语习语指的是虽然显而易见，但由于尴尬、争论、敏感或禁忌等原因而被人们故意忽略的东西。　　

　　背景随着技术的快速发展，整个行业正在通过技术和架构模式快速洗牌。如果你说“这些都让我脑袋长大了”，你就能理解了。在这篇文章中，我希望总结“API Gateway”的不同身份，明确公司中哪些群体可以使用API Gateway(他们试图解决的问题)，并重新关注这些首要原则。理想的情况是，在本文结束时，您将对API基础设施在不同级别以及对于不同团队的作用有更好的理解，同时理解如何从每个级别获得最大价值。　　

　　在深入探讨之前，我们先明确一下API这个词的含义。　　

　　我对API的定义：一个明确定义和目的型接口，通过网络调用，使软件开发人员能够以受控且方便的方式，对组织内的数据和功能进行编程访问。 　　

　　这些接口抽象了技术架构的细节来实现它们。对于这些设计的网络端点，我们希望获得一定程度的文档、使用指南、稳定性和向后兼容性。　　

　　相反，仅仅因为我们可以通过网络与另一个软件进行通信，并不一定意味着远程端点就是符合这个定义的API。许多系统相互通信，但是通信更随机地发生，并且要权衡耦合和其他因素。　　

　　我们创建API来为业务的所有部分提供全面的抽象，以实现新的业务功能和偶尔的创新。　　

　　说到API网关，首先要提到的就是API管理。　　

　　API管理很多人从API管理的角度考虑API网关。这是公平的。但是，让我们快速了解一下此类网关的功能。　　

　　通过API管理，我们试图解决“何时公开现有API以供他人使用”的问题，如何跟踪谁使用这些API，实现谁被允许使用它们的策略，建立身份验证和许可的安全流程，并创建服务目录(可在设计时使用，以促进API的使用，并为有效的治理奠定基础)。　　

　　我们希望解决“我们必须与他人共享这些现有的、设计良好的API，但我们必须根据我们的条款来共享它们”的问题。　　

　　API管理也做得很好。它允许用户(潜在的API用户)进行自助服务，并签署不同的API使用计划(请考虑：在给定的时间范围内，每个端点在指定的价格点上每个用户的调用次数)。能够执行这些管理功能的基础设施是网关(API流量通过它流动)。在网关层，我们可以执行身份验证、速率限制、索引收集和其他策略执行。　　

://tupian.lamuhao.com/pic/img.php?k=啥叫网络监控,啥叫网关5.jpg">

API Management Gateway

基于API网关的API管理软件示例：

Google Cloud ApigeeRed Hat 3ScaleMulesoftKong在这个级别上，我们考虑的是API（如上定义）是如何最好地管理和允许对其进行访问。我们不是在考虑服务器，主机、端口、容器甚至服务（另一个定义不明确的词）。

API管理（以及它们相应的网关）通常被作为由“平台团队”、“集成团队”或其它API基础架构团队所拥有的、严格控制的共享基础架构。

需要注意的一件事：我们要小心，别让任何业务逻辑进入这一层。如前一段所述，API管理是共享的基础结构，但是由于我们的API流量经过了它，因此它倾向于重新创建“大包大揽的全能型”（认为是企业服务总线）网关，这会导致我们必须与之协调来更改我们的服务。从理论上讲，这听起来不错。实际上，这最终可能成为组织的瓶颈。有关更多信息，请参见这篇文章：具有ESB，API管理和Now…Service Mesh的应用程序网络功能？

集群入口为了构建和实现API，我们将重点放在代码、数据、生产力框架等方面。但是，要想使这些事情中的任何一个产生价值，就必须对其进行测试，部署到生产中并进行监控。当我们开始部署到云原生平台时，我们开始考虑部署、容器、服务、主机、端口等，并构建可在此环境中运行的应用程序。我们可能正在设计工作流（CI）和管道（CD），以利用云平台快速迁移、更改、将其展示在客户面前等等。

在这种环境中，我们可能会构建和维护多个集群来承载我们的应用程序，并且需要某种方式来访问这些群集中的应用程序和服务。以Kubernetes为例思考。我们可能会通过Kubernetes Ingress来访问Kubernetes集群（集群中的其它所有内容都无法从外部访问）。这样，我们就可以通过定义明确的入口点（例如域/虚拟主机、端口、协议等），严格控制哪些流量可以进入（甚至离开）我们的集群。

在这个级别上，我们可能希望某种“ingress网关”成为允许请求和消息进入群集的流量哨兵。在这个级别上，您的思考更多是“我的集群中有此服务，我需要集群外的人能够调用它”。这可能是服务（公开API）、现有的整体组件、gRPC服务，缓存、消息队列、数据库等。有些人选择将其称为API网关，而且实际上可能会做比流量的入口/出口更多的事情，但重点是这个层级的问题是属于集群操作级别的。

Cluster Ingress Gateway

这些类型的ingress实现的示例包括：Envoy Proxy 及其基础上的项目包括：

Datawire AmbassadorSolo.io GlooHeptio Contour基于其他反向代理/负载均衡器构建的其它组件：

HAProxyOpenShift’s Router (based on HAProxy)NGINXTraefikKong此层级的集群入口控制器由平台团队操作，但是，这部分基础架构通常与更加去中心化的、自助服务工作流相关联（正如您对云原生平台所期望的那样）。参见The “GitOps” workflow as described by the good folks at Weaveworks

API网关模式关于“ API网关”一词的另一种扩展是我在听到该术语时通常想到的，它是与API网关模式最相似的。Chris Richardson在其“微服务模式”一书第8章很好地介绍了这种用法。我强烈建议您将此书用于此模式和其他微服务模式学习资料。可在他的microservices.io网站API Gatway Pattern可以进行快速浏览。简而言之，API网关模式是针对不同类别的消费者来优化API的使用。这个优化涉及一个API间接访问。您可能会听到另一个代表API网关模式的术语是“前端的后端”，其中“前端”可以是字符终端（UI）、移动客户端、IoT客户端甚至其它服务/应用程序开发人员。

在API网关模式中，我们明显简化了一组API的调用，以模拟针对特定用户、客户端或使用者的“应用程序”内聚API。回想一下，当我们使用微服务构建系统时，“应用程序”的概念就消失了。API网关模式有助于恢复此概念。这里的关键是API网关，一旦实现，它将成为客户端和应用程序的API，并负责与任何后端API和其他应用程序网络端点（不满足上述API定义的端点）进行通信。

与上一节中的Ingress控制器不同，此API网关更接近开发人员的视角，而较少关注哪些端口或服务暴露以供集群外使用的方面。此“ API网关”也不同于我们管理现有API的API管理视角。此API网关将对后端的调用聚合在一起，这可能会公开API，但也可能是与API描述较少的东西，例如对旧系统的RPC调用，使用不符合“ REST”的协议的调用（如通过HTTP但不使用JSON），gRPC，SOAP，GraphQL、websockets和消息队列。这种类型的网关也可用来进行消息级转换、复杂的路由、网络弹性/回退以及响应的聚合。

如果您熟悉REST API的Richardson Maturity模型，就会发现相比Level 1–3，实现了API网关模式的API网关来集成了更多的Level 0请求（及其之间的所有内容）。

https://martinfowler.com/articles/richardsonMaturityModel.html

这些类型的网关实现仍需要解决速率限制、身份验证/授权、断路、度量收集、流量路由等问题。这些类型的网关可以在集群边缘用作集群入口控制器，也可以在集群内部用作应用程序网关。

API Gateway Pattern

此类API网关的示例包括：

Spring Cloud GatewaySolo.io GlooNetflix ZuulIBM-Strongloop Loopback/Microgateway也可以使用更通用的编程或集成语言/框架（例如：

Apache CamelSpring IntegrationBallerina.ioEclipse Vert.xNodeJS由于这种类型的API网关与应用和服务的开发紧密相关，因此我们希望开发人员能够参与帮助指定API网关公开的API，了解所涉及的任何聚合逻辑以及快速测试和更改此API基础架构的能力。我们还希望运维人员或SRE对API网关的安全性、弹性和可观察性配置有一些意见。这种层级的基础架构还必须适应不断发展的、按需的、自助服务开发人员工作流。可以通过查看GitOps模型获取更多这方面信息。

进入服务网格(Service Mesh)在云基础架构上运行服务架构的一部分难点是，如何在网络中构建正确级别的可观察性和控制。在解决此问题的先前迭代中，我们使用了应用程序库和希望的开发人员治理来实现此目的。但是，在大规模和多种开发语言环境下，服务网格技术的出现提供了更好的解决方案。服务网格通过透明地实现为平台及其组成服务带来以下功能：

服务到服务（即东西向流量）的弹性安全性包括最终用户身份验证、相互TLS、服务到服务RBAC / ABAC黑盒服务的可观察性（专注于网络通信），例如请求/秒、请求延迟、请求失败、熔断事件、分布式跟踪等服务到服务速率限制，配额执行等精明的读者会认识到，API网关和服务网格在功能上似乎有所重叠。服务网格的目的是通过在L7透明地解决所有服务/应用程序的这些问题。换句话说，服务网格希望融合到服务中（实际上它的代码并没有嵌入到服务中）。另一方面，API网关位于服务网格以及应用程序之上（L8？）。服务网格为服务、主机、端口、协议等（东西向流量）之间的请求流带来了价值。它们还可以提供基本的集群入口功能，以将某些此功能引入南北向。但是，这不应与API网关可以带来北/南流量的功能相混淆。（一个在集群的南北向和一个是在一组应用程序的南北向）

Service Mesh和API网关在某些方面在功能上重叠，但是在它们在不同层面互补，分别负责解决不同的问题。理想的解决方案是将每个组件（API管理、API网关、服务网格）合适的安置到您的解决方案中，并根据需要在各组件间建立良好的边界（或在不需要时排除它们）。同样重要的是找到适合去中心化开发人员和运营工作流程的这些工具实现。即使这些不同组件的术语和标识存在混淆，我们也应该依靠基本原理，并了解这些组件在我们的体系结构中带来的价值，从而来确定它们如何独立存在和互补并存。

微服务不能没有网关，就如同 Java 程序员不能没有IDEA、Eclipse。为什么呢？

之所以网关对微服务这么重要，主要有以下几点原因：

1. 解决 API 放哪里的问题要知道，采用微服务架构的系统本身是由很多的独立服务单元组合起来的。而客户端要调用系统，则必须通过系统提供的各种对外开放的 API 来实现。

问题来了，这些 API 要放在哪里呢？直接放在组成系统的服务单元上行不行？

比如，在一套电商系统上，关于订单相关的 API ，放在组成订单服务的服务单元上；风控服务的 API ，放在组成风控服务的服务单元上。

好，咱们假设有这么一个场景，有一位用户想在这套电商系统上查看下商品详情。那么，这个查看商品详情的操作，就可能：

调用商品服务的 API 获取商品描述调用评价服务的 API 获取相关评价调用商家服务的 API 获取商家信息调用礼券服务的 API 获取相关礼券……

可以看到，就这么一个商品查看操作，就可能会调用许多服务的 API。

那这些 API 如果全部分散到各个服务单元上，供客户端调用，像查看商品这么简单的一次操作，客户端就可能需要远程访问好几次甚至十几次服务器。

微服务自己又讲究把 API 的粒度划分的很细，也就是说，可能从商品服务上调用商品信息，不止是调用一次商品服务就够了，很可能需要多次对商品服务的不同 API 进行调用，才能获取到足够的数据。

这样一来，客户端需要访问服务器的次数就更多了，可能十几次都不够，得几十次。

这种多次访问服务器的行为，会极大延迟客户端的界面响应时间，很不现实。

所以，把 API 放到各个业务相关的服务单元上，看上去问题很大。

那为什么引入网关就能解决这个问题呢？

因为引入网关，就相当于在客户端和微服务之间加了一层隔离。通常，网关本身会和各个服务单元处于同一个机房，这样，客户端做业务操作的时候，只需要访问一次网关。然后剩下的事情，再由网关分别访问同在一个机房的不同的服务，再把拿到的数据统一在网关封装好，返回给客户端就好。

2. 解决边缘功能集成的问题在一套微服务组成的系统里，除了必须的业务功能以外，还有为了系统自身的健壮与安全，以及微服务本身的管理，而必须引入的一些非业务功能。对于这些非业务又很重要的功能，我们统称为边缘功能。

还是拿电商系统为例，我们来看一些重要的边缘功能。

假设因为我们做了一次非常大的促销活动，导致流量过大，系统承载不了了。此时，为了保证系统本身的稳定，我们就需要把一些承载不了的流量给通过各种手段消化掉，一般的做法有三种：

限流：通过令牌桶等算法，把一些额外的流量挡在系统外面，不让其访问。降级：由于系统可能已经过载了，此时，我们就放弃处理一些服务和页面的请求或者仅简单处理，比如直接返回一个报错。熔断：有些时候，系统过载过度或者上线出了 bug，降级都解决不了问题。比如，缓存失效了，导致大量请求频繁访问了数据库，而这种频繁访问数据库可能造成了大量的 IO 操作，结果又去影响了数据库所在的操作系统，同时，这个操作系统上又有着别的重要服务，直接也被影响了。对于这种连锁反应，我们称之为雪崩。而为了防止雪崩，我们就会坚决把缓存失效导致数据库被频繁访问的服务给停掉，这就是熔断。可以看到，像限流、降级、熔断这些系统保障策略，最合适的地方应该是有一个集中的请求入口点，就像古时候，老百姓进城需要过城门那样。

当系统出现问题的时候，直接就在这个入口点做相应的操作即可。

限流，就直接在这个入口点限制后续请求。降级，就直接在这个入口点判断请求想要访问的服务或者页面，直接报错返回。熔断，就直接在这个入口点，断开所有访问特定服务的请求连接，然后再把后继对特定服务的访问，也统统拦在门外。在电商系统里，有很多特殊场景的接口，需要受到严格的限制。

比如，支付接口，访问它就需要认证和权限控制。又比如，对于系统的访问，有时候不能让国外的去访问国内的网站，这就需要限制客户端的访问 IP，所以系统还需要认证和授权功能。

那这种认证和授权也最合适放在请求的一个集中入口点，统一实现。

还记得上面咱们说过的网关的 API 统一存放吗？我们只需要对这些 API 做对应的权限设置，当请求访问特殊场景接口的时候，必定会通过 API 访问。所以，限制接口的访问，本质上就是对特定 API 的限制，那么，放在网关再合适不过了。

现实里，我们有时候需要把线上的流量镜像出来，转发到灰度环境，利用这些镜像出来的流量既可以用于小范围测试，又可以更好的评估系统所能承载的最大吞吐量，也因此，系统需要有一个统一入口做分流。

可以看到，无论是系统需要的保障策略，认证授权，还是流量分流等功能，都应该放到一个统一的请求入口处才能得到最好的实现。网关恰好就承担了这么个统一请求入口的角色。

所以，对于微服务中，林林总总的边缘功能，往往会通过插件的形式，集成在 API 网关中。

3. 解耦了客户端和后端微服务一套项目，在使用微服务模式的初期，往往后端变化是十分频繁的。

频繁变化的原因有很多，像业务领域划分不合适啊，像某个业务模块急速膨胀啊，都可能导致后端微服务的剧烈变化。

在这种情况下，如果没有网关，很可能就会出现客户端需要被迫随着后端的变化而变化的情况。

比如，在电商系统里，初期我们很可能会把风控服务做的非常小。随着业务的发展，风控服务越来越庞大，此时，风控服务就可能被分解为决策引擎和分析中心等更多更细的服务。