共计 937 个字符，预计需要花费 3 分钟才能阅读完成。
本文以 dubbo 为主线，概述微服务在企业中的倒退为了解决实现不同利用之间的近程调用问题，须要有一个形式去发现服务，注册服务。在设计一个分布式系统时。须要让利用之间互相感知服务。个别没有纯正的提供服务和调用服务的利用，大多数即便提供者又是调用者。所以咱们须要把本身服务写到一个公共存储，其余利用通过一直轮询和被动告诉的伎俩去获取最新的服务状态。
在 dubbo 2.7.3 之前，咱们会以服务维度向注册核心写入服务信息、提供者、调用者。解决了小规模的近程调用问题。
但随着服务规模的晋升。既提供分布式协调服务、又当数据库的核心不堪重负。总数据量 = 服务数 *（提供者数量 + 消费者数量）
可见这个增长数据是很快的。服务发现注册的模型并不纯正，他还把服务调用阶段才须要的元数据信息注册下来，导致数据泛滥。
每个利用在获取服务和注册的时候，都会冗余很多信息。所以 zk 的性能越来越差，呈现超时景象。加机器能够解决很多问题，
但增长的速率是可怕的。
dubbo 2.7.3 当前，做了三大核心的革新。将注册核心、元数据中心、配置核心拆散。肯定水平上解决了注册数据冗余的问题、进步了性能。很多公司感觉 duboo 和 nacos 是原配。想拿它作为注册核心，而然而中途放弃了。因为性能上不去。
为什么微服务体系中的 nacos 放 dubbo 这边就不行了呢？起因是微服务注册的是利用，数据量少。而 nacos1.0 服务注册相干的还是 http 明文的形式。因而性能较差。服务数到了 5000+，nacos 就常常连不上了。在 nacos2.0 的时候，优化了传输协定，改为二进制的。性能晋升了 10 倍。
dubbo 3.0 为用户提供承前启后的革新。因为服务维度和利用维度的注册，数据模型自身不一样。所以原来服务的消费者，无奈失常生产利用维度注册类型的利用。dubbo 3.0 反对服务维度和利用维度的双注册，消费者也要双注册才行。
服务发现注册与业务自身无关，然而每个人或多或少都要花些工夫在下面。
云原生时代，dubbo 的三大核心，服务注册都能够托管给 k8s。dubbo3.0 的革新也是为了适配云原生。云原生中用 sidecar 模式，代理利用的申请，但须要对立保护 sidecar。dubbo 3.0 用的是客户端的形式，防止这个问题。官网称之为 proxyless
