随着分布式系统的快速发展与广泛应用，针对共享资源的互斥访问也成为了很多业务必须要面对的需求，人们通常会引入分布式锁来解决问题。本文将从分布式锁的性质出发，探讨分布式锁的模型设计，分享分布式锁在存储的设计实践。
泛日志（Log/Trace/Metric）是大数据的重要组成，伴随着每一年业务峰值的新脉冲，日志数据量在快速增长。同时，业务数字化运营、软件可观测性等浪潮又在对日志的存储、计算提出更高的要求。 从时效性角度看日志计算引擎：数仓覆盖 T + 1 日志处理，准实时系统（搜索引擎、OLAP） 瞄准交互式场景，实时需求则加速了 Flink 等流引擎的发展。 再回到用户场景角度，各式各样的数据呼唤多种计算模式，例如本文要讨论的日志搜索场景： 业务日志搜索、高频词查询：使用全文索引技术，期望低延时。 低频日志搜索、schema 不固定场景：通过 Scan（硬扫描）方式实现不依赖 schema（索引结构）的搜索，灵活但延时有所上升。
在云计算中，FaaS 是一种非常流行的产品形态，主流的云产商都提供了对应的平台。作为平台构建者我们观察到大部分的函数实例的 CPU 和内存利用率都不高，造成集群节点的利用率也不高。一个简单的做法是在节点上超额放置更多的函数实例，但是这可能会带来资源争抢和性能下降。另外，函数的外部依赖也可能导致函数的性能下降。在本文中，我们设计了 OWL 调度系统来解决这些问题，达到高资源利用率和性能稳定性。对于低频调用的函数，调度器会统计其执行过程中的实际资源消耗，以此来指导函数实例的调度，同时调度器会监控函数的执行延时，当出现延时上升时通过隔离的手段进行缓解；对于高频调用的函数，调度器会识别不同函数实例在同一个节点共置时的性能表现，以此指导函数实例的调度。同时调度器还针对闲置的实例进行迁移，将它们从利用率低的节点迁移到利用率高的节点以释放闲置节点。我们实现了 OWL 原型系统并根据生产环境的负载构造了一组测试集。实验结果表明，OWL 调度系统能够减少 43.8% 的资源消耗并有效缓解性能下降。
云计算带来的优势之一便是弹性能力，云原生场景下 Kubernetes 提供了水平弹性扩容能力（HPA），让应用可以随着实时指标进行扩/缩。然而 HPA 的实际工作情况可能和我们直观预想的情况是不一样的，这里面存在一些认知误区。本文总结了一下 EDAS 用户在使用 HPA 时常遇到的三个认知误区，具体如下：
“ DDD设计的目标是关注领域模型而并非技术来创建更好的软件，假设开发人员构建了一个SQL，并将它传递给基础设施层中的某个查询服务然后根据表数据的结构集取出所需信息，最后将这些信息提供给构造函数或者Factory，开发人员在做这一切的时候早已不把模型看做重点了，这个整个过程就变成了数据处理的风格 ”——摘 Eric Evans《领域驱动设计》 《领域驱动设计》中的Repository（下面将用仓储表示）层实际上是极具有挑战性的，对于它的理解，也十分重要。本文大部分内容都在众多前辈理论基础上，从一个崭新的领域视觉开始探索，并结合自己的实践感悟进行细致的解析。同时本文不仅仅是DDD前辈的搬运工，也创新提出了仓储实体转移的概念，可以提供给读者思考是否在自己场景中可以用到这种模式。即使读者也对仓储有很深的了解，我也觉得本文会对你有新的阅读体验。
去年此时发表了一篇文章 《流计算引擎数据一致性的本质》，主要论述了流计算引擎中的数据一致性问题，事实上，该文章只能算作流计算数据一致性的上篇，如何通过流计算中得到真正准确、符合业务语义的数据，需要作进一步阐述。强迫症接受不了这种半拉子工程，所以今年还是陆陆续续把下篇（流计算引擎数据正确性的挑战） 撰写完成。上下两篇文章的主要论点，分别对应了流计算领域中的两大难题：端到端一致性和完整性推理。
为了提升应用稳定性，我们对前端项目开展了脚本异常治理的工作，对生产上报的js error进行了整体排查，试图通过降低脚本异常的发生频次来提升相关告警的准确率，结合最近在这方面阅读的相关资料，尝试阶段性的做个总结，下面我们来介绍下js异常处理的一些经验。
