Dubbo
第1章 远程调用
概述
单一应用的优点：开发相对简单
单一应用的缺点：部署上和后期的开发维护上，比较麻烦，优化较麻烦。
微服务：
一个大的单体应用拆分成很多小的服务，这每一个小的服务都是一个应用。这就叫微服务
每个服务都是单一的，小的，而且可运行的，每个服务可以部署在不同的服务器上，这叫微服务。
分布式：
这些小的应用分别部署在不同的服务器上，在服务器端，这些不同的服务器构成了一个结构，一个网络，这就叫分布式的结构，这就是服务器集群，集群是多个服务器，是一种物理形态，分布式则是一种思想。
这多个服务器作为一个整体向用户提供功能。
由多台服务器共同完成一件比较复杂的事，可以理解为分布式
这种分布式的结构，多台服务器，对用户而言是一个整体。
总结：
微服务的开发模式，分布式的部署
部署在不同服务器上的不同应用之间，避免不了互相调用的功能
servlet之间的调用是通过http协议进行调用，是比较慢的。
怎么方便地进行微服务之间的调用和访问的呢?
dubbo框架。
RPC协议
RPC是什么？
协议指多方共同遵循的规范，在网络上的计算机进行数据交换依靠各种协议，例如http、ftp等。
一台计算机按规定好的格式发送数据，另一台计算的程序按指定的格式接收数据，两台计算机或者说服务器使用互相理解的格式读写数据，达到数据交换的目的。
RPC是Remote Procedure Call Protocol，即远程过程调用协议。是一种通过网络从远程计算机程序请求服务，而不需要了解底层网络技术的协议。该协议允许运行于一台计算机的程序调用另一台计算机的程序。程序员无需编写网络交互的功能代码。
简而言之，RPC协议是实现分布式环境中，不同服务之间或者说服务器之间的相互调用的协议。
RPC协议定义了底层的服务器之间数据交换的方式和调用的处理逻辑等。
RPC里面还有很多子协议。
RPC的作用
主要功能是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性，在一台计算机的程序使用其他计算机上的功能就像使用自己的功能一样。
RPC技术提供了透明的访问其他服务的底层实现细节，使用分布式系统中的服务更加方便。
分布式
分布式指多台计算机（服务器）位于网络系统中，多台计算机形成一个整体对外界提供服务。用户使用系统不知道是多台计算机在使用不同的操作系统，不同的应用程序提供服务。
集群是一种物理结构，而分布式是一种思想，不同的单一的应用部署在不同的服务器上，这些不同的服务器又作为一个整体对外提供服务，这叫做分布式的结构。
分布式强调部署，微服务强调开发。
RPC让分布式地开发模式更简单。
第2章 Dubbo
Dubbo介绍
是国内的阿里公司开源的。
是一个高性能的RPC框架。
既然是RPC框架，那么就说明我们可以通过dubbo框架来做分布式、微服务的开发。
Dubbo框架的组成部分
- spring容器
- 服务提供者（提供服务的）
- 服务的消费者（用其他服务器提供的服务的）
- 注册中心---用来管理dubbo服务者和消费者的
- 监控中心---监控记录服务提供者和消费者的调用情况的。
架构介绍
单一应用架构
当网站流量很少时，只需一个应用，将所有的功能部署在一起，以减少部署节点和成本，此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆分成互不相干的几个应用以提升效率，此时，用于加速前端页面开发的web框架（MVC）是关键
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能快速地响应多变的市场需求，此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。
dubbo能做什么?---3个主要功能。
- 实现透明的远程方法调用，就像调用本地方法一样，可以忽略远程调用的实现细节。简单配置即可使用。
- 服务的自动注册和服务发现，通过注册中心，服务实现动态管理（增减服务方），调用服务的消费者无需写死调用地址。
- 软件的负载均衡和容错机制，无需使用硬件，降低成本。
Dubbo服务的实现原理
Dubbo的底层实现是通过动态代理，由Dubbo框架创建远程服务（接口）对象的代理对象，通过代理对象调用远程方法。
消费者A调用服务器B的服务，首先是通过网络，因为A的程序和B的程序是运行在不同的服务器上，也就是A应用和B应用部署在不同的服务器上，A调用B，是由Dubbo框架，创建出B服务对象的代理对象，放在A的JVM中。通过代理对象访问真实的目标对象的方法。
底层通过动态代理实现数据的转换、数据的组装、请求的发送、数据的反序列化变为实例对象。此代理对象是由dubbo框架创建的，代理做的工作我们就不用做了，这些都由dubbo框架内部实现，可以理解为远程服务的调用对于程序员来说是透明的。
我们要做的就是通过A去调用B的服务，具体底层具体怎么调用的，都是dubbo框架内部实现的。
Dubbo支持的协议
dubbo协议
Dubbo支持八种协议：
- dubbo
- hessian
- rmi
- http
- webservice
- thrift
- memcached
- redis
这八种协议也可以说是远程调用的方式。
dubbo官方推荐用dubbo协议，dubbo协议默认端口20880
dubbo协议特点
dubbo协议采用单一长连接和异步通讯，适合于小数据量高并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
网络通信：
dubbo协议底层网络通信默认使用的是netty框架，性能非常优秀，官方推荐使用。
netty框架是网络通讯的框架
dubbo协议不适合传送大数据量的服务，比如传文件、传视频等，除非请求量很低。
使用dubbo协议
<dubbo:protocol name="dubbo" port="20880"/>这句话写在spring的配置文件中。
长连接和短连接
长连接
网络连接一经建立，不关闭不销毁，一直打开。
消费者1、2、3都使用同一个网络通道进行传输，消费者1和服务器建立网络通道后，消费者2、3请求服务的时候，不需要再去建立网络通道。因为建立网络通道是比较耗时的。
MYSQL数据库底层使用的就是长连接的方式。
短连接
每一个客户端应用去请求服务的时候都必须和服务器建立一个网络通道。一次请求完毕之后，建立的网络通道就会关闭，每次请求都需要重新建立网络通道。
短连接对于服务端来说，占用的资源少，因为使用完了之后会马上释放。
在互联网应用中，做web应用的时候，用户和服务器之间使用的是短连接的方式，而服务器和服务器之间用的是长连接的方式。
比如说用户和消费者服务器之间使用的是短连接的方式，消费者服务器和服务提供者服务器之间使用的是长连接的方式。
Dubbo的组件
主要是由五大部分组成
容器--spring容器
容器指的是spring容器，由spring管理dubbo的各种对象。
dubbo服务的提供者
dubbo服务的消费者
其中服务提供者和服务消费者都是dubbo的程序
dubbo框架的注册中心
注册中心是一个单独的应用程序，负责管理dubbo服务的提供者和消费者的。注册中心是一个应用，可以用数据库来代替
dubbo框架的监控中心
监控中心是一个管理者，用来在后台的应用程序中管理消费者和提供者的，来记录消费者和提供者的调用情况的。
监控中心是可以没有的
使用Dubbo的第一个项目
点对点的直连项目：消费者直接访问服务提供者，没有注册中心，消费者必须指定服务提供者的访问地址（url）
实现Provider即dubbo服务的提供者：提供某个功能，让消费者调用的。
步骤：
新建web应用
导入jar：
- dubbo框架的jar：dubbo-2.5.3
- 网络通讯的jar包：netty
- 动态代理的相关包：javassist.jar
- spring相关jar包：spring-*.jar（dubbo框架和spring是紧密结合在一起的）
<dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.6.12</version> </dependency> <dependency> <groupId>io.netty</groupId> <artifactId>netty-all</artifactId> <version>4.1.72.Final</version> </dependency> <!-- spring核心 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.2.5.RELEASE</version> </dependency> <!-- 做SPRING事务用到的。 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-tx</artifactId> <version>5.2.5.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jdbc</artifactId> <version>5.2.5.RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.2.5.RELEASE</version> </dependency> <dependency> <groupId>org.javassist</groupId> <artifactId>javassist</artifactId> <version>3.15.0-GA</version> </dependency>定义实体类Weather，保存在网络中传输的数据，此类需要实现序列化接口
定义服务的接口和实现类
定义spring的配置文件，也是dubbo服务提供者的配置文件
- 声明服务的名称
- 暴露服务提供者的接口
- 声明服务接口的实现类对象
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <!-- 声明服务的名称：自定义的名字，表示当前的服务提供者的。 name:自定义的服务名称，一般可以使用项目名称，最好是唯一值。 服务名称是由dubbo框架内部使用的。 --> <dubbo:application name="dubboProvider"/> <!-- 声明服务的接口信息，暴露服务 interface:服务接口的全限定名称 protocol:访问这个dubbo服务使用的协议，推荐使用dubbo registry：指定使用注册中心，点对点的方式中，不使用注册中心，赋值为N/A ref：指定接口实现类bean的id --> <dubbo:service interface="org.example.service.WeatherService" protocol="dubbo" registry="N/A" ref="weatherService"></dubbo:service> <!-- 声明服务的实现类对象，真正提供接口的功能实现 --> <bean id="weatherService" class="org.example.service.impl.WeatherServiceImpl"></bean> </beans>定义测试类，测试配置文件是否有效
修改web.xml，注册spring的监听器，让spring可以在web应用中使用。
导出接口和相关的类为一个jar文件，提供给消费者使用。
实现消费者Consumer，调用服务提供者的功能
新建Java项目
导入jar包
- dubbo框架的jar：dubbo-2.5.3
- 网络通讯的jar包：netty
- 动态代理的相关包：javassist.jar
- spring相关jar包：spring-*.jar（dubbo框架和spring是紧密结合在一起的）
- 服务提供者的jar包
定义spring配置文件
- 声明服务的名称
- 声明要使用的服务，引用服务提供者
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <!-- dubbo消费者的配置文件--> <!-- 1.声明服务的名称（声明服务的操作和服务提供者的一样）--> <dubbo:application name="dubboConsumer1"/> <!-- 2.声明要使用的dubbo服务（远程服务） interface:dubbo服务接口的全限定名称 id：dubbo创建的代理对象的id，使用这个id访问代理对象 - remoteWeatherService 就是dubbo创建的WeatherService接口的代理对象！！ url：点对点访问中，访问远程服务的地址 --> <dubbo:reference interface="org.example.service.WeatherService" id="remoteWeatherService" url="dubbo://localhost:20880"/> </beans>定义使用者类，调用服务提供者的功能，这是一个远程调用。
public class MyClient { public static void main(String[] args) { // 创建spring容器 String config = "dubbo-consumer.xml"; // 从容器中获取远程的代理对象。 ApplicationContext applicationContext = new ClassPathXmlApplicationContext(config); //通过代理对象执行方法的调用，就像调用自己的方法一样 WeatherService remoteWeatherService = (WeatherService) applicationContext.getBean("remoteWeatherService"); Weather weather = remoteWeatherService.queryWeather("101010100"); System.out.println(weather); } }
使用接口作为独立项目
消费者项目只导入一个接口的jar包。
根据这个接口的jar包，在配置文件中，声明出代理对象。
通过代理对象调用方法，就像调用自己的方法一样，实际消费者项目只导入了接口，根本没有方法的实现，方法的实现在别的服务器上。
这个接口的jar包可能有很多接口，那么就有很多需要实现的方法，这些接口的实现类以及实现的方法都部署在不同的服务器上。这就是微服务，各个服务部署在不同的服务器上，这就是分布式。
而导入消费者项目的只是接口jar包，根本没有将实现类以及实现方法导入！！
但是在消费者项目中却可以像调用自己本地的方法一样调用别的服务器的实现类的方法，通过RPC框架dubbo，底层网络通信对用户而言是透明的。
总结：消费者项目中，实现类以及实现类的方法根本就不需要，但是却能调用，就是通过dubbo。能调用部署在不同服务器上的不同实现类的方法。
而部署在不同服务器上的服务提供者，即实现类，这些服务提供者项目中，也要导入接口jar包，因为在服务提供者项目中，要暴露服务的接口信息，并声明服务接口的实现类对象，并把实现类对象，对接口进行赋值。也就是说服务提供者项目中，仍用到接口jar包，这就是使用接口作为独立项目，整个大的项目中，只通过接口jar包。
服务提供者项目中的配置文件做的事：
- 声明服务名称
- 暴露接口
- 声明服务接口的实现类对象。
- .....后面还有配置注册中心等。
Dubbo常用标签
概述
使用dubbo做项目开发的时候，一般都用配置文件的方式，而不用注解。因为这样只需要在一个配置文件中就能了解到当前项目用了哪些远程服务，那么就看消费者项目配置文件的
<dubbo:reference>标签。通过一个配置文件，就能在服务提供者项目中看到哪些服务是暴露的，通过
<dubbo:service>标签。Dubbo中常用标签，分为三个类别：公用标签，服务提供者标签，服务消费者标签。
公用标签
配置应用信息：
<dubbo:application name="服务的名称"/>这个名称不是给我们开发人员使用的，是dubbo框架内部使用的，来区分这个服务是消费者还是服务提供者
配置注册中心
<dubbo:registry address="ip:port" protocol="协议"/>
服务提供者标签
配置访问服务提供者的协议信息
<dubbo:protocol name="dubbo" port="20800"/>配置暴露的服务接口
<dubbo:server interface="服务接口名" ref="服务实现对象"/>暴露的服务可以被消费者使用，消费者可以通过这个暴露的服务接口基于动态代理创建代理对象。
配置服务接口的实现类对象
<bean>
服务消费者标签
配置消费者引用远程服务
<dubbo:reference interface="服务接口名" id="服务引用bean的id"/>id表示的对象，即为dubbo框架创建的代理对象。
常用配置属性
check
Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止spring初始化完成，以便上线时，能及早发现问题，默认check=true，通过check="false"关闭检查。
表示消费者在去访问一个dubbo服务之前，检查这个服务是否已启动。
但是有的时候在项目中先部署消费者，此时服务器提供者还没启动起来，那么这时候可以设置check="false"
请求重试retries
远程服务调用重试次数，不包括第一次调用，默认是2次，加上第一次一共3次
<dubbo:reference retries="5"/>
第3章 注册中心
概述
注册中心，负责管理dubbo服务的提供者和消费者的，起到服务提供者和消费者的桥梁。
注册中心是一个软件，在项目中集中管理所有服务提供者和服务消费者。
注册中心可以检查dubbo服务是可用的还是不可用的。
用了注册中心，在配置文件中的url就不用写死了。
如果某个dubbo服务坏掉了，可以由注册中心动态地进行替换和修改，这样的话，消费者就能使用另一个正确的dubbo服务地址。
注册中心管理服务，并且还能实现故障的处理。
为什么使用注册中心？
面对复杂的应用系统，需要管理大量的服务调用。
而且对于服务提供方和服务消费方来说，他们还可能兼具这两种角色，即可能一个服务器的应用既需要提供服务，也需要消费服务。通过将服务统一管理起来，可以有效地优化内部应用对服务发布、使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。
多个服务注册到同一个注册中心，多个消费者、多个服务提供者都注册到同一个注册中心，管理起来。
Dubbo提供的注册中心有以下几种类型可选：
Multicast注册中心：组播方式，在一个固定的IP地址段来发送dubbo服务的地址信息。
Redis注册中心：使用Redis作为注册中心
也就是在redis数据库中，来记录每一个dubbo服务的访问地址。
Simple注册中心：就是一个dubbo服务，作为注册中心，提供查找服务的功能
zookeeper注册中心：使用zookeeper作为注册中心。
也就是说，消费者访问dubbo服务，得知道dubbo服务所在的地址即ip和端口，那么这个地址可以从注册中心中获取。项目中主要用zookeeper。
zookeeper概述
zookeeper是在分布式环境中，做服务协调和管理的。
是一个树形的目录服务，可用于生产环境。
zookeeper就像是windows的资源管理器，包含了所有的文件，都可以在这里找到，服务提供者和服务消费者都在注册中心登记。
服务消费者使用的访问地址不会写死，而且注册中心使用心跳机制更新服务提供者的状态。
不能使用的服务提供者会自动从注册中心删除，服务消费者不会调用不能使用的服务。
通过目录的方式记录dubbo服务提供者和消费者的信息的。
比如根目录是dubbo目录，子目录是服务接口目录，再下一层是服务提供者和服务消费者信息，再下一层是服务提供者提供的服务的URL，和消费者访问服务的URL。
用目录的方式记录dubbo服务的提供者和消费者信息。
通过目录和子目录能够定位到唯一的dubbo服务。
zookeeper是基于Java环境的软件。
zookeeper管理的就是服务相关信息，服务提供者和服务消费者。
是分布式环境中，协调管理服务的应用，zookeeper本身是一个软件应用。
先运行注册中心
启动dubbo服务
dubbo服务提供者向注册中心进行登记，在注册中心中维护了一个列表记录dubbo服务的URL
在注册中心中维护所有dubbo服务的可用的ip和端口
消费者先访问注册中心，进行一个订阅！
就是消费者要访问哪个dubbo服务，向注册中心做登记。
注册中心把对应的dubbo服务的URL信息发送给消费者。
消费者拿到dubbo服务的访问地址
消费者再拿到某一个地址（通过负载均衡来决定），就访问某一个dubbo服务
这样dubbo服务的提供者和消费者是解耦合的。
注册中心默认每隔2秒钟，向dubbo服务发送请求，验证dubbo服务是否正常工作。如果某个dubbo服务没有响应，那么注册中心认为此dubbo服务宕掉了，不能用，那么注册中心会把之前登记的这个dubbo服务的URL信息删掉（如果消费者对此dubbo服务做了订阅，也就是登记，那么注册中心会把宕掉的这个dubbo服务的新的地址推送给消费者，这样消费者拿到的dubbo服务地址永远都是可用的）。这是注册中心的心跳机制。
避免某个dubbo服务宕掉了，消费者访问不了。
zookeeper使用
服务提供者
新建web应用
导入jar：
- dubbo框架的jar：dubbo-2.5.3
- 网络通讯的jar包：netty
- 动态代理的相关包：javassist.jar
- spring相关jar包：spring-*.jar（dubbo框架和spring是紧密结合在一起的）
- zookeeper相关jar包：zkclient.jar zookeeper.jar
定义实体类Weather，保存在网络中传输的数据，此类需要实现序列化接口
定义服务的接口和实现类
定义spring的配置文件，也是dubbo服务提供者的配置文件
- 声明服务的名称
- 暴露服务提供者的接口
- 声明服务接口的实现类对象
- 声明注册中心的地址
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <!-- 声明服务的名称：自定义的名字，表示当前的服务提供者的。 name:自定义的服务名称，一般可以使用项目名称，最好是唯一值。 服务名称是由dubbo框架内部使用的。 --> <dubbo:application name="dubboProvider1-zookeeper"/> <!-- 声明服务的接口信息，暴露服务 interface:服务接口的全限定名称 protocol:访问这个dubbo服务使用的协议，推荐使用dubbo registry：指定使用注册中心，点对点的方式中，不使用注册中心，赋值为N/A ref：指定接口实现类bean的id --> <dubbo:service interface="org.example.service.WeatherService" ref="weatherService"></dubbo:service> <!--声明zookeeper注册中心的地址--> <dubbo:registry address="zookeeper://localhost:2181"/> <!-- 声明服务的实现类对象，真正提供接口的功能实现 --> <bean id="weatherService" class="org.example.service.impl.WeatherServiceImpl"></bean> </beans>定义测试类，测试配置文件是否有效
修改web.xml，注册spring的监听器，让spring可以在web应用中使用。
导出接口和相关的类为一个jar文件，提供给消费者使用。
服务消费者
新建Java项目
导入jar包
- dubbo框架的jar：dubbo-2.5.3
- 网络通讯的jar包：netty
- 动态代理的相关包：javassist.jar
- spring相关jar包：spring-*.jar（dubbo框架和spring是紧密结合在一起的）
- 服务提供者的jar包(这个jar包里是接口，也就是消费者这边只有接口，没有具体的实现，但是仍然能够实现功能，这就是远程调用RPC)
- zookeeper相关jar包：zkclient.jar zookeeper.jar
定义spring配置文件
- 声明服务的名称
- 声明要使用的服务，引用服务提供者
- 声明注册中心的地址
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <!-- dubbo消费者的配置文件--> <!-- 1.声明服务的名称（声明服务的操作和服务提供者的一样）--> <dubbo:application name="dubboConsumer1"/> <!-- 2.声明要使用的dubbo服务（远程服务） interface:dubbo服务接口的全限定名称 id：dubbo创建的代理对象的id，使用这个id访问代理对象 - remoteWeatherService 就是dubbo创建的WeatherService接口的代理对象！！ url：点对点访问中，访问远程服务的地址 --> <dubbo:reference interface="org.example.service.WeatherService" id="remoteWeatherService"/> <!-- 声明zookeeper注册中心信息--> <dubbo:registry address="zookeeper://localhost:2181" /> </beans>定义使用者类，调用服务提供者的功能，这是一个远程调用。
第4章 监控中心
概述
监控中心是dubbo框架提供好的一个web应用。
是一个后台，收集dubbo服务提供者和消费者的信息。
监控中心从注册中心收集服务提供者和消费者的信息。
步骤
- 下载dubbo-admin.war包
- 部署到tomcat服务器即容器中，发布。
- 启动。
- 进入
http://localhost:8080/dubbo_admin_2_6_0_war/页面管理
监控中心能够获取到消费者和服务提供者的相关信息。
第5章 负载均衡
概述
集群：
集群是一种计算机系统，是一种服务器结构，分布式可以理解为一种思想。把一组计算机，包括硬件和软件组织在一个网络中，相互连接起来共同完成某个工作，对用户来说是一个整体，集群对用户来说是透明的。
负载均衡：
负载均衡是以集群为前提的，英文名为load balance，意思就是将负载（工作任务）进行平衡，分摊到多个操作单元上进行执行。
对于网络应用而言，并不是一开始就需要负载均衡，当网络应用的访问量不断增长，单个处理单元无法满足负载需求的时候，网络应用流量将要出现瓶颈时，负载均衡才会起到作用。
一般通过一个或者多个前端负载均衡器（负载均衡服务器），将工作负载分发到后端一组服务器上，从而达到整个系统的高性能和高可用性。
负载均衡有两方面的含义：
- 首先，单个重负载的工作分配到多台服务器做并行处理，每个服务器处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。这是集群技术带来的优势。
- 大量的并发访问或数据流量分担到多台服务器分别处理，减少用户等待响应的时间。每个访问分配给不同的服务器处理。（不可能一台服务器承受大量用户请求，所以要将用户请求分摊到多台服务器，这就是负载均衡。）
负载均衡服务器很贵，成本高，中小型企业可以通过软件的方式实现负载均衡。
Dubbo负载均衡
概述
dubbo提供了多种负载均衡策略，缺省为random随机调用。
Ramdom LoadBalance
当请求提交给dubbo后，dubbo生成一个随机数，这个随机数对应于一个后台的服务器，通过这种方式做负载均衡，这也是dubbo框架默认的方式。
调用量越大，分布越均匀。
还可以调整请求发给某一个服务器的权重。
调用量大的时候，可以用这种方式。
RoundRobin LoadBalance
轮询。在后台多个服务器的性能差别大的时候会出现问题，性能慢的服务器积累的没处理的请求会随着时间越来越多。
后台的服务器的性能差不多的时候可以用这种方式，那么每台服务器处理的请求差不多，积累的没处理的请求也差不多。
LeastActive LoadBalance
最少活跃调用数，活跃数指调用前后技术差。比如1、2、3台服务器，每台在开始都分配了10个请求，1号处理了9个，差值为1，2号处理了5个，差值为5，3号处理了7个，差值为3，说明2号服务器的性能相对更弱。
在以后的请求分配中，分配给性能弱的服务器的请求会越少。
服务器的性能差异比较大的时候，可以用这种方式。
ConsistenceHash LoadBalance
比如说1、2、3、4请求分给A服务器
5、6、7、8请求分给B服务器
9、10、11、12请求分给C服务器
当B服务器宕掉了之后，5、6分给A，7、8分给C。
让每个服务器接收到的请求仍然保持均衡，发生故障之后，对用户来说，波动小。因为会把请求均匀地分配给剩下的服务器
