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}”)],程式碼如下
[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服務與服務之間的遠端呼叫,需要把負載分流設定為雜湊演算法程式碼如下
[ServiceBundle("Api/{Service}")] public interface IChatService: IServiceKey { [Command( ShuntStrategy=AddressSelectorMode.HashAlgorithm)] Task SendMessage(string name,string data); }
3.3 基於http,tcp協議業務實現
繼承ProxyServiceBase和業務介面IManagerService
public class ManagerService : ProxyServiceBase, IManagerService { public Task<string> SayHello(string name) { return Task.FromResult($"{name} say:hello"); } }
3.4 基於ws協議業務實現
繼承WSServiceBase和業務介面IChatService,注意:ws服務之間的呼叫只能通過基於routepath遠端呼叫,不支援通過介面建立代理遠端呼叫
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
docker pull serviceengine/surging:v0.8.0.2
啟動surging 引擎
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越來越強大。