* 1.当服务消费者需要调用某个远程微服务时，会先向服务注册中心询问该服务的注册信息（访问地址） * 2.服务注册中心返回一个服务注册列表。即：服务提供者的访问地址 * 3.服务消费者按照自己的负载均衡算法，从注册列表中选出一个服务提供者实例，发起请求。 > 所谓负载均衡，用白话说就是一个好汉三个帮。一个A服务提供者压力大的时候，创建多个A服务提供者实例分担压力。 > 所谓负载均衡算法，用白话说就是具体到某一次的任务，在众多“好汉”中选择哪一个好汉来帮你，根据什么逻辑来选择。 本章内容主要是为大家介绍远程服务调用负载均衡，为了构建一个真实的多实例负载的远程服务调用，我们需要为服务提供者创建多个启动实例（服务于不同的端口）。 ## 一、IDEA环境下微服务多端口多实例 ### 1.1.第一个实例 在congbb-cloud的应用中，目前aservice-sms是一个服务提供者，所以我们为它创建多个启动实例。如图：选择Edit Configurations  然后修改实例启动名称（加上端口），这样更容易辨认多个启动实例之间的区别。勾选右上角的Allow parallel run（允许多实例运行），我的IDEA版本比较新，比较旧的版本该沟选项的名称叫做Single instance only（只允许单实例运行），所以此时应该把勾选去掉。  并且为启动实例加上虚拟机启动参数。指定实例的启动端口： ~~~ -Dserver.port=8402 ~~~ ### 1.2.复制实例 有了第一个实例，我们通过复制创建第二个启动实例。同样修改实例启动名称和端口号，端口号要与之前的实例不一样。  这样我们第二个实例就创建好了，可以仿造这种方式创建三个或更多实例，只要你的硬件环境允许，并且是你需要的。 ### 1.3.创建Compound Compound的作用是多实例分组，同一组的实例可以分包一个包里面，同时启动。  将我们新建的两个aservice-sms实例包含到同一个Compound：aservice-sms里面  这样当我们启动Compound：aservice-sms的时候，8402和8412端口的微服务应用就一起启动了。  ## 二、linux环境下微服务多端口多实例 上面的微服务多实例是在我们的开发环境中的实现，如果在linux生产环境下，我们可以通过如下命令启动一个微服务的多实例。当然，一般使用微服务的企业都会将微服务docker容器化，使用k8s做微服务的编排。所以以下的命令酌情使用。 ~~~ java -jar sms-service.jar -Dserver.port=8402 java -jar sms-service.jar -Dserver.port=8412 ~~~ ## 三、基于RestTemplate的负载均衡 只需要在上一节的代码的基础上，加上@LoadBalanced注解即可实现远程服务调用的负载均衡。具体实现效果请看后文的测试。  加上@LoadBalanced注解注解之后，我们使用RestTemplate访问微服务的时候，就可以实现微服务多实例访问的负载均衡。注意：这里访问的地址是微服务的名称(大写)，不再是某一个微服务实例的ip和端口。 下文代码，在上一节中定义，此处做了1处修改：  ## 三、远程服务调用负载均衡测试 为了使测试结果的显示更加直观，我们为“/sms/send”服务的控制台打印加上serverPort，从而能更清楚的看到响应结果。  启动如下实例：eureka服务注册中心、aservice compound多实例。然后我们会执行aservice-rbac中的测试用例：httpPostForObject  测试结果，当我们第一次执行上文的httpPostForObject单元测试的时候，8402实例的控制台结果如下：  当我们再一次执行上文的httpPostForObject单元测试的时候，8412实例的控制台结果如下。多次访问，如此循环，这是由负载均衡的策略决定的。