談談surging引擎的tcp、http、ws協議和如何容器化部署

1、前言

           分佈式已經成爲了當前最熱門的話題，分佈式框架也百花齊放，羣雄逐鹿。從中心化服務治理框架，到去中心化分佈式服務框架，再到分佈式微服務引擎，這都是經過技術不斷積累改進而造成的結果。esb,網關，nginx網關 這些中心化服務治理框架如今都是各個公司比較主流的架構，而最近幾年你們炒的比較火的去中心化微服務框架，各個語言都有其表明做品，好比.NET就有orleans、akka.net,這些框架不言而喻都能從網上了解一二，可是針對於這些框架，是否是就知足公司的須要，就能搭建起整個平臺呢？

         能夠告訴你們，下一代框架應該稱爲分佈式微服務引擎，也能夠叫作服務網格，它應該是基礎設施引擎，加載驅動業務模塊服務，負責服務之間的可靠傳遞，提供了所需的網絡協議，而針對surging 服務引擎就是朝着這個思想前進，內部經過RPC進行調用，有一套完整的服務治理規則，提供了tcp、http、ws 協議，而且能夠支持容器化、可定製化引擎部署，下面咱們來看看是如何實現的。

2.服務引擎

服務引擎是用於處理服務與服務可靠通訊的專用基礎設施。而服務應該是獨立進行部署的，無需寄宿在其它框架當中，因爲服務之間的獨立性，業務團隊再也不須要操心服務治理相關的複雜度，全權交給服務引擎處理便可。針對每個服務實例，服務引擎都會在同一主機上一對一併行部署一個服務進程，實現該服務實例全部對外的網絡通信（參見下圖），藉助於良好的框架封裝，運維成本也能夠獲得有效的控制。

2.1 演化史

surging從無到有可分爲三個演化階段

第一個階段RPC服務治理框架，服務與服務之間通訊經過接口建立代理的方式進行訪問

第二個階段RPC服務治理框架+網關，服務與服務之間通訊經過接口建立代理或RoutePath進行訪問，外部經過網關進行調用

第三個階段服務引擎，服務再也不關心通信細節和通訊協議，通通交給引擎， 只須要關注業務的實現

2.2 架構

針對於surging如今提供了tcp、http、ws三種通訊協議，tcp、http協議是基於dotnetty，而ws是基於websocket-sharp的分支版本websocketcore(該版本支持.NET CORE)

而整個引擎的架構以下圖所示，經過對外的網絡通訊協議，能夠對接移動、web、物聯網應用，經過服務發現RPC遠程調用內部業務服務。

 

3.如何開發基於協議的業務模塊

3.1 基於http,tcp協議業務接口

繼承IServiceKey，而且都須要標識[ServiceBundle("Api/{Service}")]，代碼以下

?

1 2 3 4 5 6

[ServiceBundle( "api/{Service}" )] public interface IManagerService : IServiceKey {      [Command(Strategy = StrategyType.Injection, ShuntStrategy = AddressSelectorMode.HashAlgorithm, ExecutionTimeoutInMilliseconds = 2500, BreakerRequestVolumeThreshold = 3, Injection = @"return 1;" , RequestCacheEnabled = false )]      Task< string > SayHello( string name); }

 

3.2 基於ws協議業務接口

繼承IServiceKey，而且都須要標識[ServiceBundle("Api/{Service}")]，ws服務與服務之間的遠程調用，須要把負載分流設置爲哈希算法代碼以下

?

1 2 3 4 5 6

[ServiceBundle( "Api/{Service}" )]    public  interface IChatService: IServiceKey    {        [Command( ShuntStrategy=AddressSelectorMode.HashAlgorithm)]        Task SendMessage( string name, string data);    }

 3.3 基於http,tcp協議業務實現

繼承ProxyServiceBase和業務接口IManagerService

?

1 2 3 4 5 6 7

public class ManagerService : ProxyServiceBase, IManagerService     {         public Task< string > SayHello( string name)         {               return Task.FromResult($ "{name} say:hello" );         }     }

  3.4 基於ws協議業務實現

  繼承WSServiceBase和業務接口IChatService，注意：ws服務之間的調用只能經過基於routepath遠程調用，不支持經過接口建立代理遠程調用

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

public class ChatService : WSServiceBase, IChatService     {         private static readonly ConcurrentDictionary< string , string > _users = new ConcurrentDictionary< string , string >();         private static readonly ConcurrentDictionary< string , string > _clients = new ConcurrentDictionary< string , string >();         private string _name;                   protected override void OnMessage(MessageEventArgs e)         {             if (_clients.ContainsKey(ID))             {                 Dictionary< string , object > model = new Dictionary< string , object >();                 model.Add( "name" , _clients[ID]);                 model.Add( "data" , e.Data);                 var result = ServiceLocator.GetService<IServiceProxyProvider>()                      .Invoke< object >(model, "api/chat/SendMessage" ).Result;               }         }           protected override void OnOpen()         {             _name = Context.QueryString[ "name" ];             if (! string .IsNullOrEmpty(_name))             {                 _clients[ID] = _name;                 _users[_name] = ID;             }         }         public Task SendMessage( string name, string data)         {             if (_users.ContainsKey(name))             {                 this .GetClient().SendTo($ "hello,{name},{data}" , _users[name]);             }             return Task.CompletedTask;         }     }

  3.5. 提供哈希分流選址接口

經過調用內部提供的哈希分流選址接口，就能夠把傳遞同一參數KEY分配到同一個服務提供者上。

3.6 基於WS協議測試

 

 

4.容器化部署

經過docker下載surging引擎，如今的版本是v0.8.0.2

?

1	docker pull serviceengine/surging:v0.8.0.2

 啓動surging 引擎

?

1

docker run --name surging --env Mapping_ip=192.168.249.242  --env Mapping_Port=93 --env RootPath=/home/fanly --env Register_Conn=192.168.249.162:8500 --env EventBusConnection=192.168.249.162 --env Surging_Server_IP=0.0.0.0  --env Surging_Server_Port=93 -v /home/fanly:/home/fanly -it -p 93:93 surging

 運行以下圖所示：

 

環境變量

Protocol：能夠設置Http、Tcp、WS、None， 其中設置Http、Tcp、WS表示僅支持相關協議，None表示能夠支持全部協議

RootPath：業務模塊存儲的根目錄，如：/home/fanly

HttpPort: 啓動Http協議主機端口

WSPort：啓動WS協議主機端口

UseEngineParts:設置啓用的服務引擎組件，默認是DotNettyModule;NLogModule;MessagePackModule;ConsulModule;HttpProtocolModule;EventBusRabbitMQModule;WSProtocolModule;（注意：若是是nuget定製化引擎，不須要配置Packages，能夠進行刪除，只需下載所需的引擎組件，會自動裝配註冊到服務引擎）

IP：私有容器IP,通常都是設置0.0.0.0

Server_Port： 私有容器端口

Mapping_ip:公開主機IP

Mapping_Port:公開主機端口

 

5.總結

surging 研發已通過去一年，從原來只支持RPC遠程服務訪問，到如今能夠支持容器化部署，支持tcp、http、ws 協議的服務引擎,其中的成長演化很是有意思，有不少靈感只有在開發的時候纔會靈光乍現，也但願之後能有更好的設計思想融入到surging中,也同時但願surging愈來愈強大。

 

原文:http://www.javashuo.com/article/p-xugfgbgh-cz.html