随着微服务体系在生产环境落地，也会伴随着一些问题出现，比如流量过大造成某个微服务应用程序的性能瓶颈、CPU利用率高、或内存泄漏等问题。要找到问题的根本原因，我们通常都会通过日志、进程再结合代码去判断根本原因。对于微服务庞大的业务，这必定会很耗时，而且也很难及时找到关键问题点。
因此，在实际的生产业务场景中，为了能够全方位地追踪每一个相关组件的行为轨迹，就需要一些能够可以帮助我们理解、追踪系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和暴露问题之间的相关关键点，从而高效地解决问题。基于上述痛点，此时，APM 系统便应运而生。
作者：覃志强，腾讯CSIG研发工程师。 |导语 微服务开发利器，网络调用链遥测，性能遥测。开发、测试、生产多套环境的链路与性能全在掌控之中，告别打日志定位性能问题的苦逼日子。首次优化，网络性能提升50%，后端接口请求量减少3/4。 01 前端系统架构 前端使用 Egg + React + SSR 框架，仅用户导航时首屏使用服务端渲染（SSR），之后使用客户端渲染（CSR），可确保用户在首屏与其它页面均有极致的用户体验。Node层，也负责一些Web安全处理，比如：CSRF、CSP、缓存控制等。 02 面
Tracing 是在上世纪 90 年代就已出现的技术，但真正让该领域流行起来的还是源于 Google 的一篇 Dapper 论文。分布式追踪系统发展很快，种类繁多，但无论哪种组件，其核心步骤一般有 3 步：代码埋点、数据存储和查询展示，如下图所示为链路追踪组件的组成。
在大型网站系统设计中，随着分布式架构，特别是微服务架构的流行，我们将系统解耦成更小的单元，通过不断的添加新的、小的模块或者重用已经有的模块来构建复杂的系统。随着模块的不断增多，一次请求可能会涉及到十几个甚至几十个服务的协同处理，那么如何准确快速的定位到线上故障和性能瓶颈，便成为我们不得不面对的棘手问题。
微服务和容器增加了Ticketmaster软件系统的复杂性。它的工程师用Jaeger解决了调试问题。Jaeger是Uber在CNCF孵化的一个开源追踪工具。
🎉各位亲爱的读者，大家好！我是猫头虎博主！在微服务架构中，如何追踪一个请求在多个服务之间的完整生命周期，是许多开发者和运维人员头疼的问题。Jaeger作为一个开源的分布式跟踪工具，为我们提供了答案。在这篇博客中，我将带领大家探索如何在服务网格中使用Jaeger来捕获、分析请求的跟踪信息，并提供深入的性能诊断。对于关心分布式跟踪、性能监控和服务网格的 热门词汇的朋友，这篇文章将为你打开一个新世界的大门！🚀
随着微服务架构的流行，客户端发起的一次请求可能需要涉及到多个或 N 个服务，致使我们对服务之间的监控和排查变得更加复杂。
现在越来越多的应用迁移到基于微服务的云原生的架构之上，微服务架构很强大，但是同时也带来了很多的挑战，尤其是如何对应用进行调试，如何监控多个服务间的调用关系和状态。如何有效的对微服务架构进行有效的监控成为微服务架构运维成功的关键。用软件架构的语言来说就是要增强微服务架构的可观测性（Observability）。
跟踪是一种用于监视软件的执行路径、以便进行调试或故障排除的专门的方法。您可能熟悉TRACE日志级别，其中包含有关每个方法调用的信息。跟踪微服务的目标类似于此级别的日志记录。在最高级别，从一个微服务到另一个微服务的跟踪，讲述了事务或请求在通过基于微服务的系统传播时的路径。
Istio 是 Service Mesh（服务网格）的主流实现方案。该方案降低了与微服务架构相关的复杂性，并提供了负载均衡、服务发现、流量管理、断路器、监控、故障注入和智能路由等功能特性。
与日志记录和可观察性一样，分布式追踪是保持服务健康和可预测的关键功能。与日志和可观察性（显示服务上发生了什么）相反，追踪允许开发人员和操作人员遵循特定的请求，以及它如何调用不同的服务和依赖关系。它是围绕微服务架构设计的，而微服务架构不同于单体架构，它使用许多小型服务来运行一个平台。这些服务彼此通信，也与外部服务通信，以提供和存储用户请求的信息。
应用架构是一个系统的高级结构。它是关于系统的一系列决策，包括系统的组成部分、这些部分之间的交互，以及对这些部分的引导性指南。这些决策通常是由企业的IT团队和关键干系人员共同作出的。
随着系统微服务架构在企业全面的推进和落地的过程中，系统业务的复杂性以及系统服务数量越来越多的情况下，开发和测试不得不面对复杂的服务调用关系，在生产环境出问题的情况下，线上排查定位故障的成本会大幅度的增加，为了解决这个问题需要搭建基于分布式架构的全链路追踪监控系统。分布式系统追踪的英文单词是Distributed Tracing System，使用分布式追踪系统可实现追踪微服务架构中的故障跟踪与定位，以及网络结构和调用链的分析等。分布式追踪系统在结构上来说，主要分为如下几个部分：
随着微服务架构的流行，系统变得越来越复杂，单体的系统被拆成很多个模块，各个模块通过轻量级的通信协议进行通讯，相互协作，共同实现系统功能。
这个博客最初是由Ayrat Khayretdinov在CloudOps博客上发布
微服务全链路跟踪：jaeger集成istio，并兼容uber-trace-id与b3
随着业务的发展，所有的系统都会走向微服务化体系，微服务进行拆分后，服务的依赖关系变得复杂，如果出现了错误和异常，定位的过程将会变得复杂，一个请求可能需要调用很多个服务，所以微服务架构中，分布式链路跟踪的实现至关重要，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见。如何快速查询整个请求链路上的信息并呈现出来是解决排查问题复杂度的根本方法。
Istio集成了丰富的工具，可以为您的微服务环境添加跟踪、遥测、日志记录和其它功能。本次会议重点讨论大量的工具（包括几个CNCF项目）如何共同工作以提供Istio的全部功能。
在基于微服务的云原生架构中，客户端的一次服务调用，会产生包括服务和中间件在内的众多调用关系。对这些大量复杂的调用过程进行追踪，对于微服务的安全性分析、故障定位、以及性能提升等，有着重要的作用。
Trace 并不是一个新的概念，随着软件商业化伊始，如何迅速定位生产环境是工程师们不断探索的方向。早期的软件架构大多为 CS 结构（Client and Server）。每个语言为了提供方便快捷的方式让工程师解决问题，在 Log，Debug 和 Trace 上一直没少下功夫。
在近几个月对某产品后台微服务的SLI建设过程中，逐渐意识到这类监控的最佳方式还是通过jaeger/opentracing这类链式tracing才能以最佳的监控数据结构提供全链路的数据监控
作者：软件质量保障 知乎：https://www.zhihu.com/people/iloverain1024
OpenTelemetry 是一种开源的可观测性框架，提供一组 API 和库，用于收集、处理和导出遥测数据，如追踪、指标和日志。它允许开发人员以最小的开销来检测他们的应用程序，并提供一种收集和导出遥测数据的标准化方法。
Jaeger [ˈdʒɛgər] 是Uber公司开发的一套分布式追踪系统，受启发于 dapper 和 OpenZipkin，兼容 OpenTracing 标准，CNCF的开源项目。
在构建应用程序时，了解系统的行为方式是运维它的重要部分——这包括能够观察应用程序的内部调用、衡量其性能并在问题发生时能够立即找到问题。这对任何系统来说都是具有挑战性的，对于由多个微服务组成的分布式系统更是如此，其中由多个调用组成的流可能在一个微服务中开始，但在另一个微服务中继续调用。可观测性在生产环境中至关重要，在开发过程中对于了解瓶颈、提高性能和跨微服务执行基本调试也很有用。
微服务架构管理中最大的挑战之一是如何通过简单方法就能了解系统各个组件之间的关系。终端用户的一次会话可能会流经多个甚至几十个独立部署的微服务，因此，发现哪里有性能瓶颈或错误变得尤为重要。
Salt Security 曾部署了 OpenTelemetry ，但发现其不足。因此，公司工程师评估了 Helios ，该工具可以为快速故障排除提供分布式跟踪的可视化。
最近在做微服务构架里有关调用链跟踪（也有叫分布式追踪）的部分，有一些心得，这里总结一些。
你可能已经知道Kubernetes是领先的容器编排系统。根据最新的CNCF 研究，可能已经将它用于生产工作负载或在未来一年考虑使用它。2021 年的研究发现，惊人的 96% 的受访者正在使用 Kubernetes 或计划在不久的将来使用它——而 69% 的受访者目前正在生产中使用 Kubernetes。Kubernetes 为大型组织和小型组织提供了许多好处：它提高了开发人员的生产力、降低了成本、提高了效率，并最终为最终用户带来了更好的体验。
在分布式系统建设的过程中，我们思考的重点不是避免故障，而是拥抱故障，通过构建高可用架构体系来获得优雅应对故障的能力。QQ音乐高可用架构体系包含三个子系统：架构、工具链和可观测性。
通过上一次技术阅读摘要，我们了解了分布式链路追踪这项技术，Jaeger是其主流的实现方案。
在一个微服务分布式架构的系统中，可能存在复杂的、深层的层层服务调用关系，大致如下图
相比传统的“巨石”应用，微服务的一个主要变化是将应用中的不同模块拆分为了独立的进程。在微服务架构下，原来进程内的方法调用成为了跨进程的RPC调用。相对于单一进程的方法调用，跨进程调用的调试和故障分析是非常困难的，很难用传统的调试器或者日志打印来对分布式调用进行查看和分析。
在本系列中，我们将构建一个基于NodeJS微服务，并使用Docker Swarm集群进行部署。
导语 | 故障是开发者高频关注的问题。在分布式系统建设的过程中，我们思考的重点不是避免故障，而是拥抱故障，通过构建高可用架构体系来获得优雅应对故障的能力。本文作者冯煦亮从架构、工具链、可观测三个维度，介绍了QQ音乐多年来积累的高可用架构实践。期望对你有帮助。 QQ音乐高可用架构体系全景 故障无处不在，而且无法避免。在分布式系统建设的过程中，我们思考的重点不是避免故障，而是拥抱故障，通过构建高可用架构体系来获得优雅应对故障的能力。QQ音乐高可用架构体系包含三个子系统：架构、工具链和可观测性。 架构：架构包
Hello folks，我是 Luga，今天我们来聊一下可观测生态领域相关的技术 - Distributed Tracing（分布式追踪）。
前面我们学习了 Istio 中的流量管理功能，本节我们来学习如何配置 Istio来自动收集网格中的服务遥测。Istio为网格内所有的服务通信生成详细的遥测数据，这种遥测技术提供了服务的可观察性，使运维人员能够排查故障、维护和优化应用程序，而不会给服务的开发人员带来任何额外的负担。通过 Istio，运维人员可以全面了解到受监控的服务如何与其他服务以及Istio组件进行交互。
今天开始开新坑——把Spring Boot 微服务部署到容器平台（K8S，OpenShift）上！
在生产环境中运行系统涉及到对高可用性、弹性和故障恢复的要求。在运行云原生应用程序时，这一点变得更加关键，因为在这种环境中，基本的假设是计算节点会中断，Kubernetes节点会宕机，微服务实例可能会失败，而服务预计会继续运行。
其中，最为核心的问题莫过于微服务分布式性质导致的运行问题，以及带来的 2 个至关重要的挑战：
基于解决不同行业、业务应用的可扩展性、可用性等一系列问题，由此而生的微服务架构得到了各大厂商的、组织以及个人的青睐，随之而来便广泛应用于各种行业场景应用中。然而，随着时间的推移，越来越多的问题慢慢地呈现在大众的视野中。
K8S 容器云平台(如: K8S, OpenShift, Rancher, 博云, 才云, DaoCloud...) 是基于K8S的容器即服务(CAAS)和平台即服务(PAAS)的平台. 提供完整的企业级PAAS平台能力:
🐯 猫头虎博主报道！随着微服务的流行，分布式追踪已经成为了维护大规模系统的关键工具。我发现有很多技术同仁在搜索 “分布式追踪基础”、“OpenTracing 教程” 或 “如何配置 OpenTracing”。因此，我决定深入探讨 OpenTracing，并与大家分享如何在实际环境中应用它。无论你是刚接触还是想进一步掌握，这篇文章都会给你提供所需的知识。🚀
对于微服务实现或云原生架构来说，其中一个非常重要的点就是可观测性，分布式服务的本质决定了需要对它进行有效的度量与观测。
作者 ｜张怀龙、张海文 编辑｜邓艳琴 本文整理自中国移动云能力中心高级软件工程师、Istio 社区 Member 张海文和 Intel 云原生开发工程师、Istio 的维护者和 Linkerd 的开发者张怀龙老师在 QCon 全球软件开发大会（北京站）的演讲《移动云服务网格双栈技术的实践之路》。下载完整幻灯片地址如下：https://qcon.infoq.cn/202302/beijing/presentation/4898 背景介绍 众所周知，由于 IPv4 地址的消耗殆尽，且在未来 5G
作者 | Alex Soto 译者 | 张卫滨 策划 | 丁晓昀 为何需要微服务特性？ 在微服务架构中，应用程序是由多个相互连接的服务组成的，这些服务协同工作以实现所需的业务功能。 所以，一个典型的企业级微服务架构如下所示： 最初，我们可能认为使用微服务架构实现一个应用程序是很容易的事情。但是，要恰当地完成这一点并不容易，因为我们会面临一些新的挑战，而这些挑战是单体架构所未曾遇到的。举例来讲，这样的挑战包括容错、服务发现、扩展性、日志和跟踪等。 为了应对这些挑战，每个微服务都需要实现在 R
很多同学表示，对于微服务中常用的调用链功能的原理，感觉很模糊。本文将真正的从零开始，介绍调用链客户端开发的一些要点。让你瞬间拥有APM开发经验。文章很长很长，照例看一下相关目录。
随着分布式技术的发展与演进，微服务技术成为了大型分布式IT架构的必然选择。从本质上来讲，微服务是一种架构风格，将一个大型的系统拆分为多个拥有独立生命周期的应用，应用之间采用轻量级的通信机制进行通信。这些应用都是围绕具体业务进行构建，可以独立部署、独立迭代，也可能根据业务负载独立的水平扩展。微服务思想以及相关的技术为IT架构的发展带来了一系列深刻的变革。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
