侵入式服务治理

• 在应用端使用框架提供的API开发程序并提供服务治理方案。

dubbo

更侧重于RPC而非服务治理

概述

• 服务间基于RPC调用
• RPC 抽象一点将就是序列化，远程通信，反序列化。

核心流程

• 组成部分：服务提供者，服务消费者，注册中心
• 流程：
• 1:服务提供者完成初始化后向注册中心注册服务
• 2:服务消费者完成初始化后向注册中心订阅服务
• 3:注册中心在服务提供者列表发生变化时将变化同步给服务消费者
• 4:服务消费者和服务提供者初次建立链接后，即持有长链接，他们之间将通过透明化的远程调用进行通信。

注册中心

• 支持类型，1:Multicast，2:Zookeeper，3:Redis，4:Simple，5:Nacos
• 目前主流注册中心是Zookeeper和2.8之后的Nacos。
• 注册信息写入ZK节点，其中根节点为dubbo，URL为临时节点，保存IP端口调用方法等元数据信息，以及传输协议，最大连接数，路由决策等信息。
• 支持多注册中心
• ZK保存节点如图

负载均衡

• 负载均衡为客户端负载均衡。即由消费者一方决定将通信发往哪个服务提供者。
• 消费者实例启动时会从注册中心同步一份服务列表，并在服务提供者发生变化时跟新本地数据副本。每次远程调用时，消费者读取本地副本，并根据合适的负载均衡策略选择不同的服务提供方。
• 特点
• 1:弹性好：机遇服务发现可以快速扩容或缩容，相比生硬服务列表配置更加动态，灵活和实时（之前NG好像在upStream中是这么玩的，但两个不是同一个东西），使得应用能够已原生方式利用云资源的弹性伸缩。
• 2:高可用，去中心化，任何节点挂掉不会对服务产生实质影响。
• 3:性能优，采用dubbo协议的服务消费者和服务提供者之间是点对点直连的。建立链接后无需断开，无需重新经过三次握手，无需经过负载均衡服务器的二次转发。

远程通信

• RMI，Hessian，HTTP，WebService，Thrift，dubbo等。
• 默认支持Dubbo（特点）
• 1:创建固定长链接，减少建立链接握手次数
• 2:通过使用线程池并发处理请求提升并发效率
• 3:由于链接复用，适合小数据量请求，避免大文件占用带宽
• 4:并非原生NIO，而是才用netty做为底层通信，可以切换为mina
• 5:支持多种序列化，Dubbo，Json，pb，java原生等，可通过配置切换。序列化会对远程通信的吞吐量，响应速度，网络带宽消耗产生比较大的影响，是提升分布式系统性能的关键因素

限流

• 针对服务提供方，保护自己不被打垮。可配置实例的最大可接受连接数，最大线程数，每个服务提供者可建立的长链接数。

治理中心

• dubbo-admin，仅需要与注册中心关联即可
• 提供一个可视化中心，辅助做运维工作。提供了分组查询、配置更改、加权降权、禁用启用、权限控制、负责人管理等运维功能。

监控中心

• 现有dubbo-monitor不够好
• 1:缺乏完善的调用链统计功能
• 2:无法绘制系统的整体调用关系
• 3:无法钻去dubbo之外的请求信息

spring-cloud

• 提供了一套云原生开发组件，使用统一编程模型，为配置管理，服务发现，负载均衡，网关，限流熔断，日志追踪等提供了一套完成且便捷的解决方案。每个组建都可以写好多，这里就展开了。