迎元旦，庆surging 1.0发布

Posted 2021-01-29 fanliang11

一位摄影程序员的独白

       每个人都有爱好，都有释放压力的活动，而我也不例外，我除了每天上班，周末就会约一群好友去拍妹子，成家后，就改为拍虫子，一拍就到了30岁，到了30岁就感觉到了中年的压力，这时候停下手中的摄影，开始研究技术，我开始翻阅各种技术博客，各种开源作品，静下心去研究技术时，发现.NET的技术非常薄弱，各种解决方案都非常欠缺，尤其是微服务，在.NET领域基本上一片空白，这时候碰巧.NET CORE 的出现，研发surging想法也开始萌芽，也到处跟同事说，我要研发一套微服务框架，真正意义上的微服务框架，让大家都去关注业务，而无需去关注webapi,rest,http,tcp,rabbitmq,缓存等与业务无关的技术，这些都由框架和中间件去实现，而同事，朋友投过来的都是鄙夷，惊讶，意思是就凭你，是啊！就凭我，在不断学习下，2017年我开始迈出了研发的第一步，2017年6月16日开始在github 进行开源。而半个月后被邀请到TCC开源小组孵化surging.

        转眼间已经到2018年年尾，还有一个星期就跨入2019年，在新年到来的日子，surging 也准备发布1.0稳定版本，在这1年半的日子里，耗费了多少个日日夜夜我已经记不清，每天下班回来我都要理清下surging ，还有哪些欠缺，需要弥补，需要完善，耗费了心血和时间在surging上,但是这一切都是值得的，因为有些公司已经采用surging  ，在微服务上已经给了非常好的解决方案，并且有一家物联网公司已经使用surging 的ws,mqtt协议，据了解客户端设备就有好几万台。那下面我们来看看1.0版本有那些功能。

 

---

组件介绍

一、通信组件

1. Dotnetty:

针对于底层的http,mqtt,TCP协议采用了dotnetty进行实现 ，并且可以配置使用Libuv，而dotnetty 是微软的Azure团队，使用C#实现的Netty的版本,性能非常强大。

2.websocket-sharp:

针对于底层的websocket采用了websocket-sharp进行实现，因为官方未支持.net core，所以把它转化支持.NET CORE,并且源码放到surging ，并且同时和suring 一起发布

2.Kestrel:

针对于底层的Http协议采用了Kestrel进行实现，并且swagger也依赖于Kestrel，后期会扩展身份验证，数据加密，服务聚合等功能以代替网关，并且还会完善基于Kestrel的文件服务

二、编解码组件

1.Newtonsoft.Json

针对于json 的编解码采用了Newtonsoft.Json进行实现 ，并且默认使用Newtonsoft.Json进行编解码

2.MessagePack-CSharp

针对于messagepack 的编解码采用MessagePack-CSharp进行实现，MessagePack-CSharp是用于C＃实现的MessagePack序列化组件，比官方的MsgPack-Cli快10倍，与其他所有C＃序列化程序相比，具有最好的性能

3.protobuf-net

针对于二进制的protobuf格式的编解码采用的是protobuf-net进行实现

三、日志组件

1.Nlog

针对于Critical，Debug，Trace，Error，Information，Warning级别的日志可以通过Nlog组件进行实现，并且可以写入到Console，file，database

2.log4net

针对于Critical，Debug，Trace，Error，Information，Warning级别的日志可以通过log4net组件进行实现，并且可以写入到Console，file，database

四、注册中心

1. consul

针对于MqttServiceRoute、ServiceCache、ServiceCommand、ServiceRoute采用了consul的Key/Value 进行存储，并且更新是采用了心跳进行更新

2. zookeeper

针对于MqttServiceRoute、ServiceCache、ServiceCommand、ServiceRoute采用了zookeeper指定path进行node 储存，并且更新是采用了watcher进行更新

五、队列

1. rabbitmq

针对于消息队列rabbitmq 实现了消息的重试，失败回滚，消息的延迟处理，目前只实现了direct

2. kafka

实现了针对于topic 进行发布订阅。

六、缓存

1.MemoryCache

由surging 的Caching组件提供的内存缓存，使用该类型可以方便的在程序内部缓存数据并对于数据的有效性进行方便的管理

2.Redis

针对于redis 缓存实现了哈希一致性，并且配有健康检查，对于超过6次不健康的服务会从哈希节点移除。目前只实现了key-value

七：动态代理

1.ProxyGenerator

针对动态代理是通过Roslyn构建脚本来生成编译AOP动态代理，以提供通过接口创建代理方式访问。

负载均衡

一、容错策略

 

1. 随机（Random）：

通过生成随机数随机选择服务地址，调用量越大分布越均匀

2. 轮询（Polling）

通过轮询地址选择服务地址，存在比较慢的机器容易在这台机器的请求阻塞较多，默认使用此负载算法

3.哈希一致性（HashAlgorithm）

通过第一个参数生成的哈希值进行哈希一致性选取服务地址，对于第一个相同参数的值的请求会定位到同一个服务提供者上

4.压力最小优先（FairPolling）

通过轮询优先选择压力最小的服务地址，针对于压力比较小的服务器会分配更多的请求。

 

服务容错和熔断

一、容错策略

1.故障转移策略(Failover):

通过设置故障转移群集数(FailoverCluster),从而服务故障自动转移到健康的服务提供者

2.脚本注入策略(Injection):

通过设置脚本注入（Injection）,服务发生错误时会返回所定义运行的脚本结果

3.回退策略(FallBack)

通过设置回退的实例名（FallbackName）,服务发生错误时通过FallBackName去调用依赖注入的接口IFallbackInvoker

二、熔断

1.错误率熔断

通过设置错误率（BreakeErrorThresholdPercentage）,当失败调用数/远程调用数大于错误率，会启用熔断

2.超时熔断

通过设置执行超时时间（ExecutionTimeoutInMilliseconds）,当服务调用超过执行时间会启用熔断

3.并发熔断

通过设置信号量最大并发度（MaxConcurrentRequests）,在多线程环境下超过设置的信号量，会启用熔断

4.错误数熔断

通过设置调用失败的错误数（BreakerRequestVolumeThreshold）,在10秒钟范围内超过设置的调用失败错误数，会启用熔断

众筹活动

针对surging,体系比较庞大，组件涵盖比较多，需要4名人员一起完善surging中英文文档，然后经过大家商量进行众筹，然后得到了大家热烈响应，决定完成后，和参加者一起去云南旅游，不够我自己补上费用，经过4天的募捐已经达到6478元，最近也邀请同事，朋友参加，已经有2名非常优秀的人员参加英文文档编写，他们的英文非常好，可以和老外远程会议，并且公司藏龙卧虎的人非常多，最近有小组成员去了芝加哥出差，对于我这个英语二把刀的人来说，完全是个互补。并且每个月1号会把贡献者名单更新到github

总结

surging 还有很长的路要走，我会花很多时间在surging 维护和完善上，也请大家关注元旦1.0版本的发布，QQ群还有神秘大礼哦！