This is an automated email from the ASF dual-hosted git repository. wangxin pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/incubator-dubbo-website.git
The following commit(s) were added to refs/heads/asf-site by this push: new bd16b5c blog about new dubbo admin (#269) bd16b5c is described below commit bd16b5c308072500bc6aa85c29466e5c10ed64d1 Author: min <z82507...@gmail.com> AuthorDate: Wed Jan 30 14:03:16 2019 +0800 blog about new dubbo admin (#269) * blog about new dubbo admin * Fix misspelling * add service test blog * update blog.js * remove illegal character * change picture --- blog/zh-cn/dubbo-admin.md | 71 +++++++++++++++++ blog/zh-cn/service-test.md | 157 ++++++++++++++++++++++++++++++++++++++ img/blog/admin/appConfig.jpg | Bin 0 -> 158875 bytes img/blog/admin/complex.jpg | Bin 0 -> 231075 bytes img/blog/admin/conditionRoute.jpg | Bin 0 -> 143372 bytes img/blog/admin/config.jpg | Bin 0 -> 159676 bytes img/blog/admin/metadata.jpg | Bin 0 -> 220394 bytes img/blog/admin/metadata.png | Bin 0 -> 96953 bytes img/blog/admin/route.jpg | Bin 0 -> 176274 bytes img/blog/admin/test.jpg | Bin 0 -> 125324 bytes img/blog/admin/testFail.jpg | Bin 0 -> 226347 bytes img/blog/admin/testSearch.jpg | Bin 0 -> 91983 bytes img/blog/admin/testSuccess.jpg | Bin 0 -> 184130 bytes img/blog/admin/weight.jpg | Bin 0 -> 118044 bytes site_config/blog.js | 16 +++- 15 files changed, 243 insertions(+), 1 deletion(-) diff --git a/blog/zh-cn/dubbo-admin.md b/blog/zh-cn/dubbo-admin.md new file mode 100644 index 0000000..2c525cf --- /dev/null +++ b/blog/zh-cn/dubbo-admin.md @@ -0,0 +1,71 @@ +# 新版Dubbo Admin介绍 + +``` +Demo地址:http://47.91.207.147/#/service +github: https://github.com/apache/incubator-dubbo-ops +``` +Dubbo Admin之前的版本过于老旧,也长期疏于维护,因此在去年年中的时候,对该项目进行了一次重构,项目结构上的变化如下: +* 将后端框架从webx替换成spring boot +* 前端采用Vue和Vuetify.js作为开发框架 +* 移除velocity模板 +* 集成swagger,提供api管理功能 + +当前版本的Dubbo Admin包含了之前版本中的绝大部分功能,包括服务治理,服务查询等,同时支持了Dubbo2.7中服务治理的新特性。 + + +## 配置规范 +由于在Dubbo2.7中,配置中心和注册中心做了分离,并且增加了元数据中心,因此Dubbo Admin的配置方式也做了更新,`application.properties`中的配置如下: +```properties +admin.registry.address=zookeeper://127.0.0.1:2181 +admin.config-center=zookeeper://127.0.0.1:2181 +admin.metadata.address=zookeeper://127.0.0.1:2181 +``` +也可以和Dubbo2.7一样,在配置中心指定元数据和注册中心的地址,以zookeeper为例,配置的路径和内容如下: +```properties +# /dubbo/config/dubbo/dubbo.properties +dubbo.registry.address=zookeeper://127.0.0.1:2181 +dubbo.metadata-report.address=zookeeper://127.0.0.1:2181 +``` +配置中心里的地址会覆盖掉本地`application.properties`的配置 + +## 功能介绍 +功能上,主要延续了之前版本的功能,包括服务查询和服务治理,2.7版本在服务治理的功能上有了很大的改进,这些改进也大部分都会以Dubbo Admin作为入口来体现。 + +### 标签路由 +标签路由是Dubbo2.7引入的新功能,配置以应用作为维度,给不同的服务器打上不同名字的标签,配置如下图所示: +![tag](../../img/blog/admin/route.jpg) +调用的时候,客户端可以通过`setAttachment`的方式,来设置不同的标签名称,比如本例中,`setAttachment(tag1)`,客户端的选址范围就在如图所示的三台机器中,可以通过这种方式来实现流量隔离,灰度发布等功能。 + +### 应用级别的服务治理 +在Dubbo2.6及更早版本中,所有的服务治理规则都只针对服务粒度,如果要把某条规则作用到应用粒度上,需要为应用下的所有服务配合相同的规则,变更,删除的时候也需要对应的操作,这样的操作很不友好,因此Dubbo2.7版本中增加了应用粒度的服务治理操作,对于条件路由(包括黑白名单),动态配置(包括权重,负载均衡)都可以做应用级别的配置: +![condition](../../img/blog/admin/conditionRoute.jpg) +上图是条件路由的配置,可以按照应用名,服务名两个维度来填写,也可以按照这两个维度来查询。 + + +![weight](../../img/blog/admin/weight.jpg) +条件路由,标签路由和动态配置都采用了`yaml`格式的文本编写,其他的规则配置还是采用了表单的形式。 + +#### 关于兼容性 +Dubbo2.6到Dubbo2.7,服务治理发生了比较大的变化,Dubbo Admin兼容两个版本的用法: +* 对于服务级别的配置,会按照Dubbo2.6(URL)和Dubbo2.7(配置文件)两种格式进行写入,保证Dubbo2.6的客户端能够正确读取,解析规则 +* 对于应用级别的配置,包括标签路由,只会按照Dubbo2.7的格式进行写入,因为Dubbo2.6无此功能,不需要做向前兼容。 +* Dubbo Admin只会按照Dubbo2.7的格式进行配置读取,因此,所有在Dubbo Admin上做的配置都可以被读到,但是之前遗留的,Dubbo2.6格式的URL无法被读取。 +* 对于同一个应用或者服务,每种规则只能够配置一条,否则新的会覆盖旧的。 + +### 配置管理 +配置管理也是配合Dubbo2.7新增的功能,在Dubbo2.7中,增加了全局和应用维度的配置, +* 全局配置: +![config](../../img/blog/admin/config.jpg) +全局配置里可以指定注册中心,元数据中心的地址,服务端和客户端的超时时间等,这些配置在全局内生效。除了配置写入,也可以用来查看。如果使用zookeeper作为注册中心和元数据中心,还可以看到配置文件所在位置的目录结构。 +* 应用, 服务配置 +![appConfig](../../img/blog/admin/appConfig.jpg) +应用级别的配置可以为应用或者应用内的服务指定配置,在服务维度上,需要区分提供者和消费者。`dubbo.reference.{serviceName}`表示作为该服务消费者的配置,`dubbo.provider.{servcieName}`表示作为该服务提供者的配置。优先级服务 > 应用 > 全局。其中注册中心和元数据中心的地址,只能在全局配置中指定,这也是Dubbo2.7中推荐的使用方式。 + +### 元数据和服务测试 +元数据是Dubbo2.7中新引入的元素,主要的使用场景就在Dubbo Admin中,主要体现在两个地方: +* 服务详情展示: +![metadata](../../img/blog/admin/metadata.jpg) +跟之前版本相比,Dubbo2.7中增加了对服务方法完整签名的记录,因此服务详情中也增加了方法信息的详情,可以看到方法名,方法参数列表以及返回值信息。 +* 服务测试: +![test](../../img/blog/admin/test.jpg) +更重要的,元数据为服务测试提供了数据基础,可以在页面上调用真实的服务提供者,方便测试,也不需要为了调用服务去搭建一套Dubbo环境以及编写消费端代码。 \ No newline at end of file diff --git a/blog/zh-cn/service-test.md b/blog/zh-cn/service-test.md new file mode 100644 index 0000000..3f7000a --- /dev/null +++ b/blog/zh-cn/service-test.md @@ -0,0 +1,157 @@ +# Dubbo Admin服务测试功能 +基于Dubbo2.7的元数据,Dubbo Admin实现了服务测试功能,可以通过泛化调用,在控制台上调用真实的服务提供者 + +## 使用方式 +* 部署服务提供者: 可以在[这里](https://github.com/nzomkxia/dubbo-demo)下载demo,此工程基于spring boot,方便在IDE或者命令行启动,对于服务测试来说,只需要启动`dubbo-basic-provider`即可。 +* 服务查询: 完成服务端部署后,可以到Dubbo Admin的`服务测试`页面上查询对应的服务: +![testSearch](../../img/blog/admin/testSearch.jpg) +这里的信息和元数据类似,包含方法名,参数类型和返回值信息,点击右边的标签就可以进入服务测试页面 +* 服务测试: +![testSuccess](../../img/blog/admin/testSuccess.jpg) +服务测试页面包含了两个json编辑器,参数类型的信息都是以json格式保存,这里需要填入对应的参数值(本例中数类型时`String`),填写完成后点击`执行`即可对服务端发起调用,调用结果展示在右边的编辑器中,如果调用失败,会显示详细的失败原因,下面来看一下调用失败的例子: +![testFail](../../img/blog/admin/testFail.jpg) +本例中,先关掉Dubbo服务提供者的进程,再执行服务测试,可以看到返回的结果是`找不到服务提供者`的异常。和普通调用一样,业务和框架的异常都会返回在结果中,方便业务排查。 +* 复合类型参数 +考虑`UserService`中的以下方法和类型: +```java +//org.apache.dubbo.demo.api.UserService +Result getUser(String name, UserInfoDO userInfoDO); +``` +```java +public class UserInfoDO { + private int id; + private LocationDO locationDO; + private DepartmentDO departmentDO; + + @Override + public String toString() { + return "UserInfoDO{" + + "id=" + id + + ", locationDO=" + locationDO.toString() + + ", departmentDO=" + departmentDO.toString() + + '}'; + } +} +``` + +```java +public class DepartmentDO { + + private String departName; + private LocationDO departLocation; + + @Override + public String toString() { + return "DepartmentDO{" + + "departName='" + departName + '\'' + + ", departLocation=" + departLocation.toString() + + '}'; + } +} +``` + +```java +public class LocationDO { + private String address; + private int postNum; + + @Override + public String toString() { + return "LocationDO{" + + "address='" + address + '\'' + + ", postNum=" + postNum + + '}'; + } +} +``` +参数是比较复杂的符合类型参数,服务测试的时候,会逐层展开填写每一个field的值,如下图所示: +![complex](../../img/blog/admin/complex.jpg) +同样可以调用成功并且返回结果 + +## 原理:数据来源 +服务测试中,最重要的就是完整的方法签名信息,和参数的类型信息,有了这些信息才能够一步步填入每个参数的值,拼装出完整的服务消费者。在Dubbo2.7中,新增了元数据中心,Dubbo Admin的方法签名和参数类型信息就是从这里来的: +![medatada](../../img/blog/admin/metadata.png) +如图所示,服务端在运行的时候会将服务的元数据信息注册到元数据中心,格式如下: +```json +{ + ... + "methods": [ + { + "name": "sayHello", + "parameterTypes": [ + "org.apache.dubbo.demo.model.User" + ], + "returnType": "org.apache.dubbo.demo.model.Result" + }, + ... + ], + "types": [ + { + "type": "char" + }, + { + "type": "long" + }, + { + "type": "org.apache.dubbo.demo.model.Result", + "properties": { + "msg": { + "type": "java.lang.String", + "properties": { + "value": { + "type": "char[]" + }, + "hash": { + "type": "int" + } + } + }, + "userName": { + "type": "java.lang.String", + "properties": { + "value": { + "type": "char[]" + }, + "hash": { + "type": "int" + } + } + } + } + }, + { + "type": "org.apache.dubbo.demo.model.User", + "properties": { + "id": { + "type": "java.lang.Long", + "properties": { + "value": { + "type": "long" + } + } + }, + "username": { + "type": "java.lang.Sring", + "properties": { + "value": { + "type": "char[]" + }, + "hash": { + "type": "int" + } + } + } + } + }, + ... + ] +} +``` +与服务测试相关的就是`methods`和`types`所包含的方法和类型信息,Dubbo Admin根据这些信息,将参数渲染到服务测试页面的Json Editor中,由用户来输入每个参数,每个成员变量的值。 + + +## 原理: 泛化调用 +有了参数类型,下一个问题就是怎么能够调用到服务端,在传统的Dubbo RPC调用中,客户端需要依赖服务端的API jar包(参考前文demo中的[dubbo-basic-consumer](https://github.com/nzomkxia/dubbo-demo/tree/master/dubbo-basic-consumer)),这对于Dubbo Admin来说不太可能,因为服务的上下线是动态的,Dubbo Admin无法动态增加jar包依赖,因此需要用到Dubbo中的**泛化调用**,指的是在没有服务端API接口的情况下,客户端直接通过 `GenericService` 接口来发起服务调用,返回值中的数据对象都用Map来表示。泛化调用在服务端不需要做特殊处理,只需要客户端发起即可。 + +## 总结和展望 +本文简单介绍了服务测试的用法和原理,后续会进一步针对该功能进行增强,比如处理抽象类的参数类型,支持从json文件导入参数值,支持对参数值的保存等等,方便对服务接口进行回归测试。 \ No newline at end of file diff --git a/img/blog/admin/appConfig.jpg b/img/blog/admin/appConfig.jpg new file mode 100644 index 0000000..9fc7004 Binary files /dev/null and b/img/blog/admin/appConfig.jpg differ diff --git a/img/blog/admin/complex.jpg b/img/blog/admin/complex.jpg new file mode 100644 index 0000000..b64bd31 Binary files /dev/null and b/img/blog/admin/complex.jpg differ diff --git a/img/blog/admin/conditionRoute.jpg b/img/blog/admin/conditionRoute.jpg new file mode 100644 index 0000000..a670683 Binary files /dev/null and b/img/blog/admin/conditionRoute.jpg differ diff --git a/img/blog/admin/config.jpg b/img/blog/admin/config.jpg new file mode 100644 index 0000000..9cbf439 Binary files /dev/null and b/img/blog/admin/config.jpg differ diff --git a/img/blog/admin/metadata.jpg b/img/blog/admin/metadata.jpg new file mode 100644 index 0000000..76e7d0d Binary files /dev/null and b/img/blog/admin/metadata.jpg differ diff --git a/img/blog/admin/metadata.png b/img/blog/admin/metadata.png new file mode 100644 index 0000000..505e79a Binary files /dev/null and b/img/blog/admin/metadata.png differ diff --git a/img/blog/admin/route.jpg b/img/blog/admin/route.jpg new file mode 100644 index 0000000..afd7796 Binary files /dev/null and b/img/blog/admin/route.jpg differ diff --git a/img/blog/admin/test.jpg b/img/blog/admin/test.jpg new file mode 100644 index 0000000..f57be49 Binary files /dev/null and b/img/blog/admin/test.jpg differ diff --git a/img/blog/admin/testFail.jpg b/img/blog/admin/testFail.jpg new file mode 100644 index 0000000..dcc38d3 Binary files /dev/null and b/img/blog/admin/testFail.jpg differ diff --git a/img/blog/admin/testSearch.jpg b/img/blog/admin/testSearch.jpg new file mode 100644 index 0000000..1c57a5b Binary files /dev/null and b/img/blog/admin/testSearch.jpg differ diff --git a/img/blog/admin/testSuccess.jpg b/img/blog/admin/testSuccess.jpg new file mode 100644 index 0000000..f45ea41 Binary files /dev/null and b/img/blog/admin/testSuccess.jpg differ diff --git a/img/blog/admin/weight.jpg b/img/blog/admin/weight.jpg new file mode 100644 index 0000000..3e6ad1b Binary files /dev/null and b/img/blog/admin/weight.jpg differ diff --git a/site_config/blog.js b/site_config/blog.js index 505d04b..b5df028 100644 --- a/site_config/blog.js +++ b/site_config/blog.js @@ -164,6 +164,20 @@ export default { postsTitle: '所有文章', list: [ { + title: 'Dubbo Admin服务测试介绍', + author: '@nzomkxia', + dateStr: 'Jan 29th, 2019', + desc: '本文介绍了新版本的Dubbo Admin的服务测试功能', + link: '/zh-cn/blog/service-test.html', + }, + { + title: '新版本Dubbo Admin介绍', + author: '@nzomkxia', + dateStr: 'Jan 28th, 2019', + desc: '本文介绍了新版本的Dubbo Admin的设计和功能', + link: '/zh-cn/blog/dubbo-admin.html', + }, + { title: '如何使用Fescar保证Dubbo微服务间的一致性', author: '@slievrly', dateStr: 'Jan 17th, 2019', @@ -191,7 +205,7 @@ export default { desc: '本文介绍 Dubbo 如何整合注册中心 Nacos,包括 Nacos 控制台使用', link: '/zh-cn/blog/dubbo-registry-nacos-integration.html', }, - { + { title: 'Dubbo协议详解', author: '@authorlove', dateStr: 'Jan 2nd, 2019',