springcloud的组件及原理

文章目录

• 一、Eureka：服务注册与发现中心
• • 1.八大概念：
  • • 1.1.服务注册
    • 1.2.服务续约
    • 1.3.服务获取
    • 1.4.服务下线
    • 1.5.服务调用
    • 1.6.服务同步
    • 1.7.失效剔除
    • 1.8.自我保护
  • 2.eureka工作原理图
  • 3.eureka与zookeeper区别
• 二、使用步骤
• • 1.nginx相关概念
  • • 1.1正向代理
    • 1.2反向代理
    • 1.3负载均衡
    • 1.4动静分离
    • 1.5nginx高可用
  • 2.nginx原理及问题
  • • 2.1 nginx原理
    • 2.2 nginx问题总结：

---

一、Eureka：服务注册与发现中心 1.八大概念： 1.1.服务注册

理解：eureka客户端向服务端注册服务，eureka客户端可能是服务调用着，也可能是服务消费者，或者两者都是

1.2.服务续约

理解：eureka客户端默认每隔30s向服务端发送心跳

1.3.服务获取

理解：eureka客户端向服务端获取注册表信息

1.4.服务下线

理解：eureka客户端shutdown申请服务下线

1.5.服务调用

理解：eureka客户端A根据拿到的注册表信息向eureka客户端B发送调用请求

1.6.服务同步

理解：eureka服务端C接受新的客户端后，会向其他eureka服务端同步信息，告知其他服务端有新的客户端接入

1.7.失效剔除

理解：eureka服务端90s内没有接收到eureka客户端A的心跳时，会考虑剔除服务提供者A
例子：如服务提供者A，被剔除，如果服务调用者B有A的注册表信息那么还是可以继续调用，否则就调用不到服务A了

1.8.自我保护

指的是：eureka server的自我保护

由来：网络分区发生故障时，微服务与eureka server通讯异常，而微服务本身是正常运行的，此时不应该剔除此服务，所以引入了自我保护机制。

工作机制：如果在15分钟内超过85%的客户端节点都没有正常心跳，那么eureka server就会认为客户端与注册中心出现了网络故障，并进入自我保护机制

进入自我保护后：
a.eureka server不再移除注册表中因长时间没有收到心跳的服务
b.eureka server仍然能够接受新服务的注册和查询请求，但不会同步到其他节点，保证当前节点的可用
c.网络稳定时，eureka server新的注册信息会同步到其他节点中

自我保护机制失效：服务端源码写死是30秒进行计算，如果将客户端发送的频率改为15秒发送一次心跳，那么就会导致计算的比例有问题。如2台机器某一台下线了，服务端仍然计算这个预期值和实际值是一样的，那么此时自我保护机制不会触发（即失效）

2.eureka工作原理图

在进入读写缓存后，会stw一会（神操作）
注册表内存已经设计为ConcurrentHashMap了，为什么还需要设计三级缓存？
持续并发的情况下，读写竞争激烈严重影响eureka server服务性能

3.eureka与zookeeper区别

CAP原则
RDBMS ：(Mysql、Oracle、sqlServer) ⇒ ACID
NoSQL：（redis、mongoDB）⇒ CAP

ACID是什么？

• A （Atomicity） 原子性
• C（Consistency） 一致性
• I （Isolation） 隔离性
• D（Durability） 持久性

CAP是什么？

• C （Consistency） 强一致性
• A（Avalibility）可用性
• P（Partition tolerance）分区容错性

CAP原则只能三进二，即：CA、AP、CP
CAP理论的核心：

• 一个分布式系统不可能同时很好地满足一致性、可用性和分区容错性这三个需求

• 根据CAP原理，将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类

    - CA：单点集群，满足一致性、可用性的系统，通常可扩展性很差
    - CP：满足一致性、分区容错性的系统，通常性能不是特别高
    - AP：满足可用性、分区容错性的系统，通常对一致性要求低一些
  

• 作为注册中心，Eureka比Zookeeper好在哪里？
  CAP理论指出，一个分布式系统不可能同时满足C（强一致性）、A（可用性）、P（分区容错性）
  由于分区容错性P在分布式系统中是必须保证的，因此只能在A和C之间进行权衡

    	- Zookeeper 保证的是CP；
    	- Eureka 保证的是AP；
  

• Zookeeper保证的是CP
  现状及问题：

      当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟前的注册信息，但不能接受服务直
  接down掉而不可用。也就是说服务注册功能对可用性的要求要高于一致性。
  	但zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会进行leader
  选举。问题在于leader选举时间太长，30-120s，且期间整个zk集群是不可用的，就会导致在选举期间注册服
  务是瘫痪状态。在云部署的环境下，因为网络问题是的zk集群失去master节点是较大概率事件，虽然最终都能
  恢复，但漫长的选举导致注册长期不可用是不能容忍的。
  

• Eureka保证的是AP

  	Eureka看明白了这点，因此再设计的时优先保证可用性。Eureka的各个节点都是平等的，几个节点挂掉不
  会影响其他节点的工作，剩余节点依然可以提供服务注册和查询。
  	Eureka clinet在向server注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台server还
  在，就能保证服务的可用性，只不过查到的信息可能不是最新的；除此之外，Eureka 还有一种自我保护机制，
  如果再15分钟之内超过85%的节点都没有心跳，那么Eureka server就会认为客户端与注册中心出现了网络故障，
  此时会出现以下几种情况：
  1、Eureka不再从注册中心移除因为长时间没有收到而应该过期的服务
  2、Eureka仍然能够接受新服务的注册和查询请求，但是不会同步到其他节点上（即保证当前节点可用）
  3、当网络稳定时，当前节点新的注册信息会自动同步到其他节点
  

因此：Eureka可以很好的应对因为网络故障导致部分节点失去联系的情况，而不会像zk那样使整个注册中心瘫痪。

二、使用步骤 1.nginx相关概念 1.1正向代理

客户端浏览器通过配置代理服务器，通过代理服务器的映射关系请求到对应的网址
nginx是如果配置配置正向代理的？

1.2反向代理 1.3负载均衡 1.4动静分离 1.5nginx高可用

通过LVS+keepalived配置实现

2.nginx原理及问题 2.1 nginx原理

master：分配工作
woker：争抢处理任务
nginx底层实现：linux多路复用机制，与redis相似

2.2 nginx问题总结：

1.一个master对应多个worker的好处（争抢机制）
（1）可用使用nginx -s reload 热部署而不需要重启nginx服务
（2）每个worker是个独立进程，如其中一个worker出现问题，其他worker不受影响，可用继续争抢
2.设置多少个worker合适（性能最优）
worker数量=cpu核心数最为适宜（不会造cpu来回切换，影响性能）

3.nginx可以处理多少并发？
理解：1个worker对应多个worker_connection。如worker_connection=1024
分为2种情况：
（1）：当nginx处理静态资源时：worker数量worker_connection / 2
（2）：当nginx处理操作后台时：worker数量worker_connection / 4