Please enable JavaScript.
Coggle requires JavaScript to display documents.
服务发现、网关、路由 - Coggle Diagram
服务发现、网关、路由
服务发现
可靠与可用
- 服务注册 服务提供者注册自己信息
- 服务维护 检查服务提供者的心跳以及健康状况
- 服务发现 消费者从注册中心发现服务提供者
中间件
- 高可用：eureka
- 靠可靠性：consul
- 两者兼有：nacos
注册中心的实现
- 在分布式 K/V 存储框架上自己开发的服务发现，这类的代表是 ZooKeeper、Doozerd、Etcd。
- 以基础设施（主要是指 DNS 服务器）来实现服务发现，这类的代表是 SkyDNS、CoreDNS。
- 专门用于服务发现的框架和工具，这类的代表是 Eureka、Consul 和 Nacos。
网关
网关：路由器+过滤器
- 自定义路由规则，正则
- 过滤器周期 pre/post/routing/error
性能主要和IO模型相关
- 同步IO：阻塞IO/非阻塞IO/多路复用IO/信号驱动IO
- 异步IO Windows有IOCP linux目前不完善
- zuul使用netty ，nginx 可以自定义用哪种
- 阻塞IO：处理请求时会阻塞 省cpu但是上下文切换有代价
- 非阻塞IO 不断轮询好没好，处理快的省上下文切换，慢的耗cpu
- 多路复用: 同一条阻塞线程监听不同端口，哪个好了就处理哪个，select epoll
- 信号驱动：信号驱动 I/O 与异步 I/O 的区别是“从缓冲区获取数据”这个步骤的处理，前者收到的通知是可以开始进行复制操作了，即要你自己从饭堂拿回宿舍，在复制完成之前线程处于阻塞状态，所以它仍属于同步 I/O 操作，而后者收到的通知是复制操作已经完成，即外卖小哥已经把饭送到了
网关产品
- 基于 Nginx、HAProxy 开发的 Ingress Controlle
- 基于Netty开发的zuul
客户端负载均衡
- 每个服务消费者使用LoadBalance组件对服务进行负载均衡
- 均衡器与服务之间信息交换是进程内的方法调用，不存在任何额外的网络开销。
- 不依赖集群边缘的设施，所有内部流量都仅在服务集群的内部循环
- 避免集中单点的问题
- 可以针对每个服务实例添加不同的均衡规则
- 有程序语言限制
- 同一个进程中会消耗应用资源
- 要与服务器时刻保持心跳有网络负担
代理负载均衡器 （待办） :<3:
- 代理均衡器对此前的客户端负载均衡器的改进是将原本嵌入在服务进程中的均衡器提取出来，作为一个进程之外，同一 Pod 之内的特殊服务，放到边车代理中去实现，