surging 微服務引擎從2017年6月至今已經(jīng)有兩年的時間，這兩年時間有多家公司使用surging 服務引擎，并且有公司搭建了CI/CD，并且使用了k8s 集群，這里我可以說下幾家公司的服務搭建情況，公司名不便透露，我們就以字母標識
A公司:40多個服務提供者，一個服務提供者擴展了四五個實例節(jié)點，只使用了3臺服務器，并且搭建了CI/CD, k8s 集群，使用suring 構(gòu)建航空行業(yè)信息化系統(tǒng)
B公司：房產(chǎn)系統(tǒng)，門店2300多家，峰值在線使用人數(shù)1700，平均保持在1200人左右，有21個服務提供者，每個服務提供者有70-80個服務，使用了三臺服務器，部署在linux環(huán)境，并且使用docker, 數(shù)據(jù)庫使用sql server 2017,運行了1年，產(chǎn)生的數(shù)據(jù)已經(jīng)超過1億
C公司：業(yè)務中臺，服務2000多個，移動端和web端都已經(jīng)上線，至今沒產(chǎn)生什么問題，反應挺穩(wěn)定
D公司：物聯(lián)網(wǎng)，服務提供者1個，服務器1臺8核支持了3.5W+, 部署在window 環(huán)境
....
以上是了解比較詳細的一些數(shù)據(jù)，還有很多公司都采用了surging，還有一些公司采用surging 做二次開發(fā)，有了這些市場的證明，說明surging 作為服務引擎是及格的，可為各行業(yè)公司快速研發(fā)投入市場提供了可靠的解決方案。
那談了這么多surging又是怎么樣定義微服務這個邊界的？
微服務應該是粒度最小的功能業(yè)務模塊，針對于行業(yè)解決方案，集成相應的service host,而針對于業(yè)務需要一些中間件來輔助，比如緩存中間件，eventbus中間件（消息中間件），數(shù)據(jù)儲存中間件,而各個服務又可以互相通過rpc進行可靠性通信。
以下是surging 服務引擎的調(diào)用鏈
從以上調(diào)用可以看出surging 可以支持多行業(yè)的解決方案，通過協(xié)議Mqtt、ws、http服務主機生成服務提供者, 在服務啟動的時候服務A、服務B、服務C、服務D的ServiceRoute 會注冊到注冊中心,而A,B,C,D如果不是部署在同一個服務提供者中就需要通過RPC進行通信，而RPC提供了服務發(fā)現(xiàn) 和服務治理功能從而保證了通信之間，可靠性，可用性和可擴展性。
那么新版本surging 又有多少新的功能，多少驚喜呢？
針對于RoutePath做了一次優(yōu)化，可以通過ServiceBundle設置RoutePath, 也可以通過 ServiceRoute進行設置，具體參考以下代碼
[ServiceBundle("api/{Service}")] //[ServiceBundle("api/{Service}/{Method}")] //[ServiceBundle("api/{Service}/{Method}/test")] //[ServiceBundle("api/{Service}/{Method}/test",false)] public interface IUserService: IServiceKey { /// <summary> /// 獲取用戶姓名 /// </summary> /// <param name="id">用戶編號</param> /// <returns></returns> [ServiceRoute("{id}")] //[ServiceRoute("{參數(shù)名}")] Task<string> GetUserName(int id); }
通過以上設置，GetUserName 生成的routepath是/api/user/getusername/{id}, 然后我們可以通過引用swagger組件來測試服務是否調(diào)用成功，具體效果如下
或者也可以用postman進行訪問，具體效果如下圖
因dotnetty沒有dns 組件，擴展了基于dotnetty 的dns 編解碼,支持tcp,udp協(xié)議, 但僅支持PTR、OPT記錄類型。
引擎擴展了Dns 協(xié)議服務主機組件，包含了以下功能
1、Domain Name 解析
2、支持模塊化Domain Name 解析自定義擴展
3.、支持引擎模塊的集群化域名解析
那么我們可以按照以下方式把dns 集成到引擎中
1、需要通過nuget包引用Surging.Core.DNS或者通過指定目錄Components進行掃描裝載，再通過以下配置RootDnsAddress
"Dns": { "RootDnsAddress": "192.168.1.1", "QueryTimeout": 1000 }
2. dns服務接口，需要繼承IServiceKey
1 2 3 4 | [ServiceBundle("Dns/{Service}")] public interface IDnsService : IServiceKey { } |
3. dns業(yè)務模塊需要繼承DnsBehavior，dns 服務主機才能進行加載
public class DnsService : DnsBehavior, IDnsService { public override Task<IPAddress> Resolve(string domainName) { if(domainName=="localhost") { return Task.FromResult<IPAddress>(IPAddress.Parse("127.0.0.1")); } return Task.FromResult<IPAddress>(null); } }
然后通用以上配置，然后指向部署的DNS服務主機地址，解析域名規(guī)則為 前綴.(XX.XX.XX).后綴, 前綴會解析為key，以結(jié)合基于key做哈希一致性負載算法， (XX.XX.XX)會解析成routepath, 后綴不解析可以隨便取名。以下是通過nslookup命令進行測試
需要按照以下方式把Udp集成到引擎中
1、需要通過nuget包引用Surging.Core.Protocol.Udp或者通過指定目錄Components進行掃描裝載，再通過以下代碼編寫Udp Service
配置udp端口
1 2 3 4 5 6 7 8 9 | { "Surging": { "Ports": { "HttpPort": "${HttpPort}|280", "WSPort": "${WSPort}|96", "MQTTPort": "${MQTTPort}|97", "UdpPort": "${UdpPort}|95" } }<br>} |
udp服務接口，需要繼承IServiceKey
1 2 3 4 | [ServiceBundle("Udp/{Service}")]public interface IUdpService : IServiceKey{} |
udp業(yè)務模塊需要繼承UdpBehavior，udp服務主機才能進行加載
public class UdpService : UdpBehavior, IDnsService { public override async Task<bool> Dispatch(IEnumerable<byte> bytes) { await this.GetService<IMediaService>().Push(bytes); return await Task.FromResult(true); } public override Task<bool> Dispatch(object message) { return Task.FromResult(true); } }
通過以上代碼，可以通過ffmpeg推流到Udp，再通過udp 推流MPEG-TS 格式分發(fā)到ws 服務，再通過http://127.0.0.1:280/JSMpeg.html查看ws 推送的共享桌面
以下是推送的高清視頻，有可能是播放器緩沖的問題，推送的視頻流解析的不是很清楚
引擎擴展了netty 的ws協(xié)議服務主機組件，包含了以下功能
1.支持基于webscoket 的Open、Error、nMessage、Close方法的封裝
2.支持消息的發(fā)送和廣播
需要按照以下方式把Udp集成到引擎中
1、需要通過nuget包引用Surging.Core.Protocol.Udp或者通過指定目錄Components進行掃描裝載，再通過以下代碼編寫Udp Service
配置ws端口
{ "Surging": { "Ports": { "HttpPort": "${HttpPort}|280", "WSPort": "${WSPort}|96", "MQTTPort": "${MQTTPort}|97", "UdpPort": "${UdpPort}|95" } }}ws服務接口，需要繼承IServiceKey
[ServiceBundle("Api/{Service}")] [BehaviorContract(Protocol = "media")] public interface IMediaService : IServiceKey { Task Push(IEnumerable<byte> data); }
ws業(yè)務模塊需要繼承WSBehavior，ws服務主機才能進行加載
public class MediaService : WSBehavior, IMediaService { public Task Push(IEnumerable<byte> data) { this..Broadcast(data.ToArray()); return Task.CompletedTask; } }
可以通過設置多注冊中心進行服務注冊，配有健康檢查和負載均衡，注冊中心地址以，隔開，具體按照以下進行配置
"Consul": { "ConnectionString": "${Register_Conn}|127.0.0.1:8500,127.0.0.1:9500", // "127.0.0.1:8500,127.0.0.1:9500", "SessionTimeout": "${Register_SessionTimeout}|50", "RoutePath": "${Register_RoutePath}", "ReloadOnChange": true, "EnableChildrenMonitor": false }
"Register": { "Provider": "Consul", "Address": "${Register_Conn}|127.0.0.1:8500,127.0.0.1:9500" }
以下查看以下界面，就說明配置成功
ABP 組件在.NET使用者還是比較多，ABP是一套業(yè)務封裝快速開發(fā)框架，大多數(shù)使用者都是使用abp 架設單體應用和垂直應用SOA服務，那么使用微服務，必然需要用到ABP的組件，那么對于一些組件可以集成到surging 引擎中來，
其中通過引入Surging.Core.Abp組件，就能裝載ABP組件。那么有多少ABP組件可以引入到引擎，這個等后面的章節(jié)會講到。
surging 外層只能通過網(wǎng)關進行訪問，這樣破壞了組件引擎化思想，后面會考慮擴展關卡組件，以代替網(wǎng)關的路由轉(zhuǎn)發(fā)、鑒權，具體設想會有以下功能
1. 支持AppSecret，能支持第三方調(diào)用
2.支持jwt來實現(xiàn)鑒權功能
3. 通過業(yè)務模塊生成服務聚合服務提供者，服務聚合無需注冊到注冊中心
4.支持SSL配置
計劃是surging 能支持響應式編程，擴展支持Reactive Extensions, 具體實現(xiàn)哪些功能，還需要考慮
針對.NET還有很多很多人對于微服務這個概念模擬兩可，很多人分不清微服務的邊界，那么對于這種情況，你們可以花點時間研究下surging 或者看下其它語言是如何定義這個邊界的，也希望.NET同僚們能分清正確的微服務系統(tǒng)的架設，也希望.NET 在微服務迎頭趕上，能給公司帶來一套穩(wěn)定高效的解決方案。
