Dubbo源码解析（二十）Dubbo 服务自省（小马哥视频观后感）

服务自省

Dubbo 2.7.5 +

背景

业界方案

• CloudNative 的 技术兴起

• Sping Cloud的快速崛起

Dubbo 所面临的的挑战

• 如何解决或缓解注册中心压力过载

  • Dubbo是以接口发布服务的，所以注册中心节点会多，内存会很大。

  • 消费者和提供者与注册中心压力都会很大。网络抖动会造成网络风暴。

  • 因为注册中心需要实时将服务上下线等时间通知到对应的消费者、提供者。

• 如何支持以应用为粒度的服务注册与发现

  • 支持SpringCloud服务注册与发现模型
  • 支持Kubernetes服务注册与发现模型
  • 兼容Dubbo 传统服务注册与发现模型

• 如何精简Dubbo URL 元数据

  • https://blog.csdn.net/u013076044/article/details/89035939
  • 

概述

JavaBeans 自省- At runtime and in the builder environment we need to be able to figure out which properties，event，and methods a JavaBean supports。We call this process introspection。

定义

Dubbo 应用在运行期间处理和分析Dubbo服务元信息的过程，如当前应用暴露的Dubbo服务以及各自的通讯协议等。期间会伴随着时间的广播和处理，如服务暴露事件。

• Dubbo 2.7.5 引入服务自省和事件机制

术语定义

使用场景

架构设计

以上是小马哥的视频总结，下面是自己的一些思考。

总的来说，相比于原来的接口发布，现在是将整个微服务作为一个实例(ServiceInstance)注册，所以客户端调用的时候，需要考虑请求的路由，也就是我们之前的URL对象。

所以我们在服务调用的时候需要考虑，不仅仅拿到这个微服务实例的地址，还需要知道这个微服务实例具体发布了哪些服务，也就是微服务实例和接口的映射（ServiceNameMapping）。

然后根据对应的serviceName去元数据中心获取接口的详细信息（方法、参数）。

最后组成一批URL。

附录： zk上的节点信息

{
    
    
    "parameters":{
    
    
        "side"