花里胡哨的分布式微服务远不如日志追踪更好用

现在微服务架构盛行，很多以前的单体应用服务都被拆成了多个分布式的微服务，以解决应用系统发展壮大后的开发周期长、难以扩展、故障隔离等挑战。

分布式微服务远不如单体应用可靠

看起来像不是什么坏事，但是现在企业跟风使用微服务架构的大都以失败告终，导致本来正常的应用也变得异常甚至崩溃，由此可见，分布式微服务架构远不如单体应用可靠。

1. 一个应用裂变成数十个，哪一个有故障根本不知道

单体应用系统最大的优势就是所有代码都在一个进程内运行，调用关系一目了然，想查错很容易，但微服务拆分了之后，就会出现许多问题，最基本的问题就是——某个微服务崩了，完全查不到错。

为什么？你得先明白的是，虽然微服务分布在各处，但他们之间相互调用组成整个业务链，哪一个微服务故障导致了最后业务故障根本没办法快速定位出来，这就非常考验运维的水平了。

查错需要先从应用入口调用开始，找到上游调用方，再找到上上游调用方，再找到上上上游调用方……这个过程非常漫长，根本无法快速定位到问题所在，也无法快速恢复服务。

2. 线上故障无法重现，问题更难解决

业务链中每个微服务涉及的代码不同，其所在的机器配置不同，运行的网络环境也不同，这就导致微服务故障根本无法重现，这给解决线上故障带来了极大的挑战。

为什么线上问题没法重现？因为业务故障的发生是微服务相互作用的结果，需要特定场景才能触发，例如：多个微服务同时出错、服务之间的调用顺序不正确、服务之间的调用数据不一致、第三方服务发生故障、用户机器网络不稳定等等。

3. 分布式事务的难题始终没人能解决

分布式事务是分布式系统中最困难的问题之一，说到底还是因为分布式系统中不同服务之间的数据不一致导致的，现在各个分布式事务解决方案都没有完美的，要么是性能开销大，要么是可靠性无法保障，无论哪一个，都没有单体应用中的事务处理稳定好用。

说到底分布式事务是一把双刃剑，想要用好它，就必须花费巨大的代价，包括：时间、金钱、人力等等，还要做好事倍功半的准备，因为你很可能会发现，维护分布式事务的成本比你想象的要大得多。

做好日志追踪，是比搞微服务更值得做的事

单体应用虽然固有传统，但代码稳定性和系统稳定性更可靠，要我选，我宁可选择代码稳定性和系统稳定性更可靠的单体应用，也不选择花里胡哨的分布式微服务。

但是，对于大型应用系统，尤其是互联网应用系统来说，单体应用也存在一些难以克服的挑战，例如：开发周期长、难以扩展、故障隔离等。

因此，我们需要一种新的架构来解决这些问题，那就是日志追踪。日志追踪是一种分布式系统监控技术，它可以帮助运维人员快速定位和解决分布式系统中的问题。

日志追踪的主要原理是：在分布式系统中的各个服务中记录日志，然后将这些日志收集起来，并进行分析和展示。这样，运维人员就可以通过日志追踪系统快速找到问题的根源，并采取相应的措施来解决问题。

日志追踪系统还可以帮助运维人员了解分布式系统的运行状况，并发现潜在的问题。这样，运维人员就可以在问题发生之前采取措施来防止问题发生。

因此，对于大型应用系统，尤其是互联网应用系统来说，日志追踪是一种非常重要的技术。它可以帮助运维人员快速定位和解决问题，并了解分布式系统的运行状况，发现潜在的问题，防止问题发生。