surging如何使用swagger 元件測試業務模組

fanly11發表於2018-10-07

1、前言

微服務架構概念的提出已經有非常長一段時間了，但在近期幾年卻開始頻繁地出現，大家都著手升級成微服務架構，使用著各種技術，大家認為框架有服務治理就是微服務，實現單一協議的服務呼叫，微服務雖然沒有太明確的定義，但是我認為服務應該是一個或者一組相對較小且獨立的功能單元，可以自由組合拆分，針對於業務模組的 CRUD 可以註冊為服務，而每個服務都是高度自治的，從開發，部署都是獨立，而每個服務只做單一功能，利用領域驅動設計去更好的拆分成粒度更小的模組，而框架本身提供了多種協議，如ws,tcp,http,mqtt,rtp,rtcp, 並且有各種功能的中介軟體，所開發的業務模組，通過框架可以適用於各種業務場景，讓開發人員專注於業務開發這才是真正意義上的微服務。

以上只是談下微服務，避免一些人走向誤區。而這篇文章主要介紹下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}|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": "fanliang1@hotmail.com"
    },
    "License": {
      "Name": "MIT",
      "Url": "https://github.com/dotnetcore/surging/blob/master/LICENSE"
    }
  }

通過以上設定，就可以通過http://127.0.0.1:280/swagger進行訪問，效果如下圖所示