分布式系统在 Kubernetes 上的进化
本文译自 The Evolution of Distributed Systems on Kubernetes 在 3 月份的 QCon 上，我做了一个关于 Kubernetes 的分布式系统进化的演讲。首先，我想先问一个问题，微服务之后是什么？我相信大家都有各自的答案，我也有我的答案。你会在最后发现我的想法是什么。为了达到这个目的，我建议大家看看分布式系统的需求是什么？以及这些需求在过去是如何发展的，从单体应用开始到 Kubernetes，再到最近的 Dapr、Istio、Knative 等项目，它们是如何改变我们做分布式系统的方式。我们将尝试对未来做一些预测。 现代分布式应用 为了给这个话题提供更多的背景信息，我认为的分布式系统是由数百个组件组成的系统。这些组件可以是有状态的、无状态的或者无服务器的。此外，这些组件可以用不同的语言创建，运行在混合环境上，并开发开源技术、开放标准和互操作性。我相信你可以使用闭源软件来构建这样的系统，也可以在 AWS 和其他地方构建。具体到这次演讲，我将关注 Kubernetes 生态系统，以及你如何在 Kubernetes 平台上构建这样一个系统。 我们从分布式系统的需求讲起。我认为是我们要创建一个应用或者服务，并写一些业务逻辑。那从运行时的平台到构建分布式系统，我们还需要什么呢？在底层，最开始是我们要一些生命周期的能力。当你用任一语言开发你的应用时，我们希望有能力把这个应用可靠地打包和部署、回滚、健康检查。并且能够把应用部署到不同的节点上，并实现资源隔离、扩展、配置管理，以及所有这些。这些都是你创建分布式应用所需要的第一点。 第二点是围绕网络。我们有了应用之后，我们希望它能够可靠地连接到其他服务，无论该服务是在集群内部还是在外部。我们希望其具有服务发现、负载均衡的能力。为了不同的发布策略或是其他的一些原因的我们希望有流量转移的能力。然后我们还希望其具有与其他系统进行弹性通信的能力，无论是通过重试、超时还是断路器。要有适当的安全保障，并且要有足够的监控、追踪、可观察性等等。 我们有了网络之后，接下来就是我们希望有能力与不同的 API 和端点交互，即资源绑定–与其他协议和不同的数据格式交互。甚至能够从一种数据格式转换成另一种数据格式。我还会在这里加入诸如滤光的功能，也就是说，当我们订阅一个主题时，我们也许只对某些事件感兴趣。 你认为最后一类是什么？是状态。当我在说状态和有状态的抽象时，我并不是在谈论实际的状态管理，比如数据库或者文件系统的功能。我要说的更多是有关幕后依赖状态的开发人员抽象。可能，你需要具有工作流管理的能力。也许你想管理运行时间长的进程或者做临时调度或者某些定时任务来定期运行服务。也许你还想进行分布式缓存，具有幂等性或者支持回滚。所有这些都是开发人员级的原语，但在幕后，它们依赖于具有某种状态。你想随意使用这些抽象俩创建完善的分布式系统。 我们将使用这个分布式系统原语的框架来评估它们在 Kubernetes 和其他项目上的变化情况。 单体架构 – 传统中间件功能 假设我们从单体架构以及如何获得这些能力开始。在那种情况下，首先是当我说单体的时候，在分布式应用的情况下我想到的是 ESB。ESB 是相当强大的，当我们检查我们的需求列表时，我们会说 ESB 对所有有状态的抽象有很好的支持。
