surging 微服務引擎 2.0 會有多少驚喜？

     surging 微服務引擎從2017年6月至今已經有兩年的時間，這兩年時間有多家公司使用surging 服務引擎，而且有公司搭建了CI/CD，而且使用了k8s 集羣，這裏我能夠說下幾家公司的服務搭建狀況，公司名不便透露，咱們就以字母標識

A公司:40多個服務提供者，一個服務提供者擴展了四五個實例節點，只使用了3臺服務器，而且搭建了CI/CD, k8s 集羣，使用suring 構建航空行業信息化系統

B公司：房產系統，門店2300多家，峯值在線使用人數1700，平均保持在1200人左右，有21個服務提供者，每一個服務提供者有70-80個服務，使用了三臺服務器，部署在linux環境，而且使用docker, 數據庫使用sql server 2017,運行了1年，產生的數據已經超過1億

C公司：業務中臺，服務2000多個，移動端和web端都已經上線，至今沒產生什麼問題，反應挺穩定

D公司：物聯網，服務提供者1個，服務器1臺8核支持了3.5W+, 部署在window 環境

....

以上是瞭解比較詳細的一些數據，還有不少公司都採用了surging，還有一些公司採用surging 作二次開發，有了這些市場的證實，說明surging 做爲服務引擎是及格的，可爲各行業公司快速研發投入市場提供了可靠的解決方案。

那談了這麼多surging又是怎麼樣定義微服務這個邊界的？

微服務應該是粒度最小的功能業務模塊，針對於行業解決方案，集成相應的service host,而針對於業務須要一些中間件來輔助，好比緩存中間件，eventbus中間件（消息中間件），數據儲存中間件,而各個服務又能夠互相經過rpc進行可靠性通訊。

如下是surging 服務引擎的調用鏈

 

 

 

 從以上調用能夠看出surging 能夠支持多行業的解決方案，經過協議Mqtt、ws、http服務主機生成服務提供者,  在服務啓動的時候服務A、服務B、服務C、服務D的ServiceRoute 會註冊到註冊中心,而A,B,C,D若是不是部署在同一個服務提供者中就須要經過RPC進行通訊，而RPC提供了服務發現 和服務治理功能從而保證了通訊之間，可靠性，可用性和可擴展性。

 

那麼新版本surging 又有多少新的功能，多少驚喜呢？

1.靈活配置RoutePath

針對於RoutePath作了一次優化，能夠經過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("{參數名}")] 
        Task<string> GetUserName(int id);
    }

 

經過以上設置，GetUserName 生成的routepath是/api/user/getusername/{id}, 而後咱們能夠經過引用swagger組件來測試服務是否調用成功，具體效果以下

 

或者也能夠用postman進行訪問，具體效果以下圖

2.擴展Dns 協議服務主機

 因dotnetty沒有dns 組件，擴展了基於dotnetty 的dns 編解碼,支持tcp,udp協議, 但僅支持PTR、OPT記錄類型。

引擎擴展了Dns 協議服務主機組件，包含了如下功能

一、Domain Name 解析
二、支持模塊化Domain Name 解析自定義擴展
3.、支持引擎模塊的集羣化域名解析

那麼咱們能夠按照如下方式把dns 集成到引擎中

一、須要經過nuget包引用Surging.Core.DNS或者經過指定目錄Components進行掃描裝載，再經過如下配置RootDnsAddress

  "Dns": {
    "RootDnsAddress": "192.168.1.1",
    "QueryTimeout": 1000
  }

 2. dns服務接口，須要繼承IServiceKey

   [ServiceBundle("Dns/{Service}")]
     public interface IDnsService : IServiceKey
    {
    }

 3. dns業務模塊須要繼承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服務主機地址，解析域名規則爲 前綴.(XX.XX.XX).後綴, 前綴會解析爲key，以結合基於key作哈希一致性負載算法， (XX.XX.XX)會解析成routepath, 後綴不解析能夠隨便取名。如下是經過nslookup命令進行測試

 3.擴展Udp 協議服務主機

須要按照如下方式把Udp集成到引擎中

一、須要經過nuget包引用Surging.Core.Protocol.Udp或者經過指定目錄Components進行掃描裝載，再經過如下代碼編寫Udp Service

配置udp端口

{  
"Surging": {
    "Ports": {
      "HttpPort": "${HttpPort}|280",
      "WSPort": "${WSPort}|96",
      "MQTTPort": "${MQTTPort}|97",
      "UdpPort": "${UdpPort}|95"
    }
  }
}

udp服務接口，須要繼承IServiceKey

    [ServiceBundle("Udp/{Service}")]
    public interface IUdpService : IServiceKey
    {
    }

udp業務模塊須要繼承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 格式分發到ws 服務，再經過http://127.0.0.1:280/JSMpeg.html查看ws 推送的共享桌面

如下是推送的高清視頻，有多是播放器緩衝的問題，推送的視頻流解析的不是很清楚

 4.擴展基於netty 的ws 協議服務主機

引擎擴展了netty 的ws協議服務主機組件，包含了如下功能

1.支持基於webscoket 的Open、Error、nMessage、Close方法的封裝

2.支持消息的發送和廣播

須要按照如下方式把Udp集成到引擎中

一、須要經過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業務模塊須要繼承WSBehavior，ws服務主機才能進行加載

 

    public class MediaService : WSBehavior, IMediaService
    {
        public   Task Push(IEnumerable<byte> data)
        {
              this..Broadcast(data.ToArray());
              return Task.CompletedTask;
        }
    }

 

5. 多註冊中心集羣支持

能夠經過設置多註冊中心進行服務註冊，配有健康檢查和負載均衡，註冊中心地址以，隔開，具體按照如下進行配置

  "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"
  }

如下查看如下界面，就說明配置成功

6，擴展支持ABP 組件

 ABP 組件在.NET使用者仍是比較多，ABP是一套業務封裝快速開發框架，大多數使用者都是使用abp 架設單體應用和垂直應用SOA服務，那麼使用微服務，必然須要用到ABP的組件，那麼對於一些組件能夠集成到surging 引擎中來，

其中經過引入Surging.Core.Abp組件，就能裝載ABP組件。那麼有多少ABP組件能夠引入到引擎，這個等後面的章節會講到。

7.  擴展關卡組件

surging 外層只能經過網關進行訪問，這樣破壞了組件引擎化思想，後面會考慮擴展關卡組件，以代替網關的路由轉發、鑑權，具體設想會有如下功能

1. 支持AppSecret，能支持第三方調用

2.支持jwt來實現鑑權功能

3. 經過業務模塊生成服務聚合服務提供者，服務聚合無需註冊到註冊中心

4.支持SSL配置

8. 擴展支持Reactive Extensions（Rx）響應式編程

 計劃是surging 能支持響應式編程，擴展支持Reactive Extensions, 具體實現哪些功能，還須要考慮

總結

針對.NET還有不少不少人對於微服務這個概念模擬兩可，不少人分不清微服務的邊界，那麼對於這種狀況，大家能夠花點時間研究下surging 或者看下其它語言是如何定義這個邊界的，也但願.NET同僚們能分清正確的微服務系統的架設，也但願.NET 在微服務迎頭遇上，能給公司帶來一套穩定高效的解決方案。