使用surging 常见的几个问题

一、前言

对于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 性能不行，我看是他能力不行把。

三、如何保证非阻塞推流

集群RPC推流

在集群情况下，必然会有网络抖动的情况，如果不加处理就会导致整个调用链路进行阻塞，所以必然会有健康检查，再通过容错规则进行可靠性调用

客户终端推流

针对于客户终端推流，会有多种情况，比如客户端抖动或者突然断网，导致发送的视频流产生堆积，内存，cpu增加，那么这个问题怎么解决呢？碰到这个问题就可以设置超时时间，超过了就把添加到不健康列表中，超过5次，就直接断开连接，就比如以下代码，推流超过200ms就会超时抛出TimeoutException异常。

复制代码

    public async Task AddSubscriber(IChannel channel)
    {
        var key = channel.RemoteAddress.ToString();
        var promise = new DefaultPromise();
        try
        {
            logger.Info($"subscriber : {channel.RemoteAddress} is added to stream :{_streamName}");
            _subscribers.GetOrAdd(channel.RemoteAddress.ToString(), p => channel);
            _avcDecoderConfigurationRecord.Timestamp = _content[0].Timestamp;
            await channel.WriteAndFlushAsync(_avcDecoderConfigurationRecord);
            var content1 = new List<AbstractRtmpMediaMessage>(_content);
            foreach (var msg in content1)
            {
                using (var cancellation = new CancellationTokenSource())
                {
                    promise = new DefaultPromise(); 
                    if (channel.IsActive && channel.IsWritable)
                        await channel.WriteAndFlushAsync(msg, promise).WithTimeout(cancellation, 200);
                    writeTimeout.TryRemove(key,out _);

                }
            }
        }
        catch (TimeoutException)
        {
            await HandleWriteTimeout(promise, channel, _subscribers, key); 
        }
    }

四、和别的微服务有什么区别

首先问这个问题，你就要了解什么是真正的微服务，如果你不了解你就会把中心化的服务治理当做微服务，还有之前宣传的什么代码侵入性作为缺点进行攻击，我就反问了，如果没有代码侵入性，怎么应对多种业务场景，怎么应对去中心化系统化部署，那么微服务必然要满足以下特征：

1.去中心化，架构部署存在多样性

如果你的系统需要依赖于第三方才能做到服务治理，那么你与微服务去中心化理念相违背，对于多种业务场景不能坦然面对,难道你要求你的客户一定要装此系统工具，不装就用不了，想必微服务不是这样的吧。

2.独立的服务治理

有的人在外层架设一层网关就是微服务，因为网关包含服务治理，那么如果服务聚合要调用多个服务，那又怎么办呢？所以必然需要独立的服务治理模块。这样才能做到系统的高内聚低耦合

组件模块化

对于组件功能，应该热部署模块化，不能仅支持显示调用，应该能支持扫描热部署加载

业务领域驱动化设计

一直认为领域驱动是为微服务而设计的，通过领域驱动设计就能拆分服务，所以要分清楚领域服务，仓储服务，聚合服务，这样拆分出的业务才能部署在微服务引擎中。

协议扩展

在现在多种业务环境下，必然需要有扩展协议模块的功能，可以加载自定义的协议中间服务，这样才能应对现在多变的环境，比如物联网，AI

五、未授权的不能申请著作权

没有和作者签订合同同意的，冒然违反申请微服务，微服务引擎著作权的，后果必究。

然后对于经过作者同意授权的，你只能对于你的产品申请著作权,不允许原封不动，未加入新的构思形成自己体系的产品申请著作权的，后果必究。

六、MIT协议可以进行修改

surging 是MIT协议，可以随意修改，修改命名空间，把surging 说成是你自己开发，应聘上架构师后，这些都没关系，因为谁都要吃饭，你能吃透，回答面试官的问题，也是你的能力，但是你不能后面又来找到我来解决问题，这种你享受福报，我承受业力的事情，希望以后不要发生了，要不然我就要在博客园公布出来了。