1、前言git
surging受到你们这么强烈的关注,我感到很是意外,好比有同僚在公司的分享会上分享surging, 还有在博客拿其它的RPC框架,微服务作对比等等,这些举动都让我感受压力很大,毕竟做为我的的开源项目,没法与成熟的开源社区的项目相比,也只有等到后面有许许多多志同道合的朋友加入一块儿研发完善surging,这样才能让surging 成为流行的微服务框架。github
这篇文章介绍如何使用surging设计模式
开源地址:https://github.com/dotnetcore/surgingapi
Surging 提供了如下四种设计模式缓存
经过代理调用不一样的微服务。而且针对于规则控制其访问,以下图所示:安全
再处理等待而阻塞的问题时候, 基于微服务的架构会选择使用消息队列来代替请求/响应模式,以下图所示:架构
这种模式在接收到请求后会进行互相合并的响应,以下图所示:框架
服务A接收到请求后会与服务B进行通讯,服务B会同服务C进行通讯。全部服务之间的通讯使用基于Netty的RPC通讯。异步
这种模式容许调用多个服务提供者,来合并数据进行返回,以下图所示:ide
服务主要针对提交的数据进行处理,在单个服务或多个服务调用的问题上,采起使用网关统一访问的形式进行处理,以下图所示
网关包括如下功能:
var host = new ServiceHostBuilder() .RegisterServices(option=> { option.Initialize(); //初始化服务 option.RegisterServices();//依赖注入领域服务 option.RegisterRepositories();//依赖注入仓储 option.RegisterModules();//依赖注入第三方模块 option.RegisterServiceBus();//依赖注入ServiceBus }) .RegisterServices(builder => { builder.AddMicroService(option => { option.AddServiceRuntime();// // option.UseZooKeeperManager(new ConfigInfo("127.0.0.1:2181")); //使用Zookeeper管理 option.UseConsulManager(new ConfigInfo("127.0.0.1:8500"));//使用Consul管理 option.UseDotNettyTransport();//使用Netty传输 option.UseRabbitMQTransport();//使用rabbitmq 传输 option.AddRabbitMQAdapt();//基于rabbitmq的消费的服务适配 builder.Register(p => new CPlatformContainer(ServiceLocator.Current));//初始化注入容器 }); }) .SubscribeAt() //消息订阅 .UseServer("127.0.0.1", 98) //.UseServer("127.0.0.1", 98,“true”) //自动生成Token //.UseServer("127.0.0.1", 98,“123456789”) //固定密码Token .UseStartup<Startup>() .Build(); using (host.Run()) { Console.WriteLine($"服务端启动成功,{DateTime.Now}。"); }
在接口上,添加如下特性(还未实现统一方法配置)
[ServiceBundle("api/{Service}")]
ServiceLocator.GetService<IServiceProxyFactory>().CreateProxy<T>(key)
ServiceLocator.GetService<IServiceProxyProvider>().Invoke<string>(model, path, serviceKey)
ServiceLocator.GetService<T>(key)
经过以上配置,能够经过网关进行访问,若是咱们要访问接口IUserService ,方法为GetUser,路由映射的规则[ServiceBundle("api/{Service}/{Method}")],所转化地址应该是api/User/GetUser,
用Postman测试的效果以下:
surging外部经过Api 网关 Rest 访问,内部经过netty RPC访问,surging还在不断完善中,帮助文档也正在赶工中,请你们耐心等待。如感兴趣请多关注或者加入QQ群:542283494