分布式链接跟踪服务
微服务已成为未开发应用程序的默认选择。 毕竟，从业人员认为，微服务提供了完全数字化转型所需的解耦类型，从而使各个团队的创新速度比以往任何时候都快。
微服务只不过是常规的分布式系统，只是规模更大。 因此，它们加剧了任何分布式系统都面临的众所周知的问题，例如对跨流程边界的业务交易缺乏可见性。
鉴于在生产环境中同时运行单个服务的多个版本（在A / B测试方案中或在遵循Canary发布技术推出新版本的过程中）是非常普遍的，事实上，我们正在谈论数百种服务，很显然，我们所拥有的是混乱的。 几乎不可能映射相互依赖关系并了解跨服务及其版本的业务交易的路径。
最终会发生。可观察性
当我们可以根据发出的度量，日志和跟踪了解系统状态时，就可以观察到该系统。 鉴于我们正在谈论分布式系统，仅了解单个服务的单个实例的状态还不够。 我们需要能够汇总给定服务的所有实例的指标，也许按版本分组。 像Prometheus这样的度量解决方案在解决可观察性问题的这一方面非常受欢迎。 同样，我们需要将日志存储在中央位置，因为无法从每个服务的各个实例分析日志。 Logstash通常在此处与后备存储（例如Elasticsearch）结合使用。 最后，我们需要获取端到端的跟踪信息，以了解给定交易采取的路径。 这就是分布式跟踪解决方案发挥作用的地方。
分布式跟踪
在整体式Web应用程序中，日志框架提供了足够的功能，可以在发生某些故障时进行基本的根本原因分析。 开发人员只需要在代码中放置日志语句即可。 诸如“上下文”（通常为“线程”）和“时间戳”之类的信息会自动添加到日志条目中，从而使您更容易理解给定请求的执行并使条目相关。
Thread-1 2018-09-03T15:52:54+02:00 Request started
Thread-2 2018-09-03T15:52:55+02:00 Charging credit card x321
Thread-1 2018-09-03T15:52:55+02:00 Order submitted
Thread-1 2018-09-03T15:52:56+02:00 Charging credit card x123
Thread-1 2018-09-03T15:52:57+02:00 Changing order status
Thread-1 2018-09-03T15:52:58+02:00 Dispatching event to inventory
Thread-1 2018-09-03T15:52:59+02:00 Request finished
我们可以肯定地说，第二日志条目上面，因为它是在不同的线程中执行不相关的其他条目。
在微服务体系结构中，仅日志记录无法提供完整的信息。 该服务是呼叫链中的第一个服务吗？ 在库存服务（我们显然在其中调度了一个事件）发生了什么？
回答此问题的常用策略是在交易的第一个构建块中创建一个标识符，并在所有调用中传播该标识符，可能是在进行远程调用时将其作为HTTP标头发送。
然后，在中央日志收集器中，我们可以看到以下条目。 请注意，我们如何可以登录相关ID（本例中的第一列），所以我们知道，第二项不相关的其他条目。
abc123 Order 2018-09-03T15:52:58+02:00 Dispatching event to inventory
def456 Order 2018-09-03T15:52:58+02:00 Dispatching event to inventory
abc123 Inventory 2018-09-03T15:52:59+02:00 Received `order-submitted` event
abc123 Inventory 2018-09-03T15:53:00+02:00 Checking inventory status
abc123 Inventory 2018-09-03T15:53:01+02:00 Updating inventory
abc123 Inventory 2018-09-03T15:53:02+02:00 Preparing order manifest
该技术是任何现代分布式跟踪解决方案的核心概念之一，但并不是真正的新技术。 关联日志条目已有数十年的历史，可能与“分布式系统”本身一样古老。
与常规日志记录区别开来的是分布式跟踪，因为保存跟踪数据的数据结构更加专业，因此我们也可以确定因果关系。 查看上面的日志条目，很难判断最后一步是由上一个条目引起的，还是同时执行的，或者它们是否共享同一个调用者。 具有专用的数据结构还可以使分布式跟踪不仅可以记录单个时间点中的消息，还可以记录给定过程的开始和结束时间。
跟踪显示跨度类似于上述日志
大多数现代的分布式跟踪工具都受到2010年有关Dapper的论文的启发， Dapper是Google使用的分布式跟踪解决方案。 在该论文中，上述数据结构称为跨度，您可以在上图中看到其中的九个。 这种跨度的特殊“森林”称为跟踪，它等效于我们之前看到的相关日志条目。
上图是在Jaeger中显示的跟踪的屏幕快照， Jaeger是由Cloud Native Computing Foundation（CNCF）托管的开源分布式跟踪解决方案。 它用一种颜色标记每个服务，以便于查看过程边界。 通过查看屏幕顶部或各个跨度上的宏时间轴，可以轻松地看到定时信息，从而可以感觉到每个跨度需要多长时间以及在此特定执行中有多大影响力。 当进程是异步的时也很容易观察到，因此可能会超出初始请求。
像日志记录一样，我们需要用我们想要记录的数据注释或检测我们的代码。 与日志记录不同，我们记录跨度而不是消息，并进行一些划分以了解跨度何时开始和结束，以便我们可以获得准确的时序信息。 因为我们可能希望使我们的业务代码独立于特定的分布式跟踪实现，所以我们可以使用诸如OpenTracing之类的API，而将有关具体实现的决定保留为打包或运行时问题。 以下是显示这种划分的伪Java代码。
try
( Scope scope
= tracer.
buildSpan
(
"submitOrder"
) .
startActive
(
true
)
)
{
scope.
span
(
) .
setTag
(
"order-id" ,
"c85b7644b6b5"
)
;
chargeCreditCard
(
)
;
changeOrderStatus
(
)
;
dispatchEventToInventory
(
)
;
}
鉴于分布式跟踪概念的本质，很明显，在我们的业务服务之间执行的代码也可以成为跟踪的一部分。 例如，我们可以打开 Istio的分布式跟踪集成， Istio是一种服务网格解决方案，可帮助微服务之间进行通信，并且突然之间我们将对网络延迟和在此层做出的路由决策有更好的了解。 另一个示例是OpenTracing社区中所做的工作，旨在为流行的堆栈，框架和API（例如Java的JAX-RS ， Spring Cloud或JDBC）提供工具 。 这使我们能够看到我们的业务代码如何与中间件的其余部分交互，了解潜在的问题可能发生的位置，并确定最佳的改进领域。 实际上，当今的中间件工具是如此丰富，以至于通常只使用所谓的“框架工具”就可以开始分布式跟踪，而使业务代码中没有任何与跟踪相关的代码。
虽然如今微服务架构对于成熟的公司来说是不可避免的，它需要更快的创新和雄心勃勃的初创公司才能实现Web规模，但是当某些事情最终失败并且没有合适的工具时，在进行根本原因分析时很容易会感到无助。 好消息是诸如Prometheus，Logstash，OpenTracing和Jaeger之类的工具为您的应用程序带来了可观察性。
JuraciPaixãoKröhling将介绍我的微服务正在做什么？ 在10月22日至24日在苏格兰爱丁堡举行的欧洲开源峰会上 。
翻译自: https://opensource.com/article/18/9/distributed-tracing-microservices-world
分布式链接跟踪服务
1705
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
