微服务网关为客户端负载（微服务网关如何调用服务）

本篇文章给大家谈谈微服务网关为客户端负载，以及微服务网关如何调用服务对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务网关为客户端负载的知识，其中也会对微服务网关如何调用服务进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、微服务之网关聚合模式
• 2、微服务架构：基于微服务和Docker容器技术的PaaS云平台架构设计
• 3、【知识总结】4.微服务的治理去中心化，服务发现，安全，部署

微服务之网关聚合模式

使用网关可以将多个单独的请求聚合到一个请求中。当客户端必须对多个不同的后端系统进行多次调用操作时，此模式很有用。

有时候执行单个任务时，客户端可能必须对不同的各个后端服务进行多次调用。因为他们依赖于多个服务，那么客户端必须调用不同的服务接口以完成这次请求，这样就会导致请求过多而浪费很多的资源。当任何新功能或服务添加到应用程序时，从而会进一步增加资源需求和网络调用。客户端和后端之间的这种混乱调用可能会对应用程序的性能和规模产生负面影响。微服务架构使这个问题变得更加普遍，因为围绕许多小型服务构建的应用程序自然会有更多的跨服务调用。

在下图中，客户端向每个服务发送请求（1,2,3）。每个服务处理请求并将响应发送回应用程序（4,5,6）。通常具有高延迟的蜂窝网络上，以这种方式使用单独的请求是低效的并且可能导致连接中断或请求不完整。虽然每个请求可以并行完成，但应用程序必须为每个请求发送，等待和处理数据，所有这些都在不同的连接上，从而增加了失败的可能性。

使用网关来减少客户端和服务之间的干扰。网关接收客户端请求，将请求分派给各种后端系统，然后聚合结果并将它们发送回请求客户端。
这种模式可以有效减少应用程序对后端服务的调用请求数，而且在高延迟网络上的应用程序的性能有大的提升。

在下图中，应用程序向网关发送请求（1）。该请求包含一组附加请求。网关分解这些请求并通过将每个请求发送到相关服务来处理每个请求（2）。每个服务都返回对网关的响应（3）。网关聚合每个服务的响应并将响应发送到应用程序（4）。应用程序发出单个请求，并且只从网关接收一个响应。

1.网关不应该在后端服务中引入服务耦合
2.网关应该和后端服务位置很近，以尽可能减少延迟。
3.网关服务可能须要做ha。确保网关设计合理，以满足您的应用程序的可用性要求。
4.网关可能是性能瓶颈。确保网关具有足够的性能来处理负载，并且可以扩展以满足您的预期增长。
5.对网关执行负载测试，以确保不会导致服务的级联故障。
6.使用隔板，断路，重试和超时等技术实现弹性设计。
7.如果一个或多个服务调用花费的时间太长，则可以接受超时并返回部分数据集。考虑您的应用程序将如何处理此方案。
8.使用异步I / O来提升程序的吞吐量。
9.通过分布式跟踪对全链路进行监控。
10.监控请求指标和响应大小。
11.考虑将缓存数据作为故障转移策略来处理故障。
12.不要将聚合构建到网关中，而是考虑在网关后面放置聚合服务。请求聚合可能具有与网关中的其他服务不同的资源要求，并且可能影响网关的路由和卸载功能。

1.客户端需要与多个后端服务通信才能完成操作
2.客户端可以使用具有明显延迟的网络，例如蜂窝网络。

1.您希望客户端对单个服务的请求次数（比如获取10个学生的信息，你只有一个单个查询学生信息的接口）。在这种情况下，最好向服务添加批处理操作。
2.客户端或应用程序位于后端服务附近，延迟不是一个重要因素。

以下示例是教你如何使用Lua创建简单的网关聚合NGINX服务。

微服务架构：基于微服务和Docker容器技术的PaaS云平台架构设计

基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源，开发人员只需要开发业务代码并提交到平台代码库，做一些必要的配置，系统会自动构建、部署，实现应用的敏捷开发、快速迭代。在系统架构上，PaaS云平台主要分为微服务架构、Docker容器技术、DveOps三部分，这篇文章重点介绍微服务架构的实施。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

实施微服务需要投入大量的技术力量来开发基础设施，这对很多公司来说显然是不现实的，别担心，业界已经有非常优秀的开源框架供我们参考使用。目前业界比较成熟的微服务框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套实现微服务的框架，它提供了开发微服务所需的组件，跟Spring Boot一起使用的话开发微服务架构的云服务会变的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我们的微服务架构设计中，就使用了很多Spring Cloud Netflix框架的组件。Spring Cloud Netflix项目的时间还不长，相关的文档资料很少，博主当时研究这套框架啃了很多英文文档，简直痛苦不堪。对于刚开始接触这套框架的同学，要搭建一套微服务应用架构，可能会不知道如何下手，接下来介绍我们的微服务架构搭建过程以及 需要那些 框架或组件来支持微服务架构。

为了直接明了的展示微服务架构的组成及原理，画了一张系统架构图，如下：

从上图可以看出，微服务访问大致路径为：外部请求 → 负载均衡 → 服务网关（GateWay）→ 微服务 → 数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务，各服务集群都能通过配置中心服务来获得配置信息。

服务网关（GateWay）

网关是外界系统（如：客户端浏览器、移动设备等）和企业内部系统之间的一道门，所有的客户端请求通过网关访问后台服务。为了应对高并发访问，服务网关以集群形式部署，这就意味着需要做负载均衡，我们采用了亚马逊EC2作为虚拟云服务器，采用ELB(Elastic Load Balancing)做负载均衡。EC2具有自动配置容量功能，当用户流量达到尖峰，EC2可以自动增加更多的容量以维持虚拟主机的性能。ELB弹性负载均衡，在多个实例间自动分配应用的传入流量。为了保证安全性，客户端请求需要使用https加密保护，这就需要我们进行SSL卸载,使用Nginx对加密请求进行卸载处理。外部请求经过ELB负载均衡后路由到GateWay集群中的某个GateWay服务，由GateWay服务转发到微服务。服务网关作为内部系统的边界，它有以下基本能力：

1、动态路由：动态的将请求路由到所需要的后端服务集群。虽然内部是复杂的分布式微服务网状结构，但是外部系统从网关看就像是一个整体服务，网关屏蔽了后端服务的复杂性。

2、限流和容错：为每种类型的请求分配容量，当请求数量超过阀值时抛掉外部请求，限制流量，保护后台服务不被大流量冲垮；党内部服务出现故障时直接在边界创建一些响应，集中做容错处理，而不是将请求转发到内部集群，保证用户良好的体验。

3、身份认证和安全性控制：对每个外部请求进行用户认证，拒绝没有通过认证的请求，还能通过访问模式分析，实现反爬虫功能。

4、监控：网关可以收集有意义的数据和统计，为后台服务优化提供数据支持。

5、访问日志：网关可以收集访问日志信息，比如访问的是哪个服务？处理过程（出现什么异常）和结果？花费多少时间？通过分析日志内容，对后台系统做进一步优化。

我们采用Spring Cloud Netflix框架的开源组件Zuul来实现网关服务。Zuul使用一系列不同类型的过滤器（Filter），通过重写过滤器，使我们能够灵活的实现网关（GateWay）的各种功能。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

服务注册与发现

由于微服务架构是由一系列职责单一的细粒度服务构成的网状结构，服务之间通过轻量机制进行通信，这就引入了服务注册与发现的问题，服务的提供方要注册报告服务地址，服务调用放要能发现目标服务。我们的微服务架构中使用了Eureka组件来实现服务的注册与发现。所有的微服务（通过配置Eureka服务信息）到Eureka服务器中进行注册，并定时发送心跳进行 健康 检查，Eureka默认配置是30秒发送一次心跳，表明服务仍然处于存活状态，发送心跳的时间间隔可以通过Eureka的配置参数自行配置，Eureka服务器在接收到服务实例的最后一次心跳后，需要等待90秒（默认配置90秒，可以通过配置参数进行修改）后，才认定服务已经死亡（即连续3次没有接收到心跳），在Eureka自我保护模式关闭的情况下会清除该服务的注册信息。所谓的自我保护模式是指，出现网络分区、Eureka在短时间内丢失过多的服务时，会进入自我保护模式，即一个服务长时间没有发送心跳，Eureka也不会将其删除。自我保护模式默认为开启，可以通过配置参数将其设置为关闭状态。

Eureka服务以集群的方式部署（在博主的另一篇文章中详细介绍了Eureka集群的部署方式），集群内的所有Eureka节点会定时自动同步微服务的注册信息，这样就能保证所有的Eureka服务注册信息保持一致。那么在Eureka集群里，Eureka节点是如何发现其他节点的呢？我们通过DNS服务器来建立所有Eureka节点的关联，在部署Eureka集群之外还需要搭建DNS服务器。

当网关服务转发外部请求或者是后台微服务之间相互调用时，会去Eureka服务器上查找目标服务的注册信息，发现目标服务并进行调用，这样就形成了服务注册与发现的整个流程。Eureka的配置参数数量很多，多达上百个，博主会在另外的文章里详细说明。

微服务部署

微服务是一系列职责单一、细粒度的服务，是将我们的业务进行拆分为独立的服务单元，伸缩性好，耦合度低，不同的微服务可以用不同的语言开发，每一个服务处理的单一的业务。微服务可以划分为前端服务（也叫边缘服务）和后端服务（也叫中间服务），前端服务是对后端服务做必要的聚合和剪裁后暴露给外部不同的设备（PC、Phone等），所有的服务启动时都会到Eureka服务器进行注册，服务之间会有错综复杂的依赖关系。当网关服务转发外部请求调用前端服务时，通过查询服务注册表就可以发现目标服务进行调用，前端服务调用后端服务时也是同样的道理，一次请求可能涉及到多个服务之间的相互调用。由于每个微服务都是以集群的形式部署，服务之间相互调用的时候需要做负载均衡，因此每个服务中都有一个LB组件用来实现负载均衡。

微服务以镜像的形式，运行在Docker容器中。Docker容器技术让我们的服务部署变得简单、高效。传统的部署方式，需要在每台服务器上安装运行环境，如果我们的服务器数量庞大，在每台服务器上安装运行环境将是一项无比繁重的工作，一旦运行环境发生改变，就不得不重新安装，这简直是灾难性的。而使用Docker容器技术，我们只需要将所需的基础镜像（jdk等）和微服务生成一个新的镜像，将这个最终的镜像部署在Docker容器中运行，这种方式简单、高效，能够快速部署服务。每个Docker容器中可以运行多个微服务，Docker容器以集群的方式部署，使用Docker Swarm对这些容器进行管理。我们创建一个镜像仓库用来存放所有的基础镜像以及生成的最终交付镜像，在镜像仓库中对所有镜像进行管理。

服务容错

微服务之间存在错综复杂的依赖关系，一次请求可能会依赖多个后端服务，在实际生产中这些服务可能会产生故障或者延迟，在一个高流量的系统中，一旦某个服务产生延迟，可能会在短时间内耗尽系统资源，将整个系统拖垮，因此一个服务如果不能对其故障进行隔离和容错，这本身就是灾难性的。我们的微服务架构中使用了Hystrix组件来进行容错处理。Hystrix是Netflix的一款开源组件，它通过熔断模式、隔离模式、回退（fallback）和限流等机制对服务进行弹性容错保护，保证系统的稳定性。

1、熔断模式：熔断模式原理类似于电路熔断器，当电路发生短路时，熔断器熔断，保护电路避免遭受灾难性损失。当服务异常或者大量延时，满足熔断条件时服务调用方会主动启动熔断，执行fallback逻辑直接返回，不会继续调用服务进一步拖垮系统。熔断器默认配置服务调用错误率阀值为50%，超过阀值将自动启动熔断模式。服务隔离一段时间以后，熔断器会进入半熔断状态，即允许少量请求进行尝试，如果仍然调用失败，则回到熔断状态，如果调用成功，则关闭熔断模式。

2、隔离模式：Hystrix默认采用线程隔离，不同的服务使用不同的线程池，彼此之间不受影响，当一个服务出现故障耗尽它的线程池资源，其他的服务正常运行不受影响，达到隔离的效果。例如我们通过andThreadPoolKey配置某个服务使用命名为TestThreadPool的线程池，实现与其他命名的线程池隔离。

3、回退（fallback）：fallback机制其实是一种服务故障时的容错方式，原理类似Java中的异常处理。只需要继承HystixCommand并重写getFallBack()方法，在此方法中编写处理逻辑，比如可以直接抛异常（快速失败），可以返回空值或缺省值，也可以返回备份数据等。当服务调用出现异常时，会转向执行getFallBack()。有以下几种情况会触发fallback：

1）程序抛出非HystrixBadRequestExcepption异常，当抛出HystrixBadRequestExcepption异常时，调用程序可以捕获异常，没有触发fallback，当抛出其他异常时，会触发fallback；

2）程序运行超时；

3）熔断启动；

4）线程池已满。

4、限流： 限流是指对服务的并发访问量进行限制，设置单位时间内的并发数，超出限制的请求拒绝并fallback，防止后台服务被冲垮。

Hystix使用命令模式HystrixCommand包装依赖调用逻辑，这样相关的调用就自动处于Hystrix的弹性容错保护之下。调用程序需要继承HystrixCommand并将调用逻辑写在run()中，使用execute()（同步阻塞）或queue()（异步非阻塞）来触发执行run()。

动态配置中心

微服务有很多依赖配置，某些配置参数在服务运行期间可能还要动态修改，比如：根据访问流量动态调整熔断阀值。传统的实现信息配置的方法，比如放在xml、yml等配置文件中，和应用一起打包，每次修改都要重新提交代码、打包构建、生成新的镜像、重新启动服务，效率太低，这样显然是不合理的，因此我们需要搭建一个动态配置中心服务支持微服务动态配置。我们使用Spring Cloud的configserver服务帮我们实现动态配置中心的搭建。我们开发的微服务代码都存放在git服务器私有仓库里面，所有需要动态配置的配置文件存放在git服务器下的configserver（配置中心，也是一个微服务）服务中，部署到Docker容器中的微服务从git服务器动态读取配置文件的信息。当本地git仓库修改代码后push到git服务器仓库，git服务端hooks(post-receive，在服务端完成代码更新后会自动调用)自动检测是否有配置文件更新，如果有，git服务端通过消息队列给配置中心（configserver，一个部署在容器中的微服务）发消息，通知配置中心刷新对应的配置文件。这样微服务就能获取到最新的配置文件信息，实现动态配置。

以上这些框架或组件是支撑实施微服务架构的核心，在实际生产中，我们还会用到很多其他的组件，比如日志服务组件、消息服务组件等等，根据业务需要自行选择使用。在我们的微服务架构实施案例中，参考使用了很多Spring Cloud Netflix框架的开源组件，主要包括Zuul（服务网关）、Eureka（服务注册与发现）、Hystrix（服务容错）、Ribbon（客户端负载均衡）等。这些优秀的开源组件，为我们实施微服务架构提供了捷径。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

【知识总结】4.微服务的治理去中心化，服务发现，安全，部署

通常“治理”的意思是构建方案，并且迫使人们通过努力达到组织的目标。SOA治理指导开发者开发可重用的服务，以及随着时间推移，服务应该怎么被设计和开发。治理建立了服务提供者和消费者之间对于服务的协定，告诉消费者能从服务提供获取到什么样的支持。

SOA中有两种常见的治理：

那么微服务中的治理是什么意思呢？

在微服务架构中，不同的微服务之间相互独立，并且基于不同的平台和技术。因此，没有必要为服务的设计和开发定义一个通用的标准。

总结微服务的治理去中心化如下：

微服务架构下，有大量的微服务需要处理。由于微服务的快速和敏捷研发，他们的位置可能会动态变化。因此在运行时需要能够发现服务所在的位置，服务发现可以解决这个问题。

注册中心有微服务的实例和位置信息，微服务在启动时向注册中心注册自己的信息，关闭时注销。其它使用者能够通过注册中心找到可用的微服务和相关信息。

为了能找到可用的服务和他们的位置信息，需要服务发现机制。有两种发现机制，客户端发现和服务端发现。

客户端发现 - 客户端或者API网关通过查询服务注册中心或者服务的位置信息。

客户端/API网关必须调用服务注册中心组件，实现服务发现的逻辑。

服务端发现 - 客户端/API网关把请求发送到已知位置信息的组件（比如负载均衡器）。组件去访问注册中心，找到微服务的位置信息。

类似Kubernetes（ http://kubernetes.io/v1.1/docs/user-guide/services.html ）这种微服务部署解决方案，就提供了服务器端的自动发现机制。

微服务的部署方式也特别重要，以下是关键：

Docker（一个运行在linux上并且开源的应用，能够协助开发和运维把应用运行在容器中）能够快速部署微服务，包括关键几点：

相对于传统的虚拟机模式，利用docker容器，构建、发布、启动微服务将会变得十分快捷。

通过Kubernetes能够进一步扩展Docker的能力，能够从单个linux主机扩展到linux集群，支持多主机，管理容器位置，服务发现，多实例。都是微服务需求的重要特性。因此，利用Kubernetes管理微服务和容器的发布，是一个非常有力的方案。

图11，展示了零售应用的微服务部署。每个服务都在独立的容器中，每个主机有两个容器，通过kubernetes可以随意调整容器的数量。

在实际运行环境中，微服务的安全也非常重要。我们先看下单体架构下安全是如何实现的。

一个典型的单体应用，安全问题主要是“谁调用”，“调用者能做什么”，“如何处理”。服务器接收到请求后，一般都在处理链条的最开始，通过安全组件来对请求的信息进行安全处理。

我们能直接把这种处理方式应用在微服务架构中吗？答案是可以的，需要每个微服务都实现一个安全组件从资源中心获取对应的用户信息，实现安全控制。这是比较初级的处理方式。可以尝试采用一些标准的API方式，比如OAuth2和OpenID。深入研究之前，可以先概括下这两种安全协议以及如何使用。

OAuth2-是一个访问委托协议。需要获得权限的客户端，向授权服务申请一个访问令牌。访问令牌没有任何关于用户/客户端的信息，仅仅是一个给授权服务器使用的用户引用信息。因此，这个“引用的令牌”也没有安全问题。

OpenID类似于OAuth，不过除了访问令牌以外，授权服务器还会颁发一个ID令牌，包含用户信息。通常由授权服务器以JWT（JSON Web Token）的方式实现。通过这种方式确保客户和服务器端的互信。JWT令牌是一种“有内容的令牌”，包含用户的身份信息，在公共环境中使用不安全。

现在我们看下如何在网络零售网站中应用这些协议保障微服务的安全。

图12中所示，是实现微服务安全的关键几步：

JWT包含必要的用户信息，如果每个微服务都能够解析JWT，那么你的系统中每个服务都能处理身份相关的业务。在每个微服务中，可以有一个处理JWT的轻量级的组件。

在微服务中怎么支持事务呢？事实上，跨多个微服务的分布式事务支持非常复杂，微服务的设计思路是尽量避免多个服务之间的事务操作。

解决办法是微服务的设计需要遵循功能自包含和单职责原则。跨越多个微服务支持分布式事务在微服务架构中不是一个好的设计思路，通常需要重新划定微服务的职责。某些场景下，必须要跨越服务支持分布式事务，可以在每个微服务内部利用“组合操作”。

最关键的事情是，基于单职责原则设计微服务，如果某个服务不能正常执行某些操作，那么这个服务是有问题的。那么上游的操作，都需要在各自的微服务中执行回滚操作。

微服务架构相比较单体的设计而言，引入了更多服务，在每个服务级别会增加发生错误的可能性。一个服务可能由于网络问题、底层资源等各种问题导致失败。某个服务的不可能不应该影响整个应用的崩溃。因此，微服务系统必须容错，甚至自动回复，对客户端无感知。

任何服务在任何时间都有可能出问题，监控系统需要能够发现问题，并且自动恢复。微服务环境下有不少常用的模式。

微服务中请求的失败率达到一定程度后，系统中的监控可以激活线路中断。当正常请求的数量恢复到一定程度后，再关闭线路中断的开关，使系统回复到正常状态。

这个模式可以避免不必要的资源消耗，请求的处理延迟会导致超时，借此可以把监控系统做的更完善。

一个应用会有很多微服务租车，单个微服务的失败不应该影响整个系统。防火墙模式强调服务直接的隔离性，微服务不会受到其它微服务失败的影响。

超时机制是在确定不会再有应答的情况下，主动放弃等待微服务的响应。这种超时应该是可配置的。

哪些情况下，如何使用这些模式呢？大多数情况，都应该在网关处理。当微服务不可用或者没有回复时，网关能够决定是否执行线路中断或者启动超时机制。防火墙机制同样重要，网关是所有请求的唯一入口，一个微服务的失败不应该影响到其它微服务。网关也是获得微服务状态、监控信息的中心。

我们已经讨论了微服务的架构和各种特性，以及如何应用在一个现代的IT系统中。同时也需要意识到，微服务不是解决所有问题的灵丹妙药。盲目追求流行的技术概念并不能解决掉企业IT系统的问题。

微服务有很多优势，但是仅靠微服务不能解决企业IT中的所有问题。例如，微服务需要去除ESB，但是现实的IT系统中，大量的应用和服务是基于ESB而不是微服务。集成现有的系统，需要一些集成总线。实际情况是，微服务和其它企业架构并存。

关于微服务网关为客户端负载和微服务网关如何调用服务的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关为客户端负载的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关如何调用服务、微服务网关为客户端负载的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。