一、前言
对于surging 存在的一些问题，在这里进行解答。
HttpFlv:http://demo.kayakiot.cn:281/httpflv.html （黑衣人）
HttpFlv:http://demo.kayakiot.cn:281/httpflv1.html （大红包）
HttpFlv:http://demo.kayakiot.cn:281/httpflv2.html （鹿鼎记）
rtmp:rtmp://demo.kayakiot.cn:76/live1/livestream2 （黑衣人）
rtmp:rtmp://demo.kayakiot.cn:76/live1/livestream3 （大红包）
rtmp:rtmp://demo.kayakiot.cn:76/live1/livestream4（鹿鼎记）
注：测试服务器带宽只有8MB, httpflv 缓冲做的没有rtmp好，然后httpflv卡就多刷新几次
凯亚 (Kayak) 是什么?
凯亚(Kayak)是基于.NET8.0软件环境下的surging微服务引擎进行开发的, 平台包含了微服务和物联网平台。支持异步和响应式编程开发，功能包含了物模型,设备,产品,网络组件的统一管理和微服务平台下的注册中心，服务路由，模块，中间服务等管理。还有多协议适配(TCP,MQTT,UDP,CoAP,HTTP,Grpc,websocket,rtmp,httpflv,webservice,等),通过灵活多样的配置适配能够接入不同厂家不同协议等设备。并且通过设备告警,消息通知,数据可视化等功能。能够让你能快速建立起微服务物联网平台系统。
凯亚物联网平台：http://demo.kayakiot.cn:3100（用户名：fanly 密码：123456）
链路跟踪Skywalking V8:http://117.72.121.2:8080/
dotnetty:https://github.com/microsurging/DotNetty
surging 微服务引擎开源地址：https://github.com/fanliang11/surging（后面surging 会移动到microsurging进行维护）
二、是否存在内存泄漏
前期因为dotnetty 问题，threadpool 线程占用而得不到释放导致内存泄漏，直到程序崩溃的问题已经解决进行修复，这是修复后的https://github.com/microsurging/DotNetty, 有人要问怎么证明呢？
以上是凯亚(Kayak)物联网平台运行6天资源占用情况，内存占用50Mb左右，rtmp视频推流3个通道, cpu 只占用0.2%左右，配置是4核16G的，从截图来看，大家也可以对比一下，各个语言资源占用情况，所以有人说.net 8.0 性能不行，我看是他能力不行把。
三、如何保证非阻塞推流
1. 集群RPC推流
在集群情况下， 必然会有网络抖动的情况，如果不加处理就会导致整个调用链路进行阻塞，所以必然会有健康检查，再通过容错规则进行可靠性调用
2. 客户终端推流
针对于客户终端推流，会有多种情况，比如客户端抖动或者突然断网，导致发送的视频流产生堆积，内存，cpu增加，那么这个问题怎么解决呢？碰到这个问题就可以设置超时时间，超过了就把添加到不健康列表中，超过5次，就直接断开连接，就比如以下代码，推流超过200ms就会超时抛出TimeoutException异常。- public async Task AddSubscriber(IChannel channel)<br> {<br> var key = channel.RemoteAddress.ToString();<br> var promise = new DefaultPromise();<br> try<br> {<br> logger.Info($"subscriber : {channel.RemoteAddress} is added to stream :{_streamName}");<br> _subscribers.GetOrAdd(channel.RemoteAddress.ToString(), p => channel);<br> _avcDecoderConfigurationRecord.Timestamp = _content[0].Timestamp;<br> await channel.WriteAndFlushAsync(_avcDecoderConfigurationRecord);<br> var content1 = new List(_content);<br> foreach (var msg in content1)<br> {<br> using (var cancellation = new CancellationTokenSource())<br> {<br> promise = new DefaultPromise(); <br> if (channel.IsActive && channel.IsWritable)<br> await channel.WriteAndFlushAsync(msg, promise).WithTimeout(cancellation, 200);<br> writeTimeout.TryRemove(key,out _);<br><br> }<br> }<br> }<br> catch (TimeoutException)<br> {<br> await HandleWriteTimeout(promise, channel, _subscribers, key); <br> }<br> }
首先问这个问题，你就要了解什么是真正的微服务，如果你不了解你就会把中心化的服务治理当做微服务，还有之前宣传的什么代码侵入性作为缺点进行攻击，我就反问了，如果没有代码侵入性，怎么应对多种业务场景，怎么应对去中心化系统化部署，那么微服务必然要满足以下特征：
1.去中心化，架构部署存在多样性
如果你的系统需要依赖于第三方才能做到服务治理，那么你与微服务去中心化理念相违背，对于多种业务场景不能坦然面对,难道你要求你的客户一定要装此系统工具，不装就用不了，想必微服务不是这样的吧。
2.独立的服务治理
有的人在外层架设一层网关就是微服务，因为网关包含服务治理，那么如果服务聚合要调用多个服务，那又怎么办呢？所以必然需要独立的服务治理模块。这样才能做到系统的高内聚低耦合
3. 组件模块化
对于组件功能，应该热部署模块化，不能仅支持显示调用，应该能支持扫描热部署加载
4. 业务领域驱动化设计
一直认为领域驱动是为微服务而设计的，通过领域驱动设计就能拆分服务，所以要分清楚领域服务，仓储服务，聚合服务，这样拆分出的业务才能部署在微服务引擎中。
5. 协议扩展
在现在多种业务环境下，必然需要有扩展协议模块的功能，可以加载自定义的协议中间服务，这样才能应对现在多变的环境，比如物联网，AI
五、未授权的不能申请著作权
没有和作者签订合同同意的，冒然违反申请微服务，微服务引擎著作权的，后果必究。
然后对于经过作者同意授权的，你只能对于你的产品申请著作权,不允许原封不动，未加入新的构思形成自己体系的产品申请著作权的，后果必究。
六、MIT协议可以进行修改
surging 是MIT协议，可以随意修改， 修改命名空间，把surging 说成是你自己开发，应聘上架构师后，这些都没关系，因为谁都要吃饭，你能吃透，回答面试官的问题，也是你的能力，但是你不能后面又来找到我来解决问题 ，这种你享受福报，我承受业力的事情，希望以后不要发生了，要不然我就要在博客园公布出来了。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
