springcloud使用的一些记录

注册中心

eureka, Zookeeper, Consul, Nacos

CAP理论是分布式架构中重要理论

• 一致性(Consistency) (所有节点在同一时间具有相同的数据)

• 可用性(Availability) (保证每个请求不管成功或者失败都有响应)

• 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

支持CP的注册中心: Zookeeper, Consul

Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。

在分布式环境中, 尤其是涉及到数据存储相关的, 保持数据一致性是非常重要的。这也是Zookeeper 设计紧遵CP原则的一个原因。

但是在注册服务与服务发现时，情况就不太一样了。服务消费者只要能够发现服务的提供者，及时当前发现的服务节点信息不正确，也比无法获取服务，导致异常要好。

Zookeeper的集群在leader宕机，该集群就需要进行重新选举，或者超过半数节点宕机，此过程中服务都不可用，无法保证服务可用性。

在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。

 

支持AP的注册中心：eureka

Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，

无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

eureka集群采用互相注册的方式，只要存在一个节点可用，则注册服务可用。

 

一个问题：

客户端注册eureka报错： Cannot execute request on any known server

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    public void configure(HttpSecurity http) throws Exception {
        super.configure(http);
        http.csrf().disable();
    }
}

security默认开启了csrf防御，禁止csrf防御即可。

 

网关服务

1) 为什么需要网关服务?

API网关的出现的原因是微服务架构的出现，不同的微服务一般有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成完成一个业务需求，如果让客户端直接与各个微服务通信，会出现以下的问题。

1. 客户端会多次请求不同的微服务，增加了客户端的复杂性。
2. 存在跨域请求，在一定场景下处理相对复制。
3. 认证复杂，每个服务都需要独立的认证。
4. 难以重构，随着项目的迭代。可能需要重新划分微服务。如果客户端与微服务直接通信，那么重构将会很复杂。
5. 某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难。

以上的问题可以借助API网关来解决。API网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过API网关这一层。也就是说，API网关可以完成安全、性能、监控等功能，而服务提供者可以专门的完成具体的业务逻辑。

http只请求网关服务, 根据规则分发到各服务中:

 

配置文件路由：通过配置文件直接指定服务，但是每增加一个服务，就需要重新修改配置。

动态路由：  https://blog.csdn.net/Dome_/article/details/87350578  --Spring Cloud Zuul路由动态配置

 

认证服务:

spring security oauth2 记录