Serverless架构在今天已经不再是新鲜的事物。该架构具有多个特点：较低的运营和开发成本、能快速上线、自动扩展、安全性高和适合微服务等。各大云服务商也提供了各自的Severless解决方案。然而，尽管Serverless架构在某些方面表现出色，但在当前轰轰烈烈的“微服务”进程中，它仍然不是一种主要的选择。除了由于本身特性导致的使用场景受限外，我想乏善可陈的关于Serverless最佳实践的总结也是一个重要的因素。我有幸参与了一项基于AWS搭建的Serverless (FaaS) 系统的开发工作，该系统提供了一组核心服务。通过几次系统故障调研和性能优化的实际体验，我发现系统监控在Serverless架构中至关重要。所以本文将从Serverless系统监控的角度来展开一些讨论。
对于复杂问题的思考其实是有层次的，从最表面的事件，到事件背后的规律，再到这个问题的结构模式，再到价值观，层层递进。在画完自己的业务系统因果回路图之后，再结合这个心智模型，思考自己的思考在哪个层次，是否可以有机会再下钻到更深的层次。
在本地生活场景下，需要LLM承担不同的功能，prompt输出结果稳定性也需要进一步探索。本文是对Prompt的一些学习笔记和初步尝试的总结，希望给大家做参考。
近日（美国东部时间7月12日），CNCF通过官网宣布，Istio正式成为毕业项目，理由是作为一个快速增长的服务网格产品，为该领域增添了更多的终端用户、产品特性和维护者，达到了基金会的最高成熟度。 这距离Istio加入CNCF也仅仅过去1年的时间。 如果将Istio诞生的2017年看作服务网格元年，那么到今天为止，它已经走过了6个年头。 作为该领域的典型代表，Istio的发展历程可以看做是服务网格的浓缩史。历经多年的演进和迭代，Istio也从萌新转向成熟，它在流量控制、安全和可观测方面的能力也被越来越多的人所了解。 而服务网格领域的开发者们依然在探索着各种新的可能性。本文会基于服务网格的架构演化来阐述目前有哪些新的产品形态和技术方向值得我们关注。
火山引擎DataLeap作为一站式数据中台套件，汇集了字节内部多年积累的数据集成、开发、运维、治理、资产、安全等全套数据中台建设的经验，助力企业客户提升数据研发治理效率、降低管理成本。 Data Catalog是一种元数据管理的服务，会收集技术元数据，并在其基础上提供更丰富的业务上下文与语义，通常支持元数据编目、查找、详情浏览等功能。目前Data Catalog作为火山引擎大数据研发治理套件DataLeap产品的核心功能之一，经过多年打磨，服务于字节跳动内部几乎所有核心业务线，解决了数据生产者和消费者对于元数据和资产管理的各项核心需求。 Data Catalog系统的存储层，依赖Apache Atlas，传递依赖JanusGraph。JanusGraph的存储后端，通常是一个Key-Column-Value模型的系统，本文主要讲述了使用MySQL作为JanusGraph存储后端时，在设计上面的思考，以及在实际过程中遇到的一些问题。
本专题共10篇内容，包含淘宝APP基础链路过去一年在用户体验数据科学领域（包括商详、物流、性能、消息、客服、旅程等）一些探索和实践经验，本文为该专题第三篇。 在商详页基于用户动线和VOC挖掘用户决策因子带来浏览体验提升；在物流侧洞察用户求助时间与实际物流停滞时长的关系制订表达策略带来物流产品满意度提升；在性能优化域构建主客观关联模型找到启动时长与负向反馈指标的魔法数字以明确优化目标；构建多源VOC标签体系综合运用用户行为和用户VOC洞察、落地体验优化策略，并总结出一套用户体验分析方法论。
在 Web 3D 渲染场景中，使用建模软件构建好的 3D 模型文件，模型的细节越精细对应的文件体积也会越大，考虑到 Web 下网络传输的影响，往往会对 3D 模型文件应用压缩算法以减少文件体积，此时就需要在 Web 端对经过压缩的模型进行快速高效的解码。WebAssembly 在 CPU 计算密集的场景有着更优的性能，同时结合 Web Worker 一起使用的话，还不会阻塞渲染主线程，非常适合用来实现 3D 模型解码的解码器（以下简称 decoder）。 本文将以 glTF 格式的 3D 模型为例，介绍实际业务场景中是如何应用 WebAssembly 来实现 3D 模型的解码。首先，本文将简要介绍保时捷礼物的业务背景和 glTF 格式相关压缩算法；其次，分别介绍基于 WebAssembly 的 Draco 和 Meshopt 两种压缩算法的解码器实现；最后，在保时捷业务场景中尝试应用 glTF 两种压缩算法，并对 glTF 模型的不同压缩率和模型加载耗时进行了对比。
JavaScript 作为解析型脚本语言，它的运行速度，一直是其被诟病的一个点。WebAssembly 技术的出现，且被各主流浏览器所支持，让我们在 Web 应用中，使用新技术，突破 JavaScript 引擎的速度局限，有了新的可能。JavaScript 是动态类型语言，WebAssembly 是静态语言编译的产物，理论上 WebAssembly 的运行速度，能比 JavaScript 快好几倍。在本文中，我们将讨论如何对 Web 前端应用优化，从而提高框架以及业务代码的整体性能。
随着 5G 时代的到来，多媒体音视频、特效在 5G 时代下会迎来新的云端的挑战，同时也会催生更多的跟云端相关的业务场景。因此我们需要规划云端的建设，把音视频和特效在移动端积累的能力和经验复制扩展到云端，在云端全面打磨提升音视频能力，支持公司更多业务创造更大价值。同时随着 WebAssembly 的逐步成熟，也给了我们将编辑 SDK 放到 Web 运行的机会。 本文首先帮大家回顾一下 WebAssembly 的一些基本情况，然后将介绍 Web 视频编辑所依赖的关键特性的情况，以及再迁移过程中我们遇到的问题和解决思路。
目前 PC Web 侧实现直播推流通常基于 WebRTC 技术，视频编码为 H264/VP8 格式，音频编码为 Opus 格式，而通常的下行直播分发协议如 Flv、Hls 等挟带的视频数据编码格式为 H264，音频数据编码格式为 AAC，这中间存在流媒体服务器需要将 Opus 音频转码为 AAC 音频的工作，增加了流媒体服务器转码成本和转码稳定性问题。如果能够在直播推流时直接推送 AAC 音频数据，就可以省去流媒体服务器音频转码部分的开销。为了解决推流 AAC 的问题，我们选择在 Web 侧自己实现推流能力。 推流主要分三部分工作，音视频采集、编码、上行传输。采集借助浏览器暴露的摄像头、麦克风采集 API，视频编码借助 WebCodec API，传输借助 WebSocket、WebTransport API。只有音频编码的工作由于目前 WebCodec 暂不支持对 AAC 音频格式的编码，需要寻找音频编码的替代方案。 音视频编解码工作是 CPU 密集型任务，业界相关方案实现大多基于 C/C++ 语言编写。这其中，FFmpeg 作为多媒体处理领域强大的软件实现，提供了简洁的 API
