架构：配置中心（数据发布与订阅），配置共享，服务发现，微服务鉴权，网关，负载均衡，
设计：分布式锁，延时队列
业务：日志、链路跟踪，灰度，
日志：（面向领域、业务、基础架构）
通信协议：http(1.1, 2.0), ssl, websocket, probuf,
链路跟踪：（面向领域、业务、基础架构）
延时队列：
Redis：zset + 轮询
Netty：时间轮
RabbitMq
kafka：时间轮
Java DelayQueue
接口开发：
线下分配appid和appsecret，针对不同的调用方分配不同的appid和appsecret
防止盗链：加入时间戳
nonce（临时流水号）：防止重复提交
签名signature字段生成规则：
请求头=“appId=xxxx&nonce=xxxx×tamp=xxxx”
sign = MD5(请求头 + 请求URL地址 + 请求Request参数 + 请求Body + appSecret)
微服务鉴权：
https://mp.weixin.qq.com/s/KLaUqQUFCF9TgMh-IHvedg
负载均衡：
不同机房：智能dns，httpdns
distributed database sharding:
hash slots locationg method:
1.client存储哈希槽与节点的映射信息：
1）固化存储；
2）第一次访问节点获取然后缓存下来（Redis）；映射改变需要重定向。
2.proxy,统一代理节点。
3、every node is proxy。
分布式锁：
互斥
避免死锁：需要ttl，更严格需要自增id阻断冲突请求
容错：自身容错（zk，etcd），多个服务获取多个锁（Redlock）
可重入
自旋：MySQL，Redis
监听（自带排队功能）：zk，etcd
性能：单点Redis > etcd > Zookeeper > MySQL
Redis：
单点：set nx
Redlock：多个服务依次获取锁，超过一半成功，否则释放。
Zookeeper：
持久节点前缀，临时节点序列号自增，后一个监听前一个节点，避免惊群。
etcd:
互斥：etcd 支持事务，通过事务创建 key 和检查 key 是否存在，可以保证互斥性；
容错：etcd 基于 Raft 共识算法，写 key 成功至少需要超过半数节点确认，这就保证了容错性；
死锁：etcd 支持租约(Lease)机制，可以对 key 设置租约存活时间(TTL)，到期后该 key 将失效删除，避免死锁；etc 也支持租约续期，如果客户端还未处理完可以继续续约；同时 etcd 也有自增 id，在下文介绍。
实现：
Revision 机制。一个全局序列号，跟 ZooKeeper 的序列号类似，可以用来避免 watch 惊群；
Prefix 机制。即上述代码中 etcd 会创建一个前缀为 /my-lock/ 的 key(/my-lock/ + LeaseID)，分布式锁由该前缀下 revision 最小(最早创建)的 key 获得；
Watch 机制。跟 ZooKeeper 一样，客户端会监听 revision 比自己小的 key，当比自己小的 key 释放锁后，尝试去获得锁。
本质上 etcd 和 ZooKeeper 对分布式锁的实现是类似的。
1、缓存穿透：缓存中不存在并且在数据库中也不存在。
布隆过滤器：过滤数据库
返回空对象
2、缓存击穿：热点key过期，大量线程访问数据库。
互斥锁：第一个发现CacheMiss的线程加锁，再从数据库更新到缓存，其他线程阻塞再读缓存。
永不过期
定期更新：即将过期，从数据库更新，延迟过期时间。
3、缓存雪崩：批量同时过期，缓存宕机
均匀过期
加互斥锁
永不过期
定期更新
双层缓存策略
Rest和rpc比较
rest的服务器客户端没依赖，耦合性低
rpc原理：
一个连接，使用channel调用服务
gRpc:
http2.0
序列化：probuf
没有服务治理和注册中心
Dubbo的工作原理：
第一层： service层，接口层，给服务提供者和消费者来实现的
第二层： config层，配置层，主要是对Dubbo进行各种配置的
第三层： proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton
第四层： registry层，服务注册层，负责服务的注册与发现
第五层： cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例整成一个服务
第六层： monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
第七层： protocol层，远程调用层，封装rpc调用
第八层： exchange层，信息交换层，封装请求响应模式，同步转异步
第九层： transport层，网络传输层，抽象mina和netty为统一接口
第十层： serialize层，数据序列化层
默认使用Dubbo协议：
连接个数：单连接
连接方式：长连接，心跳时间heartbeat默认是1s
传输协议：TCP
传输方式：NIO异步传输
序列化：Hession二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要使用Dubbo协议传输大文件或超大字符串
使用场景：常规远程服务方法调用
多线程：使用唯一ID区分
consumer和provider都异步的通知监控中心
dubbo默认传输大小：8Mb
Dubbo的安全性如何得到保障
(1). 在有注册中心的情况下，可以通过dubbo admin中的路由规则，来指定固定ip的消费方来访问。
(2). 在直连的情况下，通过在服务的提供方设置密码（令牌）token，消费方需要在消费时也输入这个密码，才能够正确调用。
(3). Dubbo添加服务ip白名单，防止不法调用。
Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 `check="true"。
但是，有的时候，我们并不是都需要启动时就检查的，比如测试的时候，我们是需要更快速的启动，所以，这种场景的时候，我们是需要关闭这个功能的。
负载均衡策略
Random LoadBalance 随机，按权重设置随机概率（默认）
RoundRobin LoadBalance 轮询，按公约后的权重设置轮询比率
LeastActive LoadBalance 最少活跃调用数，相同活跃数的随机
ConsistentHash LoadBalaclava 一致性Hash，相同参数的请求总是发到同一提供者
集群容错方案
Failover Cluster 失败自动切换，自动重试其他服务器（默认）
Failfast Cluster 快速失败，立即报错，只发起一次调用
Failsafe Cluster 失败安全，出现异常时，直接忽略
Failback Cluster 失败自动恢复，记录失败请求，定时重发
Forking Cluster 并行调用多个服务器，只要一个成功即返回
Broadcast Cluster 广播逐个调用所有提供者，任意一个报错则报错
Dubbo 有四种注册中心的实现，分别是 ZooKeeper，Redis，Simple 和 Multicast。
在禁用 cookie 的情况下，可以继续使用session：
1、通过url重写，把 sessionid 作为参数追加的原 url 中，后续的浏览器与服务器交互中携带 sessionid 参数。
2、服务器的返回数据中包含 sessionid，浏览器发送请求时，携带 sessionid 参数。
3、通过 Http 协议其他 header 字段，服务器每次返回时设置该 header 字段信息，浏览器中 js 读取该 header 字段，请求服务器时，js设置携带该 header 字段。