dubbo系列之-qos运维-2021-01-17

dubbo自带的运维工具dubbo-admin，主要面向开发人员去管理服务，携带很多管理、控制等功能，然后在dubbo新版本又推出了qos（Quality of Service），主要面向运维管理。我在之前公司有用到次功能，在和k8s结合时，通过http发送主动下线功能（下线注册，但不下线服务），等到流量完全停止，在下线pod，实现平滑发布。

怎么样去管理？

dubbo通过 QosProtocolWrapper 这个包装器实现qos发布，QosProtocolWrapper 是Protocol 三大包装器(filter,listener,qos)其中之一，默认会开启qos功能，可以配置关闭

qos 主要提供了ls,online,offline,help 功能，具体说，只有三种，上下线服务和查看服务

我们跟读一下源码，看看qos 服务的启动，请求处理，上下线等。

在dubbo 生产者服务暴露和消费者消费引用的过程中都会启动qos，并且qos 通过cas来保证一个jvm只启动一次。

同样qos 功能也是通过netty启动server，处理类指定为 QosProcessHandler，这个handler实现了netty的 ByteToMessageDecoder 可以将网络流中的字节解码为对象

channelActive() 方法含有为连接建立的时候回调，这里有个定时任务500ms，会刷一个美体的dubbo给客户端，我们验证下。

我们看看 QosProcessHandler#decode 是怎么处理请求的。

上面方法讲究，先读取第一个字节判断请求是http 还是 tcp，为什么用第一个字节呢，我们知道http信息头开始为 GET /xx 或者 POST /xx，第一个字符要么G要么P，判断为http 则用http编解码，如果为tcp 则用 LineBasedFrameDecoder 编解码，这是一个换行分割读取的解码方式遇到(\n,\r)[就是telnet时候的回车]时，就截断，如果为tcp 还会添加一个 IdleStateHandler 作为心跳检测，最后处理指令的handler 为 TelnetProcessHandler。

先演示下效果

为了便于观察我们这里看http的处理指令的方式 HttpProcessHandler。

HttpCommandDecoder decode (msg)会将get或者post请求携带的路径等返回给 commandContext , BaseCommandclass 为指令扩展点会根据uri 传入的指令，来指定要处理的类，优点类似策略模式。我们看看offline 是怎么处理的

可以传入服务，默认所有服务，18行中从注册工厂中获取服务对应的注册中心，然后调用注册中心的unregister() 最后层层调用到zk客户端的delete()方法来，删除zk临时节点。

qos 的功能和简单，之所以单独拿出来讲是因为这里涵盖了我们web开发中常提到的“http服务器”概念，通过netty 启动服务，然后处理请求。

不是。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

扩展资料

dubbo服务调用机制：

1、透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入，对现有的代码几乎零改动。

2、软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

3、服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

4、Duibbo 对Spring 做了Schema 扩展支持，对于使用spring的项目来说非常的方便，对应用的Api几乎是没有入侵的，只需要在spring中配置启动即可。

--Dubbo

        大家在平时开发和测试阶段定位一些bug的时候，需要调用本地启动的dubbo服务debug。如果与服务器、其他同事共用一个注册中心的话，就会调用到别人的服务或者自己本地的服务被别人调用到，造成一些调用失败或者其他异常。

       解决如上问题有大致几种解决方案：

       1、dubbo直连；

       2、dubbo group 服务分组；

       3、dubbo version 版本过渡；

        在开发以及测试环境下，经常需要绕过注册中心，只测试指定服务的提供者，这时候可  以使用点对点直连的方式。点对点直连方式，将以服务接口为单位，忽略注册中心的提供者表。A接口配置点对点，不影响B接口从注册中心获取列表。

      消费者应用，在注入的提供者api上添加 @Reference(version = "100", url = "dubbo://ip:port") 即可！

      此时，如果提供者不希望本地的服务被别人调用到，设置：dubboregistryregister=false,默认值是true。该属性含义： 是否向此注册中心注册服务，如果设为false，将只订阅，不注册。

        通过服务分组实现环境隔离，不用绕过注册中心，大家可以共用一个注册中心。服务注册分组，使跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。

      场景：服务A希望调用到本地的服务B(此时，B服务正常的调用远程服务C)，而不是远程服务B。

      本地服务B的配置设置如下：                                                                                                          //应用全局配置                                                                              dubboprovidergroup=local-group   //设置本地B所提供的dubbo服务均在local-group分组下如图：

       //针对某个Api进行配置

      也可以针对某个api单独做分组，例如：@Service(version = "100",group = "local-group")服务A：在注入的B dubbo服务的api上加 @Reference(version = "100", group = "local-group")  即可。

      服务分组的几个属性解释：

1、dubboregistrygroup=local-group 

          该值自行定义，确保唯一即可，该属性含义：服务注册分组，跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。 该配置不推荐配置，配置之后服务在dubbo admin上默认无法查看，也调用不到该服 务。不同环境，通过zookeeper做数据隔离。

            

      2、dubboprovidergroup=local-group  

       该属性含义：服务分组，当一个接口有多个实现，可以用分组区分。该配置使当前服务所有的提供者都在local-group下。也可以只针对某个api做配置@Service(version ="100",group ="local-group")；推荐后者！

     3、dubboconsumergroup=local-group 

           该配置使当前服务只消费local-group分组下的提供者，建议只针对某个api进行配置即可，例如： @Reference(version ="100", group ="local-group")

            当一个接口的实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。dubboproviderversion=10 //服务版本， 建议使用两位数字版本，如：10 ，通常在接口不兼容时版本号才需要升级。

 dubboconsumerversion=10 //消费10版本的提供者

 可全局配置，亦可配置到某个api服务上，此时优先级大于全局配置。

 提供者服务示例：@Service(version ="your version")

 消费者api服务示例： @Reference(version ="your version")

近期由于搭建公司整套测试环境中使用Docker 容器化部署Dubbo一直出现找不到服务提供者

经过两天断断续续的摸索以及资料（说到这理要落泪了）的查询该问题得意解决这就是本次要扯的内容。

本次 dubbo 服务 是以docker-compose进行服务编排部署，服务者与消费者也在同一个Java 工程目录下

当我们服务者工程开启的时候会在Nacos中服务列表中产生新的一项接口其内容是这样的，根据下方的可以很清楚的看到IP及端口是不是有点似曾相识的感觉呢，特别是20880端口！

又经历了一资料的查询之后，我发现20800端口并没有被我映射出来。于是我把服务提供者配置文件改这样：

消费者配置文件改成这样

终于在我本地以及不同的服务器之间可以正常运行了！

其实如果不在测试环境上遇到这些问题以后在生产环境上也同样会遇到，我们能做的就是在问题到来之前做一定的知识储备避免一些常见的坑。

Protocol 还有一个实现分支是 AbstractProxyProtocol，如下图所示：

从图中我们可以看到：gRPC、HTTP、WebService、Hessian、Thrift 等协议对应的 Protocol 实现，都是继承自 AbstractProxyProtocol 抽象类。

目前互联网的技术栈百花齐放，很多公司会使用 Nodejs、Python、Rails、Go 等语言来开发 一些 Web 端应用，同时又有很多服务会使用 Java 技术栈实现，这就出现了大量的跨语言调用的需求。Dubbo 作为一个 RPC 框架，自然也希望能实现这种跨语言的调用，目前 Dubbo 中使用“HTTP 协议 + JSON-RPC”的方式来达到这一目的，其中 HTTP 协议和 JSON 都是天然跨语言的标准，在各种语言中都有成熟的类库。

下面就重点来分析 Dubbo 对 HTTP 协议的支持。首先，会介绍 JSON-RPC 的基础，并通过一个示例，快速入门，然后介绍 Dubbo 中 HttpProtocol 的具体实现，也就是如何将 HTTP 协议与 JSON-RPC 结合使用，实现跨语言调用的效果。

Dubbo 中支持的 HTTP 协议实际上使用的是 JSON-RPC 协议。

JSON-RPC 是基于 JSON 的跨语言远程调用协议。Dubbo 中的 dubbo-rpc-xml、dubbo-rpc-webservice 等模块支持的 XML-RPC、WebService 等协议与 JSON-RPC 一样，都是基于文本的协议，只不过 JSON 的格式比 XML、WebService 等格式更加简洁、紧凑。与 Dubbo 协议、Hessian 协议等二进制协议相比，JSON-RPC 更便于调试和实现，可见 JSON-RPC 协议还是一款非常优秀的远程调用协议。

在 Java 体系中，有很多成熟的 JSON-RPC 框架，例如 jsonrpc4j、jpoxy 等，其中，jsonrpc4j 本身体积小巧，使用方便，既可以独立使用，也可以与 Spring 无缝集合，非常适合基于 Spring 的项目。

下面先来看看 JSON-RPC 协议中请求的基本格式：

JSON-RPC请求中各个字段的含义如下：

在 JSON-RPC 的服务端收到调用请求之后，会查找到相应的方法并进行调用，然后将方法的返回值整理成如下格式，返回给客户端：

JSON-RPC响应中各个字段的含义如下：

Dubbo 使用 jsonrpc4j 库来实现 JSON-RPC 协议，下面使用 jsonrpc4j 编写一个简单的 JSON-RPC 服务端示例程序和客户端示例程序，并通过这两个示例程序说明 jsonrpc4j 最基本的使用方式。

首先，需要创建服务端和客户端都需要的 domain 类以及服务接口。先来创建一个 User 类，作为最基础的数据对象：

接下来创建一个 UserService 接口作为服务接口，其中定义了 5 个方法，分别用来创建 User、查询 User 以及相关信息、删除 User：

UserServiceImpl 是 UserService 接口的实现类，其中使用一个 ArrayList 集合管理 User 对象，具体实现如下：

整个用户管理业务的核心大致如此。下面我们来看服务端如何将 UserService 与 JSON-RPC 关联起来。

首先，创建 RpcServlet 类，它是 HttpServlet 的子类，并覆盖了 HttpServlet 的 service() 方法。我们知道，HttpServlet 在收到 GET 和 POST 请求的时候，最终会调用其 service() 方法进行处理；HttpServlet 还会将 HTTP 请求和响应封装成 HttpServletRequest 和 HttpServletResponse 传入 service() 方法之中。这里的 RpcServlet 实现之中会创建一个 JsonRpcServer，并在 service() 方法中将 HTTP 请求委托给 JsonRpcServer 进行处理：

最后，创建一个 JsonRpcServer 作为服务端的入口类，在其 main() 方法中会启动 Jetty 作为 Web 容器，具体实现如下：

这里使用到的 webxml 配置文件如下：

完成服务端的编写之后，下面再继续编写 JSON-RPC 的客户端。在 JsonRpcClient 中会创建 JsonRpcHttpClient，并通过 JsonRpcHttpClient 请求服务端：

在 AbstractProxyProtocol 的 export() 方法中，首先会根据 URL 检查 exporterMap 缓存，如果查询失败，则会调用 ProxyFactorygetProxy() 方法将 Invoker 封装成业务接口的代理类，然后通过子类实现的 doExport() 方法启动底层的 ProxyProtocolServer，并初始化 serverMap 集合。具体实现如下：

在 HttpProtocol 的 doExport() 方法中，与前面介绍的 DubboProtocol 的实现类似，也要启动一个 RemotingServer。为了适配各种 HTTP 服务器，例如，Tomcat、Jetty 等，Dubbo 在 Transporter 层抽象出了一个 HttpServer 的接口。

dubbo-remoting-http 模块的入口是 HttpBinder 接口，它被 @SPI 注解修饰，是一个扩展接口，有三个扩展实现，默认使用的是 JettyHttpBinder 实现，如下图所示：

HttpBinder 接口中的 bind() 方法被 @Adaptive 注解修饰，会根据 URL 的 server 参数选择相应的 HttpBinder 扩展实现，不同 HttpBinder 实现返回相应的 HttpServer 实现。HttpServer 的继承关系如下图所示：

这里以 JettyHttpServer 为例简单介绍 HttpServer 的实现，在 JettyHttpServer 中会初始化 Jetty Server，其中会配置 Jetty Server 使用到的线程池以及处理请求 Handler：

可以看到 JettyHttpServer 收到的全部请求将委托给 DispatcherServlet 这个 HttpServlet 实现，而 DispatcherServlet 的 service() 方法会把请求委托给对应接端口的 HttpHandler 处理：

了解了 Dubbo 对 HttpServer 的抽象以及 JettyHttpServer 的核心之后，回到 HttpProtocol 中的 doExport() 方法继续分析。

在 HttpProtocoldoExport() 方法中会通过 HttpBinder 创建前面介绍的 HttpServer 对象，并记录到 serverMap 中用来接收 HTTP 请求。这里初始化 HttpServer 以及处理请求用到的 HttpHandler 是 HttpProtocol 中的内部类，在其他使用 HTTP 协议作为基础的 RPC 协议实现中也有类似的 HttpHandler 实现类，如下图所示：

在 HttpProtocolInternalHandler 中的 handle() 实现中，会将请求委托给 skeletonMap 集合中记录的 JsonRpcServer 对象进行处理：

skeletonMap 集合中的 JsonRpcServer 是与 HttpServer 对象一同在 doExport() 方法中初始化的。最后，我们来看 HttpProtocoldoExport() 方法的实现：

介绍完 HttpProtocol 暴露服务的相关实现之后，下面再来看 HttpProtocol 中引用服务相关的方法实现，即 protocolBindinRefer() 方法实现。该方法首先通过 doRefer() 方法创建业务接口的代理，这里会使用到 jsonrpc4j 库中的 JsonProxyFactoryBean 与 Spring 进行集成，在其 afterPropertiesSet() 方法中会创建 JsonRpcHttpClient 对象：

下面来看 doRefer() 方法的具体实现：

在 AbstractProxyProtocolprotocolBindingRefer() 方法中，会通过 ProxyFactorygetInvoker() 方法将 doRefer() 方法返回的代理对象转换成 Invoker 对象，并记录到 Invokers 集合中，具体实现如下：

本文重点介绍了在 Dubbo 中如何通过“HTTP 协议 + JSON-RPC”的方案实现跨语言调用。首先介绍了 JSON-RPC 中请求和响应的基本格式，以及其实现库 jsonrpc4j 的基本使用；接下来我们还详细介绍了 Dubbo 中 AbstractProxyProtocol、HttpProtocol 等核心类，剖析了 Dubbo 中“HTTP 协议 + JSON-RPC”方案的落地实现。

个人觉的两者都不会被淘汰，但是在未来分布式微服务解决方案中或者架构中，springCloud会占主导地位。

springCloud：

1springCloud提供了完成的分布式解决方案，基础解决方案以及组件比较健全，而且最近几年围绕springCloud边缘服务组件越来越多，例如：nacos。

2springCloud是基于springboot的，spring的使用部署太方便了。

dubbo：

1dubbo更多解决的是服务间的调用，也就是服务通讯协议rpc，也会是dubbo没有完整的分布式解决方案基础设施。例如：注册中心需要借助Zookeper，链路追踪：zipkin。

要说Dubbo，算是Spring Cloud的一个子集好了,大致相当于Spring Cloud里的 Eureka + Feign + 1/2Hystrix另外

现在大公司也在慢慢想springCloud服务过度，还有面试中文springCloud问题越来阅读，dubbo越来越少。

dubbo生态圈没有spring cloud好，会被先淘汰掉。现有架构都会优先选择Spring cloud，毕竟使用起来更简单一点。

微服务现在是一阵风而已，实际来说，很多系统不适用，综合算下来，微服务成本比原来大多了。不是所有系统都是互联网，都是弹缩性很强。有的系统就是固定数据量，稳定运行，可能几个大一点服务器就足够了。

真正需要微服务的不会像现在看到的那么多。

慢慢沉淀，估计会把一些不需要的改回去，套壳的改回去。

如果简化方式，感觉dubbo这种轻便的有优势，开发运维都简单。或者替代品也是轻便为主。

剩的可能真的需要微服务，一般都是中等规模以上的，或者巨头，一般都有自己的内部框架。这种用也得全套完善的。

它们都淘汰也是早晚的事[捂脸]毕竟是java闭源。随着service mesh的兴起，isito的落地并于k8s的无缝融合，一切像基础设施下沉[呲牙]

事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。

以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式：

第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。

第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。

第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。

第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，信贷系统，核心系统等。

因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。

个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。

分层是计算机科学永恒的主题，service mesh是微服务的未来，这样看来这两个以后都会被取代，只有spring boot能够继续存活。

这是两个作用和使用场景不同的框架，目前的情况来看都不会被淘汰。

springcloud用于微服务，dubbo用于服务治理，各有各的适用场景。

在国外springcloud使用的多，在国内dubbo使用的多。

springcloud由国外的spring团队开发维护，热度和可靠性不用多说，dubbo由国内的阿里巴巴开发，现交由Apache孵化器，可靠性也很高。

Spring cloud是当前主流的微服务架构，轻便，插件式的设计理念很赢得当前开发及企业的青睐，在很多方面优于dubbo的架构设计，我认为dubbo最终会被淘汰，但短时间内不会，因为很多金融机构之前很多系统用的是dubbo架构，金融机构在短时间内考虑系统和业务的稳定性不会立刻就更新换代

dubbo

对内rpc，对外http，dubbo效率比httpclient高很多