分布式已经成为了当前最热门的话题,分布式框架也百花齐放,群雄逐鹿。从中心化服务治理框架,到去中心化分布式服务框架,再到分布式微服务引擎,这都是经过技术不断积累改进而造成的结果。esb,网关,nginx网关 这些中心化服务治理框架如今都是各个公司比较主流的架构,而最近几年你们炒的比较火的去中心化微服务框架,各个语言都有其表明做品,好比.NET就有orleans、akka.net,这些框架不言而喻都能从网上了解一二,可是针对于这些框架,是否是就知足公司的须要,就能搭建起整个平台呢?nginx
能够告诉你们,下一代框架应该称为分布式微服务引擎,也能够叫作服务网格,它应该是基础设施引擎,加载驱动业务模块服务,负责服务之间的可靠传递,提供了所需的网络协议,而针对surging 服务引擎就是朝着这个思想前进,内部经过RPC进行调用,有一套完整的服务治理规则,提供了tcp、http、ws 协议,而且能够支持容器化、可定制化引擎部署,下面咱们来看看是如何实现的。git
服务引擎是用于处理服务与服务可靠通讯的专用基础设施。而服务应该是独立进行部署的,无需寄宿在其它框架当中,因为服务之间的独立性,业务团队再也不须要操心服务治理相关的复杂度,全权交给服务引擎处理便可。针对每个服务实例,服务引擎都会在同一主机上一对一并行部署一个服务进程,实现该服务实例全部对外的网络通信(参见下图),借助于良好的框架封装,运维成本也能够获得有效的控制。github
2.1 演化史web
surging从无到有可分为三个演化阶段算法
第一个阶段RPC服务治理框架,服务与服务之间通讯经过接口建立代理的方式进行访问docker
第二个阶段RPC服务治理框架+网关,服务与服务之间通讯经过接口建立代理或RoutePath进行访问,外部经过网关进行调用api
第三个阶段服务引擎,服务再也不关心通信细节和通讯协议,通通交给引擎, 只须要关注业务的实现websocket
2.2 架构网络
针对于surging如今提供了tcp、http、ws三种通讯协议,tcp、http协议是基于dotnetty,而ws是基于websocket-sharp的分支版本websocketcore(该版本支持.NET CORE)架构
而整个引擎的架构以下图所示,经过对外的网络通讯协议,能够对接移动、web、物联网应用,经过服务发现RPC远程调用内部业务服务。
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协议测试
经过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:公开主机端口
surging 研发已通过去一年,从原来只支持RPC远程服务访问,到如今能够支持容器化部署,支持tcp、http、ws 协议的服务引擎,其中的成长演化很是有意思,有不少灵感只有在开发的时候才会灵光乍现,也但愿之后能有更好的设计思想融入到surging中,也同时但愿surging愈来愈强大。