第六章:侵入式服务治理

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

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


以上是关于第六章:侵入式服务治理的主要内容,如果未能解决你的问题,请参考以下文章

分布式系统架构-侵入式服务治理方案

Istio实战-非侵入的流量治理

Istio实战-非侵入的流量治理

服务网格:云原生服务治理与流量管控技术解读

微服务架构师必读必知的的服务治理一个不那都在这里

立足用户使用场景,BoCloud博云服务治理平台发布增强版