专栏首页天马行空布鲁斯负载均衡在微服务架构中的典型应用场景

负载均衡在微服务架构中的典型应用场景

这里介绍两个负载均衡在微服务架构中的典型应用场景:

  1. 微服务的负载均衡
  2. API Gateway的负载均衡

微服务的负载均衡

首先,我们看一个简单的图:

图中主要包含三个部分:API Gateway、Service Registry Server、微服务。一般来说,为了提高并发处理能力,API Gateway和微服务都需要有多个instance。

基于上面的架构图,设想两个典型的场景:

  1. API Gateway收到一个请求,在完成认证和授权校验之后,需要把请求转发到微服务A去处理,而微服务A有多个instance,那么API Gateway应该以及如何把请求转发到微服务A的哪个instance呢?
  2. 微服务A收到一个请求,处理这个请求时它需要发一个同步请求给微服务B以获取一些数据,那么这时微服务A应该以及如何把请求发送到微服务B的哪个instance呢?

对于这两个问题,我们可以利用服务注册和服务发现模块(比如说zookeeper、eureka等)来实现。一般来说,服务注册和服务发现是微服务架构里面非常重要的一个模块,它主要是用于解决微服务架构内部大量微服务之间相互依赖的问题。通过这个模块,可以使微服务之间的相互依赖变得简单和容易维护;同时,也可以实现微服务的负载均衡。

这里的负载均衡属于客户端负载均衡(client side load balance),相比于服务器端负载均衡(server side load balancer),它有一个显著的优点,就是可以一定程度避免load balancer单点故障。

服务注册和服务发现模块是如何应用到上面两个场景的呢?

服务注册的角度:每个微服务的instance在启动阶段就自动地把自己的IP和端口注册到Service Registry Server;当shutdown的时候,Service Registry Server就自动地把这个instance的IP和端口删除掉。

服务发现的角度:

针对场景1,API Gateway首先去Service Registry Server获取微服务A所有的instance列表(IP+端口),然后利用某种负载均衡策略选择一个instance,这时就可以直接把请求转发到微服务A的这个instance。

针对场景2,流程也是类似,微服务A首先去Service Registry Server获取微服务B所有的instance列表(IP+端口),然后利用某种负载均衡策略选择一个instance,这时就可以直接把请求转发到微服务B的这个instance。

从负载均衡角度可以看到,负载均衡的逻辑是运行在客户端的,顾名思义,这就是一种典型的客户端负载均衡。回到上面提到的,客户端负载均衡可以避免load balancer的单点故障,如何实现呢?以上面场景2为例,微服务A获取到微服务B的所有instance列表之后可以缓存的内存中,接下来当微服务A请求微服务B时,都直接从内存中获取微服务B的所有instance列表,这样即使Service Registry Server挂了,也不影响微服务A和微服务B正常通讯。

API Gateway的负载均衡

同样的,我们先看一个图:

其实,虽然这里说的是API Gateway的负载均衡,但也同样适用于传统的monolith应用。

关于如何设计这一层面的负载均衡,推荐大家阅读下面几篇文章,个人觉得介绍非常好。

这里只着重聊聊下面几点:

1. sticky session

对于传统的monolith应用,当遇到性能瓶颈时,常常采取的方案就是水平扩展(往往也是最直接有效的方式),直接增加instance的数量,一般来说monolith应用都是把session信息维护在内存中,所有当一个用户登录了之后,load balancer就需要把同一用户的后续请求转发到之前维护了session的instance,否则就会出现用户重新登陆的情况,这就是sticky session。

sticky session有时候会有一些问题,就是当某个instance挂掉时,load balancer没有办法failover。cloud foundry的cf-router也是这个原理。

所以在很多微服务架构中,就会把session信息存在session store(比如redis)里面,比如redis,这样就不需要依赖sticky session。

2. 高可用

server side load balance,相比上面提到的client side load balance,一个非常重要的点,就是要避免单点故障,保证load balancer的高可用。上面推荐的文章(关于负载均衡的一切)非常全面的介绍了如何实现load balancer的高可用,包括nginx、keepalived、lvs/f5、DNS轮询等方案。

基于此,那么有人要问了,如何保证DNS服务的高可用呢?其实,DNS服务本身就不是一个单点系统,它是一个分布式系统,某个域名的信息会分布到各级DNS服务器上(尽管可能会有更新时延),这样客户端的域名解析请求就分流了。

另外,针对微服务架构中的某一个微服务,可以通过水平扩展来实现高并发;但是对于某一个微服务的数据库,如何实现高并发呢?通常来讲就是分库,把数据按某种策略切分,存放在不同的数据库中,以达到分流的作用。

本文分享自微信公众号 - 天马行空布鲁斯(gh_2feda5c053bd),作者:huazailmh

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-03-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 这些年我对微服务的理解

    Monolith、SOA、DDD、The two-pizza rule、分库分表这些概念跟微服务有啥关系,你知道吗?这篇文章记录我的理解,分享给大家。

    Bruce Li
  • 如何不宕机实现数据库迁移

    由于业务的扩展或者其他原因,常常会有迁移系统数据库的场景,对于有大量用户7*24小时不间断使用的系统,如何不宕机实现数据库迁移,这是个很有挑战的话题。

    Bruce Li
  • liquibase和flyway中分布式锁实现的区别?

    大家可能都知道,锁的存在本质上是为了解决共享资源互斥访问的问题,为了解决这个问题,在单机系统中(一个进程),很多开发语言都提供了锁的特性,比如说java的syn...

    Bruce Li
  • 传统企业就应该这样进行微服务化

      很多传统企业看着互联网公司都进行着微服务化,因此也想享受微服务化带来的好处便对自己的系统进行改造,但微服务化 多“微”才是最优?有哪些拆分的原则?

    欢醉
  • 【微服务】微服务架构下,名字服务的使用体验和功能设计

    本文记录下接入微服务时,名字服务的使用体验以及名字服务的相关知识概念。作为“消费”侧,理解概念以帮助熟练使用工具即可,并不需要深入其中的原理。

    心谭博客
  • 成功微服务实施的技术演进微服务演进的技术背景通过度量驱动架构的微服务化

    在上一篇文章《我们如何衡量一个微服务实施的成功》里,我们介绍了衡量一个微服务改造成功的七个特征,分别是:

    顾宇
  • 「微服务架构」七种微服务反模式

    流行语经常为进化的概念提供背景,并且需要一个良好的“标签”来促进对话。微服务是一个新的“标签”,它定义了我个人一直在发现和使用的领域。文章和会议描述了一些事情,...

    首席架构师智库
  • 微服务架构SpringCloud

    努力,不是为了要感动谁,也不是要做给某些人看,而是有能力跳出自己厌恶的圈子,并拥有自己选择的权力,用自己喜欢的方式,过一生。

    凹谷
  • SOA与微服务

    微服务是一种应用架构模式,而 RPC 是一种远程调用方式,它们是不一样的概念;而在微服务中会出现服务之间的调用,为了确保性能,我们一般采用 RPC 来调用。

    Java高级架构
  • SpringCloud简介与微服务架构

    微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架...

    java乐园

扫码关注云+社区

领取腾讯云代金券