“效率”作为得物技术部的关键词之一，大家在研发效能、会议效率、协作效率、办公效率等方面一直进行着持续地探索。在实际落地的过程中，为了更好地评估应用效果，往往需要将定性描述转换为可量化的数据指标。这些数据指标可以帮助我们了解研发过程中的变化和趋势。但是你真的能“读懂”这一堆冷冰冰的数字吗？ 在看到这些数据指标时，我们往往很容易陷入一个误区：只关注具体的数字，而忽视了数据采集和分析解读的过程。这意味着即使我们对这些指标进行了定期监控，我们仍然不能真正了解研发过程中的状况和障碍。 因此，如何正确地解读这些数据指标变得尤为重要。为了有效解读数据，我们需要了解数据来源和分析过程，以及数据指标与业务实际情况之间的关系。只有这样，我们才能更好地理解我们所面临的问题和挑战，并且采取适当的措施来加以解决。
随着企业规模的不断扩大，传统单体应用已很难进一步支持业务的发展，业务的迭代速度已经难以满足业务的增长，此时企业会对应用系统做微服务化的改造，降低业务的耦合度，提升开发迭代的效率，让开发更加敏捷。 系统架构微服务化的，原本的愿景是希望通过将系统的颗粒度变小，提升业务的迭代效率。但是在实践微服务架构的过程中，尤其是在服务数量越来越多之后，那么引发的效率问题可能会大于微服务架构本身所带来的架构红利。
Java 应用在云计算时代面临“冷启动”慢、内存占用高、预热时间长等问题，无法很好的适应 Serverless 等云上部署模式，GraalVM 通过静态编译、打包等技术在很大程度上解决了这些问题，同时针对 GraalVM 的一些使用限制，Spring 和 Dubbo 等主流框架也都提供了相应的 AOT 解决方案。 本文我们将详细分析 Java 应用在云时代面临的挑战，GraalVM Native Image 是如何解决这些问题，GraalVM 的基本概念与工作原理，最后我们通过一个 Spring6 + Dubbo3 的微服务应用示例演示了如何将一个普通微服务应用进行静态化打包。
在分布式系统中不可避免的会遇到网络故障，机器宕机，磁盘损坏等问题，为了向用户不中断且正确的提供服务，要求系统有一定的冗余与容错能力。RocketMQ 在日志，统计分析，在线交易，金融交易等丰富的生产场景中发挥着至关重要的作用，而不同环境对基础设施的成本与可靠性提出了不同的诉求。在 RocketMQ v4 版本中有两种主流高可用设计，分别是主备模式的无切换架构和基于 Raft 的多副本架构（图中左侧和右侧所示）。生产实践中我们发现，两副本的冷备模式下备节点资源利用率低，主宕机时特殊类型消息存在可用性问题；而 Raft 高度串行化，基于多数派的确认机制在扩展只读副本时不够灵活，无法很好的支持两机房对等部署，异地多中心等复杂场景。RocketMQ v5 版本融合了上述方案的优势，提出 DLedger Controller 作为管控节点（中间部分所示），将选举逻辑插件化并优化了数据复制的实现。
本文介绍了什么是分布式ID，分布式ID的业务场景以及9种分布式ID的实现方式，同时基于vivo内部IT的业务场景，介绍了自研鲁班分布式ID服务的实践。
OpenStack 社区发布了其第 27 个软件版本，又回到了字母表的开始。由于其充满激情和活跃的贡献者基础，OpenStack 仍然是世界上五大最活跃的开源项目之一。全球各行各业的组织都拥抱了 OpenStack，在生产中达到了 4000 万核心的计算量 [1]。在这个足迹中，OpenStack 驱动的公共云的采用现在遍布全球 300 多个数据中心。 除了 OpenStack，OpenInfra Foundation[2] 复制了它的模型，用于托管开源项目，包括 Kata Containers、StarlingX 和 Zuul。现在，任何想要利用 Four Opens[3] 和三种力量构建可持续的基础架构层开源项目的组织都可以轻松使用这个模型。
对于去哪儿平台而言，酒店业务主要是通过整合不同货源，对客提供优质低价酒店。而我们本次提到的 SPA 系统（全称 supplier-product-adapter，中文全称为供应商产品报价适配系统），负责接入供应商的酒店信息以及报价信息，为上层应用提供了统一格式的报价数据。其在酒店业务定位中处于一个非常关键的位置。
