surging如何使用swagger 组件测试业务模块

发布日期:2019-03-18

1、前言

   微服务架构概念的提出已经有非常长一段时间了,但在近期几年却开始频繁地出现,大家都着手升级成微服务架构,使用着各种技术,大家认为框架有服务治理就是微服务,实现单一协议的服务调用,微服务虽然没有太明确的定义,但是我认为服务应该是一个或者一组相对较小且独立的功能单元,可以自由组合拆分,针对于业务模块的 CRUD 可以注册为服务,而每个服务都是高度自治的,从开发,部署都是独立,而每个服务只做单一功能,利用领域驱动设计去更好的拆分成粒度更小的模块,而框架本身提供了多种协议,如wstcphttpmqttrtprtcp 并且有各种功能的中间件,所开发的业务模块,通过框架可以适用于各种业务场景,让开发人员专注于业务开发这才是真正意义上的微服务。

 以上只是谈下微服务,避免一些人走向误区。而这篇文章主要介绍下surging如何使用swagger 组件测试业务模块

surging源码下载

2、如何使用swagger

 

surging 集成了Kestrel组件并且扩展swagger组件,以下介绍下如何使用swagger组件

xml文档文件设置

针对于 swagger 需要生成 schema,那么需要加载接口模块的xml文档文件,可以通过项目-属性-生成-xml文档文件 进行设置,如下图所示

通过以上设置,如果扫描加载业务模块,可以使用dotnet publish -c release 生成模块文件,如下图所示

 

文件配置

使用swagger ,如果使用官方提供的surging 引擎的话,就需要开启Kestrel组件,如以下配置所示

"Surging": { "Ip": "${Surging_Server_IP}|127.0.0.1" "WatchInterval": 30 "Port": "${Surging_Server_Port}|98" "MappingIp": "${Mapping_ip}" "MappingPort": "${Mapping_Port}" "Token": "true" "MaxConcurrentRequests": 20 "ExecutionTimeoutInMilliseconds": 30000 "Protocol": "${Protocol}|None" //Http、Tcp、None "RootPath": "${RootPath}|D:userapp" "Ports": { "HttpPort": "${HttpPort}|280" "WSPort": "${WSPort}|96" } "RequestCacheEnabled": false "Packages": [ { "TypeName": "EnginePartModule" "Using": "${UseEngineParts}|DotNettyModuleNLogModuleMessagePackModuleConsulModuleKestrelHttpModuleWSProtocolModuleEventBusRabbitMQModuleCachingModule" } ] }

以下是配置swagger,如果不添加以下配置,可以禁用swagger

"Swagger": { "Version": "${SwaggerVersion}|V1" // "127.0.0.1:8500" "Title": "${SwaggerTitle}|Surging Demo" "Description": "${SwaggerDes}|surging demo" "Contact": { "Name": "API Support" "Url": "https://github.com/dotnetcore/surging" "Email": "fanliang1@hotmail.com" } "License": { "Name": "MIT" "Url": "https://github.com/dotnetcore/surging/blob/master/LICENSE" } }

 

 通过以上设置,就可以通过http://127.0.0.1:280/swagger进行访问,效果如下图所示

测试上传文件

测试下载文件

 Post 测试

GET 测试

 

五、总结

通过swagger 引擎组件能够生成业务接口文档,能够更好的和团队进行协作,而surging计划是去网关中心化,会扩展"关卡(stage)"引擎组件以代替网关,同时也会扩展更多的通信协议,也欢迎大家扩展引擎组件,让生态更强大。