前言最近在想重构一个新产品。准备采用微服务技术方案构建基础架构。网关，是必不可少的组件。那么，究竟什么是网关？它有哪些特性或功能使其成为微服务不可或缺的组件？今天，我们就来探讨一下这个问题。希望通过这篇文章，大家能够明白为什么要用它。演进过程传统单体技术架构，所有内容打包成一个包。为了保证系统的稳定性和安全性，需要开发一些过滤器和拦截器来实现对客户端请求的过滤和拦截，完成最终请求的转发。如下图所示在微服务技术方案下，还需要为每个服务开发过滤器和拦截器来管理请求。但是由于服务数量众多，客户端形态多样化，如果每一个服务都开发，会造成大量的代码冗余和开发负担。所以期望将一些相同的功能抽取出来做成一个服务来实现，成为一个组件，也就是当前的网关。网关存在的原因：解决微服务技术架构下的请求管理功能，解决微服务技术架构下的多客户端适配，使用单一入口完成基础功能协议适配网关。在微服务技术方案下，网关，至少需要图标的基本功能。网关作为单点入口，完成统一的请求管理，消除了客户端直连众多微服务的复杂性。使用单点入口实现路由转发，从而实现服务调用服务对于整个系统来说是不稳定的，那么需要对网关进行限流熔断，以保持系统稳定和分区容错。对于服务调用的链路，网关有责任记录和监控日志，确保整个系统在监控下工作。系统可能不仅仅被自己的客户端调用，很多时候系统对外开放API，所以网关需要安全认证来保证安全。多年来，API网关正在经历一些身份危机。它们是促进API公开和对外部实体进行治理的集中式共享资源吗？它们是集群入口哨兵，允许严格控制哪些用户流量进入或离开集群吗？或者他们是否使用某种API绑定胶来更简洁地表达API，具体取决于他们拥有的客户端类型？当然，房间里的大象和我经常听到的一个问题：“服务网格会让API网关过时吗？”Theelephantintheroom:英语成语，指的是一些显而易见但可能令人尴尬、争执、触动敏感或禁忌等原因而被故意忽略的事情。一些背景随着技术的发展日新月异，整个行业在技术和架构模型上快速洗牌。可以理解。在本文中，我希望总结“API网关”的不同身份，明确公司中哪些群体可以使用API网关（他们试图解决的问题），并重新关注这些首要原则。理想情况下，到本文结束时，您将更好地了解API基础设施如何在不同层级和不同团队工作，以及如何从每一层中获得最大价值。在我们深入研究之前，让我们澄清术语API的含义。我对API的定义：一个定义明确且有目的的接口，通过网络调用，使软件开发人员能够以可控和方便的方式以编程方式访问组织内的数据和功能。这些接口抽象了其实现的技术架构细节。对于这些设计好的网络端点，我们期望有一定程度的文档、使用指南、稳定性和向后兼容性。相反，仅仅因为我们可以通过网络与另一个软件进行通信并不一定意味着远程端点是符合此定义的API。许多系统相互通信，但通信的发生更加随意，并且需要权衡耦合和其他因素。我们创建API来为业务的各个部分提供深思熟虑的抽象，从而实现新的业务功能和偶尔的创新。说到API网关，首先要提到的就是API管理。API管理许多人从API管理的角度来考虑API网关。这是公平的。但是，让我们快速了解一下此类网关的功能。通过API管理，我们试图解决“何时公开现有API供他人使用”的问题，如何跟踪谁使用这些API，对允许谁使用它们执行策略，建立身份验证和授权的安全流程，以及同时创建服务目录（可以在设计时使用，方便API消费，为有效治理提供基础）。我们想要解决“我们有这些现有的、设计良好的API，我们希望与他人共享，但要按照我们的条件”。API管理也做得很好，允许用户（潜在的API消费者）自助服务，注册不同的API使用计划（想想：每个用户调用）。能够执行这些管理功能的基础设施是网关（API流量通过）。在网关层，我们可以执行身份验证、速率限制、指标收集、其他策略执行等。API管理网关基于API网关的API管理软件示例：GoogleCloudApigeeRedHat3ScaleMulesoftKong在这一层我们考虑如何将API（如上定义）得到最好的管理并允许访问它。我们没有考虑服务器、主机、端口、容器甚至服务（另一个定义不明确的词）。API管理（及其相应的网关）通常表现为由“平台团队”、“集成团队”或其他API基础架构团队拥有的严格控制的共享基础架构。有一点需要注意：我们必须小心不要让任何业务逻辑进入这一层。如前一段所述，API管理是共享基础设施，但由于我们的API流量通过它，它往往会重新创建“一体化”（想想企业服务总线）网关，这将导致我们必须与它改变我们的服务。从理论上讲，这听起来不错。事实上，这最终可能成为组织的瓶颈。有关更多信息，请参阅此帖子：使用ESB、API管理和现在...服务网格的应用程序网络？集群入口为了构建和实施API，我们专注于代码、数据、生产力框架等。但是要使这些东西中的任何一个有价值，都必须对其进行测试、部署到生产环境并进行监控。当我们开始部署到云原生平台时，我们开始思考部署、容器、服务、主机、端口等，并构建可以在这个环境中运行的应用程序。我们可能正在设计工作流（CI）和流水线（CD），以利用云平台快速迁移、更改、拿到客户面前等。在这种环境下，我们可能会构建和维护多个集群来托管我们的应用程序，并且需要某种方式来访问这些集群中的应用程序和服务。以Kubernetes为例。我们可以通过KubernetesIngress访问Kubernetes集群（集群中的其他所有内容都无法从外部访问）。这样，我们可以通过定义明确定义的入口点（例如域/虚拟主机、端口、协议等）来严格控制哪些流量可以进入（甚至离开）我们的集群。在这个级别，我们可能希望某种“入口网关”成为允许请求和消息进入集群的流量哨兵。在这个层面上，你的想法更多的是“我的集群中有这个服务，我需要集群外的人才能调用它”。这可能是服务（公开API）、现有的整体组件、gRPC服务、缓存、消息队列、数据库等。有些人选择将其称为API网关，它实际上可能不仅仅是流量的入口/出口，但是重点是这种关注级别是在集群操作级别。ClusterIngressGateway这些类型的入口实现的示例包括：Envoy代理和基于它的项目包括：DatawireAmbassadorSolo.ioGloOHeptioContour其他构建在其他反向代理/负载平衡器之上的组件：HAProxyOpenShift的路由器（基于HAProxy）这一层的NGINXTraefikKong集群入口控制器由平台团队运营，然而，这部分基础设施通常与更分散的自助服务工作流相关联（正如您对云原生平台的期望）。请参阅WeaveworksAPI网关模式中的好人所描述的“GitOps”工作流程术语“API网关”的另一个扩展是我通常在听到该术语时想到的，它是与API网关模式最相似的一个.ChrisRichardson在他的“微服务模式”一书的第8章中很好地介绍了这种用法。我强烈建议您将这本书用于本课程和其他微服务模式学习资料。在他的microservices.io网站上可以快速浏览API网关模式。简而言之，API网关模式就是针对不同类别的消费者优化API的使用。此优化涉及API间接寻址。您可能听到的另一个代表API网关模式的术语是“前端后端”，其中“前端”可以是字符终端(UI)、移动客户端、IoT客户端甚至其他服务/应用程序开发人员。在API网关模式中，我们显着简化了对一组API的调用，以模拟特定用户、客户或消费者的“应用程序”内聚API。回想一下，当我们使用微服务构建系统时，“应用程序”的概念就消失了。API网关模式有助于恢复这个概念。这里的关键是API网关，一旦实现，它就会成为客户端和应用程序的API，并负责与任何后端API和其他应用程序网络端点（不符合上述API定义的端点）进行通信。与上一节中的Ingresscontroller不同，这个APIGateway更贴近开发者的视角，不太关心暴露哪些端口或服务在集群外使用。这个“APIGateway”也不同于我们管理现有API的API管理视角。此API网关聚合对后端的调用，这可能会公开API，但也可能对API的描述性较低，例如对遗留系统的RPC调用、使用不符合“REST”协议的调用（例如通过HTTP但不是JSON）、gRPC、SOAP、GraphQL、websockets和消息队列。这种类型的网关还可用于消息级转换、复杂路由、网络弹性/回退和响应聚合。如果您熟悉RESTAPI的Richardson成熟度模型，您会发现实施API网关模式的API网关集成了比1-3级更多的0级请求（以及介于两者之间的所有请求）。https://martinfowler.com/arti...这些类型的网关实现仍然需要解决限速、认证/授权、熔断、指标收集、流量路由等问题。这些类型的网关可以用作集群入口集群边缘的控制器，或作为集群内部的应用程序网关。API网关模式此类API网关的示例包括：SpringCloudGatewaySolo.ioGlooNetflixZuulIBM-StrongloopLoopback/Microgateway也可以使用更通用的编程或集成语言/框架（例如：ApacheCamelSpringIntegrationBallerina.ioEclipseVert.xNodeJS由于这种类型的API网关与应用程序和服务的开发密切相关，因此我们希望开发人员参与帮助指定API网关公开的API，了解涉及的任何聚合逻辑，并能够快速测试和更改此API基础设施。我们还希望Ops或SRE对API网关的安全性、弹性和可观察性的配置有一些输入。这一级别的基础设施还必须适应不断发展的、按需的、自助服务的开发人员工作流程。这可以通过查看GitOps模型捕获更多。迁移到服务网格以在云基础设施上运行服务架构的部分挑战是如何在网络中构建正确级别的可观察性和控制。解决此问题的先前迭代在中，我们使用应用程序库并希望开发人员治理来实现这一目标。然而，在大规模和多种开发语言环境中，出现了服务网格技术以提供更好的解决方案。服务网格通过透明实现为平台及其组成服务带来以下功能：服务到服务（即东西向流量）弹性安全，包括最终用户身份验证、双向TLS、服务到服务RBAC/ABAC用于黑盒服务的可观察性（专注于网络通信），例如请求/秒、请求延迟、请求失败、断路器、分布式跟踪等。服务到服务的速率限制、配额强制执行等。精明的读者会认识到，API网关和服务网格在功能上似乎有一些重叠。服务网格的目的是在L7透明地为所有服务/应用程序解决这些问题。换句话说，服务网格想要集成到服务中（它的代码实际上并没有嵌入到服务中）。另一方面，API网关位于服务网格和应用程序（L8？）之上。服务网格为服务、主机、端口、协议等（东西向流量）之间的请求流带来价值。他们还可以提供基本的集群入口功能，将其中的一些功能带入南北方向。但是，这不应与API网关带来南北流量的能力相混淆。（一个在集群的南北方向，一个在一组应用的南北方向）ServiceMesh和APIGateway在某些方面有重叠，但是在不同的层次上相互补充，分别负责解决不同的问题.理想的解决方案是将每个组件（API管理、API网关、服务网格）适当地放入您的解决方案中，并根据需要在组件之间创建良好的边界（或在不需要时排除它们）。同样重要的是找到适合分散的开发人员和运营工作流程的这些工具的实现。即使对这些不同组件的术语和标识存在混淆，我们也应该依靠基础知识并了解这些组件为我们的架构带来的价值，以确定它们如何独立存在并相互补充。微服务离不开网关，就像Java程序员离不开IDEA和Eclipse一样。为什么？网关对微服务如此重要的主要原因有以下几点：1、要解决API放在哪里的问题，必须知道采用微服务架构的系统本身就是由许多独立的服务单元组成的。但是，如果客户端想要调用系统，则必须通过系统提供的各种开放API来实现。问题是，这些API应该放在哪里呢？能不能直接放在组成系统的服务单元上呢？例如，在电子商务系统中，订单相关的API放在构成订单服务的服务单元上；风控服务的API放在构成风控服务的服务单元上。好吧，假设有一个场景，用户想在这个电商系统上查看商品详情。然后可以进行查看商品详情的操作：调用商品服务接口获取商品描述调用评价服务接口获取相关评价调用商户服务接口获取商家信息调用礼券服务接口获取相关礼券...可以看到，就这样一个商品查看操作，可能会调用很多服务的API。如果将这些API全部分发到各个服务单元供客户端调用，那么对于一个简单的查看商品的操作，客户端可能需要远程访问服务器数次甚至十几次。微服务也很注重把API的粒度划分的很细。也就是说，可以从商品服务中调用商品信息。商品服务调用一次是不够的，很可能需要多次调用商品服务的不同API。,以获得足够的数据。这样，客户端需要访问服务器的次数就更多了，可能十几次还不够，要几十次。这种多次访问服务器的行为会大大延迟客户端界面的响应时间，这是很不现实的。所以，把API放到各种业务相关的服务单元上，似乎是个大问题。那么为什么引入网关可以解决这个问题呢？因为引入网关相当于在客户端和微服务之间加了一层隔离。通常网关本身会和各个业务单位在同一个机房??，这样客户端在进行业务操作时，只需要访问一次网关即可。然后剩下的，网关会在同一个机房??分别访问不同的服务，然后把获取到的数据统一在网关里面，封装起来，返回给客户端。2.解决边缘功能集成问题在由微服务组成的系统中，除了必要的业务功能外，还有一些非业务功能是必须引入的，为了系统本身的健壮性和安全性，以及管理微服务本身。功能。对于这些非业务但非常重要的功能，我们统称为边缘功能。还是以电商系统为例，来看一些重要的边缘功能。假设因为我们有一个非常大的促销活动，流量太大，系统无法承受。这个时候，为了保证系统本身的稳定性，我们需要通过各种方式来消化一些无法承载的流量。一般的方法有3种：限流：使用令牌桶等算法，在系统外部阻断一些额外的流量，不允许其访问。降级：由于系统可能已经过载，此时，我们放弃处理一些服务和页面请求或者简单处理，比如直接返回错误报告。熔断：有时系统过载或线路有bug，降级也解决不了问题。比如缓存失效，大量请求频繁访问数据库，而这种频繁访问数据库可能会造成大量的IO操作，进而影响数据库所在的操作系统。同时，这个操作系统的其他重要服务也受到直接影响。对于这种连锁反应，我们称之为雪崩。为了防止雪崩，我们将坚决停止因缓存失效导致数据库被频繁访问的服务。这是断路器。由此可见，限流、降级、断路器等系统保护策略最适合的地方应该是有一个集中的请求入口点，就像古代普通人进城要经过城门一样城市。当系统出现问题时，只要在这个入口点做相应的操作即可。限流，直接在这个入口点限制后续的请求。降级，直接在这个入口判断请求要访问的服务或页面，直接报错。Fuse，直接在这个入口点，断开所有访问特定服务的请求，然后将后续对特定服务的访问从门口堵住。在电商系统中，有很多针对特殊场景的接口需要严格限制。比如支付接口，访问它需要鉴权和权限控制。再比如，对于系统的访问，有时候国外的用户不能访问国内的网站，这就需要限制客户端的访问IP，所以系统也需要认证和授权的功能。那么这种认证授权也是最适合放在请求的一个集中入口统一实现的。还记得我们上面提到的网关API的统一存储吗？我们只需要为这些API设置相应的权限即可。请求访问特殊场景接口时，必须通过API访问。所以，限制访问一个接口，本质上就是对具体的API进行限制，所以最好放在网关上。现实中，我们有时需要对线上流量进行镜像，转发到灰度环境。使用这些镜像流量可以用于小规模测试，更好的评估系统可以承载的最大吞吐量。因此，系统需要有一个统一的导流入口。由此可见，无论是系统需要的安全策略、认证授权，还是流量分发等功能，都应该放在统一的请求入口处，才能得到最好的实现。网关只是承担了这样一个统一请求入口的角色。因此，对于微服务而言，各种边缘功能往往以插件的形式集成在API网关中。3.解耦了一组客户端和后端微服务项目。在使用微服务模型的早期，后端往往变化非常频繁。频繁变更的原因有很多，比如业务领域划分不当，或者某个业务模块快速扩容，可能导致后端微服务发生剧变。在这种情况下，如果没有网关，很可能会出现需要随着后端的变化而强制改变客户端的情况。比如在电商系统中，我们前期很可能把风控服务做的非常小。随着业务的发展，风控服务越来越大。此时，风控服务可能会分解为决策引擎、分析中心等越来越细化的服务。在电子商务中，风控往往是下单、支付等操作的必要前置操作。如果没有网关分离客户端和微服务，客户端直接和风控服务打交道，那么风控服务的拆分必然导致API不稳定。API的变化自然会导致调用API的客户端代码发生变化。有了网关，情况就好多了。当风控服务本身变化频繁时，我们只需要改改网关的代码即可。服务器代码升级比客户端代码升级容易得多。参考链接：https://juejin.cn/post/691821...为什么微服务一定要有API网关？jianshu.com/p/9fab0982c6bb微信公众号【程序员黄小邪】作者原蚂蚁金服Java工程师。分布式、spring全家桶、微服务、高并发、JVM、Docker容器、ELK、大数据等。关注后回复【书籍】领取Java面试必备20本精选电子书。
