负载均衡 订阅
负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡(Load Balance)其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。 展开全文
负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡(Load Balance)其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。
信息
外文名
Load Balancing
别    称
负载分担
释    义
将负载进行平衡
中文名
负载均衡
负载均衡概述
负载均衡,英文名称为Load Balance,其含义就是指将负载(工作任务)进行平衡、分摊到多个操作单元上进行运行,例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等,从而协同完成工作任务。负载均衡构建在原有网络结构之上,它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。
收起全文
精华内容
参与话题
问答
  • nginx负载均衡

    万次阅读 2017-12-06 11:19:05
    发现访问量越来越多,服务器完全无法承受住压力,导致系统卡顿延时等,此时需要通过nginx技术将应用压力进行平均分配到其他服务器,将多台服务器一起提供资源,通过nginx来协调资源进行负载均衡。操作步骤1. 目标与...

    应用场景

    当一个应用部署在tomcat后,发现访问量越来越多,服务器完全无法承受住压力,导致系统卡顿延时等,此时需要通过nginx技术将应用压力进行平均分配到其他服务器,将多台服务器一起提供资源,通过nginx来协调资源进行负载均衡。

    操作步骤

    1. 目标与准备

    目标:使用docker部署nginx+tomcat,nginx实现负载均衡。

    准备:
    docker主机,192.168.199.32 (docker2)
    tomcat容器1:tomcat01
    tomcat容器2:tomcat03
    nginx容器:nginx_test

    2. 镜像下载

    docker主机pull镜像文件,需要tomcat和nginx。
     # docker pull docker.io/tomcat
     # docker pull docker.io/malderhout/tomcat
     # docker pull nginx
    

    下载两个不同版本的tomcat镜像文件,只是为了后期更好的验证nginx的负载均衡。

    用# docker search tomcat命令搜索tomcat的镜像,进行选择,选择一个tomcat7,一个tomcat8。

    这里写图片描述

    3. 部署2个tomcat容器

     # docker run -d -ti --name tomcat01 docker.io/tomcat
     # docker run -d -ti --name tomcat03 docker.io/malderhout/tomcat
    
    查看两个容器是否已开启:
     # docker ps
    

    这里写图片描述

    tomcat容器默认启用8080端口。

    4. 部署nginx容器,并修改配置文件,commit新镜像。

    启动nginx容器,并进入到容器:
     # docker run -ti docker.io/nginx /bin/bash
    
    进入容器中,进行修改配置文件:
     # cd /etc/nginx/
     # cd conf.d/
     # vi default.conf
       bash: vi: command not found
    
    提示没有vi命令,执行
     # apt-get update
     # apt-get install vim
    
    编辑default.conf文件,如下:
     # vim default.conf
    
    upstream web_app{
    server tomcat01:8080 weight=1 max_fails=2 fail_timeout=30s;
    server tomcat03:8080 weight=1 max_fails=2 fail_timeout=30s;
    }
    server {
    listen 80;
    server_name nginx_test localhost;
    index index.jsp index.html index.htm;
    #charset koi8-r;
    #access_log /var/log/nginx/log/host.access.log main;
    location / {
    proxy_next_upstream http_502 http_504 error timeout invalid_header;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://web_app;
    root /usr/share/nginx/html;
    index index.html index.htm;
    }
    location ~* \.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$
    {
    root /usr/share/nginx/html;
    }
    #error_page 404 /404.html;
    # redirect server error pages to the static page /50x.html
    #
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    root /usr/share/nginx/html;
    }
    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    # proxy_pass http://127.0.0.1;
    #}
    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    # root html;
    # fastcgi_pass 127.0.0.1:9000;
    # fastcgi_index index.php;
    # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    # include fastcgi_params;
    #}
    # deny access to .htaccess files, if Apache’s document root
    # concurs with nginx’s one
    #
    #location ~ /\.ht {
    # deny all;
    #}
    }
    

    该配置文件为网上找的,如果有好的配置文件可以替换。 注意,配置文件引用的为容器的name,而不是ip地址,好处就是不用关心ip变动。nginx_test ,为nginx容器name,一会需要创建。

    手动执行nginx,看是否报错,如果报错进行调试,直至没有报错。
     # nginx
     # ps -ef
    

    这里写图片描述

    复制这个临时容器的id:0b85b3e2edda
    退出临时容器,使用刚创建的临时容器commit新的镜像,镜像名:nginx_tomcat

     # docker commit 0b85b3e2edda nginx_tomcat
     # docker images
    

    这里写图片描述

    使用nginx_tomcat部署nginx_test容器:
    
     # docker run -d -p 80:80 --name nginx_test nginx_tomcat nginx -g “daemon off;”
     # docker ps
    

    这里写图片描述

    5. 验证

    浏览器打开: http://192.168.199.32
    连续打开2次,发现第一个为tomcat8.0界面,第二个为tomcat7.0界面。

    这里写图片描述

    这里写图片描述

    展开全文
  • 负载均衡

    千次阅读 2012-05-08 23:28:08
    在全球不同的数据服务器农场(Data Farm)之间的负载均衡主要是依照区域通过DNS来实现负载均衡的; 应用服务器级别的群集主要分两种部署实施方式: 1.硬件来实现负载均衡,一般是通过F5来实现的; 2.软件来实现负载...

    在全球不同的数据服务器农场(Data Farm)之间的负载均衡主要是依照区域通过DNS来实现负载均衡的;

    应用服务器级别的群集主要分两种部署实施方式:

    1.硬件来实现负载均衡,一般是通过F5来实现的;

    2.软件来实现负载均衡,一般是通过Windows Server 2008的负载均衡组件来实现,另外在非微软平台是通过部署独立的负载均衡软件譬如Apache Server之类的来担当;

    附录Windows 2008 NLB的部署方式:

    打开添加功能向导并安装 NLB 的步骤

      1. 单击"开始",指向"管理工具",然后单击"服务器管理器"。在"服务器管理器"主窗口的"功能摘要"区域中,单击"添加功能"。或在"初始配置任务"窗口的"自定义此服务器"区域中,单击"添加功能"。

      2. 在"添加功能"向导中,选中"Windows 网络负载平衡"旁边的复选框。

      3. 单击"安装"。

      注:还可以在命令提示符下使用如下命令安装 NLB:Servermanagercmd.exe - install nlb。

      步骤 3:创建一个 NLB 群集。

      若要配置 NLB 群集,必须配置三种类型的参数:

      1."主机参数",该参数特定于 NLB 群集中的每个主机。

      2."群集参数",该参数作为整体应用于 NLB 群集。

      3."端口规则",该参数控制群集的工作方式。默认情况下,端口规则同等平衡所有服务器之间的所有 TCP/IP 通讯。在终端服务环境中使用 NLB 时,将需要修改这些默认规则。

      注:使用网络负载平衡管理器时,您必须是正在配置的主机上的 Administrators 组的成员,或者您必须被委派了相应的权限。如果通过非群集成员的计算机运行网络负载平衡管理器来配置该群集或主机,则您不必是该计算机上 Administrators 组的成员。作为安全性最佳操作,可以考虑使用"运行身份"执行此过程。

    创建 NLB 群集的步骤

      1. 若要打开网络负载平衡管理器,请依次单击"开始"、"管理工具"和"网络负载平衡管理器"。还可以通过从命令提示符键入 Nlbmgr 来打开网络负载平衡管理器。

      2. 右键单击"网络负载平衡群集",然后单击"新建群集"。

      3. 连接到将成为新群集成员的主机。在"主机"中,输入主机名,然后单击"连接"。

      4. 选择要对群集使用的接口,然后单击"下一步"。(该接口宿主虚拟 IP 地址并接收要负载平衡的客户端通讯。)

      5. 在"主机参数"中,选择"优先级(唯一主机标识符)"中的某个值。该参数为每个主机指定一个唯一 ID。群集的当前成员中优先级数值最低的主机处理端口规则未涉及的所有群集的网络通讯。您可以通过在"网络负载平衡属性"对话框的"端口规则"选项卡上指定规则,来覆盖这些优先级或者为特定范围的端口提供负载平衡。单击"下一步"继续。

      6. 在"群集 IP 地址"中,单击"添加",输入由群集中每个主机共享的群集 IP 地址。NLB 将该 IP 地址添加到被选择作为群集一部分的所有主机的选定接口的 TCP/IP 堆栈中。NLB 不支持动态主机配置协议 (DHCP)。NLB 在其配置的每个接口上禁用 DHCP,因此 IP 地址必须是静态地址。单击"下一步"继续。

      7. 在"群集参数"中,在"IP 地址和子网掩码"中键入值(对于 IPv6 地址,不需要子网掩码值)。使用终端服务网络负载平衡时,不需要完整的 Internet 名称。

      8. 在"群集操作模式"中,单击"单播"以指定应该为群集操作使用的单播媒体访问控制 (MAC) 地址。在单播模式中,会将群集的 MAC 地址指定给计算机的网络适配器,不使用网络适配器的内置 MAC 地址。建议您接受单播默认设置。单击"下一步"继续。

      9. 在"端口规则"中,单击"编辑"以修改默认端口规则。按照如下所示配置规则:

      在"端口范围"中,指定 3389 到 3389 的范围,以便新规则只应用到 RDP 通讯。

      在"协议"中,选择 TCP 作为端口规则应该涵盖的特定 TCP/IP 协议。该规则只影响指定协议的网络通讯。不受该端口规则影响的流量由默认主机进行处理。

      在"筛选模式"中,选择"多个主机",这样将为该端口规则指定群集中的多个主机处理网络流量。

      如果计划使用会话 Broker,请在"关联"(仅适用于"多个"主机筛选模式)中选择"无"。如果不打算使用 会话 Broker,请选择"单个"。

      10. 单击"完成"创建群集。

      若要向群集中添加更多主机,请右键单击新群集,然后单击"添加主机到群集"。按照配置初始主机使用的相同说明,配置其他主机的主机参数(包括主机优先级和专用 IP 地址)。由于您是向已配置的群集中添加主机,因此所有群集范围内的参数都保持相同。

      至此,Windows Server 2008中,终端服务网络负载均衡配置完毕。

    展开全文
  • 微服务架构的实现首先需要提供一些基础组件,这些基础的功能性组件主要包括服务之间的通信、面向事件驱动的架构设计方法、负载均衡、服务路由、API网关和分布式配置中心等,我们对这六大基本组件进行初步的分析定案...

    微服务架构的实现首先需要提供一些基础组件,这些基础的功能性组件主要包括服务之间的通信、面向事件驱动的架构设计方法、负载均衡、服务路由、API网关和分布式配置中心等,我们对这六大基本组件进行初步的分析定案。

    一、服务通信:网络连接+IO模型+可靠性+同步与异步

    对于微服务而言,网络通信主要关注于网络连接、IO模型、可靠性设计及服务调用方式。

    1.网络连接

    一般,基于TCP网络连接有两种基本方式,也就是我们常说的长连接和短连接,连接的建立需要三次握手,释放需要四次握手,而每次连接都意味着资源和时间的消耗。

    三次建立握手示意图如下:            

    注:1.TCP规定,SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。

           2.TCP规定,ACK报文段可以携带数据,但是如果不携带数据则不消耗序号。

    四次释放握手示意图如下:

    注:1. TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。

           2.服务器结束TCP连接的时间要比客户端早一些。

    而且,一般短连接只会在客户端/服务器端间传递一次读写操作,存在的连接都是有用的连接,不需要额外的控制手段。而长连接则与其不同,当客户端与服务端完成一次读写操作后他们的连接不会主动关闭,用于后续的读写操作。

    注意,长连接和短连接的产生在于客户端和服务端所采取的关闭策略,具体的应用场景采用何种策略需要依据情况具体分析,没有十全十美的选择,只有合适的选择。

    2.IO模型

    现代操作系统都包括内核空间和用户空间,其中,内核空间主要存放内核代码和数据,供系统进程使用,用户空间主要存放用户代码和数据,是供用户进程使用。

    一般,IO操作都有类似如下两个阶段,第一阶段,当数据分组到来时,将其拷贝到内核空间的临时缓存区,第二个阶段,再将内存空间临时缓存区中的数据复制到用户空间缓存区。围绕着这两个阶段,存在这一下几种主流的IO操作模式:

    阻塞IO:所有的套接口都是阻塞的,意味着IO的发起和结束都需等待,任何一个系统调用都会产生一个由用户态到内核态切换,在从内核态到用户态的一个切换过程,而进程的上下文切换也是通过系统中断程序来实现的,需要保存当前进程的上下文,这是一个成本很高的过程。

    非阻塞IO:把套接口设置成非阻塞时,用户进程会不停的询问某种操作是否准备就绪,轮询方式,这是种比较浪费CPU的方式。

    IO复用:主要依赖于操作系统提供的select和poll机制,这是阻塞进程是在这两个系统调用上,不在真正的IO操作上,IO操作看起来复用阻塞了两次,但是第一次阻塞是在select上监控多个套接口是否已有IO操作准备就绪,加大了性能指标。

    信号驱动IO:通过sigaction系统调用注册一个信号处理程序,主程序可以继续向下执行,当所监控的套接口有IO操作准备就绪的时候,由内核触发通知前面的注册信号处理程序执行,将数据从内核空间复制到用户空间。

    异步IO:与信号驱动IO的区别是直接由内核告诉IO操作何时完成了。

    可以看到,前四种IO模型的主要区别是在第一阶段,因为它们第二阶段都是在阻塞等待数据由内核空间复制到用户空间;而异步IO在第一阶段和第二阶段都不会阻塞。

    3.可靠性

    常见的网络通信保障手段包括链路有效性检测以及断线以后的重连处理。

    (1)链路有效性检测

    要确保通信链路的可靠性就必须对链路进行周期性的有效性检测,通用的做法就是心跳检测,通常有两种技术实现方式:

    一种是在TCP层通过建立长连接在发送端和接收端之间传递心跳信息;

    另一种则是在应用层,心跳信息根据系统要求可能包含一定的业务逻辑。

    (2)重连处理

    当发送方检测到通信链路中断,会在事先约定好的重连间隔时间之后发起重连操作,如果重连失败,则周期性地使用该间隔时间进行重连直至重连成功。

    4.同步与异步

    通信中的两种基本方式,一种是请求应答模式的同步操作,一种是单向模式的异步操作。

    同步调用会造成业务线程阻塞,但开发和管理相对简单。

    异步调用的目的在于获取高性能,队列思想和事件驱动都是实现异步调用的常见策略,但都主要依赖于基础中间件平台。JDK也为我们提供了Future模式实现异步调用。

    Future模式调用可以进一步分为两种模式,Future-Get模式和Future-Listener模式,Future-Get模式通过主动get方式获取Future结果,但是get过程是串行的,会造成执行get方法的线程形成阻塞,Future-Listener模式中需要创建Listener,当Future结果生成时唤醒注册该Future上的Listener对象,从而形成异步回调机制。

    二、事件驱动:基本事件驱动架构+事件驱动架构与领域模型

    1.基本事件驱动架构

    基本事件驱动处理架构的优势在于当系统中需要添加另一个业务逻辑来完成整体流程时,只需要对该事件添加一个订阅者即可,不需要对原系统做任何修改。

    以下系统进行分析:

    如图,一个订单处理的基本场景中需要预约订单处理系统同时知道支付、物流和账单服务,并进行服务的调用和协调,完成业务的闭环,但是,如果当系统业务进行变更后,需要一个新的服务才能完成所需要的业务流程,那么原有交互模式就需要进行调整,不利用系统扩展。

    如果我们采用事件驱动架构来实现的话,当一个订单操作完成时,订单系统就可以发送一个事件用于表示这个操作已完成,并触发所有对该事件感兴趣的微服务,这些微服务相当于这个事件的订阅者和消费者,这样一来,一个微服务可以处理支付,一个微服务处理物流,另一个微服务则处理账单,三个事件通过事件进行了解耦,通过消息传递机制,不必花费太大代价就能实现事件驱动架构。

    2.事件驱动与领域模型

    如图,一种领域事件框架围绕领域事件生命周期给出了三种不同的处理方式,体现在不同是事件订阅者。

    简单订阅者:直接处理事件,表现为一个独立的事件处理程序,对应于事件的使用阶段。

    即时转发订阅者:对应于事件的分发和使用阶段,一方面可以具备简单订阅者的功能,另一方面也可以把事件转发给其他订阅者(消息队列是一个较好地实践方法)。

    事件存储订阅者:在处理事件的同时对事件进行持久化,存储的事件可以作为一种历史记录,也可以通过专门的事件转发器转发到消息队列,对应于事件的存车使用阶段。

    如下图,在架构设计上,对领域事件的处理就是基本的发布-订阅风格。

    其中,DomainEvent本身具备一定的类型,DomainEventSubscriber根据类型订阅某种特定的DomainEvent,领域对象间的交互图一般如下:

    应用层AplicationService对某个实体对象进行操作会触发领域事件的生成,领域事件通过DomainEventPublisher进行发布,DomainEventSubscriber则根据需要由AplicationService创建并根据事件类型进行订阅和处理。

    而包含事件存储的发布订阅时序图一般如下,针对远程交互本身存在的网络稳定性等各种不可控原因会对事件进行存储以便发生问题时跟踪和重试。支持不同事件冲突、支持领域事件和存储事件之间的转换、检索由领域模型所产生的所有结果的历史记录、使用事件存储中的数据进行业务预测和分析是常见的事件存储需求。

    三、负载均衡:服务端负载均衡+客户端负载均衡+负载均衡算法

    从横向拆分角度讲,分布式是指将不同的业务分布在不同的地方,而集群指的是将几台服务器集中在一起实现同一业务。分布式中的每一个节点都可以做集群,但集群并不一定是分布式的。

    集群概念的提出同时考虑到了分布式系统中性能和可用性的问题,一方面,集群的负载均衡机制可以将业务请求分摊到多台单机性能不一定出众的服务器,另一方面,集群的容错机制确保当集群中的某台机器无法正常提供服务时整体集群仍然可用。而负载均衡简单讲就是将请求分摊到多个操作单元上进行执行。

    负载均衡建立在现有网络结构上,提供了一种廉价、有效、透明的方法扩展服务器的带宽、增加吞吐量、加强网络数据处理能力,以及提高网络的灵活性。以各种负载均衡算法为基础的分发策略决定了负载均衡的效果,根据服务器地址列表所存放的位置可以分为两大类,一类是服务器负载均衡,另一类是客服端负载均衡。

    1.服务端负载均衡

    客户端发送请求到负载均衡器LB,负载均衡器负责将接收到的各个请求转发到运行中的某台服务节点上,然后接收到请求的微服务做响应处理,常见的有Apache、Nginx、HAProxy。

    其实现机制比较忙简单,只需要在客服端与各个微服务实例之间架设集中式的负载均衡器即可,负载均衡器动态获取各个微服务运行时的信息,决定负载均衡的目标服务,若负载均衡器检测到某个服务已经不可用的时候就会自动移除该服务。

    注意,负载均衡器运行在一台独立的服务器上并充当代理的作用,同时,需要注意的是当服务请求越来越大的时候,负载均衡器就会成为系统的瓶颈,同时若负载均衡器自身发生失败时,整体服务的调用都将发生失败。

    2.客户端负载均衡

    客户端负载均衡机制的主要优势就是不会出现集中式负载均均衡所产生的瓶颈问题,因为每个客户端都有自己的负载均衡器,负载均衡器失败也不会造成严重的后果,但是运行时的信息在多个负载均衡器之间进行服务配置信息的传递会在一定程度上加重网络流量负载。              

    实现上,需要在客服端程序里面自己设定一个调度算法,在向服务器发起请求的时候,先执行调度算法计算出目标服务器地址,具体与原理如下图分析:

    其另一种典型的实现方式是把Nginx等能够实现代理功能的负载服务器部署到运行微服务的一台机器上。这时需要考虑实施成本和维护性问题。

    客户端负载均衡比较适合于客户端具有成熟的调度库函数、算法以及API的工具和框架。

    3.负载均衡算法

    大致可以分为两大类,即静态负载均衡算法和动态负载均衡算法。

    (1)静态负载均衡算法

    主要指的是各种随机算法和轮询算法。

    轮询算法:将请求按顺序轮流地分配到后端服务器上,它均衡地对待后端的每一台服务器,而不关心服务器实际的连接数和当前的系统负载。

    随机算法:通过系统的随机算法,根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知,随着客户端调用服务端的次数增多,其实际效果越来越接近于平均分配调用量到后端的每一台服务器,也就是轮询的结果。

    加权轮询算法:不同的后端服务器可能机器的配置和当前系统的负载并不相同,因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重,让其处理更多的请;而配置低、负载高的机器,给其分配较低的权重,降低其系统负载,加权轮询能很好地处理这一问题,并将请求顺序且按照权重分配到后端。

    (2)动态负载均衡算法

    根据服务器的实时性能分配连接是常见的动态策略。所有涉及权重的静态算法都可以转变为动态算法。常见的有以下几种:

    最小连接数算法:比较灵活和智能,由于后端服务器的配置不尽相同,对于请求的处理有快有慢,它是根据后端服务器当前的连接情况,动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求,尽可能地提高后端服务的利用效率,将负责合理地分流到每一台服务器。

    源地址哈希算法:根据获取客户端的IP地址,通过哈希函数计算得到的一个数值,用该数值对服务器列表的大小进行取模运算,得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡,同一IP地址的客户端,当后端服务器列表不变时,它每次都会映射到同一台后端服务器进行访问。

    四、服务路由:直接路由+间接路由+路由规则

    负载均衡的出发点是提供服务分发而不是解决路由问题,常见的静态、动态负载均衡算法也无法实现精细化的路由管理,但是负载均衡也可以简单看做是路由方案的一种。服务路由的管理可归纳为三大类,直接路由、间接路由和路由规则。路由策略整体如下:

    1.直接路由

    服务消费者需要感知服务提供者的地址信息,基本思路是通过配置中心或者数据库,当服务消费者需要调用某个服务时,基于配置中心或者数据库中存储的目标服务的具体地址构建链路完成调用。

    存在的问题:(1)增强了服务提供者和消费者之间的耦合度;

                         (2)创建和维护配置中心或数据库持久化操作需要成本。

    2.间接路由

    强调解耦思想并充分利用了发布-订阅模式作用,发布者发布事件,订阅者关注自身所想关注的事件,发布者和订阅者并不需要感知对方的存在,两者之间通过传输事件的基础设施进行完全解耦。

    在为微服务架构里面,实现间接路由的组件一般称为服务注册中心,从概念上讲就是发布-订阅模式中传输事件的基础设施,可以把服务的地址信息理解为事件的具体表现。通过服务注册中心,服务提供者发布服务到注册中心,服务消费者订阅感兴趣的服务,服务消费者只需要知道有哪些服务,而不需要知道服务具体在什么位置,从而实现间接路由。

    3.路由规则

    间接路由解决了路由解耦问题,面向全路由场景。但是在服务故障、高峰期导流、业务相关定制路由等特定场景下,依靠间接路由提供静态路由信息并不能满足要求,这就需要动态路由,而动态路由规则需要通过路由规则进行实现。

    路由规则常见的实现方案是白名单和黑名单,即把需要路由的服务地址信息放入到可以控制是否可见的路由池中。更为复杂的可以用Python等脚本语言实现定制化。

    五、API网关:网关的作用+网关的功能

    在设计模式中,外观模式的设计意图在于为子系统中的一组接口提供一个一致的入口,这个入口使得这一子系统更加容易使用,实现上用户界面不与系统耦合,而外观类与系统耦合。在层次化结构中,可以使用外观模式定义系统中的每一层的入口。

    外观模式:封装许多对象,以简化它们的接口,此模式定义了一个高层的接口,这个接口使得这一子系统更加容易使用,如下图:

    API网关本质上就是一种外观模式的具体实现,它是一种服务器端应用程序并作为系统访问的唯一入口。在微服务架构中,API网关的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。

    1.网关的作用:解耦+API优化+简化调用过程

    微服务提供的API粒度与客户端的要求不一定完全匹配,微服务一般提供细粒度的API,这意味着客户端通常需要与多个服务进行交互,网关要起到客户端与微服务间的隔离作用,随着业务需求的变化和时间的演进,网关背后的各个微服务的划分和实现可能需要做相应的调整和升级,这种调整和升级要求对客户端透明。

    API网关的作用主要体现在以下三个方面:

    (1)解耦:API网关使客户端和服务器端在调用关系和部署环境上进行解耦,向客户端隐藏了应用如何被划分到微服务的细节。

    (2)API优化:要求对每个客户端提供最优的API,在多客户端场景中,对于同一个业务请求,不同的客户端一般需要不同的数据。

    (3)简化调用过程:可以对返回数据进行处理,API网关减少了请求往返的次数,从而简化客户端的调用,提高服务访问的性能。

    但是需要注意的是,API网关也增加了系统的复杂性和响应时间,通过API网关也多了一层网络跳转,但是我们认为API网关模式的缺点相比优点是微不足道的。

    2.网关的功能

    网关的基本功能基本包含五点,具体细分如下图:

    功能1-NIO接入和异步接出:由于API网关作为客户端和微服务之间提供了桥梁,增加了一层网络跳转,为了解决网络跳转带来的性能影响,在实现上需要提供NIO接入和异步接出功能。

    功能2-报文格式转换:API网关作为单一入口,可构建异构系统,通过协议转换整合后基于REST、AMQP和Dubbo等不同风格和实现技术的微服务。

    功能3-安全性控制:API网关是统一管理安全性的绝佳场所,可以将认证的部分抽离到网关层,然后微服务系统无需关注认证的逻辑只关注自身业务即可。

    功能4-访问控制:需要控制客户端的访问次数和访问频率等功能。

    功能5-业务路由支持:可在网关层制定灵活的路由策略,对于特定API可设置白名单、路由规则等限制,非业务功能的配置及变更在网关层单独操作。

    六、配置管理:配置中心模型+分布式协调机制

    在微服务架构中,一般都需要引入配置中心的设计思想和相关工具。

    1.配置中心模型:4大分类+4个核心需求+2个维度分析

    4大分类

    先来梳理下配置相关的内容和分类:

    按配置的来源划分:源代码文件、数据库和远程调用。

    按配置的适用环境划分:开发环境、测试环境、预发布环境、生产环境等。

    按配置的集成阶段划分:编译时---源代码级的配置+配置文件和源代码一起提交到代码仓库;

                                           打包时---通过某种方式将配置打入最终的应用包中;

                                           运行时---应用启动时并不知道具体配置,需从本地或远程获取配置,在正常启动。

    按配置的加载方式划分:单次加载型配置、动态加载型配置。

    4个核心需求

    依照配置相关的内容和分类来看,构建一个合适的配置中心,至少需要满足以下4个核心需求:

    (1)非开发环境下应用配置的保密性,避免将关键配置写入源代码;

    (2)不同部署环境下应用配置的隔离性,比如非生产环境的配置不能参与生产环境;

    (3)同一部署环境下的服务器应用配置的一致性,即所有服务器使用同一份配置;

    (4)分布式环境下应用配置的可管理性,即提供远程配置能力。

    2个维度分析

    采取配置中心也就意味着采用集中式配置管理的设计思想。

    维度一:在集中式配置中心中,开发、测试和生产等不同环境配置信息统一保存在配置中心中;

    维度二;分布式集群环境,需要确保集群中同一类服务的所有服务器保存同一份配置文件并且能够同步更新。

    2.分布式协调机制

    配置中心在实现上需要满足3大需求:高效获取、实时感知、分布式访问。为满足这三大需求,配置中心需要依赖分布式协调机制,即通过一定的方法确保配置信息在分布式环境中的各个服务中能够得到实时、一致管理。目前业界主流的分布式协调框架为Zookeeper。         

    相关Zookeeper内容参考链接:http://www.cnblogs.com/wuxl360/p/5817471.html .                   

     

    参考书籍、文献和资料:

    【1】https://blog.csdn.net/qzcsu/article/details/72861891.

    【2】郑天民. 微服务设计原理与架构. 北京:人民邮电出版社,2018.

    【3】https://blog.csdn.net/youanyyou/article/details/78990133.

    【4】https://blog.csdn.net/wind19/article/details/7373010.

    【5】http://www.cnblogs.com/wuxl360/p/5817471.html.

    展开全文
  • 服务器端负载均衡:例如Nginx,通过Nginx进行负载均衡,先发送请求,然后通过负载均衡算法,在多个服务器之间选择一个进行访问;客户端负载均衡:例如spring cloud中的ribbon,客户端会有一个服务器地址列表,在发送...

    服务器端负载均衡:例如Nginx,通过Nginx进行负载均衡,先发送请求,然后通过负载均衡算法,在多个服务器之间选择一个进行访问;即在服务器端再进行负载均衡算法分配。

    客户端负载均衡:例如spring cloud中的ribbon,客户端会有一个服务器地址列表,在发送请求前通过负载均衡算法选择一个服务器,然后进行访问,这是客户端负载均衡;即在客户端就进行负载均衡算法分配。

    展开全文
  • nginx与IIS服务器搭建集群实现负载均衡(三)

    万次阅读 多人点赞 2016-03-10 22:19:05
    在《架构之路:nginx与IIS服务器搭建集群实现负载均衡(二)》中提到有好多有趣的地方,接下来就为大家一块儿讲讲在深入研究过程中遇到那些有趣的事情。 ·实战之行——发现问题 ·探索之旅——寻出问题原因 ...
  • 上一篇我们用三台Ubuntu搭建了MySQL集群服务器 或 docker搭建了MySQL集群服务器 这里讲一下利用Haproxy对MySQL进行负载均衡
  • nginx与IIS服务器搭建集群实现负载均衡(一)

    万次阅读 热门讨论 2015-12-13 17:08:57
    本人由于初出茅庐,防骗意识薄弱,一不小心被亮亮坑上了IIS负载均衡之路(亮亮是真黑哈!)。前车之鉴啊!小伙伴们要小心。不过既上了贼船,便决定一条道走到黑。于是乎从大前天晚上被骗到今天下午正好三天的时间,...
  • 反向代理 内容服务器的替身 如果内容服务器具有必须保持安全的敏感信息,如信用卡号数据库,可在防火墙外部设置一个代理服务器作为内容服务器的替身。 当外部客户机尝试访问内容服务器时,会将其送到代理服务器。...
  • 0.负载均衡 负载均衡 建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 负载均衡,英文名称为Load Balance,...
  • 负载均衡服务器有很多有大名鼎鼎的Nginx、Apache和LVS 但此次选择的是老牌的数据库中间件Haproxy 之所以选择Haproxy原因是Haproxy经过了时间考验,得到了大量用户的肯定。 负载均衡服务器对比 Haproxy ...
  • nacos服务的负载均衡功能演示

    万次阅读 2020-09-21 13:35:52
    服务提供者 第一个服务提供者 @SpringBootApplication @EnableDiscoveryClient public class CloudalibabaProviderPayment01Application { public static void main(String[] args) { SpringApplication.run...
  • 负载均衡不只是为了计算单元的负载达到均衡状态,他依据分配算法目标,有的基于负载考虑,有的基于性能(吞吐量、响应时间)考虑,有的基于业务考虑。 DNS 负载均衡 DNS 是最简单也是最常见的负载均衡方式,一般...
  • 本文为minxihou的翻译文章,转载请注明出处Bob Hou: http://blog.csdn.net/minxihouJmilkFan:minxihou的技术博文方向是 算法&...阶段2创建你的负载均衡 本文为博主翻译文章,转载请注明出处Bob Hou: http://blog.csd

空空如也

1 2 3 4 5 ... 20
收藏数 107,440
精华内容 42,976
关键字:

负载均衡