【注册中心】【服务发现】【配置管理】【分布式一致性】基本发展史

概念

服务提供者：服务注册方，被调用方直接调用，服务应该是有状态的，基于ip+port，需要探活

服务消费者：服务调用方，从注册中心获取服务提供者ip，直接调用

注册中心：服务提供者注册、服务提供者注销、服务提供者保活；

CAP：在服务发现方面，A是大于C的，读一致性不需要强一致，是系统可接受的

软负载：基于客户端+服务发现+负载均衡

硬负载：基于服务器的负载均衡，需要独立部署负载均衡主，流量集中（F5,LSV）

fileCache：用page cache实现，查询高性能

Consumer LB方案

集中式：什么是集中式，就是所有的访问都是经过一个集中的负载均衡节点，由节点负责负载均衡，经典的实现有F5负载均衡器，Nginx实现：首先由网络请求DNS，得到集中负载均衡节点的

　　画图：DNS、Consumer、Provider

• 优势
  • 可以做到统一异常管理返回，所以适合内网对外的访问
  • 管控限流特别容易
  • 全站https加密、DDos攻击
• 劣势
  • 性能会有损耗
  • 要部署集群硬部署设备
  • 负载均衡需要特殊维护、设备成本

进程内LB：负载进程的算法实现包装为SDK，潜逃在应用程序中；同时要和注册中心持续保活，保证更新信息

　　画图：注册中心（应用进程内嵌LB）、Consumer、Provider

• 优势：可以用作软负载高性能，不需要特殊的维护
  • 直接调用Provider
• 劣势：多种语言需要多种实现
  • 无中心化，调用管控弱
  • 必须要保证注册中心高可用

单独进程LB：在同一起机器中，另外起一个进程做负载

　　画图：注册中心（独立LB进程）、Consumer、Provider

• 优势：不需要多语言，适用于大规模的网格型微服务，如k8s的管理
• 劣势：占资源，需要另起进程，不稳定性增加
  • 部署成本高，排查问题困难

Provider 注册方案

进程内注册方式：发起注册、取消注册和保活的代码，以SDK的方式在服务提供者进程中运行

　　画图：注册中心，Provider（进程内SDK）

• 需要多版本SDK支持不同语言

独立进程注册方式：发起注册、取消注册和保活的代码以独立的进程和Provider在一个机子中，如k8s kube proxy

　　画图：注册中心，Provider（同宿主机第三方进程）

均衡算法

轮询：获取所有的服务器ip，轮流发送请求，特点是简单；

随机：常见的是用hash算法，求出应该请求哪一台机器，然后发送请求；

权重：根据每台机器的特点，给他们不同的权重，然后采用权重平均的算法请求，实现负载，需要采取信息，但是效果很好；

注册中心

单机注册中心：只用一台机器做注册中心，可以用file来保存注册信息

• 无高可用性
• 一致性得意保障，实现简单

多机注册+DB：多台机器作为注册中心，数据存DB中。

• DB成为性能评价，发布者写频繁，订阅者读频繁
• 注册机器无状态，可用性高　　　　

多机器注册+FileCache+DB：多台机器作为注册中心，数据存DB中，但会加一层缓存提高性能。

• 解决多机注册+DB的性能问题，查询高性能
• 需要保持缓存一致性
  • 缓存一致性，先写file，再写内存

多机器注册+FileCache：多台机器作为注册中心，数据存DB中

• 真正分布式，高可用
• 多个副本一致性算法复杂（Paxos/raft/gosiip/zab）
• 集群管理，拓容

变更模式

• push模式，时效性强
• pull模式，时效性相对弱，无用的pull查询

额外功能

限流、熔断，同城结合服务一起用