RTC（Real Time Communication）是音视频基础设施，它已经融入了大家生活的方方面面：工作中，我们组织视频会议，即使团队成员身处异国，也能保证项目推进；休息时，我们打开抖音，看主播直播连麦；来一局游戏时，我们打开小队语音，大杀四方；学习时，我们相聚线上互动课堂，知识传播不再受距离的桎梏。RTC 拉近了大家的距离，丰富了大家的生活。 在这些场景里，我们最不能忍受的是什么？是延迟！想象一下，开会或者主播连麦时，一个人讲完话，其他人隔 10 秒才能做出反应，这几乎是完全不能接受的体验。 那么什么样的延迟才是好的体验呢？根据 ITU-T G.114 的建议：延时低于 400ms 的通话体验是可接受的，低于 200ms 是令人愉悦的。
在过去的几年中，以容器技术为代表的云原生领域受到了极大的关注和发展，容器化的落地是企业降本增效的一个重要手段，截止目前得物已基本完成了全域的容器化。容器化过程中，一方面平稳地将服务的部署和运维方式从以前的ECS模式切换到了容器化模式；另一方面为公司在资源利用率、研发效率上拿到了许多提效的收益。 得物作为新一代潮流网购社区，以AI和大数据技术为基础的搜索引擎、个性化推荐系统是业务开展的强大支撑力，所以业务应用当中算法域的应用占了的很大比例。容器化过程中，针对算法应用服务的研发流程和普通服务的差异性，在充分调研算法域研发同学需求的基础上，我们面向算法域的研发场景建设了得物云原生AI平台—KubeAI平台。经过功能的不断迭代，在支持的场景上不断拓展，KubeAI当前已经支持CV、搜索推荐、风控算法和数据分析等涉及AI能力的业务域顺利完成了容器化，在资源利用率提升、研发效率提升上面均拿到了不错的成果，本文将带大家一起了解KubeAI的落地实践过程。
去年此时发表了一篇文章 《流计算引擎数据一致性的本质》，主要论述了流计算引擎中的数据一致性问题，事实上，该文章只能算作流计算数据一致性的上篇，如何通过流计算中得到真正准确、符合业务语义的数据，需要作进一步阐述。强迫症接受不了这种半拉子工程，所以今年还是陆陆续续把下篇（流计算引擎数据正确性的挑战） 撰写完成。上下两篇文章的主要论点，分别对应了流计算领域中的两大难题：端到端一致性和完整性推理。
为了提升应用稳定性，我们对前端项目开展了脚本异常治理的工作，对生产上报的js error进行了整体排查，试图通过降低脚本异常的发生频次来提升相关告警的准确率，结合最近在这方面阅读的相关资料，尝试阶段性的做个总结，下面我们来介绍下js异常处理的一些经验。
在我们之前分享的《Dutter | 钉钉 Flutter 跨四端方案设计与技术实践》《Dutter | 前车之鉴：聊聊钉钉 Flutter 落地桌面端踩过的“坑”》文章中，有为大家简单介绍过钉钉 Flutter 桌面端应用的一些情况。在文章中我们有提到，因为需要支持多窗口、窗口内嵌等场景，在桌面端我们无法使用 FlutterBoost 一类的中间件来共享 FlutterEngine，只能采用多引擎方案来驱动多画布同时渲染。 此方案虽然能满足现阶段钉钉业务使用，但未来随着业务盖度、复杂度的提升，方案的弊端也愈加明显：引擎启动偶现卡顿、首帧耗时略长、内存占用高等。尤其是钉钉 Windows 端因为32位兼容问题，目前仍以 JIT 模式在运行 Flutter 页面，情况相比 AOT 模式更加差一些。以钉钉 Windows 目前线上业务为例，若不做任何优化，启动首帧展示耗时大概在 1000ms~2600ms 之间，每个引擎内存占用大概在 70MB 左右。 我们选择基于 Flutter 来构建钉钉跨4+端研发框架（Dutter） 的主要初衷即看中其在性能和体验上具备可媲美 Native 运行
在 ICE、Rax 等项目研发中，我们或多或少都会接触到 build-scripts 的使用。build-scripts 是集团共建的统一构建脚手架解决方案，其除了提供基础的 start、build 和 test 命令外，还支持灵活的插件机制供开发者扩展构建配置。 本文尝试通过场景演进的方式，来由简至繁地讲解一下 build-scripts 的架构演进过程，注意下文描述的演进过程意在讲清 build-scripts 的设计原理及相关方法的作用，并不代表 build-scripts 实际设计时的演进过程，如果文中存在理解错误的地方，还望指正。
一个IP报文如何跨越万水千山达到目的地？本文将以阿里云为例，带领大家一起探索同地域内云上通信的全过程，完整展现云上同地域内各种场景的IP报文之旅，深入理解云网络技术、产品和通信。
我们公司从 2015 年开始就使⽤ Dubbo 作为微服务框架，当社区推出 Dubbo 3 时，我们也⽴刻跟进并做了深⼊调研，发现 Dubbo 3 的应⽤/实例级服务注册和发现模式能够在一定程度上解决我们当前注册中⼼⾯临的压⼒，解决稳定性和安全性问题。同时 Dubbo 3 在服务治理上也做了升级，契合云原⽣架构，⽽且 Dubbo 3 能够向下兼容 Dubbo 2，这也将降低升级的成本和⻛险。 升级项目有了阶段性的进展，目前仍然在进行中。通过本⽂，我们对公司内部的 Dubbo 3 升级过程及收益等做了深⼊总结。
