泛日志（Log/Trace/Metric）是大数据的重要组成，伴随着每一年业务峰值的新脉冲，日志数据量在快速增长。同时，业务数字化运营、软件可观测性等浪潮又在对日志的存储、计算提出更高的要求。 从时效性角度看日志计算引擎：数仓覆盖 T + 1 日志处理，准实时系统（搜索引擎、OLAP） 瞄准交互式场景，实时需求则加速了 Flink 等流引擎的发展。 再回到用户场景角度，各式各样的数据呼唤多种计算模式，例如本文要讨论的日志搜索场景： 业务日志搜索、高频词查询：使用全文索引技术，期望低延时。 低频日志搜索、schema 不固定场景：通过 Scan（硬扫描）方式实现不依赖 schema（索引结构）的搜索，灵活但延时有所上升。

63 Technology lddgo Shared on 2022-10-27

阅读本文您将了解到：什么是 monorepo、为什么要 monorepo、如何实践 monorepo。

78 Technology lddgo Shared on 2022-10-27

在云计算中，FaaS 是一种非常流行的产品形态，主流的云产商都提供了对应的平台。作为平台构建者我们观察到大部分的函数实例的 CPU 和内存利用率都不高，造成集群节点的利用率也不高。一个简单的做法是在节点上超额放置更多的函数实例，但是这可能会带来资源争抢和性能下降。另外，函数的外部依赖也可能导致函数的性能下降。在本文中，我们设计了 OWL 调度系统来解决这些问题，达到高资源利用率和性能稳定性。对于低频调用的函数，调度器会统计其执行过程中的实际资源消耗，以此来指导函数实例的调度，同时调度器会监控函数的执行延时，当出现延时上升时通过隔离的手段进行缓解；对于高频调用的函数，调度器会识别不同函数实例在同一个节点共置时的性能表现，以此指导函数实例的调度。同时调度器还针对闲置的实例进行迁移，将它们从利用率低的节点迁移到利用率高的节点以释放闲置节点。我们实现了 OWL 原型系统并根据生产环境的负载构造了一组测试集。实验结果表明，OWL 调度系统能够减少 43.8% 的资源消耗并有效缓解性能下降。

72 Technology lddgo Shared on 2022-10-27

云计算带来的优势之一便是弹性能力，云原生场景下 Kubernetes 提供了水平弹性扩容能力（HPA），让应用可以随着实时指标进行扩/缩。然而 HPA 的实际工作情况可能和我们直观预想的情况是不一样的，这里面存在一些认知误区。本文总结了一下 EDAS 用户在使用 HPA 时常遇到的三个认知误区，具体如下：

61 Technology lddgo Shared on 2022-10-27

在学习《告别BeanUtils，Mapstruct从入门到精通》后，我发觉MapStruct确实是一个提升系统性能，降低无用代码的神器。然而，在实践这篇文章过程中，我遇到了些问题，并由此对MapStruct框架有了更深入的理解，以下将我的学习收获分享给大家。

78 Technology lddgo Shared on 2022-10-26

“ DDD设计的目标是关注领域模型而并非技术来创建更好的软件，假设开发人员构建了一个SQL，并将它传递给基础设施层中的某个查询服务然后根据表数据的结构集取出所需信息，最后将这些信息提供给构造函数或者Factory，开发人员在做这一切的时候早已不把模型看做重点了，这个整个过程就变成了数据处理的风格 ”——摘 Eric Evans《领域驱动设计》 《领域驱动设计》中的Repository（下面将用仓储表示）层实际上是极具有挑战性的，对于它的理解，也十分重要。本文大部分内容都在众多前辈理论基础上，从一个崭新的领域视觉开始探索，并结合自己的实践感悟进行细致的解析。同时本文不仅仅是DDD前辈的搬运工，也创新提出了仓储实体转移的概念，可以提供给读者思考是否在自己场景中可以用到这种模式。即使读者也对仓储有很深的了解，我也觉得本文会对你有新的阅读体验。

227 Design lddgo Shared on 2022-10-26

经过去年的Log4j-core的治理工作，我们通过Maven的依赖仲裁机制，在蚂蚁集团静态代码扫描平台-STC 和资产威胁透视-哈勃2款产品的联动合作下，很好的完成了直接依赖和间接依赖场景下的治理工作。但路还很远，新的场景层出不穷，故事还远远没有结束，我们要做的事情还非常多。

64 Technology lddgo Shared on 2022-10-25

去年此时发表了一篇文章 《流计算引擎数据一致性的本质》，主要论述了流计算引擎中的数据一致性问题，事实上，该文章只能算作流计算数据一致性的上篇，如何通过流计算中得到真正准确、符合业务语义的数据，需要作进一步阐述。强迫症接受不了这种半拉子工程，所以今年还是陆陆续续把下篇（流计算引擎数据正确性的挑战） 撰写完成。上下两篇文章的主要论点，分别对应了流计算领域中的两大难题：端到端一致性和完整性推理。

203 Technology lddgo Shared on 2022-10-25

为了提升应用稳定性，我们对前端项目开展了脚本异常治理的工作，对生产上报的js error进行了整体排查，试图通过降低脚本异常的发生频次来提升相关告警的准确率，结合最近在这方面阅读的相关资料，尝试阶段性的做个总结，下面我们来介绍下js异常处理的一些经验。

66 Technology lddgo Shared on 2022-10-24

在我们之前分享的《Dutter | 钉钉 Flutter 跨四端方案设计与技术实践》《Dutter | 前车之鉴：聊聊钉钉 Flutter 落地桌面端踩过的“坑”》文章中，有为大家简单介绍过钉钉 Flutter 桌面端应用的一些情况。在文章中我们有提到，因为需要支持多窗口、窗口内嵌等场景，在桌面端我们无法使用 FlutterBoost 一类的中间件来共享 FlutterEngine，只能采用多引擎方案来驱动多画布同时渲染。 此方案虽然能满足现阶段钉钉业务使用，但未来随着业务盖度、复杂度的提升，方案的弊端也愈加明显：引擎启动偶现卡顿、首帧耗时略长、内存占用高等。尤其是钉钉 Windows 端因为32位兼容问题，目前仍以 JIT 模式在运行 Flutter 页面，情况相比 AOT 模式更加差一些。以钉钉 Windows 目前线上业务为例，若不做任何优化，启动首帧展示耗时大概在 1000ms~2600ms 之间，每个引擎内存占用大概在 70MB 左右。 我们选择基于 Flutter 来构建钉钉跨4+端研发框架（Dutter） 的主要初衷即看中其在性能和体验上具备可媲美 Native 运行

211 Technology lddgo Shared on 2022-10-21