微服务的发展

本文以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