一、SpringCloud 相关知识
1. Spring Cloud 架构图
2. Eureka 原理
Eureka两大核心功能：
、
。
3. Eureka 集群原理
Eureka集群是peer to peer模式，也就是说集群中的每个Eureka实例是平等的，每个实例都可以进行服务的发现和注册，这点与ZooKeeper是不同的。
4. Eureka和ZooKeeper的区别
- 集群模式不同：Eureka是peer to peer模式，ZooKeeper是leader - follower模式。
- 一致保障性不同：
，
，
。
Eureka可以保障AP，ZooKeeper可以保障CP。
当Eureka集群中一台机器“死掉”时，调用者仍可在Eureka其他节点中获取注册表，但是这个注册表可能不是最新的数据。因为假设当服务A向Eureka-1注册时，Eureka-1死掉了，它还没来及将服务A的数据同步给其他Eureka节点，所以调用者从其他Eureka节点中可能获取不到服务A。所以，Eureka集群保障了可用性，但是强一致性没法保障。
当ZooKeeper集群中的leader“死掉”时，整个ZooKeeper集群将不可用，直到选举出新的leader并同步完数据后，ZooKeeper集群才可以对外使用。所以，ZooKeeper集群保障了一致性，却无法保障始终可用。
- 服务注册感知的时效性
Eureka默认配置速度比较慢，甚至能达到两三分钟。而ZooKeeper感知速度很快，秒级感知。
5. Eureka 参数优化（必须）
因为如果使用Eureka默认参数配置，服务的注册和发现会很慢，不符合生产使用。所以，必须手动配置参数。
| 参数 | 说明 |
|---|---|
| eureka.server.responseCacheUpdateintervalMs= 3000(单位毫秒) | Eureka server刷新readCacheMap的时间，注意，client读取的是readCacheMap，这个时间决定了多久会把readWriteCacheMap的缓存更新到readCacheMap上(
默认30秒
) |
| eureka.client.registryFetchintervalSeconds=3(单位秒) | 从Eureka服务器注册表中获取注册信息的时间间隔（s），
默认为30秒
|
| eureka.client.leaseRenewalintervalSeconds=3 | Eureka客户需要多长时间发送心跳给eureka服务器，表明它仍然活着,
默认为30 秒
|
| eureka.server.evictionintervalTimerinMs=3000 | 过期实例应该启动并运行的时间间隔，单位为毫秒，
默认为60 * 1000
|
| eureka.instance.leaseExpirationDurationinSeconds=3 | Eureka服务器在接收到实例的最后一次发出的心跳后，需要等待多久才可以将此实例删除，
默认为90秒
|
经过调整后，服务发现变为秒级。
6. 生产机器选择
服务注册中心部署个2台机器，每台机器就是4核8G，每台机器每秒钟轻松抗几百请求，上千请求也是可以的，高可用冗余，任何一台机器死掉，不会影响系统的运行。
微服务通常来说，如果每秒钟的并发在1000以内的话，每个服务部署2台机器，每台机器4核8G，每台机器每秒抗个几百请求，一点问题都没有
大部分的系统，高峰期每秒几百请求，低峰期每秒几十请求，甚至几个请求。
网关系统，4核8G的机器，一台机器抗每秒几百请求，部署3~4台机器，保证可以网关系统每台机器的压力比较小，进一步保证网关系统可靠性。
MySQL数据库，16核32G，物理机最佳，最多抗个每秒钟几千请求问题不大，平时抗个每秒钟几百或者几十请求。
7. 如何统计QPS、接口请求数等
做一个简单的metric统计机制，AtomicLong，原子性，并发下数据统计准确，不会错误，每个接口被调用的时候，一个是可以对每个接口每分钟都做一个Metric统计。
对每个接口每天的请求使用一个AtomicLong做一个计数，统计出来每天的请求次数。
8. 如何实现幂等性
插入新数据保障订单字段是唯一索引，更新数据先查再更新。
9. 分布式事务如何实现
常用TCC和可靠消息一致性。前者需要使用TCC框架，给需要保持事务的接口多写一个回滚接口，这样如果发生异常，TCC框架会调用回滚接口，保障事务。可靠消息一致性则需要使用消息中间件。
