主流微服务狂热： 随着采用而增加的挑战

就在短短几年前，微服务还只是开发人员热议的一个新奇话题，他们对这一新兴应用程序架构所呈现的可能性和机遇感到兴奋不已。

今天，甚至我们这些网络人士也在谈论它们，因为正如Lightstep 的最新研究显示，它们已经基本成为企业中的主流。 严重地。 在我们 2018 年的应用交付状况报告中，甚至与网络相关的角色也表示他们希望在容器中提供应用服务。 因此，上述 Lightstep 调查发现，不仅 91% 的受访者使用或计划使用微服务，而且 86% 的受访者预计微服务将在五年内成为默认服务，这并不奇怪。

但这并不是说没有挑战。 事实上，Lightstep 调查中的 99% 受访者表示使用微服务时遇到了挑战。 从回应来看，可以合理地说，使用微服务几乎一切都变得更加困难（有时甚至更加昂贵）。

调查指出，业务和运营方面面临的挑战包括日志聚合成本上升（21%）、不知道如何处理增加的数据（17%），以及解决问题的困难（73%）。

然而，更令人不安的是，研究结果显示，“98% 在微服务环境中遇到问题根本原因的人表示，这会对业务产生直接影响。”  

这是其他地方呼应的关键挑战之一，通常使用术语“可见性”或“可观察性”，取决于您是处于网络侧还是与 DevOps 相关。

两者本质上描述的是相同的功能——能够看到消息从客户端到服务再返回时在网络中传输时发生的情况。 在容器环境中，由于涉及的服务的范围和规模，这尤其具有挑战性。

对于传统的三层 Web 应用程序，您需要跟踪三组日志和三个系统。 采用微服务架构（可能以 Web 和移动客户端都可能使用的 API 为前端），您可能需要跟踪数十或数百种不同的服务。

扩展模型仍然相同 - 我们通过克隆进行水平扩展（向外扩展） - 但容器环境中的规模要大得多。 这就像玩打地鼠游戏，但有一百个洞，而不是十个洞。 至少可以说，弄清楚任何给定交易所采取的路径都是有挑战性的。 尤其是当路径可能已经消失的时候。 毕竟，大多数容器环境的前提是快速失败并替换实例，而不是等待人工干预。

有几种方法可以解决这个挑战。 首要的是协助追踪和排除故障的仪器。 这种方法并不新鲜，但容器环境的不稳定性质使其变得更具挑战性。 尽管如此，在尝试追踪错误或性能问题时，插入跟踪元素（例如具有唯一标识符的自定义 HTTP 标头）可以为操作带来巨大的帮助。 虽然这通常不是本机容器扩展选项的功能，但它是服务网格作为其产品的一部分正在解决的功能。

第二是隔离有问题的微服务的能力，以便操作和开发人员能够检查导致系统故障的状态。 隔离基本上是将有问题的容器从活动环境中移除，因此不再向其发送调用，但保持其活动状态以进行分析和检查。 

虽然没有什么魔杖，但能够在基于微服务的部署中跟踪和隔离容器可以大大降低平均解决时间 (MTTR) 并减少对业务的影响。