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