微服務架構概念的提出已經有很是長一段時間了,但在近期幾年卻開始頻繁地出現,你們都着手升級成微服務架構,使用着各類技術,你們認爲框架有服務治理就是微服務,實現單一協議的服務調用,微服務雖然沒有太明確的定義,可是我認爲服務應該是一個或者一組相對較小且獨立的功能單元,能夠自由組合拆分,針對於業務模塊的 CRUD 能夠註冊爲服務,而每一個服務都是高度自治的,從開發,部署都是獨立,而每一個服務只作單一功能,利用領域驅動設計去更好的拆分紅粒度更小的模塊,而框架自己提供了多種協議,如ws,tcp,http,mqtt,rtp,rtcp, 而且有各類功能的中間件,所開發的業務模塊,經過框架能夠適用於各類業務場景,讓開發人員專一於業務開發這纔是真正意義上的微服務。javascript
以上只是談下微服務,避免一些人走向誤區。而這篇文章主要介紹下surging如何使用swagger 組件測試業務模塊
html
surging源碼下載java
surging 集成了Kestrel組件而且擴展swagger組件,如下介紹下如何使用swagger組件git
針對於 swagger 須要生成 schema,那麼須要加載接口模塊的xml文檔文件,能夠經過項目-屬性-生成-xml文檔文件 進行設置,以下圖所示github
經過以上設置,若是掃描加載業務模塊,可使用dotnet publish -c release 生成模塊文件,以下圖所示架構
使用swagger ,若是使用官方提供的surging 引擎的話,就須要開啓Kestrel組件,如如下配置所示app
"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框架
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
"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進行訪問,效果以下圖所示tcp
經過swagger 引擎組件可以生成業務接口文檔,可以更好的和團隊進行協做,而surging計劃是去網關中心化,會擴展'關卡(stage)'引擎組件以代替網關,同時也會擴展更多的通訊協議,也歡迎你們擴展引擎組件,讓生態更強大。
微服務