【负载】【服务发现】【配置管理】负载均衡设计
负载
软负载：基于客户端+服务发现+负载均衡
硬负载：基于服务器的负载均衡，需要独立部署负载均衡主，流量集中（F5,LSV）
服务发现
服务提供者：服务注册方，被调用方直接调用
服务消费者：服务调用方，从注册中心获取服务提供者ip，直接调用
注册中心：注册、注销、保活；
CAP：在服务发现方面，A是大于C的，读一致性不需要强一致，是系统可接受的
LB方案
集中式：什么是集中式，就是所有的访问都是经过一个集中的负载均衡节点，由节点负责负载均衡，经典的实现有F5负载均衡器，Nginx实现：首先由网络请求DNS，得到集中负载均衡节点的
- 优势
- 可以做到统一异常管理返回，所以适合内网对外的访问
- 管控限流特别容易
- 劣势
- 性能会有损耗
- 负载均衡需要特殊维护
进程内LB：负载进程的算法实现包装为SDK，潜逃在应用程序中；
- 优势：可以用作软负载高性能，不需要特殊的维护
- 劣势：多种语言需要多种实现
单独进程LB：在同一起机器中，另外起一个进程做负载
- 优势：不需要多语言，适用于大规模的网格型微服务，如k8s的管理
- 劣势：占资源，需要另起进程，不稳定性增加
均衡算法
轮询：获取所有的服务器ip，轮流发送请求，特点是简单；
随机：常见的是用hash算法，求出应该请求哪一台机器，然后发送请求；
权重：根据每台机器的特点，给他们不同的权重，然后采用权重平均的算法请求，实现负载，需要采取信息，但是效果很好；
附加功能
限流、熔断，同城结合服务一起用
服务注册
一致性协议
- 单机+file
- 多机+DB
- 多机+Cache+DB
- 需要考虑缓存一致性
- 多机+fileCache
- 多个副本一致性算法复杂（Paxos/raft/gosiip/zab）
变更的通知
- push模式
- pull模式
容灾策略
- 主备模式/主主模式
- 本地缓存，保证可用
- 缓存一致性，先写file，再写内存
可用性保证