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 協議服務主機組件，包含了以下功能

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

   [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集成到引擎中

1、需要通過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集成到引擎中

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業務模塊需要繼承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 在微服務迎頭趕上，能給公司帶來一套穩定高效的解決方案。