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

1、前言

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

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

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}|dotnettymodule;nlogmodule;messagepackmodule;consulmodule;kestrelhttpmodule;wsprotocolmodule;eventbusrabbitmqmodule;cachingmodule;"
      }
    ]
  }

以下是配置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": "[e-mail]"
    },
    "license": {
      "name": "mit",
      "url": "https://github.com/dotnetcore/surging/blob/master/license"
    }
  }

 

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

测试上传文件

测试下载文件

 post 测试

get 测试

 

五、总结

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