surging 微服务引擎 2.0 会有多少惊喜？

微服务引擎从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 作为服务引擎是及格的，可为各行业公司快速研发投入市场提供了可靠的解决方案。

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

微服务应该是粒度最小的功能业务模块，针对于行业解决方案，集成相应的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"
    }
  }
}

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 在微服务迎头赶上，能给公司带来一套稳定高效的解决方案。

黄山市民网：https://www.huangshanshimin.com/