microservice

在抖音直播推广开源作品的可行性？作为85后，.NET开发已经有20年头了，人已经步入中年了，打工生涯也应该结束了，作为.NET微服务先驱者，2017年就开始研发surging, 然后在github开源，不出两年star 已经突破3k,star 的增加，代表了大多数人认可，也代表我的技术道路的成功，让我知道了知识也能换取财富，而后因为内存泄漏的原因，开始走下坡路，我一直认为是我使用的问题，又或者是客户的问题，导致问题一直没得到解决，直到有客户找到我，我才用心去寻找问题，发现是dotnetty 问题后，就下载源码把问题解决了，现在内存也非常

DotNetty 1.0 发布，希望不会太晚。通过1个月修改，今天dotnetty 发布了1.0 版本，虽然不是官方发布，但是我把最大的问题内存泄漏修复了，运行了7个小时，同时直播推流三个通道内存稳定在55mb左右，cpu 稳定在0.4%，服务器只有4核16G，看如下图

dotnetty 内存泄漏的BUG修复了当你做的产品内存不稳定，CPU不稳定，内存在600MB-3G之内波动，cpu 在30%左右，就算你对外宣传支持可以十万设备，也不会有人相信，如果你做的产品直播推流内存一直稳定在60MB左右，cpu 在1%左右，我说带宽足够，支持1万人在线观看，客户对于这个产品也不会有所怀疑，通过一个月的努力我终于找出dotnetty 内存泄漏的问题所在，已经进行修复，以下是我现在运行的物联网平台，内存最少的是网关，有十几个协议主机运行，内存多的是业务服务并没有更新修复的dotnetty, 下面我要阐述问题所在

dotnetty 新的篇章- 开源因为微服务引擎依赖于dotnetty组件，很多协议都是针对于dotnetty 进行扩展，然后对于老版本https://github.com/azure/dotnetty 停止更新后，本人下载源码进行修改更新，并且大家要求独立仓库进行开源，所以今天整理了代码开源至https://github.com/microsurging/DotNetty, 也希望大家一起贡献代码，让dotnetty 生态更强大。

使用 Microsoft.Extensions.ServiceDiscovery 进行服务发现并调用在现代微服务架构中，服务发现（Service Discovery）是一项关键功能。它允许微服务动态地找到彼此，而无需依赖硬编码的地址。以前如果你搜 .NET Service Discovery，大概率会搜到一大堆 Eureka，Consul 等的文章。现在微软为我们带来了一个官方的包：Microsoft.Extensions.ServiceDiscovery。这个包出自 Aspire 项目，提供了一个简便的方式在 .NET 中实现服务发现。

微服务 - 作业调度 · Hangfire集成式 · 仪表盘 · DolphinScheduler分布式 · 定义流程系列目录关于调度，个人用的不太多，更多的重心不在这里，调度自己负责的并不多，或者仅仅是调用下，或者另有替代方案。。。早期的，有Windows服务方式、Crontab方式等等。现在市场上的产品更为丰富了，功能全面，还带UI，界面也非常友好。。。所以选择一款适合的应用起来，也没必要再去写一套，直接使用已经非常成熟的产品，方便又快捷。除非要求很高，除非很有必要。。。

微服务 - 应用性能监测 · 链路追踪 · 概念规范 · 产品接入 · 方法级追踪 · 创建指标跨度系列目录本文从 [场景/概念/定义]，演变的统一规范，再到滋生出的各类开源产品，产品的接入，应用案例等的阐述。

我是有底线的