Surging 微服务引擎 2.0 会有多少惊喜?

来自:fanly11

surging 微服务引擎从2017年6月至今已经有两年的时间,这两年时间有多家公司使用surging 服务引擎,并且有公司搭建了CI/CD,并且使用了k8s 集群,这里我可以说下几家公司的服务搭建情况,公司名不便透露,我们就以字母标识


A公司:40多个服务提供者,一个服务提供者扩展了四五个实例节点,只使用了3台服务器,并且搭建了CI/CD, k8s 集群,使用suring 构建航空行业信息化系统


B公司:房产系统,门店2300多家,峰值在线使用人数1700,平均保持在1200人左右,有21个服务提供者,每个服务提供者有70-80个服务,使用了三台服务器,部署在linux环境,并且使用docker, 数据库使用sql server 2017,运行了1年,产生的数据已经超过1亿


C公司:业务中台,服务2000多个,移动端和web端都已经上线,至今没产生什么问题,反应挺稳定


D公司:物联网,服务提供者1个,服务器1台8核支持了3.5W+, 部署在window 环境


....


以上是了解比较详细的一些数据,还有很多公司都采用了surging,还有一些公司采用surging 做二次开发,有了这些市场的证明,说明surging 作为服务引擎是及格的,可为各行业公司快速研发投入市场提供了可靠的解决方案。


那谈了这么多surging又是怎么样定义微服务这个边界的?


微服务应该是粒度最小的功能业务模块,针对于行业解决方案,集成相应的service host,而针对于业务需要一些中间件来辅助,比如缓存中间件,eventbus中间件(消息中间件),数据储存中间件,而各个服务又可以互相通过rpc进行可靠性通信。


以下是surging 服务引擎的调用链


 

从以上调用可以看出surging 可以支持多行业的解决方案,通过协议Mqtt、ws、http服务主机生成服务提供者,  在服务启动的时候服务A、服务B、服务C、服务D的ServiceRoute 会注册到注册中心,而A,B,C,D如果不是部署在同一个服务提供者中就需要通过RPC进行通信,而RPC提供了服务发现 和服务治理功能从而保证了通信之间,可靠性,可用性和可扩展性。


那么新版本surging 又有多少新的功能,多少惊喜呢?


1、灵活配置RoutePath


针对于RoutePath做了一次优化,可以通过ServiceBundle设置RoutePath, 也可以通过 ServiceRoute进行设置,具体参考以下代码


[ServiceBundle("api/{Service}")]
//[ServiceBundle("api/{Service}/{Method}")]
//[ServiceBundle("api/{Service}/{Method}/test")]
//[ServiceBundle("api/{Service}/{Method}/test",false)]
public interface IUserService: IServiceKey
{
   /// <summary>
   /// 获取用户姓名
   /// </summary>
   /// <param name="id">用户编号</param>
   /// <returns></returns>
   [ServiceRoute("{id}")]  //[ServiceRoute("{参数名}")]
   Task<string> GetUserName(int id);
}


通过以上设置,GetUserName 生成的routepath是/api/user/getusername/{id}, 然后我们可以通过引用swagger组件来测试服务是否调用成功,具体效果如下



或者也可以用postman进行访问,具体效果如下图



2、扩展Dns 协议服务主机


因dotnetty没有dns 组件,扩展了基于dotnetty 的dns 编解码,支持tcp,udp协议, 但仅支持PTR、OPT记录类型。


引擎扩展了Dns 协议服务主机组件,包含了以下功能


1、Domain Name 解析


2、支持模块化Domain Name 解析自定义扩展


3.、支持引擎模块的集群化域名解析


那么我们可以按照以下方式把dns 集成到引擎中


1、需要通过nuget包引用Surging.Core.DNS或者通过指定目录Components进行扫描装载,再通过以下配置RootDnsAddress


"Dns": {
 "RootDnsAddress": "192.168.1.1",
 "QueryTimeout": 1000
}


2. dns服务接口,需要继承IServiceKey


[ServiceBundle("Dns/{Service}")]
public interface IDnsService : IServiceKey
{
}


3. dns业务模块需要继承DnsBehavior,dns 服务主机才能进行加载


public class DnsService : DnsBehavior, IDnsService
{
   public override Task<IPAddress> Resolve(string domainName)
   {
       if(domainName=="localhost")
       {
           return Task.FromResult<IPAddress>(IPAddress.Parse("127.0.0.1"));
       }
       return Task.FromResult<IPAddress>(null);
   }
}


然后通用以上配置,然后指向部署的DNS服务主机地址,解析域名规则为 前缀.(XX.XX.XX).后缀, 前缀会解析为key,以结合基于key做哈希一致性负载算法, (XX.XX.XX)会解析成routepath, 后缀不解析可以随便取名。以下是通过nslookup命令进行测试



3、扩展Udp 协议服务主机


需要按照以下方式把Udp集成到引擎中


1、需要通过nuget包引用Surging.Core.Protocol.Udp或者通过指定目录Components进行扫描装载,再通过以下代码编写Udp Service


配置udp端口


{
"Surging": {
   "Ports": {
     "HttpPort": "${HttpPort}|280",
     "WSPort": "${WSPort}|96",
     "MQTTPort": "${MQTTPort}|97",
     "UdpPort": "${UdpPort}|95"
   }
 }
<br data-filtered="filtered">
}


udp服务接口,需要继承IServiceKey


[ServiceBundle("Udp/{Service}")]
public interface IUdpService : IServiceKey
{
}


udp业务模块需要继承UdpBehavior,udp服务主机才能进行加载


public class UdpService : UdpBehavior, IDnsService
{
   public override async Task<bool> Dispatch(IEnumerable<byte> bytes)
   {
       await this.GetService<IMediaService>().Push(bytes);
       return await Task.FromResult(true);
   }
   public override Task<bool> Dispatch(object message)
   {
       return Task.FromResult(true);
   }
}


通过以上代码,可以通过ffmpeg推流到Udp,再通过udp 推流MPEG-TS 格式分发到ws 服务,再通过http://127.0.0.1:280/JSMpeg.html查看ws 推送的共享桌面




以下是推送的高清视频,有可能是播放器缓冲的问题,推送的视频流解析的不是很清楚



4、扩展基于netty 的ws 协议服务主机


引擎扩展了netty 的ws协议服务主机组件,包含了以下功能


1.支持基于webscoket 的Open、Error、nMessage、Close方法的封装


2.支持消息的发送和广播


需要按照以下方式把Udp集成到引擎中


1、需要通过nuget包引用Surging.Core.Protocol.Udp或者通过指定目录Components进行扫描装载,再通过以下代码编写Udp Service


配置ws端口


{
"Surging": {
   "Ports": {
     "HttpPort": "${HttpPort}|280",
     "WSPort": "${WSPort}|96",
     "MQTTPort": "${MQTTPort}|97",
     "UdpPort": "${UdpPort}|95"
   }
 }
}


ws服务接口,需要继承IServiceKey


[ServiceBundle("Api/{Service}")]
[BehaviorContract(Protocol = "media")]
public interface IMediaService : IServiceKey
{
   Task Push(IEnumerable<byte> data);
}


ws业务模块需要继承WSBehavior,ws服务主机才能进行加载


public class MediaService : WSBehavior, IMediaService
{
   public  Task Push(IEnumerable<byte> data)
   
{
         this..Broadcast(data.ToArray());
         return Task.CompletedTask;
   }
}


 

5、多注册中心集群支持


可以通过设置多注册中心进行服务注册,配有健康检查和负载均衡,注册中心地址以,隔开,具体按照以下进行配置


"Consul": {
 "ConnectionString": "${Register_Conn}|127.0.0.1:8500,127.0.0.1:9500", // "127.0.0.1:8500,127.0.0.1:9500",
 "SessionTimeout": "${Register_SessionTimeout}|50",
 "RoutePath": "${Register_RoutePath}",
 "ReloadOnChange": true,
 "EnableChildrenMonitor": false
}


以下是通过网关的管理界面配置


"Register": {
 "Provider": "Consul",
 "Address": "${Register_Conn}|127.0.0.1:8500,127.0.0.1:9500"
}


以下查看以下界面,就说明配置成功



6、扩展支持ABP 组件


ABP 组件在.NET使用者还是比较多,ABP是一套业务封装快速开发框架,大多数使用者都是使用abp 架设单体应用和垂直应用SOA服务,那么使用微服务,必然需要用到ABP的组件,那么对于一些组件可以集成到surging 引擎中来,


其中通过引入Surging.Core.Abp组件,就能装载ABP组件。那么有多少ABP组件可以引入到引擎,这个等后面的章节会讲到。


7、 扩展关卡组件


surging 外层只能通过网关进行访问,这样破坏了组件引擎化思想,后面会考虑扩展关卡组件,以代替网关的路由转发、鉴权,具体设想会有以下功能


1. 支持AppSecret,能支持第三方调用


2.支持jwt来实现鉴权功能


3. 通过业务模块生成服务聚合服务提供者,服务聚合无需注册到注册中心


4.支持SSL配置


8、扩展支持Reactive Extensions(Rx)响应式编程


计划是surging 能支持响应式编程,扩展支持Reactive Extensions, 具体实现哪些功能,还需要考虑


总结


针对.NET还有很多很多人对于微服务这个概念模拟两可,很多人分不清微服务的边界,那么对于这种情况,你们可以花点时间研究下surging 或者看下其它语言是如何定义这个边界的,也希望.NET同僚们能分清正确的微服务系统的架设,也希望.NET 在微服务迎头赶上,能给公司带来一套稳定高效的解决方案。

推荐↓↓↓
DotNet程序员
上一篇:C#使用InstallerProjects打包桌面应用程序