线程、数据库、算法、JVM、分布式、微服务、框架、Spring相关知识
一线互联网P7面试集锦+各种大厂面试集锦
学习笔记以及面试真题解析
该页面会显示Eureka Client的注册信息及它们的健康情况，现在只有一个Eureka Server在运行，可以看到在图2.11的最下面，当前在Eureka注册的实例显示的是无可用的实例，在DS Replicas （副本）中显示的是localhost，即没有副本，只有本地一个实例。
我们可以尝试配置一个简单的集群，来看看这个监控页面的变化，首先需要再启动一个Eureka Server的实例。假设我们配置的新的Eureka Server 实 例 的 应 用 名 称 是 ms-register2 ，域 名 是 ms-registry2，application.yml中的配置如下。
那么，回到ms-registry1，之前其他的配置都不变，唯一需要修改的是application.yml中的配置，代码如下。
我们增加了client下service-url的配置，正如之前所说的，这里将ms-registry1当作ms registry2的Client，这时再次访问http://ms-registry1:8080，来看看现在的变化，监控页面如图2.12所示。
这时DS Replicas显示的不再是localhost，而是ms-registry2，这表示ms-registry1和ms registry2已经建立同步副本的关系。访问一下ms-registry2的监控页面，监控页面如图2.13所示。
这说明ms-registry1已经成功注册到了ms-registry2中，通常我们会将多个Eureka Server相互注册，构成一个统一的集群，以达到高可用的目的。
配置完Server，如何配置Client呢？无论是服务提供者还是服务消费者，对于Eureka Server来说都是Client，这里需要引入spring
cloud-starter-netflix-eureka-client的库，新建一个工程，项目可以通过https://start.spring.io/进行初始化，build.gradle代码如下。
application.yml的配置可以参考上文配置Server集群时的client下service-url的配置，毕竟Server相互之间就是Server与Client的关系，如果Server之间都相互进行注册，那么service url只配置一个实例的地址即可，Eureka Server之间可以进行信息复制，具体代码如下。
如果不配置服务的端口，Spring默认为8080，一般我们会设置服务的端口为0，那么Spring就会生成一个随机数作为端口号，如果端口占用就会重新生成一个，这样也省去了我们去关心端口的配置，服务消费者只需通过应用名称（如ms-provider），就可以对该服务进行调用，如果使用的是RestTemplate，那么调用的URL可以写成如下代码。
Client的配置还有一点不同，就是在SpringBoot的启动类上不再使用@EnableEurekaServer注解，而是使用@EnableDiscoveryClient或@EnableEurekaClient注解，代码如下。
当 然 ， 有 时 我 们 也 使 用 @EnableEurekaClient ， 那么它和@EnableDiscoveryClient有什么区别呢？从两者的所属库就可以看出，@EnableEurekaClient是Netflix Eureka Client中的实现，它只支持Eureka作为注册中心，如果你使用Eureka，那么可以使用@EnableEurekaClient 。 @EnableDiscoveryClient 是 Spring Cloud Common中的实现，使用时Spring会根据你的classpath中的依赖来判断目前使用的是Eureka还是ZooKeeper，或者是Consul，然后动态地去初始化注册服务的配置。
启动后，再次访问注册中心页面，监控页面如图2.14所示。
在当前注册的实例列表中，除本身两个相互注册的注册中心msregistry1和ms-registry2，ms-provider也出现在列表中，此时表明服务已经注册成功。
负载均衡
====
如果服务部署了多个实例？这时又如何处理？首先可能想到的是反向代理，提到负载均衡，很多人都想到Nginx，确实在以往的单应用模式下的系统中，最常见的做法就是通过Nginx来完成负载均衡策略，如随机、轮询和权重等。例如，我们一般会部署多个Tomcat实例作为多个Web服务器，然后通过Nginx的反向代理来分发客户端的请求到不同的Web服务器，而Nginx可以定义不同的规则来分发这些请求，以达到负责均衡的目的。反向代理好比是集中式的统一入口，所有的服务信息都需要被描述在入口处，然后由入口来决定请求的去向，也就是负载的策略。
当然，也有通过一些中间件的方式来达到负载均衡，如SOA中的消息总线模式，通过中间的消息层来转发请求，从而达到负载均衡的目的。
那么，在微服务中又是如何设计的呢？微服务强调分离，提倡职责单一，虽然引入了注册中心的概念，但是注册中心除了负责对服务信息的统一微服，还包括对服务的健康状况等信息进行监控，而真正去完成负载均衡任务的是服务的消费者，这样做也比较符合逻辑，消费者自行决定需要采用哪些策略去调用服务提供者。
不过，消费者在做决定时，可以通过注册中心的消息来帮助自己做决定。例如，注册中心告诉消费者服务A的B实例是不可用状态，那么消费者在请求服务A时，则会把B实例剔除，如果注册中心告诉消费者B实例已经恢复为可用状态，那么消费者会重新把B实例加入自己可调用的目标中。
下面以Spring Cloud为例，一起来看看在Java的微服务项目中远程调用的具体技术实践。
Spring Cloud的设计是让服务之间采用HTTP的方式进行远程调用，所以Spring Web框架本身就提供RestTemplate、WebClient等HTTP通信的实现。而Spring Cloud Ribbon是客户端的负载均衡器，还有Spring Cloud Feign，Feign是对Ribbon的封装，提供了一些便捷的高级功能。如果不考虑使用客户端的负载均衡，就可以完全不集成该组件。在大多数情况下，通过软方法在客户端使用负载均衡也是一个不错的选择，下面介绍Spring Cloud Ribbon和Spring Cloud Feign的用法。
新建一个工程，build.gradle配置如下。
然后需要使用和provider相同的方式，将项目实例加入注册中心中，application.yml的配置如下。
1. Spring Cloud Ribbon
Spring Cloud Ribbon的用法十分简单，首先是要引入
spring-cloud-starter-netflix-ribbon的库，下面以使用RestTemplate为例，需要在初始化RestTemplate时加上@LoadBalanced注解，代码如下。
如果使用了WebFlux，那么WebClient的用法如下。
然后调用时需要build()一下，如调用一个程序用户的接口，其代码如下。
当你在使用RestTemplate请求其他服务时，就会默认使用Ribbon的负载均衡策略进行请求，默认的是轮询，即会对所有可用的服务实例进行轮询访问。可以编写测试程序来测试代码是否生效。
当然，Ribbon为我们提供了7种负载均衡策略，如表2.2所示。
然后，可以通过配置application.yml文件来配置我们想要的策略。例如，想将负载均衡策略改成随机选择RandomRule，那么配置如下。
配置完成后，还需要配置对应IRule类型的Bean去覆盖原有的Rule实例，代码如下。
2. Spring Cloud Feign
Feign其实是对Ribbon的一个高级的封装，负载策略与Ribbon一致。首先，Feign在Ribbon的基础上提供了更加简便的服务调用方式，可以像调用本地方法一样调用远程服务；其次，Feign还集成了断路器：Spring Cloud Netflix Hystrix。这里先来介绍Spring Cloud Feign是如何优化远程调用方式的。
首先，需要引入
spring-cloud-starter-openfeign的库，然后在Spring Boot的启动类上加上@EnableFeignClients注解，代码如下。
结语
小编也是很有感触，如果一直都是在中小公司，没有接触过大型的互联网架构设计的话，只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。
我们选择的这个行业就一直要持续的学习，又很吃青春饭。
虽然大家可能经常见到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。
送给每一位想学习Java小伙伴，用来提升自己。
本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！
文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！
3263
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
