本专题所写所感所得，来自转转首席架构师和字节架构团队，此致，敬礼。。
一、高可用
1.1 定义
高可用：全年365天「任何人」在「任何时间」、「任何地点」访问「任何服务」的能正确返回「任何结果」。
1.2 为什么要保证高可用
因为服务依赖于硬件或者软件，其中任何一个环节出问题，都可能导致服务出现问题。
1.2.1 硬件
- 生命周期：如过了保质期
- 硬件故障：如硬件坏了
- 网络划分：如机房划分
1.2.2 软件
- Bugs
- 性能极限
- 软件见相互影响
1.3 高可用评估手段
1.3.1 传统评估手段
传统评估手段
1.3.2 科学评估手段
科学评估手段
1.4 高可用手段
- 服务冗余：无状态
- 负载均衡：幂等设计
- 超时机制：异步化设计
- 熔断降级限流：数据复制／缓存／sharding
- 架构拆分
- 服务治理
-
实时监控
监控异常 -
服务分级
服务分级评估
二、高并发
2.1 高并发评估标准
- 吞吐量
- 响应延迟
2.2 高并发目标
目标
2.3 高并发手段
高并发主要关注：调用了多少RPC接口；载入多少数据；使用什么算法，非核心流程能否异步，没有数据依赖的逻辑能否并发执行。
2.3.1 架构层次
如何拆分系统，使得各个部分整体负载均衡，充分发挥硬件设施性能优势，减少系统内部开销。
2.3.2 算法层次
2.3.3 代码层次
- 循环遍历是否合理高效
循环调用rpc接口：使用批量接口
- 代码避免生成过多对象或无效对象
log日志级别判断，避免无效new对象
if(LOG.isDebugEnabled()) {
LOG.debug("debug log")
}
- map/list/数组等初始化容量合理
- 数据是否合理复用
- 字符串拼接
- string相加使用stringbuilder append
- 单例
- 数据库字段尽量使用小的数据结构
- 避免使用select *
- 等等...
2.3.4 常见高并发系统设计
秒杀系统：https://www.jianshu.com/p/bebd7cd4ea72
feed系统：https://www.jianshu.com/p/f8f0930f9d68
三、负载均衡
3.1 狭义负载均衡
3.1.1 负载均衡系统
3.1.1.1 硬件
- F5
- A10
- Redware
3.1.1.2 软件
- LVS：4层
- Nginx：7层
- HAProxy：4层或7层
3.1.1.3 正向代理和反向代理
正向代理：用户必须感知具体ip
反向代理：用户无法感知具体ip
3.1.2 负载均衡算法
- 随机：按权重设置随机概率
- 轮循：按权重设置轮循概率
- 一致性hash
3.2 广义负载均衡
3.2.1 完整的故障处理恢复机制
- 故障自动发现：如心跳检查
- 故障服务自动摘除
a. 服务熔断机制：如程序假死 - 请求自动重试
- 服务恢复自动发现
3.2.2 故障处理恢复机制案例
问题a.业务逻辑层1故障，谁来发现？
答：
1.注册中心(zk/etcd/consul)：通过心跳检查发现；
2.网关层：在心跳依然存在，程序假死的情况下，错误率达到一定比例通知注册中心熔断。
问题b.服务熔断机制怎么实现？
答：
1.hystrix
2.自实现方式：网关层单独线程计算错误率
问题c.服务恢复自动发现怎么重启？
答：
a.zk发指令给故障节点agent
b.打印2-3次jstack(主要发现死循环，两次内存堆栈信息是一样的)
c.kill -2(-2能处理完再推出，不能-9) 进程(虚拟机)／pod(k8s)
d.sleep 6s(zk心跳检查每3s一次，检查2次失败zk认定节点挂了，才能把节点从注册中心踢出)
e.start，注册zk
