dubbo接口管理工具（dubbo接口自动化）

网友投稿 424 2023-01-22


本篇文章给大家谈谈dubbo接口管理工具，以及dubbo接口自动化对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享dubbo接口管理工具的知识，其中也会对dubbo接口自动化进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

Dubbo高性能网关--Flurry介绍

从架构的角度来看dubbo接口管理工具，API网关暴露http接口服务,其本身不涉及业务逻辑,只负责包括请求路由、负载均衡、权限验证、流量控制、缓存等等功能。其定位类似于Nginx请求转发、但功能要多于Nginx,背后连接了成百上千个后台服务，这些服务协议可能是rest的，也可能是rpc协议等等。

网关的定位决定了它生来就需要高性能、高效率的。网关对接着成百上千的服务接口,承受者高并发的业务需求，因此我们对其性能要求严苛，其基本功能如下:

Flurry是云集自研的一款轻量级、异步流式化、针对Dubbo的高性能API网关。与业界大多数网关不同的是，flurry自己实现了 http与dubbo协议互转的流式化的dubbo-json协议，可高性能、低内存要求的对http和dubbo协议进行转换。除此之外，其基于 netty作为服务容器，提供服务元数据模型等等都是非常具有特点的。下面我们将详细介绍 flurry的特性:

Flurry 网关请求响应基于Netty线程模型,后者是实现了Reactive,反应式模式规范的,其设计就是来榨干CPU的，可以大幅提升单机请求响应的处理能力。
最终,Flurry通过使用Netty线程模型和NIO通讯协议实现了HTTP请求和响应的异步化。

每一次http请求最终都会由Netty的一个Client Handler来处理,其最终以异步模式请求后台服务，并返回一个CompletableFuture,当有结果返回时才会将结果返回给前端。
见下面一段例子:

有了服务元数据,我们就可以不必需要服务的API包,并能够清晰的知道整个服务API的定义。
这在Dubbo服务Mock调用、服务测试、文档站点、流式调用等等场景下都可以发挥抢到的作用。

小孩子才分对错，成年人只看利弊。额外引入一个元数据生成机制，必然带来运维成本、理解成本、迁移成本等问题，那么它具备怎样的价值，来说服大家选择它呢dubbo接口管理工具？上面我们介绍元数据中心时已经提到了服务测试、服务 MOCK 等场景，这一节我们重点探讨一下元数据中心的价值和使用场景。

那么，Dubbo服务元数据能够利用到哪些场景呢？下面我们来详细描述。

Http请求，数据通过JSON传输,其格式严格按照接口POJO属性。返回结果再序列化为Json返回前端。现在大多数开源的网关,在dubbo协议适配上都是采用的泛化模式来做到协议转换的,这其中就包括 Soul 等。

JsonString - JSONObject(Map) - Binary

将JSON 字符串转换为 JSON 对象模型（JSONObject),此处通过第三方JSON映射框架（如Google的Gson, 阿里的FastJSON等)来做,然后将Map通过Hessian2 协议序列化为Binaray。

自定义的Dubbo-Json协议参考了 dapeng-soa 的流式解析协议的思想,详情请参考: dapeng-json

针对上述泛化模式转换Dubbo协议的缺点,我们在flurry-core 中的 Dubbo-Json 序列化协议做到了这点，下面我们来讲解它是如何高效率的完成JsonString到 dubbo hessian2 序列化buffer的转换的。

虽然大部分情况下的JSON请求、返回都是数据量较小的场景, 但作为平台框架, 也需要应对更大的JSON请求和返回, 比如1M、甚至10M. 在这些场景下, 如果需要占用大量的内存, 那么势必导致巨大的内存需求, 同时引发频繁的GC操作, 也会联动影响到整个网关的性能.

Dubbo-Json参考了XML SAX API的设计思想, 创造性的引入了JSON Stream API, 采用流式的处理模式, 实现JSON 对 hessian2 的双向转换, 无论数据包有多大, 都可以在一定固定的内存规模内完成.

流式协议，顾名思义就是边读取边解析,数据像水流一样在管道中流动,边流动边解析，最后，数据解析完成时，转换成的hessian协议也已全部写入到了buffer中。
这里处理的核心思想就是实现自己的Json to hessian2 buffer 的语法和此法解析器,并配合前文提及的元数据功能,对每一个读取到的json片段通过元数据获取到其类型，并使用 hessian2协议以具体的方式写入到buffer中。

首先我们来看看JSON的结构. 一个典型的JSON结构体如下

其对应Java POJO 自然就是上述三个属性,这里我们略过。下面是POJO生成的元数据信息

相比XML而言，JSON数据类型比较简单, 由 Object/Array/Value/String/Boolean/Number 等元素组成, 每种元素都由特定的字符开和结束. 例如Object以'{'以及'}'这两个字符标志开始以及结束, 而Array是'['以及']'. 简单的结构使得JSON比较容易组装以及解析。

如图,我们可以清晰的了解JSON的结构,那么对上述JSON进行解析时,当每一次解析到一个基本类型时,先解析到key，然后根据key到元数据信息中获取到其value类型，然后直接根据对应类型的hessian2序列化器将其序列化到byte buffer中。

当解析到引用类型,即 Struct类型时,我们将其压入栈顶,就和java方法调用压栈操作类似。
通过上面的步骤一步一步，每解析一步Json，就将其写入到byte buffer中，最终完成整个流式的解析过程。

拿上面json为例:

总结:

上述整个请求和响应,网关处理如下:

请求和响应中没有像泛化模式中的中间对象转换，直接一步到位，没有多余的临时对象占用内存,没有多余的数据转换,整个过程像在管道中流式的进行。

如上图所示，flurry dubbo网关不必依赖任何dubbo接口API包,而是直接通过获取服务元数据、并通过dubbo-json流式协议来调用后端服务。其本身不会耦合业务逻辑。

硬件部署与参数调整

对基于Y-Hessian的 异步化、流式转换的Yunji Dubbo API网关进行性能压测，了解它的处理能力极限是多少，这样有便于我们推断其上线后的处理能力,以及对照现有的Tomcat接入层模式的优势,能够节约多少资源，做到心里有数。

性能测试场景

上述场景均使用wrk在压测节点上进行5～10min钟的压测，压测参数基本为12线程256连接或者512连接，以发挥最大的压测性能。

flurry集Dubbo网关、异步、流式、高性能于一身,其目标就是替代一些以tomcat作为dubbo消费者的接入层，以更少的节点获得更多的性能提升，节约硬件资源和软件资源。

后续在flurry的基础上，将实现鉴权管理、流量控制、限流熔断、监控收集等等功能

Flurry : 基于Dubbo服务的高性能、异步、流式网关
dubbo-json : 自定义的Dubbo协议，支持流式序列化模式，为flurry网关序列化/反序列化组件。
Yunji-doc-site : 与元数据集成相关的项目,以及文档站点

dapeng-soa : Dapeng-soa 是一个轻量级、高性能的微服务框架，构建在Netty以及定制的精简版Thrift之上。 同时，从Thrift IDL文件自动生成的服务元数据信息是本框架的一个重要特性，很多其它重要特性都依赖于服务元数据信息。 最后，作为一站式的微服务解决方案，Dapeng-soa还提供了一系列的脚手架工具以支持用户快速的搭建微服务系统
dapeng-json :dapeng-json协议介绍

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 , BaseCommand.class 为指令扩展点会根据uri 传入的指令，来指定要处理的类，优点类似策略模式。我们看看offline 是怎么处理的

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

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

Dubbo+ZooKeeper实现分布式服务搭建

Dubbo就是资源调度和治理中心的管理工具。

remote- provider.xmldubbo接口管理工具，将服务引用部分放在服务消费方remote-consumer.xml。
并在提供方增加暴露服务配置<dubbo:servicedubbo接口管理工具，在消费方增加引用服务配置<dubbo:reference。

安装环境：

tar -zxvf zookeeper-3.4.6.tar.gz
第四步：进入zookeeper-3.4.6目录，创建data文件夹。
第五步：把zoo_sample.cfg改名为zoo.cfg

dubbo原理和机制

dubbo原理和机制：应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

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

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

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

扩展资料

在大规模dubbo服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。

(1)当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。

并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。

(2)当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。

(3)接着，服务的调用量越来越大，服务的容量问题就暴露出来。

为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。

其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

Zookeeper在hadoop中充当什么角色，dubbo使用zookeeper又是干嘛的？

Apache Zookeeper是我最近遇到的最酷的技术，我是在研究Solr Cloud功能的时候发现的。Solr的分布式计算让我印象深刻。你只要开启一个新的实例就能自动在Solr Cloud中找到。它会将自己分派到某个分片中，并确定出自己是一个Leader（源）还是一个副本。不一会儿，你就可以在你的那些服务器上查询到了。即便某些服务器宕机了也可以继续工作。非常动态、聪明、酷。
将运行多个应用程序作为一个逻辑程序并不是什么新玩意。事实上，我在几年前就已写过类似的软件。这种架构比较让人迷惑，使用起来也费劲。为此Apache Zookeeper提供了一套工具用于管理这种软件。
为什么叫Zoo？“因为要协调的分布式系统是一个动物园”。
在本篇文章中，我将说明如何使用PHP安装和集成Apache ZooKeeper。我们将通过service来协调各个独立的PHP脚本，并让它们同意某个成为Leader（所以称作Leader选举）。当Leader退出（或崩溃）时，worker可检测到并再选出新的leader。
ZooKeeper是一个中性化的Service，用于管理配置信息、命名、提供分布式同步，还能组合Service。所有这些种类的Service都会在分布式应用程序中使用到。每次编写这些Service都会涉及大量的修bug和竞争情况。正因为这种编写这些Service有一定难度，所以通常都会忽视它们，这就使得在应用程序有变化时变得难以管理应用程序。即使处理得当，实现这些服务的不同方法也会使得部署应用程序变得难以管理。
虽然ZooKeeper是一个Java应用程序，但C也可以使用。这里就有个PHP的扩展，由Andrei Zmievski在2009创建并维护。你可以从PECL中下载，或从GitHub中直接获取PHP-ZooKeeper。
要使用该扩展你首先要安装ZooKeeper。可以从官方网站下载。
$ tar zxfv zookeeper-3.4.5.tar.gz
$ cd zookeeper-3.4.5/src/c
$ ./configure --prefix=/usr/
$ make
$ sudo make install
这样就会安装ZooKeeper的库和头文件。现在准备编译PHP扩展。
$ cd$ git clone https://github.com/andreiz/php-zookeeper.git
$ cd php-zookeeper
$ phpize
$ ./configure
$ make
$ sudo make install
将“zookeeper.so”添加到PHP配置中。
$ vim /etc/php5/cli/conf.d/20-zookeeper.ini
因为我不需要运行在web服务环境下，所以这里我只编辑了CLI的配置。将下面的行复制到ini文件中。
extension=zookeeper.so
使用如下命令来确定扩展是否已起作用。
$ php -m | grep zookeeper
zookeeper
现在是时候运行ZooKeeper了。目前唯一还没有做的是配置。创建一个用于存放所有service数据的目录。
$ mkdir /home/you-account/zoo
$ cd$ cd zookeeper-3.4.5/
$ cp conf/zoo_sample.cfg conf/zoo.cfg
$ vim conf/zoo.cfg
找到名为“dataDir”的属性，将其指向“/home/you-account/zoo”目录。
$ bin/zkServer.sh start
$ bin/zkCli.sh -server 127.0.0.1:2181[zk: 127.0.0.1:2181(CONNECTED) 14] create /test 1
Created /test[zk: 127.0.0.1:2181(CONNECTED) 19] ls /[test, zookeeper]
此时，你已成功连到了ZooKeeper，并创建了一个名为“/test”的znode（稍后我们会用到）。ZooKeeper以树形结构保存数据。这很类似于文件系统，但“文件夹”（译者注：这里指非最底层的节点）又和文件很像。znode是ZooKeeper保存的实体。Node（节点）的说法很容易被混淆，所以为了避免混淆这里使用了znode。
因为我们稍后还会使用，所以这里我们让客户端保持连接状态。开启一个新窗口，并创建一个zookeeperdemo1.php文件。
<?php
class ZookeeperDemo extends Zookeeper {
public function watcher( $i, $type, $key ) {
echo "Insider Watcher\n";
// Watcher gets consumed so we need to set a new one
$this-get( '/test', array($this, 'watcher' ) );
}
}
$zoo = new ZookeeperDemo('127.0.0.1:2181');$zoo-get( '/test', array($zoo, 'watcher' ) );
while( true ) {
echo '.';
sleep(2);}
现在运行该脚本。
$ php zookeeperdemo1.php
此处应该会每隔2秒产生一个点。现在切换到ZooKeeper客户端，并更新“/test”值。
[zk: 127.0.0.1:2181(CONNECTED) 20] set /test foo
这样就会静默触发PHP脚本中的“Insider Watcher”消息。怎么会这样的？
ZooKeeper提供了可以绑定在znode的监视器。如果监视器发现znode发生变化，该service会立即通知所有相关的客户端。这就是PHP脚本如何知道变化的。Zookeeper::get方法的第二个参数是回调函数。当触发事件时，监视器会被消费掉，所以我们需要在回调函数中再次设置监视器。
现在你可以准备创建分布式应用程序了。其中的挑战是让这些独立的程序决定哪个（是leader）协调它们的工作，以及哪些（是worker）需要执行。这个处理过程叫做leader选举，在ZooKeeper Recipes and Solutions你能看到相关的实现方法。
这里简单来说就是，每个处理（或服务器）紧盯着相邻的那个处理（或服务器）。如果一个已被监视的处理（也即Leader）退出或者崩溃了，监视程序就会查找其相邻（此时最老）的那个处理作为Leader。
在真实的应用程序中，leader会给worker分配任务、监控进程和保存结果。这里为了简化，我跳过了这些部分。
创建一个新的PHP文件，命名为worker.php。
<?php
class Worker extends Zookeeper {
const CONTAINER = '/cluster';
protected $acl = array(
array(
'perms' = Zookeeper::PERM_ALL,
'scheme' = 'world',
'id' = 'anyone' ) );
private $isLeader = false;
private $znode;
public function __construct( $host = '', $watcher_cb = null, $recv_timeout = 10000 ) {
parent::__construct( $host, $watcher_cb, $recv_timeout );
}
public function register() {
if( ! $this-exists( self::CONTAINER ) ) {
$this-create( self::CONTAINER, null, $this-acl );
}
$this-znode = $this-create( self::CONTAINER . '/w-',
null,
$this-acl,
Zookeeper::EPHEMERAL | Zookeeper::SEQUENCE );
$this-znode = str_replace( self::CONTAINER .'/', '', $this-znode );
printf( "I'm registred as: %s\n", $this-znode );
$watching = $this-watchPrevious();
if( $watching == $this-znode ) {
printf( "Nobody here, I'm the leader\n" );
$this-setLeader( true ); }
else {
printf( "I'm watching %s\n", $watching );
}
}
public function watchPrevious() {
$workers = $this-getChildren( self::CONTAINER );
sort( $workers );
$size = sizeof( $workers );
for( $i = 0 ; $i < $size ; $i++ ) {
if( $this-znode == $workers[ $i ] ) {
if( $i 0 ) {
$this-get( self::CONTAINER . '/' . $workers[ $i - 1 ], array( $this, 'watchNode' ) );
return $workers[ $i - 1 ];
}
return $workers[ $i ];
}
}
throw new Exception( sprintf( "Something went very wrong! I can't find myself: %s/%s",
self::CONTAINER,
$this-znode ) );
}
public function watchNode( $i, $type, $name ) {
$watching = $this-watchPrevious();
if( $watching == $this-znode ) {
printf( "I'm the new leader!\n" );
$this-setLeader( true );
}
else {
printf( "Now I'm watching %s\n", $watching ); }
}
public function isLeader() {
return $this-isLeader;
}
public function setLeader($flag) {
$this-isLeader = $flag;
}
public function run() {
$this-register();
while( true ) {
if( $this-isLeader() ) {
$this-doLeaderJob();
}
else {
$this-doWorkerJob();
}
sleep( 2 );
}
}
public function doLeaderJob() {
echo "Leading\n";
}
public function doWorkerJob() {
echo "Working\n";
}
}
$worker = new Worker( '127.0.0.1:2181' );$worker-run();
打开至少3个终端，在每个终端中运行以下脚本：
# term1
$ php worker.php
I'm registred as: w-0000000001Nobody here, I'm the leader
Leading
# term2
$ php worker.php
I'm registred as: w-0000000002I'm watching w-0000000001
Working
# term3
$ php worker.php
I'm registred as: w-0000000003I'm watching w-0000000002
Working
现在模拟Leader崩溃的情形。使用Ctrl+c或其他方法退出第一个脚本。刚开始不会有任何变化，worker可以继续工作。后来，ZooKeeper会发现超时，并选举出新的leader。
虽然这些脚本很容易理解，但是还是有必要对已使用的Zookeeper标志作注释。
$this-znode = $this-create( self::CONTAINER . '/w-', null, $this-acl, Zookeeper::EPHEMERAL | Zookeeper::SEQUENCE );
每个znode都是EPHEMERAL和SEQUENCE的。
EPHEMRAL代表当客户端失去连接时移除该znode。这就是为何PHP脚本会知道超时。SEQUENCE代表在每个znode名称后添加顺序标识。我们通过这些唯一标识来标记worker。
在PHP部分还有些问题要注意。该扩展目前还是beta版，如果使用不当很容易发生segmentation fault。比如，不能传入普通函数作为回调函数，传入的必须为方法。我希望更多PHP社区的同仁可以看到Apache ZooKeeper的好，同时该扩展也会获得更多的支持。
ZooKeeper是一个强大的软件，拥有简洁和简单的API。由于文档和示例都做的很好，任何人都可以很容易的编写分布式软件。让我们开始吧，这会很有趣的。

用于计算依赖关系 是什么意思

dubbo 简单的provider与consumer实现

项目用到了rest+dubbo的架构，使得服务可以在一个点死掉之后用其它点的服务来代替响应。

这里先实现一个最简单的dubbo消费者与提供者。官网说明:http://dubbo.io/

首先需要解决的是dubbo的各种依赖，最简单的实现方法即将github上dubbo项目在本地maven install一遍，所需要的各种相关依赖就到本地库中了。但是貌似dubbo项目已经没更新了。

最基本的我们需要一个zookeeper，这个主要是用来调度各种服务，管理注册中心，对zookeeper的稳定性有比较高的要求。我们写两个最简单的工程，来模拟Provider和Consume。

其中，TestDubbo用来提供服务，是Provider。而TestDubbo2用来消费服务，是Consumer。嗯，随便取的工程名。

在Provider中需要一个配置文件，将所提供的服务，以及zk注册中心的地址，以及Dubbo的服务在哪个端口暴露出来。其中有接口TestApi以及它的实

现TestApiImpl，以及一个启动项Start。

而之后的消费者工程，只需要配置好Consumer.xml文件，而后将其加载启动即可调用到Provider所发布的服务。

pom中需要依赖dubbo,zk相关的依赖。由于引入了父工程中的某些版本，所以此处有些版本需要读者自行添加。服务提供者的Start采用最原始

的ClassPathXmlApplicationContext来加载配置文件，加载之后start(),为了让提供者保持这个状态，可以加一行System.in.read();同理适用于服

务消费者。

准备工作完成后，启动zk，启动服务提供者，再启动服务消费者，消费者使用该接口，打印出（TestApiImpl中的实现即打印一行字符，以检验提

供与消费的效果）对应的字符就算OK。在其对应的可视化工具dubbo-admin中可以观察到更多详细的信息。（下个小节介绍）。

<dependency
           <groupIdcom.alibaba</groupId
           <artifactIddubbo</artifactId
           <version2.8.4</version
       </dependency
       <dependency
           <groupIdorg.apache.zookeeper</groupId
           <artifactIdzookeeper</artifactId
           <version3.4.6</version
       </dependency
       <dependency
           <groupIdorg.apache.zookeeper</groupId
           <artifactIdzookeeper</artifactId
       </dependency
       <dependency
           <groupIdcom.101tec</groupId
           <artifactIdzkclient</artifactId
       </dependency
       
       <dependency
           <groupIdcom.github.sgroschupf</groupId
           <artifactIdzkclient</artifactId
           <version0.1</version
       </dependency
       <dependency
           <groupIdorg.springframework</groupId
           <artifactIdspring-context</artifactId
       </dependency
       <dependency
           <groupIdorg.javassist</groupId
           <artifactIdjavassist</artifactId
           <version3.15.0-GA</version
       </dependency

Provider.xml：

<?xml version="1.0" encoding="UTF-8"?
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd
"
<!-- 具体的实现bean --
<bean id="testApiImpl" class="com.changjiang.test.TestApiImpl" /
<!-- 提供方应用信息，用于计算依赖关系 --
<dubbo:application name="xixi_provider" /
<!-- 使用multicast广播注册中心暴露服务地址 <dubbo:registry address="multicast://224.5.6.7:1234"
/ --
<!-- 使用zookeeper注册中心暴露服务地址 --
<dubbo:registry address="zookeeper://127.0.0.1:2181" /
<!-- 用dubbo协议在20880端口暴露服务 --
<dubbo:protocol name="dubbo" port="20880" /
<!-- 声明需要暴露的服务接口 --
<dubbo:service interface="com.changjiang.test.TestApi"
ref="testApiImpl" /
</beans

Consumer.xml：

<?xml version="1.0" encoding="UTF-8"?
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://code.alibabatech.com/schema/dubbo
http://code.alibabatech.com/schema/dubbo/dubbo.xsd
"
<!-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 --
<dubbo:application name="hehe_consumer" /
<!-- 使用zookeeper注册中心暴露服务地址 --
<!-- <dubbo:registry address="multicast://224.5.6.7:1234" / --
<dubbo:registry address="zookeeper://127.0.0.1:2181" /
<!-- 生成远程服务代理，可以像使用本地bean一样使用demoService --
<dubbo:reference id="testApiImpl" interface="com.changjiang.test.TestApi" /
</beans  

在Consumer中加载了Consumer.xml之后，直接调用Provider提供的服务，而后直接使用接口，可以检测提供-注册-消费是否成功。

public class App {
public static void main(String[] args) throws IOException {
ClassPathXmlApplicationContext ac = new ClassPathXmlApplicationContext(new String[] { "Consumer.xml" });
ac.start();
TestApi ta = (TestApi) ac.getBean("testApiImpl");
ta.hello();
System.in.read();
}
}

运行结果（没有添加log4j.properties）

=================

另一种启动方式，在src/main/resources目录下设置dubbo.properties文件

dubbo.spring.config=classpath*:spring/*.xml

而后将Provider.xml放到指定目录src/main/resources/spring下

启动时只需要在Main中：

public class App {
public static void main(String[] args) {
/**
* 模拟启动
*/
//        ClassPathXmlApplicationContext ac = new ClassPathXmlApplicationContext(new String[] { "spring/Provider.xml" });
//        ac.start();
//        try {
//            System.in.read();
//        } catch (IOException e) {
//            // TODO Auto-generated catch block
//            e.printStackTrace();
//        }
/**
* main启动
*/
String[] ars = {};
com.alibaba.dubbo.container.Main.main(ars);
}
}

关于dubbo接口管理工具和dubbo接口自动化的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 dubbo接口管理工具的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于dubbo接口自动化、dubbo接口管理工具的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。

标签：接口管理工具 接口管理 API网关 接口自动化 Mock
上一篇:Java正则表达式验证固定电话号码符合性
下一篇:webuploader+springmvc实现图片上传功能
相关文章

 发表评论

暂时没有评论，来抢沙发吧~