去年此时发表了一篇文章 《流计算引擎数据一致性的本质》，主要论述了流计算引擎中的数据一致性问题，事实上，该文章只能算作流计算数据一致性的上篇，如何通过流计算中得到真正准确、符合业务语义的数据，需要作进一步阐述。强迫症接受不了这种半拉子工程，所以今年还是陆陆续续把下篇（流计算引擎数据正确性的挑战） 撰写完成。上下两篇文章的主要论点，分别对应了流计算领域中的两大难题：端到端一致性和完整性推理。
为了提升应用稳定性，我们对前端项目开展了脚本异常治理的工作，对生产上报的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报文之旅，深入理解云网络技术、产品和通信。
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。在 2020 年，Sentinel 社区推出 Sentinel Go 版本，朝着云原生方向演进。Sentinel Go 是一个流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。 无论是流量控制还是熔断降级，实现的核心思想都是通过统计一段时间内的指标数据（请求数/错误数等），然后根据预选设定的阈值判断是否应该进行流量管控 那么如何存储并统计这一段时间内的指标数据则是核心关键，本文将揭秘 Sentienl-Go 是如何实现的毫秒级指标数据存储与统计。
最近几年，钉钉迅速成为一款国民级应用。IM 作为钉钉最核心的功能，每天需要支持海量企业用户的沟通，同时还通过 PaaS 形式为淘宝、高德等 App 提供基础的即时通讯能力，是日均千亿级消息量的 IM 平台。 我们通过 RocketMQ 实现了系统解耦、异步削峰填谷，还通过定时消息实现分布式定时任务等高级特性。另外，过程中也与 RocketMQ 深入共创，不断优化解决了很多问题，并且孵化出 POP 消费模式等新特性，彻底解决了RocketMQ 负载粒度只能到Queue级别、rebalance导致时延等问题。
