随着 Docker 和 Kubernetes 的出现，一个庞大的单体应用可以被拆分成多个独立部署的微服务，并被打包运行于对应的容器中。不同应用之间相互通信，以共同完成某一功能模块。微服务架构与容器化部署带来的好处是显而易见的，它降低了服务间的耦合性，利于开发和维护，能更有效地利用计算资源。当然，微服务架构也存在相应的缺点： 强依赖于SDK，业务模块与治理模块耦合较为严重。除了相关依赖，往往还需要在业务代码中嵌入SDK代码或配置。 统一治理难。每次框架升级都需要修改 SDK 版本，并重新进行回归测试，确认功能正常后再对每一台机器重新部署上线。不同服务引用的 SDK 版本不统一、能力参差不齐，增大了统一治理的难度。 缺少一套统一解决方案。目前市场不存在一整套功能完善、无死角的微服务治理与解决方案。在实际生产环境往往还需要引入多个治理组件来完成像灰度发布、故障注入等功能。 为解决这些痛点，Service Mesh诞生了。以经典的side car模式为例，它通过在业务 Pod 中注入 Sidecar 容器，对代理流量实施治理和管控，将框架的治理能力下层到 side car 容器中
在 Gartner 发布的《2023 年十大战略技术趋势》[1]报告中,「应用可观测性」再次成为热门趋势。用户需要建立可观测体系来统筹、整合企业数字化所产生的指标数据，并以此为基础进行反馈并制定决策，这对于提高组织决策有效性和及时性，将是最强有力的支撑。 新需求带来新革命，Prometheus 产品应运而生，引领新一轮可观测技术革命。得益于良好的产品设计，Prometheus 部署与轻度使用体验非常流畅：敲两三个命令就能运行起来，配置几行 yaml 就能收集数据，编辑一个规则就能触发告警，再配合上 Grafana，写一句 PromQL 就能画出趋势图表。一切简单而美好，仿佛SRE光明的未来正向我们招手，这一切来的太突然，它真的如此轻易么？ 当然不是。 Prometheus 用良好的用户接口掩盖了内部复杂实现。深入其中，我们会看到时序数据存储、大规模数据采集、时间线高基数、数据搅动、长周期查询、历史数据归档等等。像潜藏在宁静湖面下磨牙吮血的鳄鱼，静待不小心掉进坑中的 SRE 们。
闲鱼作为C2C电商交易平台，消息系统是导购链路上关键的一环。用户依赖聊天建立买家与卖家的信任，进一步获取商品信息。闲鱼消息的稳定性直接影响到闲鱼用户体验，成交效率。 为强化闲鱼消息系统的稳定性，保障用户体验。闲鱼消息团队在2022年8月份对消息系统稳定性进行了体系化治理。本文将从闲鱼消息团队视角出发，讲讲我们怎么做稳定性治理。
iLogtail 作为一款阿里云日志服务（SLS）团队自研的可观测数据采集器，拥有的轻量级、高性能、自动化配置等诸多生产级别特性，可以部署于物理机、虚拟机、Kubernetes 等多种环境中，用于采集文件、容器输出、指标等各类可观测数据。iLogtail 的核心定位是帮助开发者构建统一的数据采集层，助力可观测平台打造各种上层的应用场景；此外，对于一些寻求轻量计算的场景，也可以使用 iLogtail 承担一些数据聚合、数据过滤、数据路由等功能。
