经过长达大半年时间的崩溃治理后，基于 Electron 框架开发的新版 PC 淘宝直播推流客户端的稳定性终于赶超基于QT 框架开发的旧版本了。剩下的崩溃问题中有 40% 是跟内存 OOM 有关，其中 V8FatalErrorCallback js heap OOM 问题整整困扰了我一个多月。历经千辛万苦终于破案并解决了这个问题，作为技术人来说还是非常兴奋的。为了了解该问题的来龙去脉，本文会从 V8FatalErrorCallback 崩溃问题的堆栈分析开始讲起，然后通过堆栈信息尝试各种解决方案，并对 v8 堆内存进行源码分析和尝试编译 electron 源码提升 v8 堆内存上限都不奏效后（如果对于编译 electron 源码不感兴趣，可以直接跳到 “如何用 Memory 和 Performance 工具分析内存泄漏问题“章节查看最终解决问题的方案），最终借助 chrome devtools 提供的 Memory 和 Performance 工具一步步排查和解决 Electron v8 引发的内存 OOM 问题，并且触类旁通解决其他内存 OOM 问题。
随着企业规模的不断扩大，传统单体应用已很难进一步支持业务的发展，业务的迭代速度已经难以满足业务的增长，此时企业会对应用系统做微服务化的改造，降低业务的耦合度，提升开发迭代的效率，让开发更加敏捷。 系统架构微服务化的，原本的愿景是希望通过将系统的颗粒度变小，提升业务的迭代效率。但是在实践微服务架构的过程中，尤其是在服务数量越来越多之后，那么引发的效率问题可能会大于微服务架构本身所带来的架构红利。
Java 应用在云计算时代面临“冷启动”慢、内存占用高、预热时间长等问题，无法很好的适应 Serverless 等云上部署模式，GraalVM 通过静态编译、打包等技术在很大程度上解决了这些问题，同时针对 GraalVM 的一些使用限制，Spring 和 Dubbo 等主流框架也都提供了相应的 AOT 解决方案。 本文我们将详细分析 Java 应用在云时代面临的挑战，GraalVM Native Image 是如何解决这些问题，GraalVM 的基本概念与工作原理，最后我们通过一个 Spring6 + Dubbo3 的微服务应用示例演示了如何将一个普通微服务应用进行静态化打包。
在分布式系统中不可避免的会遇到网络故障，机器宕机，磁盘损坏等问题，为了向用户不中断且正确的提供服务，要求系统有一定的冗余与容错能力。RocketMQ 在日志，统计分析，在线交易，金融交易等丰富的生产场景中发挥着至关重要的作用，而不同环境对基础设施的成本与可靠性提出了不同的诉求。在 RocketMQ v4 版本中有两种主流高可用设计，分别是主备模式的无切换架构和基于 Raft 的多副本架构（图中左侧和右侧所示）。生产实践中我们发现，两副本的冷备模式下备节点资源利用率低，主宕机时特殊类型消息存在可用性问题；而 Raft 高度串行化，基于多数派的确认机制在扩展只读副本时不够灵活，无法很好的支持两机房对等部署，异地多中心等复杂场景。RocketMQ v5 版本融合了上述方案的优势，提出 DLedger Controller 作为管控节点（中间部分所示），将选举逻辑插件化并优化了数据复制的实现。
前台业务同学在业务承接过程中总是抱怨大部分业务无法通过设计模式来承接，写的代码是越来越没有追求，理由是我无法预测未来的业务的发展，且设计模式更多的是在框架或中间件中使用。然而设计模式是对能力抽象出的通用模式，从哲学的角度来看世间万物皆尘土，事物都是可以抽象出共同的本质的东西。所以，难道只有底层能力可以抽象，业务逻辑部分就不可以抽象了？必须可以才是啊。 在前台业务承接过程中除了能力可以抽象，还有可以抽象出业务流程，假设在有这样一些业务场景，品搜和图搜、直播间评论和点赞、公域直播会场和私域商详透直播等等，这些各领域内的业务流程“大同小异”，因此都可以抽象出通用的业务流程节点。 但是通常在一个主干流程需要承接的场景有很多，比如直播间互动这个主干流程包括了直播间评论、点赞、求讲解、看证书、进场等等场景，所以我们需要通过主要流程进行进行多场景承接。但是这样还不够，在面对多端型多场景的情况下需要处理返回不同的数据模型。 综上所述，我们如何通过一个主干业务流程承接多个业务场景并在数据上可适配到多端型多场景，实现在服务端高质量高效率的“包接口”，下面会详细介绍。
早在 2012 年淘宝开始无线化探索时，店铺页面就作为一个重要的业务形态出现在「淘宝APP」之中。店铺是电商交易核心链路中的重要一环，也是商家运营私域流量的一个重要载体。通过店铺平台，商家可以个性化装修自己的店铺页面，运营自己的会员粉丝，与消费者之间创造更多的连接，挖掘更大的价值。因此，店铺的开放属性也一直是店铺业务的重要能力之一。伴随着店铺产品的迭代升级、运营策略的升级、二方业务的不断接入、以及开放能力的增强和店铺定制化程度的提升，店铺框架在技术侧也在不断的演进升级中。 最早起的无线店铺形态，页面结构比较简单，装修模块只支持官方定制，无法开放给外部开发者进行定制。 店铺装修能力探索。提供了一套模块开放的 JSON 协议，店铺装修模块具备了一定的开放能力。但是 JSON 协议为非标准化协议，可读性差，难以组件化，无法实现复杂交互。 店铺样式动态化。基于高性能动态化框架 Weex 进行开发，对接前端完善的工具链和研发模式，符合前端开发习惯，有助于提升 ISV 生产力，同时支持动画、支持轻量级的组件扩展和 API 扩展，交互体验和端侧能力得到巨大提升。
