世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。

可以通过dubbo.protocol或dubbo.provider的host属性对host进行配置，支持IP地址和域名。但此时注册到注册中心的IP地址和监听IP地址是同一个值。为了解决在虚拟环境或局域网内consumer无法与provider通信的问题，可以通过环境变量分别设置注册到注册中心的IP地址和监听IP地址，其优先级高于dubbo.protocol或dubbo.provider的host配置。

Dubbo-RPC是Dubbo框架体系中最核心的一种高性能、高吞吐量的远程调用方式，称之为多路复用的TCP长连接调用。

如果你看到了这里，那么接下来你将会认识Dubbo3的诞生将如何引领微服务领域更进一步，从而迈入云原生的领域，这当然不仅仅是Dubbo3，之前也介绍了Java生态另外一个云原生领域的技术Quarkus等技术，而本文内容侧重点去介绍Dubbo3迈向云原生的技术分析和探索，如果有不正确的地方，还需要大家多多指正。

如开篇所述，Dubbo 提供了构建云原生微服务业务的一站式解决方案，可以使用 Dubbo 快速定义并发布微服务组 件，同时基于 Dubbo 开箱即用的丰富特性及超强的扩展能力，构建运维整个微服务体系所需的各项服务治理能力， 如 Tracing、Transaction 等，Dubbo 提供的基础能力包括如下。

通过令牌验证在注册中心控制权限，以决定要不要下发令牌给消费者， 可以防止消费者绕过注册中心访问提供者， 另外通过注册中心可灵活改变授权方式，而不需修改或升级提供者。

在电商系统中，商品模型至关重要，是整个电商的核心，下面通过一个简单的分析，设计一个基础的商品模型。类目是商品所属的分类，类目决定了商品的归属。类目是有层次的，分为一级类目、二级类目等，之间有继承关系，通常是通过类目树来展现。比如厨房电器这个一级类目下，有电磁炉，冰箱等二级类目，电磁炉下面还会有细分的三级类目，类目树的最下面一层类目是叶子类目；一般来说，只有叶子类目才可以下挂商品。

用户中心，在我们的概念里面范围比较的广泛，包含了用户信息、账号信息以及租户信息的管理控制，在我们的总体设计里面，如果设计的边界较为紧密，也可以将权限的部分功能RBAC划分进入，当业务剧增的时候，可以将领域划分细一些。作为服务提供者的实现接口，将会有一个被:进行修饰的接口实现类主要面向与用户的注册账号功能（新增账号功能）主要面向与用户的注销账号功能（删除账号功能），并且清除该账号下所有的相关信息主要获取用户登录后，根据token以及相关的凭证获取相关的用户基本信息模型，作为系统全局的用户信息上下文。

在当前互联网服务时代，服务拆分成为主流，服务之间的远程调用变得越来越复杂，使得像本地调用一样简单的远程调用成了一个大问题。在这个背景下，Dubbo是一个具有高度可扩展性的开源RPC框架。该框架提供了Java、Golang等多种语言的SDK和独特的服务治理体验，可以提高开发人员的效率。Dubbo还支持用户实现流量拦截、定制化逻辑、选址等各种定制逻辑。在微服务架构中，Dubbo具备极为重要的地位，被广泛应用于各大互联网公司的微服务场景中。

是否准备就绪，现在是否可以开始工作。Pod的生命周期与服务调度息息相关，通过对 Kubernetes 官方探针的实现，能够使 Dubbo3 乃至整个应用的生命周期与 Pod 的生命周期，在 Pod 的整个生命周期中，影响到 Pod 的就只有健康检查这一部分, 我们可以通过配置 liveness probe（存活探针）和 readiness probe（可读性探针）来影响容器的生命周期。的 Service，注意这里的 service name 与项目中的 dubbo 应用名是一样的。

在运行之前，我们需要保障进行运行对应的Dubbo-Admin服务，可以参考 【Dubbo3终极特性】「流量治理体系」一文教你如何搭建Dubbo3的控制台服务Dubbo-Admin，进行搭建和运行启动Dubbo-Admin服务。可以使用标签路由对不同环境中的不同版本进行流量隔离，将秒杀订单流量或不同渠道订单流量路由到特殊环境，将正常的流量路由到日常环境。将服务提供者进行分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标。

properties字段指定的内容将会覆盖 Admin 镜像中application.properties 指定的默认配置，除了properties之外，还可以定制 Admin helm chart 定义的其他属性，这里是可供使用的完整参数。将 /the/host/path/containing/properties 替换为宿主机上包含 application.properties 文件的实际路径（必须是一个有效目录的绝对路径）。从仓库根目录切换到以下目录 deploy/helm/dubbo-admin。

*** @param userModel 入参请求对象* @param response 出参对应结果/*** @param response 出参对应结果* @return 请求参数对象/*** @param userModel 入参请求对象* @param response 出参对应结果/*** @param response 出参对应结果* @return 请求参数对象/*** @param userModel 入参请求对象。

注册中心：协调 Consumer 与 Provider 之间的地址注册与发现配置中心：存储Dubbo3启动阶段的全局配置，保证配置的跨环境共享与全局一致性。负责服务治理规则（路由规则、动态配置等）的存储与推送。元数据中心：接收Provider上报的服务接口元数据，为Admin等控制台提供运维能力（如：服务测试、接口文档等）。服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展。上图完整的描述了Dubbo3微服务组件与各个中心的交互过程。

在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。在这样的场景下，对 Dubbo3 的服务注册发现机制提出了两个要求： Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型，并确保这部分模型足够合理，以支持将地址的注册行为和存储委托给下层基础设施 Dubbo3 特有的业务接口同步机制，是 Dubbo3 需要保留的优势，需要在 Dubbo3 中定义的新地址模型之上，通过框架内的自有机制予以解决。

服务发现是微服务架构体系中最关键的组件之一。如果尝试着用手动的方式来给每一个客户端来配置所有服务提供者的服务列表是一件非常困难的事，而且也不利于 服务的动态扩缩容。对于Nacos服务进行了简单的介绍和部署后，我们就可以使用其作为我们的注册中心使用，Nacos 作为 Dubbo 生态系统中重要的注册中心实现，本文将会介绍如何进行 Dubbo 对接 Nacos 注册中心的工作。通过一些简单的注解，您可以快速来注册一个服务，并使用经过双十一考验的 Nacos 组件来作为大规模分布式系统的服务注册中心。

Apache Dubbo 是一款微服务开发框架，它提供了 RPC通信 与 微服务治理 两大关键能力。使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力， 同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。

基于 grpc 协议进行进一步扩展其中 Service-Version 跟 Service-Group 分别标识了 Dubbo 服务的 version 跟 group 信息，因为grpc的 path 申明了 service name 跟 method name，相比于 Dubbo 协议，缺少了version 跟 group 信息；Tracing-ID、Tracing-RPC-ID 用于全链路追踪能力，分别表示 tracing id 跟 span id 信息；

本节内容主要是针对于如何在Dubbo中适配日志框架并支持运行时动态切换使用的日志框架，首先前提是需要进行启动我们Dubbo服务的Qos服务，它主要用于作为我们的操作对应的日志切换的功能实现机制。日志框架适配，自 2.2.1 开始，dubbo 开始内置 log4j、slf4j、jcl、jdk 这些日志框架的适配，根据不同的实现，采用SPI模式进行实现对应的类，对适配器集合的方法所示。其他的类型暂时不展示了效果差不多的。官方文档说的这个命令：loggerInfo，其实本身再很多版本是不兼容的所以暂时不可用的。

【Dubbo3高级特性】「框架与服务」服务并发控制及集群负载均衡的实践指南（含扩展SPI）

上下文中存放的是当前调用过程中所需的环境信息。所有配置信息都将转换为URL的参数，参见schema配置参考手册中的对应URL参数一列。RpcContext是一个ThreadLocal的临时状态记录器，当接收到RPC请求，或发起RPC请求时，RpcContext的状态都会变化。比如：A 调B，B再调C。

上下文信息是RPC框架很重要的一个功能，使用RpcContext可以为单次调用指定不同配置。如分布式链路追踪场景，其实现原理就是在全链路的上下文中维护一个traceId，Consumer和Provider通过传递traceId来连接一次RPC调用，分别上报日志后可以在追踪系统中串联并展示完整的调用流程，这样可以更方便地发现异常，定位问题。

Dubbo3会提供一种新的线程池管理方式，用于隔离服务之间的线程池调用机制，主要用于服务提供者端进行实现服务资源隔离和容器隔离机制，最终的效果就是服务提供者内部的各个服务通过线程池隔离且互相独立，任何一个服务的线程池资源耗尽都不会影响其他正常服务，支持线程池可配置化，由用户手动指定。

服务端泛接口实现方式主要用于服务器端没有API接口及模型类元的情况，参数及返回值中的所有POJO均用Map表示，通常用于框架集成，比如：实现一个通用的远程服务框架，可通过实现RawTypeService接口处理所有服务请求。

参数验证功能是基于JSR303实现的，用户只需标识JSR303标准的验证annotation，并通过声明 filter 来实现验证。

建立内嵌是Zookeeper启动类 - EmbeddedZooKeeper

Dubbo3的服务容器是一个standalone的启动程序，因为后台服务不需要 Tomcat 或 JBoss 等 Web 容器的功能，如果硬要用 Web 容器去加载服务提供方，增加复杂性，也浪费资源。所以服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用 Web 容器去加载服务。

在Dubbo中发起异步调用机制，从而提高对应的服务的调用的吞吐能力和调用机制

推荐使用相关限流降级组件（如 Sentinel）以达到最佳体验，微服务治理/限流降级

【Dubbo3高级特性】「框架与服务」 Nacos作为注册中心-服务分组及服务分组聚合实现。

Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=“true”。通过check="false"关闭检查，比如，测试时，有些服务不关心，必须有一方先启动，或者针对于相关的dubbo3所对应的微服务利链路种形成了环路依赖或者相互引用关系。

内置的DubboNetty Server 和新引入的 gRPC 协议都提供了基于 TLS 的安全链路传输机制。