第六章:侵入式服务治理
Posted 魔都码农
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了第六章:侵入式服务治理相关的知识,希望对你有一定的参考价值。
侵入式服务治理
-
在应用端使用框架提供的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
-
提供了一套云原生开发组件,使用统一编程模型,为配置管理,服务发现,负载均衡,网关,限流熔断,日志追踪等提供了一套完成且便捷的解决方案。每个组建都可以写好多,这里就展开了。
以上是关于第六章:侵入式服务治理的主要内容,如果未能解决你的问题,请参考以下文章