服务网格和应用现代化

集装箱热潮持续不减。 但从应用和架构的角度来看，这可能并不意味着您所想的那样。

人们仍然倾向于将容器等同于微服务。 我所说的等同是指“互换使用”。 

这是一个错误的假设。

您会看到，当今相当大比例的容器实际上被用于部署……现有应用。 据《Container Journal》报道，IDC 的一项调查发现，不到一半（46%）的容器用于新应用。 其余的都在运行现有的应用。 （来源： IDC 调查发现容器推动关键任务应用）对于这种奇怪组合经常被引用的解释是什么？ 现代化。

大量研究和调查表明，作为云原生构建的“新”应用的数量仍然相对较少——根据 Cap Gemini 的研究，这一比例不到五分之一。 Diamanti 最近的一项研究发现，31% 的 IT 领导者正在寻求容器来实现遗留应用的现代化。 这并不奇怪。 我们正处于多代 IT 时代，支持五代不同的应用架构。 

所以，现有的所有这些传统应用程序以及即将出现的更多应用程序最终都可能部署在容器中。

我认为这是一件好事，因为容器和服务网格等相关技术实际上可以帮助现代化工作。

利用服务网格实现监控现代化

如果你不熟悉可观察性，可观察性包括三个普遍接受的支柱，正如 Cindy Sridharan 在“分布式系统可观察性”中详述的那样：

1. 事件日志
2. 指标
3. 踪迹

关于这个主题的内容并不缺乏 - 包括日志生成的大型运营数据和遥测发射所固有的挑战 - 所以我不会在这里介绍它。 可以这么说，为了充分发挥可观察性的潜力，你需要这三者。

还可以说，在这个最新的点 - 痕迹 - 上，现有和遗留的应用处于劣势。 您会发现，大多数设备都没有配备必要的遥测数据来追踪交易从发起到完成的整个过程。 无论应用架构和环境如何，事件日志和指标都更容易生成和获取。 这些是几乎所有网络和应用平台的标准选项。 但是仪器呢？ 这通常意味着嵌入式代码或代理能够查看实时流量。

这是服务网格可以提供的功能之一。

如果你还记得的话，服务网格主要由容器编排环境内的 sidecar 代理组成。 这些代理基本上代理了容器的所有通信（进出）。 通过这样做，这些代理不仅可以扩展服务，还可以提供一个完美的地方来检测流量，从而实现全面的可观察性。 它们可以丰富遍历容器环境的消息，包括详细的标签和其他元数据，使系统能够跟踪和关联跨多个系统和服务的流量。

最棒的是，他们只需对应用进行很少的修改即可实现这一点。 在某些情况下，例如 Java 应用程序，有基于配置的选项来注入适当的功能而无需修改代码。

从现有应用发出跟踪的能力是追求真正可观察性的一项关键能力。 如果现有应用将部署在容器中，请考虑服务网格如何帮助实现其现代化。