继 2019 年开源 Midway 框架之后，大淘宝技术一直在 Node.js 的前沿进行深度研究，除了加入 TC39 参与标准化建设，向上游 Node.js 项目持续贡献，与龙蜥社区合作优化之外，也在 Serverless 领域有了不小的成果。 今天，向大家介绍我们最新的面向云原生场景，面向 Serverless 架构下的新产品， 代号 Noslate，现已正式开源。
电商业务场景，随着平台订单规模的日益增长，订单现有的存储已经没办法支撑后面业务的发展。在得物五彩石项目的时候就对订单进行了分库分表的拆分，为了解决分库分表后卖家维度的查询问题，单独创建了一个卖家维度的订单库。 目前订单分为买家和卖家两个库，卖家库的数据是通过监听买家库binlog异构出来的一个库。现在订单主要有两张表，分别是订单的主表和子表。 在异构的逻辑中，我们会对这两张表的binlog消息进行处理，异构成我们的卖家订单表。在监听到插入的消息时，只会处理子表的插入消息，其余需要补充的主订单表数据直接查询主表。
随着云原生的发展，云原生应用一致性、可靠性、灵活编排的能力让大部分企业选择将应用往云上迁移，但同时云基础设施在稳定性、可观测、也接受的强大的考验。 ChaosBlade 是阿里巴巴开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具，帮助企业提升分布式系统的容错能力，并且在企业上云或往云原生系统迁移过程中业务连续性保障。 ChaosBlade Operator 是 kubernetes 平台实验场景的实现，将混沌实验通过 Kubernetes 标准的 CRD 方式定义，很方便的使用 Kubernetes 资源操作的方式来创建、更新、删除实验场景，包括使用 kubectl、client-go 等方式执行，同时也可以使用 chaosblade cli 工具执行。 本文将主要介绍 ChaosBlade 在 Kubernetes 中故障注入的底层实现原理、版本优化过程以及大规模应用演练测试。
现实系统往往有着较高的复杂度，我们借助 Trace、Log、Metric 三驾马车使我们的系统具备了一定的可观测性，但观测位置和信息往往是固定的，而我们所遇到的问题常常是意料之外的，这就导致我们能够定位问题的范围，但是难以更进一步，这时候我们就需要在我们想要的位置采集信息来帮助我们，在通常的实践中这就意味着我们需要添加日志逻辑并重启应用，这种做法成本较高而且会丢失现场。而借助日志治理，只需要通过在控制台配置规则便可以在不重启应用的前提下，动态采集任意点位信息。接下来通过一个假想的排查流程来简单介绍下日志治理的实践。
Notebook 是一种支持 REPL 模式的开发环境。所谓「REPL」，即「读取-求值-输出」循环：输入一段代码，立刻得到相应的结果，并继续等待下一次输入。它通常使得探索性的开发和调试更加便捷。在 Notebook 环境，你可以交互式地在其中编写你的代码、运行代码、查看输出、可视化数据并查看结果，使用起来非常灵活。 在数据开发领域，Notebook 广泛应用于数据清理和转换、数值模拟、统计建模、数据可视化、构建和训练机器学习模型等方面。 但是显然，做数据开发，只有 Notebook 是不够的。在火山引擎 DataLeap 数据研发平台，我们提供了任务开发、发布调度、监控运维等一系列能力。我们将 Notebook 作为一种任务类型，加入了数据研发平台，使用户既能拥有 Notebook 交互式的开发体验，又能享受一站式大数据研发治理套件提供的便利。
近几年，低代码技术发展的如火如荼，在商业领域也是目前市场关注的重点.作为商业低代码产品通常是用来助力企业信息化转型的利器，其中的核心逻辑是通过将软件开发普民化，让传统企业中更熟悉企业运作流程的业务人员可以亲自动手开发适合自己业务的系统或平台。这个领域内在市场上已经有国内外很多有竞争力的产品，钉钉宜搭作为阿里巴巴的商业低代码产品也是其中的一员。 今天重点讲的是另外一个领域，低代码技术在产研团队应用落地的相关话题。商业低代码产品可以赋能业务团队具备研发能力，但对于已经具备不错研发能力的互联网厂商的产研团队来说，商业低代码产品可以解决很大长尾应用场景的快速开发，但对于产研团队的服务的主要业务上，并不是完全适用。对于阿里巴巴来说，集团里各BU因地制宜建设了众多适合本业务的低代码平台/产品，其实也都是用于解决通用型商业低代码产品不适用部分的问题。
• 如何描述、存储和计算优惠并提供较好的业务可扩展性 • 如何保障大流量下优惠实时计算的性能 • 为优惠查询加速做的数据同步如何实现一致性
根据不同的应用场景与意图，设计模式主要分为创建型模式、结构型模式和行为型模式三类。本文主要探索行为型模式中的策略模式如何更好地应用于实践中。
