1 简介

微服务的四个问题？

1. 服务很多，客户端该怎么访问？（路由网关）
2. 这么多服务，服务之间如何通信？（通信）
3. 这么多服务，如何治理？（服务注册和发现）
4. 服务挂了，怎么办？（熔断）

解决方案：SpringCloud是一个生态！

1. SpringCloud NetFlix：停止维护，成熟的一站式解决方案
   1. Api网关：zuul组件
   2. 负载均衡：Ribbon
   3. 声明式远程调用：Feign，基于HttpClinet，同步并阻塞
   4. 注册中心：EureKa
   5. 熔断机制：Hystrix

1. Dubbo+Zookeeper：半自动，需要整合别人的。异步非阻塞。基于
   1. Api网关：没有，找第三方插件，或者自己实现
   2. Dubbo：基于RPC
   3. Zookeeper：
   4. 没有熔断：借助Hystrix
2. SpringCloud Alibaba：2019年开始，目前主流，比第一个更简单了，基于Http协议的

新概念：服务网格（Server Mesh），自己查学习

2 微服务

• 概念（面试）：目前没有明确的概念，微服务是一个架构风格，它提倡将单一的应用划分成一组小的服务，每个服务运行在其独立的进程内，服务之间互相协调调用。通过一个简单的通信机制互相调用，每个服务都围绕着具体的业务进行构建，一个服务做一件事事情，从技术角度看就是一种小而独立的处理过程。
• 微服务不会和css、html等前端页面产生交互，微服务只是业务逻辑的代码
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库

SpringBoot和SpringCloud关系

1. SpringBoot专注于快速开发方便的个体微服务（jar包）
2. SpringCloud是关注全局的微服务协调治理框架，离不开前者

3 搭建环境

4 Eureka

三大角色

• Eureka Server：提供服务的注册与发现。=Zookeeper
• Service Provider：将自身服务注册到Eureka中，让消费者获得
• Service Consumer：消费服务
• 自我保护机制：是一种应对网络异常的安全保护机制，它的架构哲学是宁可同时保留所有微服务，也不会盲目注销任何健康的微服务。可以在配置中取消自我保护机制
• 配置集群：eureka中修改defaultZone中注册的多个端口，提供者中再同时调用多个

CAD原则

• C（Consistency）：强一致性

• A（Availability）：可用性

• P（Partition tolerance）：分区容错性

• 一个分布式系统只能兼容以上3者中的2者

Zookeeper区别

• Z保证的是CP
  • 可以容忍查询出前几分钟的以前的注册信息，但不能接受服务直接down不能使用，当master结点挂掉，选取leader时间过长，导致注册服务瘫痪Eureka保证的是AP
• Eureka保证的是AP
  • Eureka中的各个结点中都是平等的，几个结点挂掉不会影响正常结点的工作，只不过查到的信息可能不是最新的，并且它有自我保护机制

5 Ribbon负载均衡

• 基于客户端，是一种负载均衡（load balance）的工具，将用户的请求平摊到多个服务器上，从而达到系统的高可用，默认是轮询算法，

• 使用微服务名字来访问

• 负载均衡简单分类：

  • 集中式的LB：消费和服务之间提供独立的LB设施，如Nginx，方向代理服务器
  • 进程式的LB：消费方从服务注册中心获知哪些地址可用，然后自己调用，Ribbon就属于此类

• Ribbon核心组件：IRule，各种负载均衡算法都在里面

6 Feign负载均衡

• 使用接口来访问
• 导包，编写接口，调用接口