熔断
个人感觉在语音上对熔断和降级的说明有些重合，或者不容易区分
当扇出链路的某个微服务不可用或者响应太长时，熔断(或者中断)该节点微服务的调用，快速返回错误的响应信息
熔断的目的是当A服务模块中的某块程序出现故障后为了不影响其他客户端的请求而做出的及时回应。
直接看例子
最底部的熔断方法和服务主体是跑在一起的
降级
降级的目的是为了解决整体项目的压力，而牺牲掉某一服务模块而采取的措施。
- 降级的代码是在调用端跑的（当被调用端的服务由于资源不够等原因被停止时，上游调用端也能得到一个相对正常的响应）
- 熔断的代码是在被调用端跑的（当某个服务或接口超过频率或者触发其他规则时，进行的某些动作）
也许这就是最能说明两者区别的区别
现在熔断的依赖包hystrix现在已经没人维护了，所以不推荐使用，个人更推荐使用**阿里巴巴的sentinel框架**
sentinel提供了熔断、流量整形等各种灵活功能
阿里巴巴的sentinel框架
在管理后台可以定义目标、应用什么规则(策略)、触发后采取的措施
可以这样使用：
也可以：
网关
JAVA生态的网关
- Zuul
兼容servlet，学习成本比gateway低一些，但性能比gateway要差
- Spring Cloud Gateway
和servlet不兼容，底层通信采用的netty，基于webflux开发，有一定的学习成本，但性能比zuul好很多
云原生网关
- nginx家族(nginx/openresty/kong)
之前尝试过nginx/openresty，但学习成本相对高，最后自己通过filter写了一套代码来达到目的
- apisix
国内开源项目，已从apache毕业，很多大厂也在使用，具体还没使用过，有提供方便管理的界面，这个很吸引人
Zookeeper
- 可以理解为是一个分布式文件系统，满足CAP中的CP，在进行leader选举的时候不满足A
- 基于内存，所以性能很高，非常使用读多写少的场景。
- 针对写多读少的场景，zk存在一些性能瓶颈，因为它要把数据同步到其他zk节点上
- 分为4种节点，每个节点存储的数据大小限制为1M
- 永久节点：即便zk宕机也还在，直到删除
- 永久顺序节点：
- 临时节点：和会话绑定，会话消失节点消失，只能是叶子节点，不能有子节点
- 临时顺序节点：除了临时节点的特性外，节点名称还具有顺序性
- 节点间通过zab协议保持数据同步
- 会有脑裂问题，也就是可能同时存在两个leader，但由于有过半机制，所以只能一个leader能提供写服务，所以也可以说没有脑裂问题。
- 节点有三种角色(raft协议也是三种角色)
- leader
- follower
- observer
- 为啥节点数最好奇数个，因为2n个节点和2n-1个节点的容忍度一样，比如4台最多宕机一台，3台也是最多宕机一台
- zab协议，这个没去研究了，研究了下更简单易懂的raft协议
如何设计一个高可用系统？
个人认为这个问题有点大，因为一个系统往往是由很多子系统或者组件构成，要整个系统高可用，那么冲请求进来到请求返回的整个链路都要高可用才行。
总的来说分几个层来说吧：
- 存储层
- 各种中间件
- 代码层(服务层)
- 网关层
- 监控系统、动态扩容
- 操作系统层
- cdn，dns等等
存储层高可用
不同的存储又有不同的高可用
- mysql：尽量sql简单，全表查询，慢查询，利用好索引等等因素，还可以做异地备份，异地双活这些，分库分表呀等等
- es：合适的分词器，副本的设置，分片的设置，每条消息大小的限制等等
各种中间件
- 比如redis高可用方案，个人比较喜欢codis:
- codis
- redis本身的cluser方案，同时redis自身的各种设置，比如持久化规则，aof重写，内存淘汰策略等等
- twitter的Twemproxy
- mq的高可用，不同的mq又有不同的方案
代码层(服务层)
- 自身代码逻辑要处理好，避免出现一些OOM，cpu飙高等问题
- 比如数据库连接池呀，锁呀，分布式锁呀，等等很多小的问题在大流量下都可能放大为导火索
- 缓存呀
网关层
- 限流熔断呀，非法请求识别与拦截呀，限流算法呀，如何实现，是用云原生还是服务网关呀等等
操作系统层
- 比如单进程打开的文件数，tcp握手挥手相关参数设置
cdn和dns
- 比如cdn，图片大小，上次西安还是哪个地方的类似渝康码的东西就蹦了斗嘛，主要就是没有图片原因样
- dns也能达到分流的目的这些
- 随机毒鸡汤：骑电动车请戴好头盔，否则，开奔驰的同学会认出你。
