Spring Cloud (Eureka + Ribbon + Feign + Hystrix + Zuul) 搭建

1. 微服务技术栈(描述微服务框架大体)

这就是整个spring cloud 的大致架构图，包括运维

1. dubbo: zookeeper +dubbo + SpringMVC/SpringBoot
   • 配套 通信方式：rpc
   • 注册中心：zookeeper / redis
   • 配置中心：diamond
2. SpringCloud：全家桶+轻松嵌入第三方组件(Netflix)
   • 配套 通信方式：http restful
   • 注册中心：eruka / consul
   • 配置中心：config
   • 断 路 器：hystrix
   • 网关：zuul
   • 分布式追踪系统：sleuth + zipkin
3. SpringCloud Alibaba
   

2. 正文开始

2.1 RestTemplate （HTTP调用服务，Dubbo是RPC）

1. RestTemplate是由Spring框架提供的一个可用于应用中调用rest服务的类它简化了与http服务的通信方式，统一了RESTFul的标准，封装了http连接，我们只需要传入url及其返回值类型即可。相较于之前常用的HttpClient，RestTemplate是一种更为优雅的调用RESTFul服务的方式。

2. 在Spring应用程序中访问第三方REST服务与使用Spring RestTemplate类有关。RestTemplate类的设计原则与许多其他Spring的模板类(例如JdbcTemplate)相同，为执行复杂任务提供了一种具有默认行为的简化方法。

3. RestTemplate默认依赖JDK提供了http连接的能力（HttpURLConnection），如果有需要的话也可以通过setRequestFactory方法替换为例如Apache HttpCompoent、Netty或OKHttp等其他Http libaray。

4. 考虑到了RestTemplate类是为了调用REST服务而设计的，因此它的主要方法与REST的基础紧密相连就不足为奇了，后者时HTTP协议的方法：HEAD、GET、POST、PUT、DELETE、OPTIONS例如，RestTemplate类具有headForHeaders()、getForObject()、putForObject()，put()和delete()等方法。

---

2.2 本地psringcloud

创建两个服务，一个服务写 service 同时也写完 coontrller 。另一个服务 写相同的服务，通过相同的 mapping地址（只是提供给consumer 客户端访问需要） ，通过配置 url（http:// xxx,xxx,xxx,xxx：8001 的地址）远程调用controller ，实现两个服务器相同。consumer 只做服务器请求， provider 只做业务逻辑。

2.3 Eureka (服务注册与发现)

在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。（多个zookeeper之间网络出现问题,造成出现多个leader，发生脑裂）当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。

1. zookeeper保证cp原则（一致性）而Eureka保证的是ap原则（可用性）

2. zookeeper在选举期间注册服务瘫痪不可用，而Eureka各个节点平等，只要一台就能保证服务可以，但查询到的数据不一定是最新的，可以很好的应对网络故障导致的部分节点失联

3. zookeeper有header和follower角色（当header挂掉，会从剩下的follower里面选举一个header），Eureka各个节点平等

4. zookeeper采用半数存活原则（避免脑裂），Eureka采用自我保护机制来解决分区问题

5. kafka就是使用的zookeeper作为注册中心，理论上Eureka更适合作为注册中心

---

2.4 将我们注册进服务的组件，配置服务信息（公司个人信息）

---

2.5 Eureka集群配置

上诉仅仅做了 单个Eureka 服务器的 7001端口访问，now，我们 将建多个 Eureka服务，形成集群

图略

2.6 使用 Ribbon 实现负载均衡

开启@EnableEurekaClient 注解，他获取我们服务的列表，通过一种算法来选择访问谁。

1. 通过cnsumer访问provider的list方法，随机进入到db_01的数据库…
   
2. 随机进入db_03的数据库…
   
3. 自定义 Ribbon 客户端。因为自定义的 Ribbon 规则给单个进行约束，不能放在同一个包下，如果放在同级目录下，@ComponentScan会扫描到，变为共享规则，对单个服务器的负载均衡自定义算法就失效了。

2.7 Feign（声明式调用服务），在Ribbon 基础上封装了地址

Ribbon 在 consumer 里面写死了服务名字"http://SPRINGCLOUD- PROVIDER-DEPT" 。 而我们Reign 并不这样做，我们想的是面向接口，在公共模块的controller 层写"http://SPRINGCLOUD- PROVIDER-DEPT" 的位置。

feign ,主要是社区,大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法
1.微服务名字[ribbon]
2.接口和注解[feign ]
I

Feign 也是就是在 Ribbon的基础架构上加了一层，将固定调用的服务器地址放在我们的 API 公共层中，然后在原有的类中，@AutoWired 进去 ，使项目的可读性变强 。对API中的复写controller地址，类似于Dubbo ， RPC远程过程调用机制。

2.8 Hystrix 防止服务器熔断

2.8.1 防止 provider 服务提供端熔断，访问不存在的服务会进行抛出

1. 负载均衡是为了降低服务的压力，熔断是服务崩了后的处理措施，两者本质不一样。
2. 服务崩了会抛异常，熔断截取这个异常，走另一个请求，只要不是Hystrix异常都可以截取的。
3. 我B服务崩了，但是我A服务没崩，我A服务去调用B服务,调用失败返回异常，我A服务可以说：服务异常，调用失败
   
   从前端传来不存在的数据，会抛出并作出操作，而不是直接404
   

2.8.2 防止consumer 客户端访问服务端频繁出现负载——降级，在API 公共实体类中加入接口负载抛出，（一个接口负载满了，就抛出到另外一个接口进行服务）

由于是对异常接口的操作，比前者更符合面向接口编程的逻辑。Feign是对接口的调用 进行负载均衡，这里Hystrix（熔断）可以和Feign（声明式调用服务）相结合

我们关闭所有服务器，依旧可以访问地址。意思就是，停了服务器，客户端依旧能正常运行，正常访问。

总结：

服务熔断：比较被动，服务端挂了才会自动启用备用的服务器；
服务降级：比较主动 我就是不想你访问这个服务，所以直接就压根不让你访问，在客户端就给你拦下来了，你管我关没关服务，懂了吧。

2.8.3 Hystrix 面板

面板的注册肯定是在我们的 provider 服务器上配置 。
Hystrix 的面板地址：http://localhost:9001/hystrix
数据源地址：http://localhost:8001/actuator/hystrix.stream

上图的监控页面写完后，我们就可以在 provider - hystrix 里面放服务了

在 provider - hystrix 里卖弄添加服务监控，才能监控这个服务器的请求流

<dependency>A
<groupId>org . springfr amework . boot
<artifactId>spring- boot- starter- actuator< / artifactId>

---

2.9 zuul 路由网关

详解如图：配置不多。

2.10 SpringCloud Config

1. Spring Cloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环节提供了-一个中心化的外部配置。
2. Spring Cloud Config 分为服务端和客户端两部分;
3. 服务端也称为分布式配置中心，它是一 个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密,解密信息等访问接口。
4. 客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。

3. 总结：

常见面试题

3.1、 什么是微服务?

3.2、 微服务之间是如何独立通讯的?

3.3、SpringCloud 和Dubbo有哪些区别?

3.4、SpringBoot和SpringCloud, 请你谈谈对他们的理解

3.5、什么是服务熔断?什么是服务降级

3.6、 微服务的优缺点是分别是什么?说下你在项目开发中遇到的坑

3.7、 你所知道的微服务技术栈有哪些?请列举一二

3.8、eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别?

…