聊聊微服务环境中的可观察性和弹性.docxVIP

聊聊微服务环境中的可观看性和弹性 我是 Itiel，Komodor 的首席技术官。今日，我将和你们争辩分布式系统中的变更跟踪，以及变更的阴暗面。Komodor 是一家初创公司，它建立了业内第一个 Kubernetes 原生的毛病排解平台。 我是 DEV Empowerment 理念的信徒，这个理念的内容基本上就是快速前进和“测试左移”。在之前工作中，我曾在 eBay、Forter 和 Rookout 工作。我有很多后端和基础设备相关的阅历。另外，我还是 Kubernetes 的忠实粉丝。 我首先要谈谈为什么要关怀变更，以及哪些事物转变了你的环境。然后，我将尝试缩小范围，谈谈我所说的变更指的是什么，以及在当今的现代化环境中哪些变更具有极大风险。稍后，我将争辩为什么我们很难找出系统中发生了什么变化。我们将争辩变更跟踪的将来。最终，我将供应一些有用的提示，帮你减轻在今日的现代化系统中跟踪变更时遇到的种种苦痛。 为什么关怀变更？ 那么首先，你为什么要关怀变更？我们提到了跟踪以及停机时间和微服务成本之类的东西。这些应当不是什么新颖的话题，但对于某些公司来说，每个小时，甚至可以是每分钟都会消灭问题。 谈到“问题”（issue），它的内涵是很丰富的，从整个系统的停机时间到阶段性的小问题，或者像是某个错误之类的问题都包含在里面。全部大事中有 85％可以追溯到某项系统变更，这意味着组织中某个地方有某人变更了某些内容，于是现在你的应用程序消灭了问题。 我要说的是，大多数毛病排解时间都在关注这个领域，就是找出根本缘由。系统中发生的事情可能可以解释你当前遇到的症状成因。就像我说的那样，这些症状可能是完全停机或你的 UI 中消灭的某个错误。 变更到底是什么？ 我一直在谈变更这个词，但当我提到这个词时我真正的意思是什么？ 我在这次演讲里会特地针对整个系统范围的变更。那么当提到变更和系统变更时，我真正的意思是什么呢？我说的是代码部署之类的东西，首先能想到的就是这个。还有基础设备变更，比如变更 AWS 上的平安组。 还有配置变更，开启关闭一些 flag，暗启动，在 Jenkins、ArgoCD 或其他类似的作业平台中拆分 IO 作业的变更；另外还有 DB、迁移、第三方变更。在这场讲座中，我不会争辩不同的用量或数据变更。 不管怎样，有的时候你的应用程序会停机，由于用户行为发生了变化。或许他们发送了其他类型的数据，或给你的系统发来了巨大的负载。但今日我不会争辩这些问题。就像我说的那样，大多数变更都源于系统变更，而不是这些变更类型。 期望你理解了我的意思，或许你已经晓得这种变更都是很重要的。当你尝试处理一个问题时，你的角色就是侦探，并且基本上，你会尝试找出哪些变更可以解释，试着解释清楚你面对的问题。 为什么很难找到变更？ 那么，为什么我们很难找到系统中发生了哪些变更呢？ 由于今日的现代化技术栈（或者你可以将其称为干草堆）格外简单。Chinmay 就总结得很好。它包括很多第三方服务，例如 Xero、你的云供应商以及数十种不同的 Rest API，你的应用程序需要这些 API 才能正常运转。 更重要的是，我们把过去那些巨大的单体分解为 Lambda、Kubernetes，分成了十几个、一百甚至数千个处处运转的小型微服务。更重要的是，变更频率已经发生了巨大变化，如今的组织（现代化的优秀组织）每天可以部署数百次甚至数千次。 这里我说的只不过是代码变更之类，但就像我们在上一张幻灯片中看到的那样，有很多变更实际上并没有被视为部署。可是它们实际上可以破坏你的整个系统，比如配置变更、标志等等。在过去，担任部署到生产中的人员通常是一些 IT 或运维人员。 可是在今日的现代化系统中，担任部署到生产环境的可能是开发人员。甚至产品经理现在都可以打开和关闭影响客户的各种功能标志。试图了解当今的现代化系统中发生的变更，基本上就像试图争辩一个格外简单的、不断变化的难题，还要弄清楚这个难题五分钟前是什么样子。 我尝试过，试着认真争辩毛病排解面临的三大妨碍之类的东西。一切事物都是相互连接的，而 Epsagon 这样的公司在分布式跟踪方面做了很精彩的成果来应对这一局面。同时，一个微服务的变更可能会影响很多甚至与它不相关的微服务。 或许这种影响波及的甚至不是第一级的连接，而是其次、第三甚至第四级的连接。一项变更可能会对整个系统产生连锁反应。更重要的是，今日的很多变更都是在根本没有任何音频时钟的工具中完成的，或者这些音频时钟真的很难用得上。 AWS 就是一个很好的例子。每次你在 AWS 把握台中变更某项内容时，基本上这里都会有一些云托盘日志被审核。但几乎没有人使用它们，由于它们用起来太简单了。而且其他很多变更（例如直接进入生产的变更）完全未经任何方式或方式的审核。 最终说一下，即便全部变更都经过了审核，