基于.NET CORE微服务框架 -浅析如何使用surging

1、前言

surging受到大家这么强烈的关注,我感到非常意外,比如有同僚在公司的分享会上分享surging, 还有在博客拿其它的RPC框架,微服务做对比等等,这些举动都让我感觉压力很大,毕竟作为个人的开源项目,无法与成熟的开源社区的项目相比,也只有等到后面有许许多多志同道合的朋友加入一起研发完善surging,这样才能让surging 成为流行的微服务框架。

这篇文章介绍如何使用surging

开源地址:https://github.com/dotnetcore/surging

2、设计模式

Surging 提供了以下四种设计模式

2.1  代理模式

通过代理调用不同的微服务。并且针对于规则控制其访问,如下图所示:

2.2 异步消息模式

再处理等待而阻塞的问题时候, 基于微服务的架构会选择使用消息队列来代替请求/响应模式,如下图所示:

2.3 链式模式

这种模式在接收到请求后会进行互相合并的响应,如下图所示:

服务A接收到请求后会与服务B进行通信,服务B会同服务C进行通信。所有服务之间的通信使用基于Netty的RPC通信。

2.4  分支模式

这种模式允许调用多个服务提供者,来合并数据进行返回,如下图所示:

3、外部如何交互

服务主要针对提交的数据进行处理,在单个服务或多个服务调用的问题上,采取使用网关统一访问的形式进行处理,如下图所示

网关包括以下功能:

  1. 安全身份认证
  2. 统一访问
  3. 流量控制
  4. 分流控制
  5. 数据监控
  6. 缓存拦截

2.简单示例

服务端

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)

服务根据RoutePath 进行调用(不需要依赖接口,耦合性低)

ServiceLocator.GetService<IServiceProxyProvider>().Invoke<string>(model, path, serviceKey)

本地模块和服务调用

ServiceLocator.GetService<T>(key)

通过以上配置,可以通过网关进行访问,如果我们要访问接口IUserService ,方法为GetUser,路由映射的规则[ServiceBundle("api/{Service}/{Method}")],所转化地址应该是api/User/GetUser,

用Postman测试的效果如下:

4. 总结

surging外部通过Api 网关 Rest 访问,内部通过netty RPC访问,surging还在不断完善中,帮助文档也正在赶工中,请大家耐心等待。如感兴趣请多关注或者加入QQ群:615562965

时间: 2024-11-02 23:08:34

基于.NET CORE微服务框架 -浅析如何使用surging的相关文章

基于.NET CORE微服务框架 -谈谈surging的服务容错降级

一.前言 对于不久开源的surging受到不少.net同学的青睐,也受到.net core学习小组的关注,邀请加入.NET China Foundation以方便国内.net core开源项目的推广,我果断接受邀请加入了队伍进行互相交流学习,最近也更新了surging新的版本 更新内容: 1. Castle.Core 兼容性问题,下一版本会去除,解决部分用户第一次编译VS卡死问题2. 增加容错降级3. 路由容错重构,针对于失败重试和失败没有重试,失败回调,4.增加部分功能单元测试5. 升级支持.

基于.NET CORE微服务框架 -Api网关服务管理

1.前言 经过10多天的努力,surging 网关已经有了大致的雏形,后面还会持续更新完善,请大家持续关注研发的动态 最近也更新了surging新的版本 更新内容: 1. 扩展Zookeeper封装2. 增加服务元数据3. 增加API网关 开源地址:https://github.com/dotnetcore/surging 2.软件环境 IDE:Visual Studio 2017 15.3 Preview ,vscode 框架:.NET core 2.0 依赖程序:Zookeepe.Rabbi

基于.NET CORE微服务框架 -谈谈Cache中间件和缓存降级

1.前言 surging受到不少.net同学的青睐,也提了不少问题,提的最多的是什么时候集成API 网关,在这里回答大家最近已经开始着手研发,应该在1,2个月内会有个初版API网关,其它像Token身份验证,限流降级等功能完成时间会往后推 最近也更新了surging新的版本 更新内容: 1. Cache中间件基于Redis 所依赖的第三方库已将servicestack.redis转成stackexchange 2. 增加缓存降级3. 增加拦截缓存降级的例子 开源地址:https://github

基于.NET CORE微服务框架 -谈谈surging 的messagepack、protobuffer、json.net 序列化

1.前言 surging内部使用的是高性能RPC远程服务调用,如果用json.net序列化肯定性能上达不到最优,所以后面扩展了protobuf,messagepack序列化组件,以支持RPC二进制传输. 在这里需要感谢白纸无字Zonciu,新增了messagepack序列化,让surging 性能上跨了一大步.此篇文章我们来谈谈messagepack.protobuffer.json.net ,并且性能做下对比 开源地址:https://github.com/dotnetcore/surging

基于.net core 微服务的另类实现

原文:基于.net core 微服务的另类实现 基于.net core 的微服务,网上很多介绍都是千篇一律基于类似webapi,通过http请求形式进行访问,但这并不符合大家使用习惯.如何像形如[ GetService<IOrderService>().SaveOrder(orderInfo)]的方式, 调用远程的服务,如果你正在为此苦恼, 本文或许是一种参考. 背景 原项目基于传统三层模式组织代码逻辑,随着时间的推移,项目内各模块逻辑互相交织,互相依赖,维护起来较为困难.为此我们需要引入一种

ASP.NET Core微服务框架Ocelot+Consul+IdentityServer4实战演练

一.背景介绍 API网关的流行源于最近几年移动应用与企业间接口对接的兴起,使得原来单一的PC客户端,变化到PC客户端.各种浏览器.手机移动端及智能终端等.同时系统之间大部分都不是单独运行,经常会涉及与其他系统对接.共享数据的需求.随着微服务架构概念的提出,API网关成为了微服务架构的一个标配组件.随着业务快速发展,面向手机移动应用业务越来越多,为了减少客户端与服务的耦合,节约后端微服务的开发成本,建立一个高性能.高可用.减少上线风险的API网关成为一个迫切的需求. 1).目前面临现状:假设你正好

基于Spring-Cloud的微服务框架设计

先进行大的整体的框架整理,然后在针对每一项进行具体的详细实现 原文地址:https://www.cnblogs.com/breka/p/9789995.html

几个基于jvm 的微服务框架

一个简单的整理,留待深入学习 micronaut http://micronaut.io/ sparkjava http://saprkjava.com spring cloud http://projects.spring.io/spring-cloud/ javalin https://javalin.io ktor.io http://ktor.io dropwizard https://dropwizard.io 原文地址:https://www.cnblogs.com/rongfeng

(二)surging 微服务框架使用系列之surging 的准备工作consul安装

suging 的注册中心支持consul跟zookeeper.因为consul跟zookeeper的配置都差不多,所以只是consul的配置 consul下载地址:https://www.consul.io/downloads.html consul agent 命令的常用选项,如下: -data-dir 作用:指定agent储存状态的数据目录 这是所有agent都必须的 对于server尤其重要,因为他们必须持久化集群的状态 -config-dir  作用:指定service的配置文件和检查定