前言、理论，实践请参考 微博增值团队可观测性探索与实践-初探 、微博增值团队可观测性探索与实践-实践 强烈建议优先阅读。 提前说明一下，本人现在已经从微博离职了，这篇文章算是对我过去两年多关于可观测性相关工作的反思与回顾吧。 截止23年3月末，微博增值团队从上线一站式可观测平台到现在也运行了差不多两年的时间了。在这两年里，团队成员通过一站式可观测平台不断优化和改进服务，提高了整体系统的性能与稳定性（3个9到4个9，tp99 case by case优化，平均下降 100ms），同时降低了问题发现和定位的时间（5分钟发现问题，30分钟内定位问题），从而使开发人员能够更专注于创新和业务发展。
随着作者工作年限的增长，因为经历的多、思考的多和总结的多，慢慢积累了一些自认为有价值的观点，希望对刚毕业进入职场的同学们有所帮助。
我们知道，若要保证一个系统的稳定运行，那么对于这个系统的监控是不可或缺的环节。当今在云原生领域中，Prometheus 作为已经毕业的 CNCF 项目，已经成为了非常主流的监控和报警工具。但它也存在一些缺点，例如：默认情况下，其数据存储于本地文件的 TSDB 中，不利于容灾和做数据管理，若用于生产一般需要搭配第三方的如 InfulxDB 进行使用。大数据量的场景下，指标的收集和管理性能存在一定的瓶颈。 而我们今天介绍的 VictoriaMetrics 可以认为是 Prometheus 在上述问题上的一个增强版。它不仅能作为时序数据库结合 Prometheus 使用进行指标的长期远程存储，也能单独作为一个监控解决方案对 Prometheus 进行平替。
随着历史业务不断迭代和业务场景越来越复杂，携程用车、租车（简称两车）面临历史技术债和系统复杂度越来越高带来的理解、维护、迭代困难等问题，我们开始寻求如何更有效的降低复杂度和提升效率的方法。 本文描述了两车如何利用DDD（Domain-driven Design，领域驱动设计）方法论降低系统复杂度以及在重构历史系统中的取舍和思考。对于复杂业务场景下的领域驱动设计具有借鉴意义。
目前，美团内部每天产生的慢查询数量已经超过上亿条。如何高效准确地为慢查询推荐缺失的索引来改善其执行性能，是美团数据库研发中心面临的一项挑战。为此，我们与华东师范大学开展了科研合作，在AI领域对索引推荐进行了探索和实践，并将基于代价的方法和新提出的基于AI+数据驱动的方法共同应用于慢查询的索引推荐，成功提升了推荐效果。
随着微服务技术的快速发展，其在各个领域都形成了一系列事实标准，在 Kubernetes 和容器技术加持下，云原生微服务已经成为了主流解决方案。而 Go 语言作为云原生领域最受欢迎的开发语言，正被越来越多的企业作为微服务开发的首选语言，其中比较流行的包括 Go-micro、Go-zero、Dubbo-go 等。作为 Dubbo 微服务体系中多语言实现的一员，在 2022 年 Dubbo-go 以微服务领跑者的角色积极拥抱云原生标准，探索了 Proxyless Mesh 形态，配合适配 Pixiu 云原生网关，形成了完善的 Dubbo-go 微服务生态矩阵。 以 Dubbo-go 为中心的微服务体系在多个知名企业中成功落地和实践，框架的稳定性在实际场景下经受住了考验。截止今年已有 60+ 家企业在我们的用户列表中登记，其中较为典型案例请参考文章《小米电商 Apache Dubbo-go 微服务实践》。小米电商选用了 Dubbo-go + Nacos + sidecar + etcd + mirpc 为核心的微服务体系，除了看中了 Dubbo-go 的互联互通和服务治理能力
当周末躺在被窝里，点外卖时；双 11 的零点，疯狂提交订单时；假期和基友激情开黑，五杀超神…在这个精彩纷呈的互联网世界里，这些应用背后又隐藏着什么？每一次点击行为在 IT 世界里会流经哪些节点，调用哪些服务，带来哪些变化？这一切庞杂且精密，超出了人力探索的边界，而分布式链路追踪就是追溯请求在 IT 系统间流转路径与状态的一门技术。接下来，让我们通过对分布式链路追踪的来了解这个 IT 世界！ 说到分布式链路追踪，就绕不开分布式系统与微服务的兴起。早期 IT 系统非常简单，几乎所有程序都运行在同一个节点，互相之间也没有什么依赖。但随着硬件技术突飞猛进，硬件成本大幅下降，软件复杂度却越来越高。单一系统性能无法满足复杂的数据计算任务，而软件逻辑的复杂性也导致维护成本大幅上升。另外，单节点的可靠性也难以保障，不可避免的会偶尔出现宕机等行为，影响软件的可用性。“性能、可维护性和可用性”这三大因素促使了分布式系统与微服务的诞生。
在日常生活中，我们可能都经历过以下场景：去医院看病就诊，但预约页面迟迟无法打开；新款手机发布日促销秒杀，下单页面一直卡住转菊花；游戏大版本更新，在线人数过多，导致人物一直在“漂移”。这些问题令产品体验变得非常差，有耐心的同学还会吐槽几句，没耐心的同学早已转身离开。试想一下，作为该系统开发/运维人员，又该如何避免此类问题发生，或者快速定位止损？
